Amazon Web Services ブログ

AWS オンラインセミナー – 2016 年 9 月(英語によるセミナー)

今月始めに継続学習のメリットについて説明したブログを公開し、継続学習と昇給、効率性の向上や転職の傾向が減少する関連性について表したインフォグラフィックをご紹介しました。AWS のイノベーションのペースは、いつも何か新しいことを学べるチャンスがあることを意味しています。これを実践するには AWS のオンラインセミナーに参加するのも 1 つの方法です。AWS ではこうしたオンラインセミナーをデザインする上でトレーニングと教育の面を考慮しています。そうすることで、参加者は新しい AWS サービスを使い始める準備を整えることができるほか、既存のサービスを別の方法で活用するための知識を得ることができると考えています。9 月に開催するオンラインセミナーにも素晴らしい内容が揃っています。いつもながら受講は無料ですが、すぐに満席になってしまうため、お早目の登録をお勧めします。開催時間はすべて太平洋標準時、所要時間は 1 時間です。

9 月 20 日

9 月 21 日

9 月 22 日

9 月 26 日

9 月 27 日

9 月 28 日

9 月 29 日

Jeff;

 

PS – 過去のセミナーは AWS オンラインセミナーのアーカイブからご覧ください。

週刊 AWS – 2016 年 9 月 5 日

これは、週刊 AWS 第 3 回目のコミュニティ型エディションです。これを実現するために貢献してくださった 15 名の内外部寄稿者に感謝申し上げます。寄稿を希望される場合は、GitHub の週刊 AWS をご覧ください。

月曜日

9 月 5 日

火曜日

9 月 6 日

水曜日

9 月 7 日

木曜日

9 月 8 日

金曜日

9 月 9 日

土曜日

9 月 10 日

日曜日

9 月 11 日

新しい & 注目のオープンソース

  • s3logs-cloudwatch は S3 サーバーのアクセスログファイルの分析や CloudWatch でバケットのメトリックスを追加する Lambda 関数です。
  • README.md は、AWS 認定の準備に使用する AWS リソースのリストです。
  • RedEye は Redshift のパフォーマンスをモニタリングするユーティリティです。
  • Dockerfile は Docker イメージを作成、EC2 Container Registry にプッシュし Elastic Beanstalk でデプロイします。
  • lambda-contact-form は S3/CloudFront でホストしている静的ウェブサイトの投稿からの連絡に対応します。
  • dust は EC2 の SSH クラスターシェルです。
  • aws-ssh-scp-connector は EC2 インスタンスへの接続を助けるユーティリティです。
  • lambda-comments は Lambda で構築したブログのコメントシステムです。

新しい SlideShare プレゼンテーション

新しい YouTube 動画

新しいお客様の事例

  • MYOB は AWS を使用してインフラストラクチャをスケールし、新しいサービスの要求に対応したり未使用のキャパシティーをシャットダウンすることで 30 パーセントの節約、予約済みの Amazon EC2 インスタンスを使用します。MYOB はオーストラリアやニュージーランドの企業や団体、約 120 万社にビジネス管理ソフトウェアを提供しています。MYOB は予測分析を組み込んだスマートアプリケーションを構築する Amazon Machine Learning や、災害時に新しい AWS 環境を作成する AWS CloudFormation スクリプトなど、さまざまな AWS サービスを使用しています。
  • グローバルにわたる市場浸透を可能にする上で、ゲームサービスに確実な安定性と拡張性を持つ IT ソリューションを必要としていた PATI Games に、AWS はもっとも安全でコスト効率の高いソリューションを提供しました。韓国企業の PATI Games は主に SNS プラットフォームをベースにしたゲーム開発に取り組んでいます。Amazon EC2、Amazon RDS (Aurora)、Amazon CloudFront を含む AWS サービスは、PATI Games の高い信頼性やレイテンシーの短縮を維持し顧客の満足度の向上に協力しています。
  • Rabbi Interactive はライブブロードキャスト、セカンドスクリーンアプリ、何百、何千人というユーザーの投票システムをサポートし、テレビの視聴者がリアルタイムなインタラクションを楽しめるようにするほか、AWS を使用することで月々の運用コストを 60% も削減することを実現しました。イスラエルに拠点を構える同企業は、セカンドスクリーンアプリなどで「ライジングスター」や「ビッグブラザー」などテレビの人気番組で視聴者がインタラクションを楽しめるデジタルエクスペリエンスを提供しています。Rabbi Interactive は AWS パートナーと協力してインタラクティブなセカンドスクリーンプラットフォームを開発しました。

近日開催のイベント

サポート募集

来週をお楽しみに。それまでは、Twitter でフォローして、RSS フィードをサブスクライブしてね。

Amazon Auroraにリーダーエンドポイントが追加されました – 負荷分散と高可用性向上 –

機能向上を行うたびにAmazon Auroraはパワフルかつ簡単にご利用頂けるようになってきました。ここ数ヶ月で、MySQLバックアップからAuroraクラスタを作成する機能や、クロスリージョンレプリケーションアカウント間でのスナップショットの共有フェイルオーバー順を指定可能になったり、他のクラウドやオンプレミス環境のデータベースからAuroraへ移行などを追加してきました。

本日、Auroraのリードレプリカの機能を向上する、クラスタレベルのリードエンドポイントを追加しました。皆様のアプリケーションは今まで通り特定のレプリカに対して直接クエリを実行することが可能です。しかし、今回追加したリードエンドポイントを利用するように変更することで、負荷分散や高可用性といった2つの大きな利点を得ることが出来ます。

Load Balancing – クラスタエンドポイントに接続することでDBクラスタ内のリードレプリカ間でコネクションのロードバランシングが可能になります。これは、リードワークロードを分散することで利用可能なレプリカ間でリソースを効率的に活用することができ、よりよりパフォーマンスを得ることが可能になります。フェイルオーバーの際には、もしアプリケーションが接続しているレプリカがプライマリインスタンスに昇格した場合コネクションは一旦クローズされます。その後、再接続を行うことでクラスタ内の他のレプリカにリードクエリを実行することが可能です。

