AWS の Availability Zone 設計 - 物理的分離と障害隔離が生む信頼性の差
AWS の AZ が物理的に独立したデータセンター群である設計思想を、Azure・GCP の可用性ゾーンと比較しながら、公開されている設計基準と実際の障害事例に即して解説します。
可用性ゾーンはどのクラウドにもある、しかし同じではない
AWS、Azure、GCP のいずれも「可用性ゾーン」(Availability Zone) という概念を提供しています。複数のゾーンにリソースを分散させることで、単一障害点を排除し、高可用性を実現するという基本的な考え方は共通です。しかし、その実装の詳細には大きな違いがあります。AWS が AZ を提供し始めたのは 2008 年 3 月で、2006 年の EC2 ローンチから 2 年後に Elastic IP アドレスなどと同時に追加された機能でした。以降 2026 年までの運用のなかで、分離の設計基準とマルチ AZ を前提としたサービス群が整備されてきました。Azure が Availability Zones を一般提供したのは 2018 年で、提供開始の時期には 10 年の差があります。ただし早く始めたことがそのまま設計の優劣を意味するわけではありません。この記事では、各社が公開している設計基準と実際に起きた障害の一次情報に即して、どこまでが確認できる違いなのかを整理します。
AWS の AZ 設計 - 物理的分離の徹底
AWS の各 AZ は、1 つまたは複数の物理的に独立したデータセンターで構成されています。AWS はこの物理的分離について、具体的な設計基準を公開しています。各 AZ は独立した電力供給源を持ち、異なる変電所から給電されます。冷却システム、ネットワーク接続もそれぞれ独立しています。AZ 間の距離は、低レイテンシ通信を維持できる範囲 (通常 100km 以内) でありながら、洪水、地震、火災などの局所的な災害が複数の AZ に同時に影響しないよう、十分に離れています。この設計の核心は「障害ドメインの完全な分離」です。ある AZ で電力障害が発生しても、隣接する AZ には影響が及ばないように設計されています。ネットワーク機器の故障、冷却システムの異常、建物レベルの災害についても、影響を当該 AZ 内に封じ込めることが設計目標です。AWS の一次記述も「各 AZ は他の AZ の障害から隔離されるように設計されている」という設計目標の形で書かれており、あらゆる事象について他 AZ への波及がないと保証するものではありません。可用性設計では、この「設計目標」と「保証」の違いを踏まえて冗長化の範囲を決める必要があります。AWS はこの分離を「blast radius (爆発半径) の最小化」と表現しており、障害の影響範囲を物理的に制限する設計哲学が一貫しています。
Azure の Availability Zones - 導入の経緯と確認すべき点
Azure は 2018 年に Availability Zones を一般提供しました。可用性ゾーンは「独立した電力、冷却、ネットワークを持つ 1 つ以上のデータセンター」と説明されており、複数のゾーンにリソースを分散して単一障害点を排除するという考え方は AWS と共通です。異なるのは経緯です。Azure は当初、Availability Sets (障害ドメインと更新ドメインによる論理的な分離) を可用性の基本単位としており、可用性ゾーンは後から追加された概念として、既存のサービスとの整合性を取りながら段階的に展開されてきました。そのため設計時には、対象リージョンが可用性ゾーンに対応しているか、使うサービスがゾーンをどう扱うか (ゾーン冗長か、特定ゾーンへの固定か) を、Microsoft の公式リージョン一覧とサービス別ドキュメントで確認する手順が必要になります。対応状況は随時拡大しているため、特定時点の対応表を前提に判断を固定しないほうが安全です。また、AZ 間の距離や電力・冷却の分離基準をどこまで公開しているかは各社で異なります。同じ「可用性ゾーン」という言葉で語られていても、利用者が検証できる粒度は揃っていない点を前提に比較する必要があります。
GCP のゾーン設計 - 異なるアプローチ
GCP のゾーンは、AWS の AZ と概念的には類似していますが、設計のアプローチが異なります。GCP は各リージョンに通常 3 つのゾーンを配置し、Google の大規模なグローバルネットワーク上に構築しています。GCP の強みは、Google が長年運用してきた大規模分散システムの知見がゾーン設計に反映されている点です。Spanner のようなグローバル分散データベースは、ゾーン間のレプリケーションを前提に設計されており、ゾーン障害に対する耐性が高いとされています。一方で、GCP は 3 ゾーン構成のリージョンが多数派で、AWS の東京リージョン (4 AZ) のように 4 つ以上のゾーンを選べるリージョンは限られます。ただし 4 ゾーンのリージョンが存在しないわけではなく、us-central1 は 4 つのゾーンを持ちます。ゾーン数が多いほどリソースの分散配置の選択肢が増え、1 ゾーンが利用不能になったときに残りのゾーンで受け止める余力を確保しやすくなります。設計時に確認したいのは各社の総ゾーン数ではなく、使いたいリージョンで実際に選べるゾーン数と、そこへキャパシティを分散して配置できるかどうかです。
実際の障害事例から見る AZ 分離の実効性
AZ 設計の真価は、実際に障害が発生したときに問われます。AWS は過去に複数の大規模障害を経験していますが、その多くで AZ の分離が設計どおりに機能しています。2017 年の S3 障害 (us-east-1) では、タイプミスによるオペレーションエラーが原因でしたが、影響は特定のサブシステムに限定され、他のリージョンや AZ のサービスは正常に稼働し続けました。2019 年の us-east-1 での電力障害では、事象は単一の AZ に封じ込められました。ただし、その AZ にしかリソースを置いていなかった環境は影響を受けます。マルチ AZ 構成なら自動的に無傷というわけではなく、単一 AZ の事象として乗り切れるかどうかは、アプリケーション側が残りの AZ で処理を続けられる構成になっているかで決まります。AWS は大規模障害の一部について事後サマリを公開していますが、すべての事象で公開されるわけではありません。設計の前提は個別の公開レポートではなく、設計目標と各サービスの動作仕様に置くべきです。他社でも同種の事象は起きています。2023 年 8 月のオーストラリア東部リージョンの障害では、電圧低下によって冷却装置が停止しました。Microsoft の公開事後レビューでは、影響範囲は 3 つの可用性ゾーンのうち 1 つのゾーン内のサブセットとされています。1 社の障害事例から他社の分離度の優劣を読み取ることはできません。判断材料になるのは、各社が公開している設計基準と、事後レビューがどの粒度で公開されるかという運用姿勢です。
マルチ AZ 設計のベストプラクティス
AZ の分離が優れていても、アプリケーション側がマルチ AZ を前提に設計されていなければ、その恩恵は得られません。AWS はマルチ AZ 設計を容易にするサービスとツールを豊富に提供しています。RDS のマルチ AZ デプロイメントは、プライマリとスタンバイを異なる AZ に自動配置し、障害時に自動フェイルオーバーします。ELB (Elastic Load Balancing) は、有効化した複数の AZ へトラフィックを分散します。AZ をまたいで振り分ける cross-zone load balancing の既定値はロードバランサー種別で異なり、Application Load Balancer は既定で有効、Network Load Balancer は既定で無効です。NLB でターゲット数の偏りによる負荷の偏りを避けたい場合は、この設定を明示的に有効にするか、各 AZ へ同数のターゲットを配置します。Auto Scaling グループは複数の AZ にインスタンスを分散配置し、特定の AZ が利用不能になった場合は残りの AZ でキャパシティを自動補充します。ただし、これらのサービスでも「複数の AZ を有効にしておく」「AZ ごとに十分なキャパシティを確保しておく」という利用側の設定が前提になります。サブネットを 1 つの AZ にしか作っていない、Auto Scaling グループの最小台数が 1 台のまま、single-AZ 構成の RDS を使っている、といった状態では、サービス側の分散機能は働きません。マルチ AZ 設計とは、対応サービスを選ぶことではなく、各サービスの AZ 関連設定を意図して選び切ることです。
AZ 間通信の低レイテンシ - 分離と接続の両立
物理的に分離しつつも、AZ 間の通信レイテンシを低く保つことは、マルチ AZ アーキテクチャの実用性に直結します。AWS は AZ 間を専用の高帯域・低レイテンシネットワークで接続しており、AZ 間のラウンドトリップレイテンシは通常 1〜2 ミリ秒以内です。この低レイテンシにより、同期レプリケーション (RDS マルチ AZ、EFS) やリアルタイムのフェイルオーバーが実用的な速度で動作します。分離と接続は本来トレードオフの関係にありますが、AWS は専用のダークファイバーネットワークへの投資によって、このトレードオフを高いレベルで解決しています。AZ 間の通信にはデータ転送料金が発生しますが、これは AZ 間の専用ネットワークインフラの維持コストを反映したものであり、同一 AZ 内の無料通信とのコスト差を理解した上で設計に組み込む必要があります。
まとめ
AWS の AZ 設計は、2008 年 3 月の提供開始以降、物理的分離の設計基準の公開、障害事例を踏まえた改善、マルチ AZ を前提としたサービス設計の積み上げによって整備されてきました。Azure は 2018 年に可用性ゾーンを一般提供し、GCP は Google の大規模分散システムの知見を反映したゾーン設計を持ちます。横並びの比較が難しいのは、公開されている設計基準の粒度も、障害の事後レビューの公開範囲も各社で異なるためです。したがってクラウド選定では、可用性ゾーンという言葉の有無ではなく、使いたいリージョンで実際に選べるゾーン数、利用するサービスがゾーンをまたぐ動作をどう既定しているか、障害時の事後レビューがどこまで公開されるかを個別に確認するのが実務的です。そのうえで最後に効くのは、選んだクラウドの分離設計を活かせるよう、アプリケーション側をマルチ AZ 前提で組めているかどうかです。
参考資料 (AWS 公式)
本ページの一次情報は AWS 公式サイトおよび公式ドキュメントです。最新の仕様 / 料金は次の公式ページで確認できます。
本ページと公式ドキュメントの記述が食い違う場合は、公式ドキュメントを正としてください。