[レポート] リライアブル・スケーラビリティ：Amazon.com がクラウドでスケールする方法 #ARC206 #reinvent

アノテーション テクニカルサポートの川崎です。

本記事は AWS re:Invent 2022 のセッションレポートとなります。

概要

1995年、Amazon.com は控えめなアーキテクチャと、地球上で最も顧客中心の企業になるという壮大なビジョンを掲げて設立されました。Amazon.com がどのようにして急速に成長したのかを学び、モノリシックアーキテクチャからサービス指向アーキテクチャとマイクロサービスに基づいた非常にスケーラブルなシステムへの進化を見てみましょう。このセッションでは、IMDb、Amazon Search、Amazon Selection and Catalog Systems、Amazon Warehouse Operations、Amazon Transportation から大規模な本番ワークロードの実例を用いて、Amazon がどのようにして大規模なクラウド・ワークロードを構築および実行するか、また、毎日数百万トランザクションをどのように確実に処理しているかを紹介します。Amazon.com が AWS を使用してカスタマーオブセッションを大規模に実現する方法をご覧ください。

セッション動画

セッション資料

Reliable scalability: How Amazon.com scales in the cloud

セッション情報

ARC206

イントロダクション

私は Seth Eliot (セス・エリオット)と言います。 このセッションでは、Amazon.com がAWS上で高い信頼性とスケーラビリティを実現する方法について紹介します。以前 Amazon.com で働いていました。最近、ディベロッパー・アドボケイトとなりました。 Amazon.comの歴史を振り返ると、1995年当時のWebサイトがどのようなアーキテクチャで動いていたのかが分かります。当時は、C言語で書かれた単一のバイナリが、単一のOracle データベースと通信する形態でした。当時のモットーは「早く大きくなる」であり、スケーラビリティが重要でした。 スケーラビリティとは、負荷やスコープが変化したときに、ワークロードが合意された機能を実行する能力のことです。 そのために、Amazon.comはアーキテクチャを進化させました。データベースの分割やサービス指向アーキテクチャの導入などが行われました。これにより、顧客サービスや商品サービスなどが登場しました。 Amazon.comは、急速に成長しました。現在では、何万ものサービスやマイクロサービスが相互に接続され、何千ものチームがそれらを所有しています。 これにより、信頼性の高いスケーラビリティを実現できます。 信頼性の高いスケーラビリティを達成するために、Amazon.comはAWSを活用し、さまざまなベストプラクティスを用いて構築しています。これらのベストプラクティスは、Well-Architected フレームワークを通じて紹介されています。このセッションでは信頼性に焦点を当て、そのベストプラクティスの例を紹介します。

IMDb はサーバーレス・マイクロサービスに再構築

IMDbはサーバーレスマイクロサービスアーキテクチャに再構築されました。このアーキテクチャでは、特定のビジネスドメインに焦点を当てた小規模で分離されたサービスが利用されます。映画やテレビ番組に関する情報を提供するIMDbは、以前モノリシックビルドで構築され、EC2サーバー上のREST APIを使用していました。再設計により、マイクロサービスとフェデレーションスキーマに移行しました。これにより、様々なサービスが連携して効率的に情報を提供できるようになりました。 IMDbでは、マイクロサービスを用いてAWSのLambdaを活用しています。Lambdaはサーバーレスコンピューティングで、サーバーなしでコードを実行できます。これにより、適切なスケーラビリティが実現され、コールドスタートを減らすことができます。 アーキテクチャには、アプリケーションロードバランサー、Webアプリケーションファイアウォール（WAF）、コンテンツ配信ネットワーク（CDN）などが含まれています。これらのテクノロジーを組み合わせることで、パフォーマンスが向上し、セキュリティが確保されます。 2ピザチームは、開発者とビジネスの専門家が協力してサービスを所有するという Amazon の文化を表しています。このモデルを採用することで、サービスのビジネスロジックがチームによって所有され、組織が効率的に運用されます。また、サーバーレスへの移行がスケーラビリティの向上に役立ちます。 最後に、可用性の高いパブリックエンドポイントの使用がベストプラクティスとして提案されています。これにより、リソースの取得やスケーリングにおいて自動化が実現され、リソースが必要な場合に迅速に対応できます。全体として、IMDb のアーキテクチャはサーバーレスマイクロサービスを活用して効率的に情報を提供し、スケーラビリティとセキュリティを確保しています。

Amazon Global Ops Robotics はセルベースのアーキテクチャでワークロードを保護

Amazon Global Ops Robotics がセルベースのアーキテクチャでワークロードを保護する方法について話します。 まず、Global Ops RoboticsはAmazonのサプライチェーン内の倉庫管理を担当しています。 これには、資材の受け取りや保管、ピッキング、梱包、発送などが含まれます。 また、500以上の倉庫や配送センターがあり、それぞれ数百万の商品があります。 ここでは、セルベースのアーキテクチャが取り入れられており、 互いに隔離され互いにデータを共有しない複数の完全なスタックを繰り返し生成し、 その上に薄いルーティング層を配置しています。 これにより、1つのセルで障害が発生しても、他のセルに影響を与えないようにしています。 このアーキテクチャでは、フルフィルメントセンターがセルに割り当てられ、各センターは他のセンターとデータを共有しません。 また、セルとフルフィルメントセンターの割り当ては、DynamoDBを使用して行われています。 これにより、フルフィルメントセンターのサイズが異なるため、セル間の負荷分散も可能になります。 このシステムは、セルのバランスを取るためにさまざまなルールやヒューリスティックも実行し、他のセルよりも特に大きなセルがないようにしています。

