Category: 利用事例


Earth on AWS: AWS の地理空間データ

AWS のオープンデータチームのメンバーで私の同僚、Joe Flasher が新たな Earth on AWS プロジェクトについて説明するため、ゲスト投稿者としてブログを公開しました。

Jeff;


 

AWS は地球観測衛星のランドサット 8 号が撮影した画像を集めた公開データセット、Landsat on AWS を 2015 年 3 月にリリースしました。Landsat on AWS をリリースしてから 1 年以内に記録された Landsat データのリクエスト数は 10 億件を超え、AWS はユーザーによる革新的なデータの使用方法から様々なインスピレーションを得ています。Landsat on AWS はクラウド内でのデータ共有により、従来の IT インフラストラクチャによる帯域幅やストレージ、メモリや処理能力の制限なしに地球的規模のアプリケーションを構築することが可能になりました。

そして本日、AWS がリリースした Earth on AWS により、今後はクラウド内で大容量の地理空間データセットの利用が可能になったため、アルゴリズムをローカルマシンにダウンロードせずにアルゴリズムをデータに持ち込めるようになりました。Earth on AWS では誰でも自由にデータを使えるだけでなく、リソースを提供することでデータをどのように使用できるか説明する情報も提供しています。また、Earth on AWS データセットを利用した調査方法の 公開プロポーザル も受け付けています。

使用可能なデータを追加
現在、Earth on AWS には次のデータセットがあります。

NAIP 1m の画像
The National Agriculture Imagery Program (NAIP) は、米国本土を対象に作物成長時期の航空画像を撮影しています。約 1 メートルの航空画像 (赤、緑、青、NIR) を Amazon S3 で入手できるようになりました。詳しくは NAIP on AWS をご覧ください。

地形タイル
地形ベクトルタイルで世界中の標高データを使用できるようになりました。また、米国では 10 メートルの NED データが以前の NED 3 メートルと 30 メートル SRTM データを拡大するようになり、より鮮明に山脈の詳細情報を表示できるようになりました。Amazon S3 でタイルを使用できます。詳しくは地形タイルをご覧ください。

GDELT – A Global Database of Society
The GDELT Project は、世界中のほぼすべての国々から 100 か国以上の言語によるブロードキャスト、印刷物、ウェブニュースなどをモニタリングし、毎日秒刻みにグローバル社会に影響を与えている人物、場所、企業や団体、数値、テーマ、ソース、感情、件数、引用文、画像、イベントなどを特定しています。詳しくは GDELT をご覧ください。

ランドスタット 8 号の衛星画像
ランドスタット 8 号のデータは Amazon Simple Storage Service (S3) で誰でも使用することができます。2015 年にランドスタッド 8 号が撮影した画像はすべて 2013 年と 2014 年のクラウドフリーシーンのセレクションと同様に使用可能になっています。ランドスタット 8 号の新しい画像はすべて毎日数時間内に作成されています。衛星画像は 16 日間ごとに 30 メートルの解像度で地球全体を撮影しています。詳しくは Landsat on AWS をご覧ください。

NEXRAD 気象レーダー
The Next Generation Weather Radar (NEXRAD) は、ドップラー式 160 度の高解像度気象レーダー網で、降水の傾向と大気移動を検知し各地点から約 5 分間隔で情報を発信しています。NEXRAD は暴風雨を予測し、研究者や営利企業は複数の地域に渡る気象上の影響を調査する場合にこれを使用しています。詳しくは NEXRAD on AWS をご覧ください。

SpaceNet 機械学習コーパス
SpaceNet は高解像度が非常に高い DigitalGlobe 衛星画像のコーパスで、研究者が機械学習アルゴリズムを開発するために利用するトレーニングデータです。このデータセットはおよそ 1,990 平方キロに渡る画像を 50 cm の解像度と基礎伏図に一致する 220,594 から成り立ちます。詳しくは SpaceNet コーパスをご覧ください。

NASA Earth Exchange
The NASA Earth Exchange (NEX) は研究者が地球科学データに簡単かつ効率的にアクセスできるようにします。NEX データセットは Amazon S3 で使用可能です。ダウンスケール気候予測 (リリースされたばかりの Localized Constructed Analogs を含む)、グローバル MODIS 植生指数、Landsat Global Land Survey データも含みます。詳しくは NASA Earth Exchange をご覧ください。