Higher Availability – 複数のAuroraレプリカをAvailability Zone毎に配置し、リードエンドポイント経由で接続することが出来ます。Availability Zoneの可用性の問題が万が一発生した場合、リードエンドポイントを利用することで最小限のダウンタイムでリードトラフィックを他のレプリカに実行可能です。

 

Find the Endpoint

リーダーエンドポイントはAurora Consoleで確認可能です:

aurora_read_replica_endpoint

この便利な機能は本日からご利用可能です!

Jeff; (翻訳は星野が担当しました。原文はこちら)

MeetMe での S3 データレイクへのリアルタイムデータのストリーミング

本日のゲスト投稿では、MeetMe の Anton Slutsky 氏が、自社のデータレイク用の実装プロセスについて説明します。

Jeff;


Anton Slutsky 氏は、この分野で 20 年近い経験を持つ経験豊富な情報技術者です。ビラノバ大学でコンピューター科学の修士号を取得し、ドレクセル大学で情報科学の博士号を取得しています。

現在のビッグデータシステムには、しばしばデータレイクと呼ばれる構造が含まれています。データレイクという業界用語は、大量の構造化データと非構造化データを吸収し、多数の同時分析ジョブを実行する機能を備えた大規模なストレージおよび処理サブシステムのことです。Amazon Simple Storage Service (S3) はスケーラブルで信頼性が高く、レイテンシーが短いストレージソリューションを低いオペレーションのオーバーヘッドで提供するため、データレイクインフラストラクチャとして現在人気の高い選択肢となっています。ただし、S3 によってペタバイト規模のストレージのセットアップ、設定、管理に関連する多くの問題が解決される一方で、S3 へのデータの取り込みがしばしば課題となっています。これは、ソースデータのタイプ、ボリューム、速度が組織によって大きく異なっているためです。このブログでは、Amazon Kinesis Firehose を使用して MeetMe で大規模なデータ取り込みを最適化、合理化する当社のソリューションについて説明します。これは毎日数百万人のアクティブなユーザーに対応している人気の高いソーシャル検出プラットフォームです。MeetMe のデータサイエンスチームは、1 日あたり約 0.5 TB のさまざまなタイプのデータを、データマイニングタスク、ビジネス向けレポート、高度な分析に公開するような方法で収集、保存する必要がありました。チームはターゲットのストレージ機能として Amazon S3 を選択し、大量のライブデータを堅牢で信頼性が高く、スケーラブルで運用費用が低い方法で収集するという課題に直面していました。ここでの全体的な目的は、可能な限り低いオペレーションのオーバーヘッドで、AWS データインフラストラクチャに大量のストリーミングデータをプッシュするプロセスをセットアップすることでした。Flume、Sqoop など多くのデータ取り込みツールが現在入手可能ですが、当社は、その自動的なスケーラビリティと伸縮性、設定と管理の容易さ、それに S3、Amazon RedshiftAmazon Elasticsearch Service など他の Amazon サービスとの即座の統合機能により、Amazon Kinesis Firehose を選択しました。

ビジネス価値 / 正当化
多くのスタートアップ企業と同じように、MeetMe は最大のビジネス価値をできるだけ低いコストで提供することに焦点を置いています。したがって、データレイクについては次のような目標がありました。

  • 効果的な意思決定のための高レベルなビジネスインテリジェンスでビジネスユーザーに力を与える
  • 収益を生み出す洞察の発見に必要なデータをデータサイエンスチームに提供する。

Scoop や Flume といったよく使われているデータ取り込みツールを検討した結果、データサイエンスチームはデータ取り込みプロセスをセットアップ、設定、調整、維持するためにフルタイムの BigData エンジニアを追加する必要があり、冗長性のサポートを可能にするために、エンジニアリングの時間がさらに必要であると予測されました。このようなオペレーションのオーバーヘッドは MeetMe でのデータサイエンスの費用を増やし、全体的な速度に影響する不要な範囲をチームにもたらします。Amazon Kinesis Firehose サービスにより多くの運用面の懸念が軽減され、それによりコストも削減されました。それでもある程度の社内の統合開発は必要でしたが、データコンシューマーのスケーリング、管理、アップグレード、トラブルシューティングは Amazon によって行われるため、データサイエンスチームの規模と範囲は大幅に減りました。

Amazon Kinesis Firehose Stream の設定
Kinesis Firehose には、複数の Firehose システムを作成する機能があり、それぞれの対象を異なる S3 の場所、Redshift テーブル、または Amazon Elasticsearch Service インデックスにすることができます。当社の場合、主要な目標はデータを S3 に保存し、将来的には上記のような他のサービスも検討するというものでした。Firehose の配信ストリームのセットアップは 3 ステップのプロセスです。ステップ 1 では、送信先タイプを選択する必要があります。これにより、データの統合先を S3 バケット、Redshift テーブル、または Elasticsearch インデックスに定義できます。当社ではデータを S3 に配置することを希望したため、統合先オプションとして “Amazon S3″ を選択しました。S3 を統合先として選択すると、Firehose でその他の S3 オプション (S3 バケット名など) が求められます。Firehose のドキュメントで説明したように、Firehose では自動的にデータを日時で整理し、”S3 プリフィックス” 設定が、特定の Firehose ストリームオブジェクトのすべての S3 キーの前に付加されるグローバルプレフィックスとなります。プレフィックスは、データを使用中のライブストリームにおいてさえ後日に変更できるため、最初から命名規則について深く考える必要はまったくありません。

プロセスの次のステップはストリーム設定です。ここで、さまざまなデフォルト値を上書きし、他の意味ある値を指定することができます。たとえば、非圧縮のデフォルト値の代わりに GZIP 圧縮を選択すると、S3 ストレージのフットプリントを大幅に減らし、それにより S3 のコストを減らすことができます。データ暗号化を有効にすると、保管時のデータが暗号化されます。これは機密データにとって重要です。

1 つの重要な注意点として、圧縮アルゴリズムの選択により、ストリームオブジェクトのファイル名 (S3 キー) に影響があります。したがって、これらの設定は後からライブストリームで変更することができるものの、処理スクリプトで発生する可能性がある問題を回避するため、最初から圧縮/暗号化手法を決定することが賢明かもしれません。