Amazon Relay アプリ (ミドルマイル) がマルチリージョンに対応し、トラックの運行を継続

Amazon Relay アプリは、ミドルマイル物流を管理するために、トラック運転手が使用する iOS および Android 向けのアプリです。 しかし、2021年12月に us-east-1 リージョンで SNS の問題が発生し、一部のトラック運転手が荷物の割り当てを受けられないという問題が起きました。 そこで、Amazon は要件定義やグレースフル・デグラデーションの実装、マルチリージョン対応など、いくつかのベストプラクティスを導入して、 この影響を最小限に抑えました。 これらのベストプラクティスには、可用性の高いエンドポイントを使用することや、 ワークロードを複数の場所にデプロイし、適切な場所にリソースを配置することが含まれています。 また、フェイルオーバーや災害復旧戦略のテストも重要なプロセスです。 Amazon が達成しようとしている目標は、すべてのトラックが運行を継続し、ドックに製品がバックアップされずにサービスが提供され続けることです。

Amazon クラシフィケーション・ポリシープラットフォーム (CPP) はシャッフル シャーディングを使用して影響範囲を限定

Amazon クラシフィケーション・ポリシープラットフォーム（CPP: Classification and Policy Platform）ではシャッフル・シャーディングを使用して影響範囲を限定します。 CPPは、何百万もの商品が含まれる Amazon カタログを分類するプラットフォームで、 50種類の分類プログラムが実行されています。 CPPでは、10,000を超える機械学習モデルと100,000のルールが適用されており、毎日100のモデルが更新されます。 シャーディングは、リソースに負担をかけずにシステムの障害を局所化し、システムの他の部分への影響を防ぐことができます。 シャッフル・シャーディングでは、各クライアントに独自の一意のシャードペアが割り当てられ、他のシャードと共有されます。 これにより、障害が発生した場合でも全体への影響が最小限に抑えられます。 シャーディングと組み合わせることで、AWS Lambdaを利用した疎結合依存関係が実装され、 キューのバックプレッシャーに応じて適切なワーカーを選択できます。 負荷が高すぎる場合、負荷制限キューにリクエストが送信され、一定時間経過後に再処理されます。 この方法で、CPPは効率的に分類とポリシーを適用し、リソースの使用を最適化することができます。

Amazon Search では "be ready for Prime Day, any day"（いつでもプライムデーに備えて）カオス・エンジニアリングを実行

本日最後に紹介するのは、Amazon Search が「いつでもプライムデーに備える」ために、どのようにカオス・エンジニアリングを活用しているかについてです。 Amazon Search は3億のアクティブユーザーが利用し、前回のプライムデーではピーク時に1秒あたり84,000リクエストがありました。 Search チームは独自の回復力チームを持っており、彼らの主要な目標は「Amazon Search サービスの復元力をテスト、改善、推進する」ことです。 カオス・エンジニアリングでは、システムを実験する学問であり、本番稼働中の不安定な状況に耐えられるシステムの能力に対する信頼を築くことが目的です。 カオス・エンジニアリングの方法は、定常状態と仮説の設定から始め、実験を実行し、仮説が確認されたかどうかを検証し、改善する必要があれば再設計を行います。 Amazon Search では、AWS の Fault Injection Simulator (FIS)を用いてカオス・エンジニアリングを実行しています。 彼らは、FISに加えて、オーケストレーション構成を構築しています。 これにより、一貫したエクスペリエンスが提供され、カオス・エンジニアリングを簡単に行うことができます。 また、顧客重視のアプローチをとるため、カオス・エンジニアリングの実験はエラーバジェット内で行われます。 緊急レバーを設定して、障害が発生した場合にサービスを元に戻せるようにしています。 これにより、カオス・エンジニアリング実験を通じて、エンドユーザーに利益がもたらされることを重視しています。

まとめ

さて、要約すると、このセッションで取り上げた 5 つのサービスです。

このパートは私にとって重要です。 すべての情報を入手して皆さんと共有するために、 複数のチームの多くの優秀なエンジニアと協力する必要がありました。 みなさんも楽しんでいただければ幸いです。 そして、優秀なエンジニアが素晴らしいものに取り組んでいることは、彼らが優れているということです。 本当に忙しい中、時間を割いて私に説明してくれ、皆さんと共有できるようにしてくれました。 エンジニアたちに心から感謝するとともに、彼らが行ったエンジニアリングに畏敬の念を抱きます。 本当に感動しました。 あなたもそれに感動していただければ幸いです。

このセッションの内容をカバーする可能性のある今後の講演、 このセッションで取り上げた 2 つの例には実際にいくつかの外部リソースがあります。 詳細を知りたい場合はチェックしてください。

本セッションの内容に興味を持たれた方は、上部のリンクからセッション動画、セッション資料をご覧ください。