オープンデータの活用
オープンデータは自分の目的に合わせた使用法を理解することで初めて便利になります。そのため、Earth on AWS は他のユーザーがどのように地理空間データを独自のワークフローに取り入れているのかを説明したビデオや記事を提供しています。Lambda を使用して地理空間サーバーを置換する方法からレーダー情報を使用した鳥の大群移動の調査まで、様々な活用方法があります。

他にも Earth on AWS データを活用できるアイデアがあれば、ぜひお聞かせください。Earth on AWS データセットに関する調査用の公開プロポーザルを受け付けています。これは従来のバリアを崩すことで学生、教育者、研究者が技術革新において主要な促進力となり、ご自分の分野で新たに進歩することを目的としたものです。お客様に感謝の気持ちを込めて
こうしたデータセットを AWS で使用可能にするためにご協力いただいた DigitalGlobeMapzenPlanetUnidata のお客様に、この場を借りて感謝申し上げます。

AWS では常に大規模なデータセットを使用する新たな方法を模索しています。追加すべき新しいデータやデータ提供の新たな方法についてアイデアがあればこちらにお問い合わせください。

Joe Flasher、Open Geospatial Data リード担当、アマゾン ウェブ サービス

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 が Amazon の記録更新に貢献

今年で 2 年目となった Prime Day で Amazon は新記録を達成しました。この日、世界中からの注文数はブラックフライデー、サイバーマンデー、Prime Day 2015 の記録を遥かに上回るものとなりました。Slice Intelligence は、Prime Day 2016 の当日における米国全土の e コマース消費者のうち 74% を Amazon が占めていたと報告しています。この 1 日限りのグローバルショッピングイベントは Amazon Prime メンバーのみを対象としています。Prime 2015 に比べ、今年のトラフィックレベルは過去最高そして Amazon Mobile App からの注文数は昨年の 2 倍にも上昇しました。世界中の Prime メンバーが 1 日に購入したアイテムの例として、玩具は 2 万個以上、靴は 1 万足以上そしてテレビは 9 万台以上の売り上げが記録されています (統計の詳細は Amazon’s Prime Day is the Biggest Day Ever をご覧ください)。これほど大きなスケールのイベントを実施するには、急増するトラフィックにインフラストラクチャが対応できなければなりません。

 

AWS スタイルでスケーリング
Amazon の小売用ウェブサイトはウェブトラフィックの対応に複数の EC2 インスタンスを使用しています。
Prime Day に急増するカスタマートラフィックに対応するため、Amazon のリテールチームは多数の EC2 のサイズを増やし、2009 年の時点での AWS と Amazon.com を合わせたサイズに等しい能力を追加しました。リソースは世界中の複数の AWS リージョンから取得しました。7 月 11 の朝は涼しく、Amazon シアトル本社のビルの上にはいくつかの雲が浮かんでいました。午前 8 時が近付く頃、Amazon リテールチームは Prime Day 第 1 弾となる最初の 10 件のリリース準備を完了していました。太平洋の反対側は、ほぼ午前 0 時を刻む頃です。日本では Prime Day の開始を待ち侘びる Prime メンバー達がそれぞれのスマートフォン、タブレット、ラップトップに釘付けの状態で待っていました。日本のトラフィックが急増し始めると、CloudWatch メトリックスで Amazon CloudWatch のエンドポイントや ElastiCache ノードが光り、高速モバイルやウェブリクエストが増加していることを示しだしました。このトラフィックの波は地球を一周し、ヨーロッパから米国に到達するまでに 40 時間、そしてクリックストリームのログエントリーは 850 億件を記録しました。 今年の Prime Day の注文数は Prime Day 2015 に比べ世界中で 60% そして米国内だけで 50% も上昇しました。モバイルでは 100 万人を超える Prime メンバーが Amazon Mobile App を初めてダウンロードし、アプリを利用したことが分かっています。Prime Day に伴い 38 種類 (下記サービスを含む) の AWS サービスの使用率が大幅に増加したことに Amazon.com は気付きました。