Amazon Kinesis Firehose Limits」で述べたように、 Kinesis Firehose にはデフォルトのスループットクォータのセットがあります。これらのクォータを超えると、Firehose は “ServiceUnavailableException: Slow down.” というエラーメッセージで応答し、データを削除します。したがって、データ損失を避けるには、個別のスループット要件を予測することが重要です。これらの要件がデフォルトのクォータを超える可能性が高い場合、制限で説明されているように限度の引き上げリクエストを送信することで、追加のスループットをリクエストできます。最終ステップ (ここには示しません) では、目的の設定を確認し、ストリームを作成します。

アップロードプロセスのセットアップ
MeetMe では、RabbitMQ が、システムを通過するほとんどのデータのサービスバスとして機能しています。したがって、データ収集のタスクのほとんどの部分は、大量の RabbitMQ メッセージを使用し、Firehose ストリームを利用してそれらを S3 にアップロードすることになります。これを達成するため、軽量の RabbitMQ コンシューマーを開発しました。RabbitMQ コンシューマーは他の場所 (Flume など) に実装されていますが、Firehose API との統合を可能にするため、独自のバージョンを開発することにしました。

Firehose には、データをアップロードするために、単一のレコードとバルクレコードという 2 つの方法があります。単一のレコードの手法では、各個別のレコードが Amazon Firehose API フレームワークオブジェクトにパッケージ化され、各オブジェクトは HTTP/Rest を通じて Firehose エンドポイントにシリアル化されます。この手法は一部のアプリケーションにとって適切な場合がありますが、当社はバルク API 方法を使用することで、より良いパフォーマンスを達成しました。バルク方法では、最大 500 レコードを 1 つのリクエストで Firehose にアップロードできます。メッセージのバッチをアップロードするため、軽量 RabbitMQ コンシューマーは小規模な内部バッファを維持します。これは事前定義されたプロセッサスレッドのセットにより、可能な限り多く Firehose にシリアル化されます。以下にコードを示します。

new Thread(new Runnable()
{
  public void run()
  {
    logger.info("Kinesis ライタースレッドが開始しました。  レコードの処理を待機しています...");
    while(true)
    {
      try
      {
        if(!recordsQueue.isEmpty())
        {
           if(logger.isDebugEnabled())
             logger.debug("現在のバッチを AWS にアップロードしています: "+recordsQueue.size());
        
           List<MMMessage> records = recordsQueue;
           recordsQueue = new CopyOnWriteArrayList<MMMessage>();
        
           final int uploadThreshold = 499;
        
           List<Record> buffer = new ArrayList<Record>(uploadThreshold);
        
           for(int i = 0; i < records.size(); i++)
           {
             // 内部キューから独自のメッセージオブジェクトを取得します
             MMessage mmmessage = records.get(i);
                 
             // バイト数を取得します
             String message = new String(mmmessage.body, "UTF-8");
                 
             // データの新しい行とタブ文字を確認し
             // Hadoop/Spark 処理行ベースの処理の問題を
             // 後で回避します
             message = CharMatcher.anyOf("\n").replaceFrom(message, "\\n");
             message = CharMatcher.anyOf("\t").replaceFrom(message, "\\t");
 
             // Amazon Firehose API ラッパーでメッセージバイトをラップします    
             Record record = new Record().withData(ByteBuffer.wrap(message.getBytes()));
 
             buffer.add(record);
                 
             // 現在のバッファが十分に大きい場合、
             if(buffer.size() == uploadThreshold)
             {
               // Firehose に送信し
               uploadBuffer(buffer);
               // 新しいバッファをインスタンス化します
               buffer = new ArrayList<Record>(uploadThreshold);
             }
           }
           // 最後のバッファのアップロードを忘れないでください!
           uploadBuffer(buffer);                                
         }
       }
       catch(Exception e)
      {
        logger.error("Error in sending to Kinesis:"+e.getMessage(), e);
      }
    }
  }
}).start();

uploadBuffer メソッドは、バルクアップロード Firehose API に対するシンプルなラッパーです。

private void uploadBuffer(final List<Record> buffer)
{
  // 新しいリクエストオブジェクトを作成します
  PutRecordBatchRequest request = new PutRecordBatchRequest();
  // ストリーム名を指定します
  request.setDeliveryStreamName("MEETME_STREAM");
        
  // データバッファを設定します
  request.setRecords(buffer);
 
  // Firehose への送信を試みます
  PutRecordBatchResult result = getAmazonClient().putRecordBatch(request);
        
  // 常に失敗について確認してください!
  Integer failed = result.getFailedPutCount();
  if (failed != null && failed.intValue() > 0)
  {
    // 失敗がある場合、その原因を見つけます
    logger.warn("AWS upload of [" + buffer.size() + "] resulted in " + failed + " failures");
                 
    // 応答を調べ、さまざまな種類の失敗がないかどうか確認します
    List<PutRecordBatchResponseEntry> res = result.getRequestResponses();
    if (res != null)
    {
      for (PutRecordBatchResponseEntry r : res)
      {
        if (r != null)
        {
          logger.warn("Report " + r.getRecordId() + ", " + r.getErrorCode() + ", " + r.getErrorMessage()
                      + ", " + r.toString());
        }
        else
        {
          logger.warn("Report NULL");
        }
      }
    }
    else
    {
      logger.warn("BatchReport NULL");
    }
  }
}

Firehose ストリームのモニタリング
Firehose ストリームをセットアップし、内部コンシューマープロセスがデータの送信を開始した後の一般的なタスクは、データフローのモニタリングを試みることです。データフローに注意する理由として、データボリュームの考慮事項、エラー状態の可能性、失敗の検出などがあります。Amazon Firehose では、モニタリングは Amazon CloudWatch を利用して達成されます。一般的な配信ストリームメトリックスは、各 Firehose ストリーム設定の [Monitoring] タブで表示でき、その他のメトリックスは CloudWatch コンソールから表示できます。

