なぜ AWS はサービスを統合しないのか - Two-Pizza Team とサービス分離の設計哲学
AWS が 200 以上のサービスを個別に提供し続ける理由を、Bezos の API Mandate、Two-Pizza Team の組織原則、Conway の法則の観点から解説し、サービス分離がもたらす利点と代償を考察します。
似たサービスが多すぎるという疑問
AWS を使い始めた人が必ず抱く疑問があります。SQS と Kinesis はどちらもメッセージを扱うのになぜ 2 つあるのか。ECS と EKS はどちらもコンテナを動かすのに統合しないのか。CodeCommit、CodeBuild、CodeDeploy、CodePipeline はなぜ 1 つのツールにまとめないのか。2006 年に S3 と EC2 だけで始まった AWS は、現在 200 以上のサービスを提供しています。この膨大なサービス群は偶然の産物ではなく、Amazon という組織の構造と設計思想が生み出した必然的な結果です。その根源を理解するには、2002 年に Jeff Bezos が社内に発した 1 通のメモまで遡る必要があります。
Bezos の API Mandate - すべてはここから始まった
2002 年、Amazon のコードベースは巨大なモノリスに成長し、チーム間の依存関係がスケーリングのボトルネックになっていました。Bezos はこの問題に対し、全チームに向けて明確な指令を出しました。(1) すべてのチームは自分たちのデータと機能をサービスインターフェースを通じて公開すること。(2) チーム間の通信はすべてこのインターフェースを経由すること。(3) 他のチームのデータストアに直接アクセスすることは一切認めない。(4) これに従わない者は解雇する。この指令は後に「Bezos API Mandate」として知られるようになりました。重要なのは、この指令がすべてのインターフェースを外部公開可能な品質で設計することを求めた点です。内部用だからといって手を抜くことは許されませんでした。この原則が、後に Amazon の内部ツールを外部サービスとして切り出す AWS の誕生につながります。S3 は Amazon の内部ストレージサービスが原型であり、EC2 は社内のコンピューティングリソース管理の仕組みが基盤になっています。
Two-Pizza Team と Conway の法則
Bezos が導入したもう 1 つの組織原則が Two-Pizza Team です。1 つのチームは 2 枚のピザで全員が食事できる規模、つまり 6 人から 10 人程度に収めるというルールです。この小さなチームが 1 つのサービスの設計、開発、運用のすべてに責任を持ちます。ここで作用するのが Conway の法則です。1967 年に Melvin Conway が提唱したこの法則は、組織が設計するシステムは、その組織のコミュニケーション構造を反映するという観察です。Amazon はこの法則を逆手に取りました。望ましいアーキテクチャ (疎結合なサービス群) を先に定義し、それに合わせて組織構造を設計したのです。各 Two-Pizza Team が独立したサービスを持つため、サービスの数はチームの数に比例して増えていきます。SQS と Kinesis が別々に存在するのは、それぞれを担当する独立したチームが存在し、異なる顧客課題を解決しているからです。SQS は非同期メッセージングの信頼性に特化し、Kinesis はリアルタイムストリーミングのスループットに特化しています。統合すれば便利に見えますが、1 つのチームが両方の要件を同時に最適化することは困難です。
サービス分離がもたらす 3 つの利点
第一に、リリース速度の独立性です。各チームが自分のサービスを独立してデプロイできるため、他チームのリリーススケジュールに依存しません。AWS が年間数千の機能改善をリリースできるのは、この独立性があるからです。第二に、障害の爆発半径の局所化です。1 つのサービスに障害が発生しても、他のサービスへの影響を最小限に抑えられます。2017 年の S3 障害では多くのサービスが影響を受けましたが、これは逆に S3 への依存が集中していたことの教訓となり、AWS はその後サービス間の依存関係をさらに疎結合にする設計改善を進めました。第三に、顧客にとっての選択の粒度です。フルマネージドなコンテナ実行環境が欲しければ Fargate を、Kubernetes エコシステムとの互換性が必要なら EKS を、シンプルな Docker 実行環境で十分なら ECS を選べます。統合された 1 つのサービスでは、この粒度の選択肢を提供することが難しくなります。
分離の代償 - 学習コストと統合の複雑さ
サービス分離には明確な代償もあります。最も顕著なのは学習コストの増大です。新しいプロジェクトを始めるとき、類似サービスの違いを理解し、適切なものを選定するだけで相当な時間を要します。料金体系もサービスごとに異なるため、コスト見積もりが複雑になります。サービス間の連携にも摩擦が生じます。Lambda から DynamoDB を呼び出し、結果を SQS に送り、別の Lambda で処理するといった構成では、各サービスの IAM 権限、エラーハンドリング、リトライ戦略をそれぞれ個別に設計する必要があります。AWS 自身もこの問題を認識しており、後から統合ビューを提供するアプローチを取っています。Application Composer はサーバーレスアーキテクチャを視覚的に設計するツールであり、個別のサービスを組み合わせる複雑さを軽減します。Step Functions はサービス間のオーケストレーションを宣言的に記述できます。つまり、サービスそのものは分離したまま、統合のレイヤーを上に被せるという戦略です。
自分のシステム設計への示唆
AWS のサービス分離の思想は、自社のシステム設計にも示唆を与えます。マイクロサービスの粒度を決めるとき、「技術的に分割できるか」ではなく「独立したチームが責任を持てるか」を基準にすべきです。チームの境界とサービスの境界を一致させることで、Conway の法則を味方につけられます。一方で、小さな組織が AWS と同じ粒度でサービスを分割するのは過剰です。3 人のチームが 20 のマイクロサービスを運用するのは、分離の利点よりも運用コストが上回ります。組織の規模に合った分割粒度を選ぶことが重要です。AWS のサービスが多すぎると感じるのは自然な反応ですが、その背景には組織構造とアーキテクチャを一致させるという一貫した設計哲学があります。この構造を理解すれば、類似サービスの選定基準も明確になります。各サービスが解決しようとしている具体的な課題は何か、自分のユースケースにはどの課題解決が最も合致するか、という視点で選べばよいのです。 クラウドアーキテクチャの設計思想を深く学びたい方は関連書籍 (Amazon) も参考になります。
まとめ
AWS が 200 以上のサービスを統合せず個別に提供し続ける理由は、2002 年の Bezos API Mandate と Two-Pizza Team という組織原則に根ざしています。Conway の法則が示すとおり、組織構造がアーキテクチャを規定し、小さな独立チームがそれぞれのサービスを所有する体制が、リリース速度の独立性、障害の局所化、顧客の選択肢の粒度という利点を生み出しています。学習コストや統合の複雑さという代償はありますが、AWS は Application Composer や Step Functions といった統合レイヤーで補完する戦略を取っています。