Two-Pizza Team とサービス分離の設計哲学 - AWS が 200 超のサービスを高品質に維持できる理由
AWS の組織設計の根幹である Two-Pizza Team (2 枚のピザで足りる規模のチーム) が、サービスの独立性と品質にどう寄与しているかを、Azure の統合志向や GCP の組織構造と比較します。
組織の構造がソフトウェアの構造を決める
コンウェイの法則は「組織はその組織のコミュニケーション構造を反映したシステムを設計する」と述べています。この法則は、クラウドプロバイダーのサービス設計にも明確に当てはまります。AWS のサービスが 200 を超えながらも、それぞれが独立した API と独立したリリースサイクルを持つのは、AWS の組織構造がそのように設計されているからです。AWS は Two-Pizza Team と呼ばれる小規模チームを基本単位として組織されています。各チームは 1 つのサービスまたはサービスの主要コンポーネントに対して完全な責任を持ち、設計、開発、テスト、デプロイ、運用のすべてを自律的に行います。この組織設計が、AWS のサービスの独立性と品質を支える構造的な基盤です。
Two-Pizza Team の設計原則
Two-Pizza Team の名前は「2 枚のピザで全員が食べられる規模」に由来しており、通常 6〜10 人程度のチームです。この規模には明確な設計意図があります。第一に、コミュニケーションコストの最小化です。チームの人数が増えると、メンバー間のコミュニケーションパスが指数関数的に増加し、意思決定の速度が低下します。小規模チームでは、全員が同じコンテキストを共有し、迅速に意思決定できます。第二に、オーナーシップの明確化です。各チームが 1 つのサービスに対して完全な責任を持つことで、「誰の責任か分からない」という状況が排除されます。サービスの品質、可用性、パフォーマンスのすべてがチームの責任であり、問題が発生した場合の対応も迅速です。第三に、イノベーションの促進です。小規模チームは大きな組織の承認プロセスに縛られず、実験と改善を素早く繰り返せます。新しい機能のアイデアから実装、デプロイまでのサイクルが短く、顧客のフィードバックを迅速に反映できます。
サービス分離がもたらす技術的な利点
Two-Pizza Team の組織設計は、サービスのアーキテクチャにも直接反映されています。各サービスは独立したコードベース、独立したデプロイパイプライン、独立したデータストアを持ちます。サービス間の通信は明確に定義された API を通じて行われ、内部実装の詳細は隠蔽されます。この分離により、あるサービスの変更が他のサービスに予期しない影響を与えるリスクが最小化されます。S3 チームが S3 の内部実装を変更しても、EC2 や Lambda には影響しません。各サービスが独立してスケールし、独立して障害から回復できるため、システム全体の耐障害性が向上します。リリースの独立性も重要です。各チームは他のチームのリリーススケジュールに依存せず、自分のペースで機能追加やバグ修正をデプロイできます。AWS が年間数千回のデプロイを行えるのは、この独立したリリースサイクルのおかげです。
Azure の統合志向との対比
Azure のサービス設計は、AWS とは対照的に統合志向が強い傾向があります。Azure Portal は単一の管理画面からすべてのサービスを操作できる統合体験を提供しており、サービス間の連携が密に設計されています。この統合は、ユーザーにとって一貫した操作体験を提供するという利点がありますが、裏返しとして、サービス間の依存関係が複雑になりやすいという課題を抱えています。Azure の障害事例では、1 つのサービスの問題が連鎖的に他のサービスに波及するケースが報告されています。2023 年の Azure の大規模障害では、認証基盤の問題が Azure Portal、Azure DevOps、Microsoft 365 など広範なサービスに影響しました。これは、サービス間の統合が密であるがゆえに、障害の blast radius (爆発半径) が大きくなる構造的なリスクです。Microsoft の組織構造も、Azure の設計に影響しています。Azure は Microsoft の一部門であり、Office、Windows、Dynamics などの他の事業部門との連携が求められます。この組織的な統合要求が、サービス設計の統合志向を強化しています。
GCP の組織構造とサービス設計
GCP は Google のクラウド部門として運営されており、Google の技術文化の影響を強く受けています。Google は社内で大規模な分散システムを運用してきた実績があり、その技術を外部に提供するという形で GCP のサービスが生まれています。GCP のサービス数が AWS や Azure と比較して少ないのは、Google が「少数精鋭」のアプローチを取っているためです。多数の専門化されたサービスを提供するのではなく、汎用性の高いサービスを少数提供し、それぞれの品質を高めるという戦略です。BigQuery、GKE、Spanner などは、この戦略の成功例です。しかし、このアプローチには「顧客のニッチな要件に対応しにくい」という課題があります。AWS が 15 以上のデータベースサービスを用途別に提供しているのに対し、GCP は Cloud SQL、Cloud Spanner、Bigtable、Firestore など比較的少数のサービスでカバーしようとしています。特定のユースケースに最適化されたサービスが存在しない場合、顧客は汎用サービスで妥協するか、自前で最適化する必要があります。
You Build It, You Run It の文化
Two-Pizza Team の重要な側面は「You Build It, You Run It (作った人が運用する)」の原則です。AWS では、サービスを開発したチームがそのサービスの運用にも責任を持ちます。開発チームと運用チームが分離されている従来の組織構造とは異なり、開発者自身がオンコール対応を行い、障害対応にあたります。この原則がもたらす効果は大きく 3 つあります。第一に、運用品質の向上です。自分が深夜に叩き起こされる可能性があると知っていれば、開発者はより堅牢なコードを書き、より充実した監視とアラートを設定します。第二に、フィードバックループの短縮です。運用中に発見された問題は、開発者自身が直接修正できるため、問題の報告から修正までの時間が短縮されます。第三に、設計品質の向上です。運用の苦労を知っている開発者は、運用しやすい設計を最初から心がけます。ログの出力、メトリクスの収集、設定の変更容易性など、運用性を考慮した設計が自然に行われます。Azure や GCP でも DevOps の文化は推進されていますが、AWS ほど組織構造のレベルで「開発者が運用する」原則が徹底されているわけではありません。 チーム設計と組織論を学ぶには関連書籍 (Amazon) も参考になります。
まとめ
AWS の Two-Pizza Team は、小規模チームによる自律的なサービス開発と運用を組織構造のレベルで制度化したものです。この設計により、200 を超えるサービスがそれぞれ独立した品質と進化のペースを維持し、障害の影響範囲が限定される構造が実現しています。Azure の統合志向は一貫した操作体験を提供する一方で、障害の連鎖リスクを内包しています。GCP の少数精鋭アプローチは個々のサービスの品質を高めますが、ニッチな要件への対応力で AWS に及びません。クラウドプラットフォームの長期的な品質と進化を評価する際、背後にある組織設計の思想を理解することは、機能比較と同等に重要です。