AWS は広範なモニタリング機能を提供していますが、当社の経験では、内部データプロデューサーログでエラーを慎重にモニタリングするのが重要であることがわかっています。syslog 機能、Splunk、およびその他のログモニタリングツールを使ってこのように注意深いモニタリングを行うことで、特定のエラーを検出して修正し、個別のレコードの失敗数を許容できるレベルにまで減らすことができました。さらに、内部ログのモニタリングにより、ボリュームが急速に Firehose のデフォルトのスループットクォータを超えていることを早期に認識できました (上記を参照)。

Anton Slutsky、データサイエンス担当ディレクター、MeetMe

Yemeksepeti: サーバーレスアーキテクチャへの当社の移行

AWS コミュニティヒーローの Onur Salk 氏から、自社のサーバーレスアーキテクチャへの移行をどのように支援したかについて、次のようなゲスト投稿が寄せられました。

Jeff;


私は AWS コミュニティヒーローAWS 認定ソリューションアーキテクト – プロフェッショナルトルコの AWS ユーザーグループの主催者である Onur Salk と申します。私はヒーローとして、AWS の経験と知識を個人ブログやコミュニティでの出会いを通じて共有していきたいと思っています。本日は、当社 Yemeksepeti の事例と、サーバーレスアーキテクチャへの移行についてお話したく思います。

Yemeksepeti の事例
Yemeksepeti はトルコ最大のオンライン注文企業です。ユーザーは、提携先のネットワークレストランから食材の注文を行うことができ、手数料はかかりません。Yemeksepeti では、スケーラブルでパフォーマンスと費用効率の高い、世界中に分散したサービスをセットアップする必要がありました。当社は、サーバーレスアーキテクチャを設計することで、サーバーの管理について心配することなく、チームから多くの運用面の負担を取り除くことができると考えています。つまり、コードの大規模な実行に集中できるということです。

Yemeksepeti.com では、約 4 年前に Joker と呼ばれるリアルタイムの割引システムを開発しました。このシステムの目的は、レストランに関して通常ないような割引を顧客に提案することです。元の Joker プラットフォームは .NET で開発され、その REST API を使ってウェブサイトやモバイルデバイスと統合されました。世界 34 か国で営業している関連会社も顧客にリアルタイムの Joker 割引を提供できるように、関連会社に対してプラットフォームの API を公開することを求められました。

最初はコードを共有し、関連会社にアプリケーションを統合させることを考えました。ただし、他のほとんどの国では異なる技術スタック (プログラミング言語、データベースなど) を使用していました。当社のコードを使用することで、最初は関連会社による開発が迅速化する可能性がありますが、不慣れなシステムを管理しなければなりません。実装がより簡単で、管理費用がより安い統合方法を見つける必要がありました。

当社の要件
これはグローバルなプロジェクトであり、次の 5 つの重点領域がありました。

  • 管理の容易さ
  • 高可用性
  • スケーラビリティ
  • 複数のリージョンでの使用
  • 費用のメリット

複数の異なる処理モデルについてこれらの重点領域を評価した結果を、次のマトリックスに示します。

管理の容易さ 高可用性 スケーラビリティ 複数のリージョンでの使用 費用のメリット
IaaS

一部の EC2 インスタンスにより Microsoft Windows Server で IIS を実行し、RDS DB インスタンスに接続できた。
いいえ。サーバーの管理が必要。 はい。別の AZ にサーバーを分散できる。 はい。Auto Scaling を使用できる はい。AMI を使用し、リージョン間でコピーできる 部分的。EC2 インスタンスの実行にはライセンス料と費用が必要。
PaaS

AWS Elastic Beanstalk を使用できた。
部分的。サーバーの管理が必要。 はい。別の AZ にサーバーを分散できる。 はい。Auto Scaling を使用できる。 はい。環境設定、AMI などを使用できる。 部分的。EC2 インスタンスの実行にはライセンス料と費用が必要。
FaaS

AWS Lambda を使用できた。
はい。AWS がサービスを管理。 はい。すでに高い可用性を確保している はい。規模を問わずパフォーマンスを発揮する はい。設定を簡単にエクスポート/インポート/アップロードできる。 はい。ライセンス不要で従量課金制である。

当社は Faas (Functions as a Service) を使用することに決定しました。以下のサービスを使って、Europe (Ireland) リージョンでプロジェクトを開始しました。

アーキテクチャ
当社のアーキテクチャを次に示します。

Amazon VPC: 当社は Amazon VPC を使用してプライベートネットワークでリソースを起動します。

Amazon API Gateway: 開発段階中、Europe (Ireland) リージョンでサービスの開発を開始しました。その当時、AWS Lambda は Europe (Frankfurt) で利用できませんでした。当社は 2 つの API を作成しました。1 つはウェブ統合用、もう 1 つは管理インターフェイス用です。JSON ウェブトークン (JWT) を使用したカスタム認証により、API 用にトークンベースの認証を可能にしました。マッピングテンプレートを使用して変数を Lambda 関数に渡しました。

開発段階では、各 API に対してテストステージのみがありました。

本稼働段階中に、AWS Lambda がフランクフルトで利用可能になりました。そこにサービスを移動し、トルコから低レイテンシーのアクセスのメリットを受けることにしました。API Gateway Export API 機能を使用して設定を Swagger 形式でエクスポートし、それをフランクフルトにインポートしました (インポート前に、エクスポートされたファイルのリージョン定義を eu-central-1 に変更しました)。その後、実稼働ステージを作成し、ステージ変数を使用して Amazon RDS インスタンスのデータベース定義 (ホスト、ユーザー名など) をパラメーター化しました。また、カスタムドメイン名を使用したいと考えました。ドメイン用に SSL 証明書を購入した後で、Amazon API Gateway コンソールでカスタムドメイン名を作成し、CloudFront ディストリビューション名のエイリアスを作成しました (Amazon API Gateway はバックグラウンドで Amazon CloudFront を使用します)。最後に、API コール、レイテンシーなどについて Amazon CloudWatch のログ記録を有効にするために IAM ロールを作成しました。

Get_Joker_offer リソースのメトリックス:

AWS Lambda: 開発段階中に、Python を使用してサービスを開発し、CloudWatch Events Lambda トリガーを使用して API メソッドとスケジュールされたタスクを統合するために、65 個の関数を作成しました。Lambda VPC の統合が実稼働段階中に利用可能になったため、関数をフランクフルトリージョンにアップロードし、VPC と統合しました。

Get_joker_offer Lambda 関数の呼び出しカウント (ピークは昼食時および夕食時に一致します (空腹時)):

Amazon RDS: 開発段階中に、Amazon RDS for PostgreSQL の使用を選択しました。サービスをテストするために、1 つの AZ RDS インスタンスを作成しました。実稼働段階中に、API と関数をフランクフルトに移行したため、データベースを移動する必要がありました。インスタンスのスナップショットを作成し、RDS のスナップショットのコピー機能を使用して、データベースを正常に移動しました。VPC で、実稼働用のマルチ AZ インスタンスと、テスト目的のシングル AZ インスタンスの 2 つのインスタンスを起動しました。API ステージ変数で、ステージングを適切なインスタンスにマッピングするため、RDS インスタンスのエンドポイント名を定義しました。また、両方のインスタンスで自動バックアップを有効にしました。Amazon S3: Joker プラットフォームには、Joker のオファーを管理および報告するための管理パネルがあります。この管理インターフェイスをホストするため (基本的に Single Page Application (SPA) と AngularJS)、Amazon S3 の静的ウェブサイトホスティング機能を使用しました。すべてのロジックと機能は Lambda で実行されているメソッドによって提供されているため、管理インターフェイス用のサーバーは必要ありませんでした。

Amazon CloudWatch: 当社はこのサービスを使用して重要なアセットの使用量をモニタリングし、何かあった場合にアラートを受け取っています。プロダクションデータベースの CPU、接続カウント、重要な API レイテンシー、および関数のカウントと継続時間をモニタリングするためにカスタムダッシュボードを作成しました。Python コードで、CloudWatch の各内部メソッドの継続時間をログに記録し、パフォーマンスを追跡してボトルネックを発見します。

CloudWatch ダッシュボードを次に示します。

Amazon ElasticSearch: 開発段階中に、Amazon ES への Cloudwatch ログストリーミングがアイルランドリージョンで利用可能になりました。この機能を使用して、コードから生成するログの他のメトリックスをモニタリングするため、Kibana ダッシュボードを作成しました。Amazon ES がフランクフルトリージョンで利用可能になったらすぐに、再びこれを使用する予定です。

初期の結果
Joker システムは、国の小規模なリージョンに対して、パイロット運用として現在は実稼働状態になっています。次の図からわかるように、注文数の増加は前途有望です。当社は、サーバーレスアーキテクチャを利用することで、オペレーティングシステムと依存関係をインストール、管理する必要がなくなりました。Amazon API Gateway、AWS Lambda、Amazon S3、および Amazon RDS を使用することで、当社のアーキテクチャを可用性の高い環境で実行できます。マスタースレーブレプリケーション機能やサードパーティーのツールについて学習し、管理する必要がありません。サービスでより多くのリクエストを受け取ると、AWS Lambda がより多くの Lambda インスタンスを追加し、任意のスケールで実行されます。実稼働に移行する前のように、AWS サービスの機能を使用してサービスを別のリージョンにコピーすることができます。最後に、サーバーは一切実行していないので、サーバーレスアーキテクチャの費用のメリットを活用できます。Joker を通じて行われたオーダー数を次に示します。

次のステップ
このサービスが Delivery Hero Holding の 34 の関連会社すべてに拡大されることを願っています。サービスをグローバルに展開する際に、他の AWS リージョンにデプロイします。会社に最も近いリージョンを選択する予定です。費用を最適化するため、RDS インスタンス用のリザーブドインスタンスを購入します。また、内部メソッドの継続時間をモニタリングし、コードをリファクタリングおよび最適化して、Lambda 関数の実行時間を減らすことができます。当社はクラウドの将来は FaaS であると考えています。他の機能、サービス、関数が利用可能になったときにさらに試したいと思っています。AWS コミュニティヒーローとして、トルコの AWS ユーザーグループと Yemeksepeti の事例を共有することを楽しみにしています。みなさまのサーバーレスアーキテクチャの検証と利用のお手伝いができればと考えております。– Onur Salk

AWS SDK for C++ – 本稼働環境で使用する準備ができました

1 年近くに及ぶ開発者からのフィードバックと貢献により、バージョン 1.0 の AWS SDK for C++ が利用可能になりました。本稼働環境での使用をお勧めします。SDK はセマンティックバージョニングに従っているため、バージョン 1.0 から、任意のバージョン 1.x の C++ SDK を信頼することができ、アップグレードによってビルドが破損することはありません。

SDK のデベロッパープレビューについて寄せられたフィードバックに基づいて、いくつかの重要な変更や機能強化を行いました。

  • セマンティックバージョニング – SDK はセマンティックバージョニングに従っています。バージョン 1.0 から、1.x シリーズ内のアップグレードによってビルドが破損することはありません。
  • Transfer Manager – 元の TransferClient は機能が強化された新しい TransferManager インターフェイスへと進化しました。
  • ビルドプロセス – CMake ビルドチェーンは、プラットフォームのデフォルト値を簡単に上書きできるよう機能が強化されました。
  • 簡略化された設定 – 実行時に SDK 全体の設定オプションを簡単に設定できるようになりました。
  • 暗号化 – SDK には、サポートされるすべてのプラットフォームで対称暗号化のサポートが含まれるようになりました。
  • NuGet – 現在、SDK は NuGet を通じて入手できます (詳細については、「AWS SDK for C++ Now Available via. NuGet」を参照してください)。
  • Fixes – 1.0 コードベースには数多くのバグ修正とビルドの機能強化が含まれています。

さらに、AWS での C++ の開発をさらに簡単で安全にするための、より高いレベルの API を間もなく公開します。機能が強化された新しい TransferManager API を使用したコードサンプルを次に示します。

#include <aws/core/Aws.h>
#include <aws/s3/S3Client.h>
#include <aws/transfer/TransferManager.h>

static const char* ALLOC_TAG = "main";

