Amazon.com は AWS 最大の顧客である - 内部ドッグフーディングが生んだサービス品質の秘密
Amazon.com の EC サイト、Prime Video、Alexa が AWS 上で稼働している事実から、内部ドッグフーディングがサービス品質をどう高めているか、Prime Day の負荷が AWS の設計をどう鍛えたかを解説します。
AWS の起源は Amazon.com のインフラ問題だった
AWS の誕生は、Amazon.com 自身のインフラ課題から始まりました。2000 年代初頭、Amazon.com のエンジニアリングチームは、新しい機能を開発するたびにインフラチームにサーバーの調達を依頼し、数週間から数ヶ月待たされるという問題に直面していました。各チームが独自にインフラを構築・運用していたため、重複投資と運用の非効率が蔓延していました。2003 年頃、Andy Jassy (後の AWS CEO) と少数のチームが、Amazon.com の内部インフラを標準化されたサービスとして提供するアイデアを提案しました。このアイデアが発展し、2006 年に S3 と EC2 が外部向けに公開されました。重要なのは、AWS は最初から外部顧客向けに設計されたのではなく、Amazon.com 自身の問題を解決するために生まれたという点です。この「自分たちが最初のユーザーである」という事実が、AWS のサービス品質を根本的に支えています。
Amazon.com のどの部分が AWS で動いているのか
Amazon.com のほぼすべてのシステムが AWS 上で稼働しています。商品カタログ、検索エンジン、レコメンデーションエンジン、注文処理、在庫管理、配送最適化、カスタマーサービスのチャットボットなど、EC サイトの全機能が AWS のサービスを使用しています。Prime Video のストリーミング配信は、S3 にコンテンツを保存し、CloudFront で世界中に配信しています。Alexa の音声認識と自然言語処理は、AWS の機械学習インフラ上で動作しています。Amazon Go の無人店舗のコンピュータビジョンも AWS で処理されています。DynamoDB は、もともと Amazon.com のショッピングカートの問題を解決するために開発されました。2007 年に発表された論文「Dynamo: Amazon's Highly Available Key-value Store」は、Amazon.com の内部システムとして開発された Dynamo の設計を公開したもので、この論文が後の DynamoDB の基盤になっています。つまり、DynamoDB は Amazon.com の実運用で鍛えられた技術を、外部顧客向けにマネージドサービスとして提供したものです。
Prime Day - AWS の限界を試す年に一度のストレステスト
毎年 7 月に開催される Prime Day は、Amazon.com にとって年間最大のトラフィックイベントであり、同時に AWS にとって最大のストレステストです。2023 年の Prime Day では、48 時間で 3 億 7,500 万点以上の商品が購入されました。この規模のトラフィックを処理するために、AWS は Prime Day の数ヶ月前から準備を開始します。Amazon.com のエンジニアリングチームは、過去のトラフィックデータに基づいて予想負荷を算出し、各サービスのキャパシティを事前にプロビジョニングします。Prime Day の負荷は、通常時の数十倍に達することがあります。この極端な負荷テストが、AWS のサービスの信頼性を鍛えています。Auto Scaling のアルゴリズム、DynamoDB のパーティション分割、CloudFront のキャッシュ戦略、ELB の負荷分散ロジックなど、AWS の多くの機能改善は Prime Day の経験から生まれています。たとえば、DynamoDB のアダプティブキャパシティ (ホットパーティションへのスループットの自動再配分) は、Prime Day のフラッシュセールで特定の商品にアクセスが集中する問題を解決するために開発されました。
ドッグフーディングがサービス品質を高めるメカニズム
ドッグフーディング (自社製品を自社で使うこと) が品質向上に寄与するメカニズムは、フィードバックループの速度と密度にあります。外部顧客からのフィードバックは、サポートチケット、フォーラム、アカウントマネージャーを経由して開発チームに届くまでに時間がかかります。一方、Amazon.com の内部チームからのフィードバックは、同じ社内ネットワーク上で即座に開発チームに届きます。Amazon.com のエンジニアは AWS のサービスを毎日使用しており、パフォーマンスの劣化、API の使いにくさ、ドキュメントの不備を直接体験します。この体験が、サービス改善の最も強力な推進力になっています。具体例として、AWS Lambda の同時実行数の管理機能は、Amazon.com の内部チームが Lambda を大規模に使用した際に、1 つの関数の暴走が他の関数に影響する問題を経験したことから開発されました。予約済み同時実行数 (Reserved Concurrency) とプロビジョンド同時実行数 (Provisioned Concurrency) は、この内部経験から生まれた機能です。
内部顧客と外部顧客の利害が一致する構造
Amazon.com が AWS の最大顧客であることは、外部顧客にとっても利点があります。Amazon.com は世界最大級の EC サイトであり、そのトラフィック規模、可用性要件、セキュリティ要件は、ほとんどの外部顧客よりも厳しいです。AWS がこの要件を満たすために投資する技術改善は、すべての外部顧客にも恩恵をもたらします。たとえば、Amazon.com が Prime Day のために DynamoDB のスケーリング性能を改善すれば、その改善は DynamoDB を使用するすべての顧客に適用されます。Amazon.com が CloudFront の配信品質を改善すれば、CloudFront を使用するすべてのウェブサイトの表示速度が向上します。ただし、この構造には潜在的なリスクもあります。Amazon.com と外部顧客が同じインフラを共有しているため、Amazon.com の大規模イベント (Prime Day など) が外部顧客のパフォーマンスに影響する可能性があります。AWS はこのリスクを、リソースの物理的な分離とキャパシティプランニングで管理しています。AWS のサービスは、特定の顧客のトラフィックが他の顧客に影響しないよう、マルチテナントの隔離が設計されています。クラウド戦略と AWS の設計思想を体系的に学ぶには、専門書籍 (Amazon)が参考になります。