AWS の障害ドメイン設計 - AZ・リージョン・パーティションの 3 層構造が守る可用性の仕組み
AWS のインフラが AZ (障害隔離)、リージョン (地理的分離)、パーティション (政治的分離) の 3 層で設計されている理由と、各層の障害がどこまで波及するかを具体的な事例とともに解説します。
障害ドメインとは何か
障害ドメイン (Fault Domain) とは、単一の障害が影響を及ぼす範囲のことです。電源ケーブルが 1 本切れたら何台のサーバーが停止するか、ネットワークスイッチが 1 台故障したら何台のサーバーが通信不能になるか、データセンターが 1 棟停電したら何台のサーバーが影響を受けるか。これらの「影響範囲」が障害ドメインです。AWS のインフラは、障害ドメインを 3 つの層で階層的に設計しています。最小の障害ドメインは AZ (Availability Zone) で、単一のデータセンター群の障害を隔離します。中間の障害ドメインはリージョンで、地理的に離れた場所の障害を隔離します。最大の障害ドメインはパーティション (aws、aws-cn、aws-us-gov) で、政治的・法的に独立したインフラを分離します。この 3 層構造により、1 つの AZ の障害がリージョン全体に波及せず、1 つのリージョンの障害が他のリージョンに波及せず、1 つのパーティションの障害が他のパーティションに波及しない設計になっています。
AZ の障害隔離 - 電力・冷却・ネットワークの独立性
AZ は AWS の障害隔離の最小単位です。各 AZ は 1 つ以上のデータセンターで構成され、電力系統、冷却系統、ネットワーク接続がすべて独立しています。同一リージョン内の AZ 間は、専用の高帯域・低レイテンシのネットワークで接続されていますが、物理的には数十キロメートル以上離れています。AZ の障害隔離が実際に機能した事例があります。2019 年に us-east-1 の 1 つの AZ で電力障害が発生し、その AZ 内の EC2 インスタンスと EBS ボリュームが影響を受けました。しかし、同じリージョン内の他の AZ は正常に稼働し続けました。マルチ AZ 構成で運用していたサービスは、障害のあった AZ のインスタンスが停止しても、他の AZ のインスタンスがトラフィックを処理し続けたため、エンドユーザーへの影響はありませんでした。ここで注意すべきは、AZ の ID (use1-az1 など) はアカウントごとにマッピングが異なるという点です。アカウント A の us-east-1a とアカウント B の us-east-1a は、異なる物理的な AZ を指している可能性があります。AZ ID (use1-az1) はアカウント間で一貫しているため、クロスアカウントで AZ を指定する場合は AZ ID を使用してください。
リージョンの地理的分離 - 自然災害と大規模障害への備え
リージョンは、地理的に離れた場所に配置された独立したインフラです。各リージョンは独自のコントロールプレーン (リソースの作成・変更・削除を管理するシステム) を持ち、他のリージョンのコントロールプレーンとは独立して動作します。この設計により、1 つのリージョンのコントロールプレーンに障害が発生しても、他のリージョンのリソース管理には影響しません。ただし、一部のサービスはグローバルなコントロールプレーンを持っています。IAM、Route 53、CloudFront はグローバルサービスであり、コントロールプレーンは us-east-1 に集中しています。2021 年の us-east-1 ネットワーク障害の際、IAM のコントロールプレーンが影響を受け、他のリージョンでも新しい IAM ロールの作成やポリシーの変更ができなくなりました。ただし、IAM のデータプレーン (認証・認可の処理) は各リージョンにキャッシュされているため、既存の認証情報を使ったアクセスは継続できました。この「コントロールプレーンは停止してもデータプレーンは動く」という設計が、Static Stability (静的安定性) の原則です。
パーティションの政治的分離
AWS のパーティションは、政治的・法的な理由で完全に分離されたインフラです。商用パーティション (aws)、中国パーティション (aws-cn)、GovCloud パーティション (aws-us-gov) の 3 つが存在します。各パーティションは独立した IAM、独立した請求システム、独立したサポート体制を持ち、パーティション間でのリソース共有やデータ転送は原理的にできません。中国パーティションが分離されている理由は、中国の法律が外国企業によるクラウドサービスの直接提供を禁止しているためです。中国リージョンは中国のパートナー企業が運営しており、AWS のグローバルインフラとは完全に独立しています。中国リージョンの AWS アカウントは、商用パーティションのアカウントとは別に作成する必要があります。GovCloud パーティションは、米国政府の機密データを扱うために設計されています。FedRAMP High、ITAR (国際武器取引規則)、CJIS (刑事司法情報サービス) などの厳格なコンプライアンス要件を満たしており、米国市民のみがアクセスできます。
障害ドメインを意識したアーキテクチャ設計
障害ドメインの 3 層構造を理解した上で、ワークロードの可用性要件に応じた設計を選択します。単一 AZ 構成は、開発・テスト環境や、ダウンタイムが許容されるバッチ処理に適しています。コストは最小ですが、AZ 障害時にサービスが停止します。マルチ AZ 構成は、本番環境の標準的な構成です。ALB + Auto Scaling Group を複数の AZ に配置し、RDS をマルチ AZ 配置にすれば、単一 AZ の障害に耐えられます。ほとんどのワークロードはこの構成で十分です。マルチリージョン構成は、リージョン全体の障害に耐える必要がある場合に採用します。Route 53 のフェイルオーバールーティングで、プライマリリージョンが障害を起こした場合にセカンダリリージョンに自動切り替えします。DynamoDB Global Tables や Aurora Global Database を使えば、リージョン間のデータレプリケーションも自動化できます。ただし、マルチリージョン構成はコストと運用の複雑さが大幅に増加するため、ビジネス上の要件 (RPO/RTO) を明確にした上で採用を判断してください。可用性設計のパターンを体系的に学ぶには、専門書籍 (Amazon)が参考になります。