int main()
{
    Aws::SDKOptions options;
    Aws::InitAPI(options);

    auto s3Client = Aws::MakeShared<Aws::S3::S3Client>(ALLOC_TAG);
    Aws::Transfer::TransferManagerConfiguration transferConfig;
    transferConfig.s3Client = s3Client;

    transferConfig.transferStatusUpdatedCallback =
       [](const TransferManager*, const TransferHandle& handle)
       { std::cout << "Transfer Status = " << static_cast(handle.GetStatus()) << "\n"; }

    transferConfig.uploadProgressCallback =
        [](const TransferManager*, const TransferHandle& handle)
        { std::cout << "Upload Progress: " << handle.GetBytesTransferred() << " of " << handle.GetBytesTotalSize() << " bytes\n";};

    transferConfig.downloadProgressCallback =
        [](const TransferManager*, const TransferHandle& handle)
        { std::cout << "Download Progress: " << handle.GetBytesTransferred() << " of " << handle.GetBytesTotalSize() << " bytes\n"; };
    
    Aws::Transfer::TransferManager transferManager(transferConfig);
    auto transferHandle = transferManager.UploadFile("/user/aws/giantFile", "aws_cpp_ga", "giantFile", 
                                                     "text/plain", Aws::Map<Aws::String, Aws::String>());
    transferHandle.WaitUntilFinished();
     
    Aws::ShutdownAPI(options);
    return 0;
}

詳細については、AWS SDK for C++ ホームページおよび AWS 開発者ブログ (C++) を参照してください。

引き続きフィードバックをお寄せください
AWS SDK for C++ は本稼働環境で使用する準備ができたため、お客様のご意見やご感想、使用事例、さらにより良くするための方法などをお寄せください。改善点について、お気軽に問題を登録いただくか、プルリクエストを送信してください。

Jeff;

週刊AWS – 2016 年 8 月 29 日

これは、AWS Week in Review の 2 番目のコミュニティ型エディションです。 この実現に貢献してくれた 13 名の外部寄稿者に特に感謝します。 寄稿を希望される場合は、GitHub の AWS Week in Review をご覧ください。 関連するコンテンツの追加は、快適なご自分のウェブブラウザから迅速かつ簡単に行えます。 念のためですが、他者によって書かれたコンテンツを追加することもまったく問題ありません。 目標は、よく言われるように、すべてをキャッチすることです。

月曜日

8 月 29 日

火曜日

8 月 30 日

水曜日

8 月 31 日

木曜日

9 月 1 日

金曜日

9 月 2 日

新しい & 注目のオープンソース

  • apilogs は、API Gateway および Lambda サーバーレス API によって生成された CloudWatch ログイベントを集計、ストリーミング、フィルタリングするのを補助するコマンドラインユーティリティです。
  • MoonMail は、完全に Lambda / SES による、E メールマーケティングツールです。

新しい SlideShare プレゼンテーション

新しいお客様事例

  • Bustle は、AWS Lambda を使用して、リアルタイムでウェブサイトにより生成された大量のデータを処理し、チームが迅速にデータ主導の意思決定を行えるようにしています。 Bustle.com は女性の望みに応えるニュース、エンターテインメント、ライフスタイル、ファッションのウェブサイトです。
  • Graze は、そのインフラストラクチャを含め、俊敏性を維持することにより顧客エクスペリエンスを向上させ続けています。 同社はウェブサイトを通じて、および英国の小売業者を経由して健康的なスナックを販売しています。 顧客向けウェブサイト、および工場のフロアからビジネスインテリジェンスまでそのすべての内部システムを含むすべてのインフラストラクチャを、AWS で実行しています。
  • Made.com は、ダウンタイムなしで記録的な販売期間をサポートするために、AWS に移行しました。 同社は、家具デザイナーを直接消費者にリンクするウェブサイトを提供します。 Amazon EC2、Amazon RDS、および Auto Scaling グループなどのサービスを使用して、AWS で e コマースプラットフォーム、ウェブサイト、および顧客向けのアプリケーションを実行しています。
  • ソニー DADC ニューメディアソリューションズ (NMS) では、AWS の全面活用により、毎月数十万時間分のビデオコンテンツを配信し、データ分析をスピンアップし、ソリューションを数か月ではなく数日単位で提供し、ハードウェア更新にかかるコストを数百万ドル節約しています。 同社は、世界中の映画スタジオ、テレビ放送局、他のプロバイダにコンテンツを配信および提供しています。 NMS は、AWS クラウド上で、コンテンツ配信プラットフォーム、ブロードキャストプレイアウトサービス、ビデオアーカイブを実行しています。
  • Upserve では Amazon Machine Learning を使用して、100 以上の学習モデルを迅速に開発および訓練し、リアルタイムでレストランの売上高およびメニューアイテムのデータをストリームし、レストラン経営者が毎晩のビジネスを予測できるようにしています。 同社は米国中の数千人のレストランの経営者にオンライン決済および分析ソフトウェアを提供しています。Upserve は、そのシフト準備アプリケーションを使って予測分析を提供するために Amazon Machine Learning を使用しています。

近日開催のイベント

サポート募集

来週をお楽しみに。それまでは、Twitter でフォローしてください。また、RSS フィードをご購読いただき、コンテンツを投稿してください。

Jeff;

Amazon Auroraアップデート – Parallel Read Ahead, Faster Indexing, NUMA Awareness

Amazon Aurora はAWSサービスの中で最も速く成長するサービスになりました!

リレーショナルデータベースをクラウドに適したデザインにすることで(Amazon Aurora – Amazon RDSに費用対効果の高いMySQL互換のデータベースが登場!! の記事もご覧ください)、Aurora は大きなパフォーマンス改善や、64TBまでシームレスにスケールアップするストレージ、堅牢性・可用性の向上を実現しています。AuroraをMySQL互換にデザインすることによって、お客様は既存のアプリケーションの移行や新しいアプリケーションの構築を簡単に行って頂けています。

MySQL互換を保ちながら、そしてクラウドネイティブなAuroraアーキテクチャを活用することでAuroraには多くのイノベーションを加えられると考えています。