Prime Day のスケールと、その他の AWS をご利用されているお客様が、これに類似する大規模で 1 日限りのイベントをホストする機会があるかもしれませんので、より詳しく複数の AWS サービスの視点から Prime Day についてご説明します。

  • AmazonMobile Analytics イベントは前週の同じ曜日と比較すると 1,661% 上昇しました。
  • Amazon が使用する CloudWatch メトリックスは Prime Day の当日、前週の同じ曜日と比較すると世界中で 400% 上昇しました。
  • DynamoDB は Prime Day の当日、前週の同じ曜日と比較すると世界中で 560 億件以上のリクエストに対応しました。

AWS で実行
AWS チームは他の企業への対応と同様に Amazon.com に対応しています。この 2 つの組織はビジネスパートナーであり、定義済みのサポートプランやチャネルを通じてコミュニケーションを取っています。比較的に形式的なこのスタイルを取り入れることで、AWS チームが AWS をご利用されているお客様全員に提供するサポートプランやコミュニケーションプロセスを改善しやすくしています。Amazon のウェブサイトや AWS でモバイルアプリを実行することは、Prime Day のように短期間でありながらスケールの大きなグローバルイベントを実施することを可能にし、低コストに抑えることを実現します。私が Amazon.com に入社した 2002 年の時点では (ウェブサイトが AWS に移行する以前のことです)、ホリデーショッピングのシーズン準備には実に様々な計画を練り、予算組みや効果なハードウェアの購入などを必要としていました。このハードウェアはトラフィックの増加に対応する上で役立っていましたが、別の意味ではトラフィックが平常に戻り次第 Amazon.com が未使用でほぼ利用されていないハードウェアを無駄に所有していることを意味していました。AWS は、お客様が Prime Day のようなスケールの大きいイベントを実施するために必要な処理能力を追加できるようにし、柔軟性を備えコスト効率が良い方法で、そうした機能を利用できるようにしています。AWS は、これほどのスケールのオンラインイベントを実施する上で必要とする作業に対応できるので、Amazon リテールチームはお客様にできる限り最高のユーザーエクスペリエンスを提供することに専念できるようになりました。

今回の教訓
Amazon リテールチームは Prime Day の終了に安堵感を感じながらも、今回の件で学んだ点を教えてくれました。

  • 準備 – 計画とテスト実施は必須である。過去の傾向をもとに、将来のトラフィックについて予測し計画を練ること。それに応じて必要なリソースを予測すること。GameDay エクササイズで問題発生時の対応を事前に準備する – インフラストラクチャやサイトのいくつかの部分で意図的に障害を起こし、複数の障害が発生した時の状況をシミュレーションすること (Amazon の GameDay エクササイズ詳細については Resilience Engineering – Learning to Embrace Failure をご覧ください)。
  • 自動化 – 手動による作業を減らし、すべて自動化すること。デマンドに自動的に応じることができるサービスのメリットを活用すること。例えば Route53 を使用して自動的に拡張したり、デマンドに応じて EC2 を自動拡張、また Elastic Load Balancing を使用して自動フェイルオーバーを可能にし複数のリージョンやアベイラビリティゾーンに渡りトラフィックのバランスを取るなど (AZ)。
  • モニタリングAmazon CloudWatch メトリックスを使用して柔軟に通知を送信すること。CloudWatch モニタリングは優れた顧客体験を提供できるように、使用法を常に把握できるようにデザインされている。
  • 自由な発想 – AWS を使用することで、チームに別のホリデーシーズンに必要なリソースを提供できたこと。自社のインフラストラクチャに対する自信がスケールの大きなイベントの実施に繋がる。

前述しましたが、これほどのスケールのイベントを計画し実施しない理由はどこにもないこと。スケールの大きな発想を、そしてサポートプランやサービスのメリットを活用すること。ソリューションアーキテクトやテクニカルアカウントマネージャーそして APN コンサルティングパートナーが必要に応じてご協力します。スケールの大きい 1 度限りのイベントを計画しているのであれば、ぜひお知らせください。イベント開始前そして終了後に必要なサポートをご提供いたします。

Jeff

PS – Prime Day で何を購入されましたか?

GameStop – ミッションクリティカルなマルチチャネルのマーケティングプラットフォームを AWS に移動

