AWS の Advanced Multi-AZ Resilience Patterns を参照して AZ 退避パターンを整理してみた
はじめに
テクニカルサポートの 片方 です。
AWS で高可用性を考えるうえで、Multi-AZ 構成は基本的な設計パターンの 1 つです。
ただし、Multi-AZ 構成にしていればすべての障害に対応できる、というわけではありません。特定の AZ だけでレイテンシーが悪化したり、特定の AZ から依存先サービスへの通信だけが不安定になったりすることがあります。
AWS の Whitepaper Advanced Multi-AZ Resilience Patterns では、このような検出しづらい障害をグレー障害として扱い、観測や障害検出、AZ 退避の考え方が整理されています。
このブログでは、グレー障害への備え方と AZ 退避パターンについて、以下の流れで整理します。
- 先に結論から
- グレー障害とは
- Multi-AZ オブザーバビリティ
- 単一 AZ に影響する障害の検出方法
- AZ 退避パターン
Multi-AZ 構成を採用している方や、レジリエンス設計を見直したい方の参考になれば幸いです。
先に結論から
本記事の結論は、Multi-AZ 構成を採用するだけでなく、AZ 単位で「観測する」「判断する」「退避する」仕組みまで設計しておくことが重要という点です。
Multi-AZ 構成は可用性を高める有効な設計パターンですが、特定の AZ や特定の通信経路だけに影響が出るようなグレー障害では、リージョン全体のメトリクスや AWS サービス側の標準的なヘルスチェックだけでは、ワークロードへの影響を把握しきれない場合があります。
そのため、レジリエンス設計では以下の流れを事前に整理しておくことが重要です。
-
観測する
AZ 単位で可用性、レイテンシー、エラー率、スループットなどを確認できるようにする。 -
判断する
障害が単一インスタンスの問題なのか、単一 AZ に限定された問題なのか、複数 AZ やリージョン全体に影響する問題なのかを切り分ける。 -
退避する
影響を受けた AZ に新しいリクエストや処理を送らない手段を用意し、必要に応じて新しいキャパシティも配置されないようにする。
この 3 つは個別に考えるのではなく、セットで設計する必要があります。
AZ 単位のメトリクスを収集していても、退避手段がなければ復旧アクションにつながりません。一方で、退避手段だけを用意しても、どの AZ を退避すべきか判断できなければ安全に運用できません。
つまり、Multi-AZ 構成を本当にレジリエントにするには、単に複数の AZ にリソースを配置するだけでなく、AZ 単位で状態を把握し、影響範囲を判断し、必要に応じて退避できる状態にしておくことが重要です。
以降では、この考え方を前提に、グレー障害の概要、Multi-AZ オブザーバビリティ、単一 AZ に影響する障害の検出方法、AZ 退避パターンについて整理しました。
グレー障害とは
まず、グレー障害について説明します。
こちらは、ある視点からは障害として見えているものの、別の視点からは明確な障害として見えにくい状態を指します。
たとえば、ワークロードを利用しているユーザーやアプリケーションから見るとエラー率やレイテンシーが悪化している一方で、依存している AWS サービス側の標準的なヘルスチェックでは異常として検出されない場合があります。
Multi-AZ 構成では、特定の Availability Zone に配置されたリソースや、特定の AZ から依存先サービスへの通信経路だけに影響が出ることがあります。このような場合、リージョン全体やサービス全体のメトリクスだけを見ていると、影響が平均化されてしまい、問題に気づきにくくなります。
たとえば、以下のようなケースが考えられます。
- 特定の AZ に配置されたアプリケーションサーバーだけでエラー率が上昇する
- 特定の AZ からデータベースへの通信だけレイテンシーが悪化する
- 特定の AZ のワーカーだけがキューの処理に失敗する
- 一部の AZ では正常に処理できているため、全体のヘルスチェックでは問題が見えにくい
このようなグレー障害に対応するには、単にリソースを複数の AZ に配置するだけでは不十分です。
ワークロード側で AZ 単位のメトリクス を収集し、どの AZ で、どのような影響が出ているのかを判断できるようにしておく必要があります。
特に重要なのは、障害を AWS サービス単位ではなく、ワークロードの利用者視点 で捉えることです。サービス側のヘルスチェックが正常であっても、アプリケーションの可用性、レイテンシー、エラー率、スループットに影響が出ていれば、ワークロードとしては対応が必要な状態です。
そのため、グレー障害への備えとしては、以下のような観点が重要になります。
- AZ ごとに可用性、レイテンシー、エラー率、スループットを確認できるようにする
- 単一インスタンスの問題なのか、AZ 単位の問題なのかを切り分けられるようにする
- リージョン全体の障害と単一 AZ に限定された障害を区別できるようにする
- 影響を受けた AZ へトラフィックや処理を流し続けない仕組みを用意する
つまり、グレー障害は 「AWS サービスが完全に停止しているわけではないが、ワークロード視点では影響が出ている状態」 と捉えることが重要です。
Multi-AZ オブザーバビリティ
グレー障害を検出するためには、まず AZ 単位でワークロードの状態を確認できることが重要です。
Multi-AZ 構成では、複数の Availability Zone にリソースを分散します。ただし、メトリクスをリージョン全体やサービス全体で集計しているだけでは、特定の AZ で発生している影響が平均化され、問題に気づきにくくなる場合があります。
たとえば、3 つの AZ にアプリケーションを配置している構成で、1 つの AZ だけエラー率が上昇しているとします。この場合、サービス全体のエラー率だけを見ると小さな変化に見えても、該当 AZ を利用しているリクエストでは明確な影響が出ている可能性があります。
そのため、Whitepaper では、ワークロードが提供するカスタマーエクスペリエンスを AZ 単位で可視化することの重要性が説明されています。AWS サービスが提供する標準メトリクスだけでなく、アプリケーション側で可用性、レイテンシー、エラー数などを計測するためのインストルメンテーションが必要になります。
AZ 単位で見たいメトリクス
AZ 単位で確認したい代表的なメトリクスは、以下のようなものです。
- 可用性
- レイテンシー
- エラー数またはエラー率
- スループット
- 依存先サービスへの呼び出し成功率
- キュー処理の成功率や処理遅延
インフラリソースが正常に見えていても、アプリケーションのリクエスト成功率やレスポンスタイムに影響が出ていれば、ワークロードとしては対応が必要な状態です。そのため、ユーザー体験に近いメトリクスを収集し、AZ 単位で確認できるようにしておくことが重要です。
メトリクスには障害分離境界に沿ったディメンションを付ける
AZ 単位で状態を確認するには、メトリクスやログに AZ を識別できる情報を含める必要があります。
たとえば、以下のようなディメンションを持たせると、あとから分析しやすくなります。
- Region
- AZ-ID
- InstanceId
- ServiceName
- Operation
- HttpMethod
- StatusCode
Whitepaper では、Web アプリケーションの例として、Region、Availability Zone ID、Controller、Action、InstanceId などのディメンションを使う考え方が紹介されています。マイクロサービスの場合は、Controller や Action の代わりにサービス名や HTTP メソッドを使う考え方も示されています。
特に複数の AWS アカウントをまたいで運用する場合は、AZ 名ではなく AZ ID を使うことが重要です。
us-east-1a のような AZ 名は、AWS アカウントごとに実際の物理 AZ との対応が異なる場合があります。一方で、use1-az1 のような AZ ID を使うことで、同じ物理 AZ を一貫して識別しやすくなります。
AWS は、物理アベイラビリティーゾーンを AWS アカウントごとのアベイラビリティーゾーン名にランダムにマップします。このアプローチは、AWS リージョン 内のアベイラビリティーゾーンにリソースを分散するうえで役立ち、各リージョンのアベイラビリティーゾーン「a」にリソースが集中しなくてすみます。その結果、自分の AWS アカウントのアベイラビリティーゾーン us-east-1a が、異なる AWS アカウントについては us-east-1a と同じ物理的な場所を表さない可能性があります。
サーバー側とクライアント側の両方から観測する
グレー障害では、サーバー側のメトリクスだけでは影響を把握しきれない場合があります。
そのため、アプリケーションサーバー側で出力するメトリクスに加えて、Canary などを使ったクライアント側の観測も有効です。
たとえば、以下のような観測を組み合わせると、より多面的に状態を把握できます。
- アプリケーションサーバー側のリクエスト成功率
- ロードバランサー側の HTTP ステータスコード
- 依存先サービスへの呼び出し結果
- Canary による外形監視
- ユーザー体験に近いレイテンシー指標
CloudWatch で扱いやすい形にしておく
AWS 環境では、Amazon CloudWatch を中心にメトリクス、ログ、アラーム、ダッシュボードを設計することが多いと思います。
アプリケーションログからカスタムメトリクスを生成する場合は、CloudWatch Embedded Metric Format を利用することで、ログとメトリクスを関連付けて扱いやすくなります。また、CloudWatch Contributor Insights を使うことで、特定のインスタンスやディメンションがエラーにどの程度寄与しているかを分析しやすくなります。
ここまでのポイントをまとめると、Multi-AZ オブザーバビリティでは、以下を意識するとよさそうです。
- サービス全体だけでなく、AZ 単位で状態を確認できるようにする
- インフラメトリクスだけでなく、アプリケーション視点のメトリクスを収集する
- メトリクスやログに AZ-ID などのディメンションを含める
- サーバー側とクライアント側の両方から観測する
- 障害検出や AZ 退避の判断に使える粒度でメトリクスを設計する
Multi-AZ オブザーバビリティは、単なる監視強化ではなく、後述する「単一 AZ 障害の検出」や「AZ 退避判断」の前提になる部分です。
単一 AZ に影響する障害の検出方法
AZ 単位でメトリクスを収集できるようになったら、次に必要になるのは、その影響が単一 AZ に閉じているかを判断する仕組みです。
ここで重要なのは、単に「どこかでエラー率が上がった」ことを検知するだけでは不十分という点です。AZ 退避を行う場合は、少なくとも以下を切り分ける必要があります。
- 単一インスタンスや一部コンテナの問題なのか
- 単一 AZ に限定された問題なのか
- 複数 AZ またはリージョン全体に影響する問題なのか
- 共有リソースが原因で複数 AZ に影響しているのか
単一 AZ に影響する障害を検出する方法として、主に 3 つの考え方が紹介されています。
CloudWatch 複合アラームで検出する
1 つ目は、Amazon CloudWatch のメトリクスアラームと複合アラームを組み合わせる方法です。
考え方としては、まず AZ ごとに可用性やレイテンシーのアラームを作成します。そのうえで、複合アラームを使って、特定の AZ で可用性が低下している、またはレイテンシーが悪化していることを判断します。
さらに、単一 AZ に限定された影響を検出するには、以下のような条件を組み合わせます。
- 対象 AZ のアラームが ALARM 状態である
- 他の AZ のアラームは OK 状態である
- 単一インスタンスだけの問題ではない
1 つの AZ のアラームが ALARM 状態で、他の AZ のアラームが OK 状態であることを使って、単一 AZ に分離された影響を検出する考え方が紹介されています。
ただし、ここで注意したいのは、1 台のインスタンスや一部のコンテナだけが問題を起こしているケースです。この場合、AZ 全体の障害のように見えていても、実際には特定のリソースを置き換えるだけで解決できる可能性があります。
そのため、CloudWatch Contributor Insights などを使い、エラーに寄与しているインスタンス数やコンテナ数を確認することが重要です。Whitepaper では、5xx エラーに対する寄与要因を InstanceId で確認し、単一インスタンスの問題ではないことを判断する例が紹介されています。
なお、複合アラームの実装については、弊社ブログをご参考ください。
外れ値検出で AZ 間の偏りを見る
2 つ目は、AZ 間でエラーの分布に偏りがないかを見る方法です。
CloudWatch 複合アラームによる判定では、「対象 AZ は ALARM、他の AZ は OK」という条件を使えます。
その一方で、現実には複数の AZ で多少のエラーが発生している場合もあります。
たとえば、ある AZ では大きくエラー率が上昇し、別の AZ では無関係な理由で一部のエラーが発生しているケースです。このような場合、単純に他の AZ が OK であることだけを条件にすると、単一 AZ の大きな影響を見逃す可能性があります。
このようなケースでは、外れ値検出を使い、エラーが特定の AZ に統計的に偏っているかを確認します。
AZ 間のエラー数に統計的に有意な偏りがあるかを判断する方法として、カイ二乗検定 を使う例が紹介されています。
この方式は、通常の CloudWatch アラームだけで完結させるというより、メトリクスを取得・集計し、判定結果を新しいカスタムメトリクスとして出力する実装として考えると理解しやすいです。
単一インスタンスのゾーンリソースに注意する
3 つ目は、単一インスタンスのゾーンリソースに対する検出です。
ここでいう単一インスタンスのゾーンリソースとは、たとえば Amazon RDS のプライマリインスタンスや、Amazon ElastiCache のプライマリノードのように、ある時点でアクティブなリソースが特定の AZ に存在する構成を指します。
このようなリソースが影響を受けると、そのリソースにアクセスする複数の AZ からの処理に影響が出る可能性があります。その結果、すべての AZ でエラー率やレイテンシーが悪化し、単一 AZ に閉じた障害としては見えにくくなります。
Amazon RDS のプライマリインスタンスや Amazon ElastiCache のプライマリノードなど、ある時点で特定の AZ にアクティブなコンポーネントが存在するシステムでは、プライマリリソースが存在する AZ の障害が、他の AZ からのアクセスにも影響する可能性があると説明されています。
この場合は、リソース自身のメトリクスだけでなく、そのリソースを利用する側のメトリクスも確認することが重要です。具体的には、以下のような観点を見ます。
- 共有リソースへのリクエスト成功率
- 読み取りや書き込みのレイテンシー
- トランザクション数や処理件数
- 複数 AZ から見た依存先呼び出しの失敗状況
- メトリクスが欠損していないか
特に、障害時に対象リソースがメトリクスを出力できなくなる可能性もあります。そのため、重要なメトリクスについては、欠損データをどのように扱うかも設計しておく必要があります。
重要なメトリクスが報告されなくなったことを検出するために、欠損データを違反として扱うアラーム設定についても言及されています。
検出方法は組み合わせて考える
これらの検出方法は、どれか 1 つを選べば十分というより、ワークロードの特性に応じて組み合わせて使うものだと感じました。
整理すると、以下のようになります。
| 検出方法 | 主な目的 |
|---|---|
| CloudWatch 複合アラーム | AZ 単位の可用性やレイテンシー悪化を検出する |
| CloudWatch Contributor Insights | 単一インスタンスや一部リソースの問題ではないかを確認する |
| 外れ値検出 | 複数 AZ でエラーがある中でも、特定 AZ への偏りを確認する |
| 共有リソース向けの検出 | RDS や ElastiCache など、特定 AZ に存在する重要リソースの影響を確認する |
特に実運用では、以下のようなガードレールを用意しておくと安全性が高まります。
- 単一 AZ に影響が閉じていることを確認する
- 単一インスタンスの問題ではないことを確認する
- 残りの AZ に十分なキャパシティがあることを確認する
- 自動退避する場合は、誤検知時に影響が拡大しないよう制御する
- 退避判断に使ったメトリクスとアラームを後から確認できるようにする
このように、障害検出は単なるアラート通知ではなく、AZ 退避を安全に実行するための判断材料をそろえる仕組みとして設計する必要がありそうです。
AZ 退避パターン
単一 AZ に影響する障害を検出できたら、次に考えるのは 影響を受けた AZ からどのように退避するかです。
AZ 退避の目的として大きく以下の 2 つが説明されています。
- 影響を受けている AZ に新しいリクエストや処理を送らないこと
- 影響を受けている AZ に新しいキャパシティを配置しないこと
なお、ここで重要になるのが、データプレーン と コントロールプレーン の考え方です。
-
データプレーン
既存のリソースが実際にリクエストやデータを処理する経路です。
たとえば、ロードバランサーがリクエストを振り分ける、Amazon EC2 インスタンスがアプリケーションを実行する、Amazon DynamoDB が読み書きを処理する、といった処理が該当します。 -
コントロールプレーン
リソースの作成、削除、設定変更などを行う管理用の経路です。
たとえば、Auto Scaling グループの設定を変更する、Amazon ECS サービスのネットワーク設定を更新する、AWS Lambda 関数の VPC 設定を変更する、といった操作が該当します。
AZ 退避では、まずデータプレーン側で影響を受けた AZ に新しい作業を送らないことを考えます。そのうえで、必要に応じてコントロールプレーン側で影響を受けた AZ に新しいキャパシティを配置しないようにします。
障害時はコントロールプレーンの操作が期待どおり実行できるとは限らないため、初動としてはデータプレーン制御の退避を優先し、必要に応じてコントロールプレーン制御で追従する、という整理が分かりやすそうです。
データプレーン制御の退避
まず検討したいのが、データプレーン制御の退避 です。
これは、既存のリソース設定を大きく変更するのではなく、トラフィックや処理の流れを制御して、影響を受けた AZ に新しいリクエストや処理を送らないようにする方法です。
代表的な方法として、Amazon Application Recovery Controller (ARC) の zonal shift と、Route 53 ARC ルーティングコントロールを用いた DNS ベースの退避 があります。Application Load Balancer や Network Load Balancer など、ARC zonal shift に対応したリソースでは、障害が発生した AZ から同一リージョン内の正常な AZ へトラフィックを一時的にシフトできます。
なお、この方式は退避操作をシンプルにしやすい一方で、zonal shift を開始する前に、残りの AZ で退避対象 AZ のトラフィックを受けられるように事前にスケールしておくことが前提になります。
コントロールプレーン制御の退避
データプレーン制御だけでは、影響を受けた AZ に新しいキャパシティが配置されることを防げない場合があります。
その場合は、コントロールプレーン制御の退避も検討します。これは、各 AWS サービスの設定を変更し、影響を受けた AZ のサブネットを利用対象から外す方法です。
ただし、コントロールプレーン制御は各サービスの API や設定変更に依存します。サービスごとに更新時の挙動も異なるため、障害時の初動として使えるかは事前検証が必要です。
例として、以下のような対応があります。
| サービス | 退避時の考え方 |
|---|---|
| AWS Lambda | VPC 設定から影響を受けた AZ のサブネットを外す |
| Auto Scaling グループ | ASG のサブネット設定から影響を受けた AZ を外す |
| Amazon ECS | ECS サービスのネットワーク設定から影響を受けた AZ のサブネットを外す |
| Amazon EKS | 影響を受けた AZ のノードに taint を付け、必要に応じて既存 Pod を退避・削除し、追加の Pod がスケジュールされないようにする |
障害時の初動としては、まずデータプレーン制御で影響 AZ への新しい作業を止め、必要に応じてコントロールプレーン制御で追従する、という流れが現実的かと思います。
実運用で意識したいこと
AZ 退避を設計する際は、以下を事前に整理しておくとよさそうです。
- どの AZ を退避対象にするかを AZ ID で判断できるようにする
- 退避操作をランブック化しておく
- 残りの AZ で処理できるキャパシティを確保しておく
- 誤検知で不要な退避を行わないようにする
- 退避後に元の構成へ戻す手順を用意しておく
AZ 退避は、単にトラフィックを切り替えるだけではなく、キャパシティや復旧手順も含めて設計する必要があります。
端的にまとめると、まずデータプレーン制御で影響を受けた AZ に新しいリクエストや処理を送らないようにし、必要に応じてコントロールプレーン制御で新しいキャパシティ配置も止める、という考え方で整理すると分かりやすいです。
まとめ
AWS の Advanced Multi-AZ Resilience Patterns では、Multi-AZ 構成をより実運用に強いものにするための考え方として、グレー障害の検出や AZ 退避パターンが整理されていました。
Multi-AZ 構成は可用性を高めるうえで有効ですが、それだけですべての障害に対応できるわけではありません。特に、特定の AZ や特定の通信経路だけに影響が出るグレー障害に備えるには、ワークロード側での観測と退避設計が重要です。
今回の内容をまとめると、以下の 3 点が特に重要だと感じました。
- AZ 単位で可用性、レイテンシー、エラー率、スループットを観測する
- 単一インスタンスの問題なのか、単一 AZ に影響する問題なのかを切り分ける
- 影響を受けた AZ に新しいリクエストや処理を送らない退避手段を用意する
また、AZ 退避では、まずデータプレーン制御で影響を受けた AZ へのトラフィックや処理を抑制し、必要に応じてコントロールプレーン制御で新しいキャパシティ配置も制御する、という考え方が分かりやすいと感じました。
Multi-AZ 構成を採用している場合でも、「複数 AZ に配置しているから安心」と考えるのではなく、AZ 単位で観測し、判断し、退避できるか まで確認しておくことが重要そうです。
本ブログが誰かの参考になれば幸いです。
参考資料
- マルチ AZ の高度なレジリエンスパターン - マルチ AZ の高度なレジリエンスパターン
- グレー障害 - マルチ AZ の高度なレジリエンスパターン
- マルチ AZ の可観測性 - マルチ AZ の高度なレジリエンスパターン
- AWS リソースのアベイラビリティーゾーン ID - AWS Resource Access Manager
- CloudWatch 複合アラームによる障害検出 - マルチ AZ の高度なレジリエンスパターン
- CloudWatch 複合アラームが利用可能になりました！！ | DevelopersIO
- 外れ値検出による障害検出 - マルチ AZ の高度なレジリエンスパターン
- 付録 B — カイ二乗計算の例 - マルチ AZ の高度なレジリエンスパターン
- 単一インスタンスのゾーンリソースの障害検出 - マルチ AZ の高度なレジリエンスパターン
- アベイラビリティーゾーンの退避パターン - マルチ AZ の高度なレジリエンスパターン
- データプレーン制御の退避 - マルチ AZ の高度なレジリエンスパターン
- コントロールプレーン制御による退避 - マルチ AZ の高度なレジリエンスパターン
クラスメソッドオペレーションズ株式会社について
クラスメソッドグループのオペレーション企業です。
運用・保守開発・サポート・情シス・バックオフィスの専門チームが、IT・AIをフル活用した「しくみ」を通じて、お客様の業務代行から課題解決や高付加価値サービスまでを提供するエキスパート集団です。
当社は様々な職種でメンバーを募集しています。
「オペレーション・エクセレンス」と「らしく働く、らしく生きる」を共に実現するカルチャー・しくみ・働き方にご興味がある方は、クラスメソッドオペレーションズ株式会社 コーポレートサイト をぜひご覧ください。※2026年1月 アノテーション㈱から社名変更しました