本日、3つのパフォーマンスを改善する新機能をAuroraに追加しました。それぞれの機能は、AWSをご利用の多くのお客様の一般的なワークロードでAuroraのパフォーマンスを改善するように設計されました。

 

Parallel Read Ahead – レンジ select、 フルテーブルスキャン、テーブル定義の変更やindex作成が最大5倍高速に

Faster Index Build – indexの作成時間が約75%短縮

NUMA-Aware Scheduling – 2つ以上のCPUが搭載されているデータベースインスタンスをご利用の場合、クエリキャッシュからの読み込みやバッファキャッシュからの読み込みが速くなり、全体的なスループットが最大10%向上

 

詳細をご紹介します

Parallel Read Ahead

MySQLで利用されているInnoDBストレージエンジンは行やindex keyを利用するストレージ(ディスクページ)を管理します。これはテーブルのシーケンシャルスキャンの高速化や新しく作成されたテーブルに効果的です。しかし、行が更新・作成や削除されるにつれて、ストレージがフラグメントされることによって、ページは物理的にシーケンシャルではなくなってきます。そして、スキャン性能が大きく低下します。InnoDBのLinear Read Ahead機能はページが実際に利用されるまでメモリ内で64ページまでまとめることでフラグメントに対処しています。しかし、エンタープライズスケールのワークロードでは、この機能は有効な性能向上にはなりません。

今日のアップデートでは、Auroraは多くの状況で賢くこのような状況を扱う機能をご提供します。Auroraがテーブルをスキャンする際に、論理的に判断し、並列で追加のページをプリフェッチします。この並列プリフェッチはAuroraのレプリケーションが行われているストレージ(3つアベイラビリティゾーンにそれぞれ2つずつのコピー)で優位性を発揮し、データベースキャッシュ中のページがスキャンオペレーションに関連しているかを判断するのに役立ちます。

結果として、レンジselect、フルテーブルスキャン、ALTER TABLE そして、index作成を以前のバージョンと比較して最大5倍高速に行えるようになりました。

Aurora 1.7(詳細はこの後の情報をご覧ください)にアップグレードすることで、すぐにこのパフォーマンス改善をご体験頂けます。

 

Faster Index Build

プライマリー、セカンダリーインデックスをテーブルに作成する時、ストレージエンジンは新しいキーを含んだ木構造を作成します。この処理は、多くのトップダウンのツリーサーチや、より多くのキーの増加に対応するためにツリーの再構築によりページ分割が伴います。

Auroraはボトムアップ戦略でツリーを構築します。リーフを最初に作成し、必要な親ページを追加していきます。この機能によりストレージ内の移動を軽減し、加えて各ページが一旦全て埋まるためページを分割する必要がなくなります。

この変更により、テーブルのスキーマによりますがindexの追加やテーブルの再構築が最大4倍高速になります。例として、Auroraチームが以下の様なスキーマでテーブルを作成し100億行を追加し5GBののテーブルを作製しました:

 

create table test01 (id int not null auto_increment primary key, i int, j int, k int);

そして4つのindexを追加しました

alter table test01 add index (i), add index (j), add index (k), add index comp_idx(i, j, k);

db.r3.largeインスタンスで、このクエリの実行時間が67分から25分になりました。db.r3.8xlargeでは、29分から11.5分に短縮されました。

これは新機能でプロダクション環境以外でのテストをお勧めします。利用するには、Aurora 1.7へアップグレードを行ない DB Instance Parameter group(詳細は DB Cluster and DB Instance Parametersをご覧ください)でaurora_lab_mode1に設定します。

rds_aurora_set_lab_mode

Auroraチームはこのパフォーマンス改善に対するみなさまからのフィードバックを楽しみにしています。お気軽にAmazon RDS Forumへ投稿をお願いします。

 

NUMA-Aware Scheduling

最も大きいデータベースインスタンス(db.r3.8xlarge) は2つのCPUを搭載しNUMA(Non-Uniform Memory Access)と呼ばれる機能を持っています。このタイプのシステムでは、メインメモリの各区画は各CPUに直接効率的にアクセス出来ます。残りのメモリは少し非効率なCPU間のアクセス経路を介してアクセスします。

Auroraはこの不均等なアクセス時間を活用するためにスケジューリングスレッドのjobを効率的に扱うことが可能になりました。スレッドは他のCPUに接続されている非効率なメモリへのアクセスを気にする必要がありません。結果として、クエリキャッシュやバッファキャッシュを大量に利用する様なCPUバウンドな操作で最大10%性能が向上しました。パフォーマンス向上は同じデータベースインスタンスに数百または数千接続を行っているときに顕著に発揮します。例として、Sysbench oltp.lua ベンチマークで570,000 reads/secondから625,000 reads/secondに向上しました。このテストではdb.r3.8xlarge DBインスタンスで以下のパラメータを利用して行いました。

  • oltp_table_count=25
  • oltp_table_size=10000
  • num-threads=1500

Aurora 1.7にアップグレードすることで、すぐにこのパフォーマンス改善をご体験頂けます。

 

Upgrading to Aurora 1.7

新しく作成されたDBインスタンスはAurora 1.7で自動的に起動します。既に起動しているDBインスタンスでは、update immediately か during your next maintenance windowを選択することでインストールが可能です。

以下のクエリでAurora 1.7で起動しているか確認出来ます。

mysql> show global variables like “aurora_version”;
+—————-+——-+
| Variable_name | Value |
+—————-+——-+
| aurora_version | 1.7 |
+—————-+——-+

Jeff (翻訳は星野が担当しました。原文はこちら)

 

インフォグラフィック – トップ 5 の調査結果: Global Knowledge の IT スキルおよび給与レポート

ビジネスをクラウドに移行する顧客が増えるに伴い、市場では、AWS でアプリケーションとインフラストラクチャを設計、デプロイ、運用できる熟練した IT プロフェッショナルの需要が高まっています。IT 認定資格は、技術的熟練度と職務遂行能力を検証するための究極の判断基準と考えられています。認定資格の取得は、IT プロフェッショナルにとって、キャリアアップにつながることがよくあります。個人がキャリアアップに目を向け、顧客が使用施設に関する知識とスキルを組織内に構築するに伴い、IT 認定資格の取得へと導くトレーニングがより重要になっています。