GameStop は新品および中古のビデオゲームのハードウェア、ソフトウェア、アクセサリ、家電製品、ワイヤレスサービスを販売しています。14 か国に渡る小売店は 7,000 店以上あり、同社は日々何百万人もの顧客を相手に販売、サービスを提供しています。小売店の他にもオムニチャネル戦略を導入し、世界中で 4,600万人以上のメンバーがロイヤルティプログラムに参加しています。GameStop の Justin Newcom (インターナショナルテクノロジーサービス & サポート部シニアディレクター) と Jim March (アドバンスクラウドシステムエンジニア) との対話で、ミッションクリティカルなマルチチャネルマーケティングプラットフォームを従来のホスティングから AWS に移行した方法について伺いました。GameStop のストーリーをご覧ください。

ビジネスチャレンジ
2015 年 3 月、GameStop のインターナショナルホスティングとの契約期限が近付いていたため、GameStop チームは別のホスティングソリューションがないか真剣に探し始めました。以前から知られているホスティング企業数社と AWS を含むクラウドベンダー数社に RFP (提案依頼書) を送り、その返信が届き次第、決断は明らかになったそうです。その時のことを Justin は「AWS が圧倒的に優れていました」と述べています。別のクラウドベンダーとのミーティングから戻った Jim は、AWS の資料を読み進めるうちに思っていたよりも遥かに完全性が高く洗練されているサービスであることが分かったといいます。その後、GameStop は製品そして革新的なサービスを次々と送り出していること、評判、価格に基いて AWS を利用することに決定したそうです。しかし圧倒的に優れたサービスを選んだからといっても、問題なく進行させていくには様々なことを学ぶ必要があると考えていたといいます。

AWS 導入の始まり
GameStop のテクノロジーリーダー達は AWS について学びやすい文化を築いていくことにしました。AWS を使用している他の利用者やパートナーと話し合い、優れた AWS コンサルティングパートナーを呼び、クラウド導入のスタートを切りました。そして最初に移行するのはミッションクリティカルなマルチチャネルのマーケティングプラットフォームに決定したそうです。このプラットフォームは e コマース以上のもので、カナダやヨーロッパのインストアカスタマーのアクティビティの他に、オンラインカスタマーへのサービスも管理しています。これは、顧客がレジでオンライン購入をする場合などインストアとオンラインのアクティビティを統合できるようにしています。AWS への移行は 2015 年ホリデーショッピングのシーズンまでに完了し、AWS のパフォーマンスは完璧だったそうです。GameStop にとって最初のブラックフライデーは転機だったといいます。まだ Auto Scaling を使用していませんでしたが、需要に合わせて新しい EC2 インスタンスを素早く立ち上げることができ、サイトは正常に作動し素早く応答していました。また、初期段階のその他の成功例で GameStop が重要なターニングポイントに面していることが明らかになりました。例えば当社のチームは任天堂がカナダで立ち上げる予定の Amiibo の準備を 4 時間で完了しなければならないことがありました。そしてその時も問題なくプロジェクトを完了することができました。また、6 時間限りの特別セールスプロモーションに対応するために AWS でのインフラストラクチャを構築した時もスムーズに進行し AWS の請求額は、たったの 300 USD でした。こうした初期の成功により、社内のチームは1 時間から 2 時間だけという短時間限りの「スポット」セールなど、インパクトが高く短期間のマーケティングプログラムについて検討し始めました。従来、こうしたイベントは困難かつコストがかかるものでしたが、現在では楽しいものになったと Jim は語っています。