Global Knowledge は最近、2016 年 IT スキルおよび給与レポートをリリースしました(利用には登録が必要)。このレポートは、Global Knowledge の第 9 回年次 IT スキルおよび給与調査(この種では最大規模)における、北米の 10,000 人以上の IT およびビジネスプロフェッショナルからの回答に基づいています。Global Knowledge の調査結果では、トレーニングの重要性が明らかになり、AWS 認定資格取得者の価値も示されました。

トップ 5 の調査結果
以下に、今年のレポートで際立っていたトップ 5 の調査結果を取り上げます。

  1. 回答者の 4 分の 3 は、新しいスキルを構築するために何らかの形式の専門的能力開発トレーニングに参加したと答え、その半分は、キャリアの証明やスペシャリスト試験の準備が主な動機だと答えました。
  2. 総じて、IT プロフェッショナルの 59% は、何らかの形式の認定資格取得トレーニングに参加中か、今年中に参加予定です。
  3. 昨年に認定資格取得トレーニングに参加した回答者の 73% が、そのトレーニングにより仕事の有効性が上がったと答えました。
  4. 大幅な昇給(11% 以上)があったと報告した回答者の 21% は、付加価値として開発された新しいスキルがその要因だと答えました。
  5. トレーニングプランのある組織の従業員は、会社を辞める可能性が低いと答えました(トレーニングプランのない組織では 73%、あるかどうかは不明な組織では 69% に対して、そのようなプランのある組織では 78%)。

これらは実に興味深い調査結果です。以下に、その概要をインフォグラフィック形式で示します(ご自由にお使いください)。

AWS トレーニング & 認定資格
参考までに、AWS には現在、ソリューションアーキテクト、システムオペレーション管理者、開発者、開発オペレーションエンジニアの職務を対象とした、5 つの認定資格があります。AWS はまた、一連のテクニカルトレーニングコースなど、試験の準備に役立つ手段を提供しています。受講希望がセルフペースのオンラインラボでも、テクニカルインストラクター主導のクラスでも、皆様のニーズに合ったトレーニングをご用意しています。

Global Knowledge は、世界中で AWS トレーニングの提供を認められている多くの APN トレーニングパートナーの 1 社です。オンサイトトレーニングの申し込みについては、AWS グローバルクラス一覧で受講可能なクラスを検索するか、こちらまでお問い合わせください。

Jeff;

新機能 – EC2 スポットフリートの Auto Scaling

EC2 スポットフリートモデル(詳しくは「Amazon EC2 スポットフリート API – 1 回のリクエストで数千台のスポットインスタンスを制御」をご覧ください)では、1 回のリクエストで EC2 インスタンスのフリートを作成できます。お客様はフリートのターゲットキャパシティーを指定し、1 時間あたりの入札価格を入力して、フリートに含めるインスタンスタイプを選択するだけです。

バックグランドで、AWS は最安値のスポットインスタンスを起動することにより、必要なターゲットキャパシティー(インスタンスまたは仮想 vCPU の数で表記)を維持します。やがて、フリート内のインスタンスが価格上昇により終了されると、その時点で最安値の交換用のインスタンスが起動されます。

新しい Auto Scaling
今回、Auto Scaling の追加により、スポットフリートモデルが強化されました。Amazon CloudWatch メトリックスに基づいて、フリートをスケールアップ/ダウンできるようになりました。メトリックスには、EC2、Amazon EC2 Container ServiceAmazon Simple Queue Service (SQS) などの AWS サービスのものを使用できます。代わりに、アプリケーションからパブリッシュしたカスタムメトリックスを使用して、Auto Scaling が開始されるようにもできます。いずれにせよ、これらのメトリックスを使用してフリートのサイズを制御することで、条件や負荷が変わったとしてもアプリケーションの可用性、パフォーマンス、コストをきめ細かく制御できます。以下に示しているのは、この機能の使用開始に必要ないくつかの概念です。

  • コンテナCPU やメモリの使用率メトリックスを使用して、Amazon ECS で動作しているコンテナベースのアプリケーションをスケーリングします。
  • バッチジョブSQS キュー内のメッセージ数に基づいて、キューベースのバッチジョブをスケーリングします。
  • スポットフリート – スポットフリートメトリックス( MaxPercentCapacityAllocation など)に基づいて、フリートをスケーリングします
  • ウェブサービス – 測定された応答時間と 1 秒あたりの平均リクエスト数に基づいて、ウェブサービスをスケーリングします。

スポットフリートコンソール、AWS Command Line Interface (CLI)、または AWS CloudFormation を使用するか、AWS SDKs のいずれかにより API 呼び出しを行うことで、Auto Scaling を設定できます。

私はフリートの起動から始めました。フリートをスケールアップ/ダウンできるようにするために、リクエストタイプとして [Request and Maintain] を使用しました。

フリートは 1 分ほどで稼働状態になりました。

続いて、例示用に SQS キューを作成し、いくつかのメッセージをそのキューに入れて、CloudWatch アラーム(AppQueueBackingUp)を定義しました。このアラームは、キューに 10 件以上のメッセージが入ると起動されます。

また、アラーム(AppQueueNearlyEmpty)も定義しました。このアラームは、キューが空になりそう(メッセージが 2 件以下)になると起動されます。

最後に、このアラームをフリートの ScaleUpScaleDown のポリシーにアタッチしました。

この記事を書き始める前に、SQS キューに 5 件のメッセージを入れました。フリートを起動して、スケーリングポリシーを設定してから、さらに 5 件のメッセージを追加して、アラームが起動されるのを待ちました。

その後、フリートにチェックインすると、キャパシティーが想定どおりに増加したことがわかりました。この結果は [History] タブに表示されました("New targetCapacity: 5")。

仕上げとして、キューからすべてのメッセージを消去し、植物の水やりをして戻ると、フリートが想定どおりスケールダウンされたことがわかりました("New targetCapacity: 2")。

今すぐ利用可能
この新機能は、スポットインスタンスがサポートされているすべてのリージョンで、今すぐ利用し始めることができます。

Jeff;