変化の時期
最初の移行を成功させた後は、クラウドスキルを取得して経験を重ねながら IT 組織を企業のクラウドインフラストラクチャチームに変えていくことでした。この近代化に伴い、チームがアジャイルおよび DevOps プラクティスの経験を培いながら、マイクロサービスやコンテイナなどの新技術を取り入れることを確実にしました。
GameStop は JiraConfluence など最新のツールを使用し、新しいアプローチを取り入れるために上層部からの賛同を求め、いくつかのテストを実行、社内研修を行うための準備を行いました。さらに、将来大きく飛躍した企業は、このモデルを導入しているケースが多い傾向があることも分かりました。場合によってはクラウドが最新のプラクティス方法を生むこともあれば、最新のプラクティスがクラウドを生み出すこともあります。IT の変革計画が起動に乗っていく上で、チームは効率性の改善とコスト節約のために、どの面でも AWS を使用する方法を検討しています。これまでとは異なったタイプの社内 IT チームになるように、社内のパートナーシップの強化、購入上のアドバイスの提供、様々なレベルの IT に関する知識を備えたチームをサポートできるようにしていきたいと考えているそうです。コストの低下、予測可能性の上昇に成功し、現在はこれまで実行することが不可能だった革新的なソリューションの構築とデプロイを実現する立場に到達したといいます。現在、GameStop は海外の IT インフラストラクチャのリソースをまとめる方法を検討しています。こうしたリソースは米国外の「データルーム」 (データセンター以下の規模) で保管されています。AWS を開発前のシングルプラットフォームと見なし、ロケーション、ビジネスユニット、アプリケーションに渡りレプリケートできる一般的なモデルを導入しました。現在は新しいハードウェアを購入していないそうです。その代わりに耐用年数が終了したハードウェアの機能を AWS に移行し、データルームを空にしています。現在のペースで行くと、8 つのデータルームはすべて 3 年以内に空になる予定だそうです。

AWS への移行と AWS の使用
通常、GameStop のインターナショナルチームにとって移行は 2 つのステージプロセスから成り立っています。最初の段階で現状のアプリケーションをクラウドにリフト & シフトします。次の段階で効率性や管理性の改善を実現するため、リファクターや最適化を行います。AWS に移行する前、マルチチャネルチームはサードパーティを通じた IT サービスの提供が主な障害になっていることに気付いていました。AWS に移動後、関係は改善しチームが解決策に向けて協力し合えるようになりました。リファクタリングの段階で、既存のオペレーションを様々な面から検討し、既存の機能を最新の AWS とどのように置き換えることができるか決定します。これにはデータベースロジック、ネットワークアーキテクチャ、セキュリティ、バックアップ、社内メッセージ、モニタリングなども含まれます。このチームはサーバーが不要なデータ処理モデルに興味を持ち、AWS LambdaAmazon API Gateway を使用して内部サービスアーキテクチャを構築する予定です。そのため、従来の古くプロセスを行う上で柔軟性に欠けたテクノロジースタックと置換することになります。また、ストレージや解析をすべて検索可能にするため、ログやメトリックスをすべて Amazon CloudWatch にルーティングすることも計画しています。現在も移行プロセスは進行中です。EC2 インスタンスは今でも主要機能として使用されていないケースが見られます。すべてのインフラストラクチャがダイナミックかつ処分できるものにするモデルを導入し、サーバーにログインしてから行うステータスチェックや変更は稀であるようにすることを目的としています。

推奨事項
Justin と Jim に、クラウド移行を検討している組織に何かアドバイスや推奨事項を求めたところ、次の答えが返ってきました。

  • すべて自動化すること。それを予期して構築すること。
  • インフラストラクチャをコードとして扱うこと。移行することを、このプラクティスを受け入れる文化作りのチャンスと見ること。
  • 最初からすべて正しく実行すること。後で面倒になるアプリケーションを移動しないこと。シンプルに、ただクラウドに移動すること。手の届きやすいものを選び、初期予算はすでに理解していることに費やすこと。移行を修得のプロセスと見ること。ただし可能な場合はコストを節約すること。
  • 時間的制約に屈しないこと。ビジネスパートナーとコミュニケーションを図ること。誰にとってもクラウドは新しいものなので、一時的な問題はあたりまえであること。透明性を高くしオープンでいること。なぜ時間が掛かるのか説明すること。
  • リーダーシップチームと IT チームが共にこのプロセスに取り掛かっている点を理解してもらうこと。自分のマネジメントチームが必ず上層部からの賛同を得ること。

その他にも Jim は AWS Management Consoleインスタンスを作成ボタンを将来の自動化に対する一種の「技術的負債」であり、返済が必要なものであると考えていると語っていました。GameStop の IT 環境改善の実現、おめでとうございます。また、本ブログにあたり GameStop の Justin と Jim からのご協力に感謝申し上げます。

Jeff