東京リージョンのAZ障害(2019)に学ぶ — マルチAZを"本当に効かせる"信頼性設計

「複数のアベイラビリティゾーン（AZ、地理的・電源的に分離された独立したデータセンター群）に置けば安心」――この前提は本当でしょうか。2019年に東京リージョンで起きた単一AZの障害は、その問いに具体的な材料を与えてくれます。本記事は、何が起きたかの解説は簡潔にとどめ、AZ障害が起こる前提で「マルチAZを本当に効かせる」設計判断に重心を置きます。題材にする事実はすべてAWS公式のPES（Post-Event Summary、障害の事後サマリー）に基づく当時のもので、設計原則は公式ドキュメントを典拠にします。AWSへの批判ではなく、設計の学びとして読める内容です。

何が起きたか（公式PESに基づく事実）

2019年8月23日、東京リージョン（AP-NORTHEAST-1）の単一のAZで障害が発生しました。時刻はJSTで、12時36分に始まり、18時30分までに大半が復旧しています。根本原因は制御システムの故障で、冗長化されていたはずの複数の冷却システムが同時に停止しました。フェイルオーバーの動作中に、サードパーティ製の制御システムのロジックの不具合が制御システムとデバイス間の過剰なやり取りを引き起こし、システムが応答不能になって過熱に至りました。

影響は、当該AZの一部のEC2サーバーが過熱で停止し、EBSボリュームの性能が劣化するというものでした。二次的に、13時21分JST以降、EC2のRunInstances APIのエラー率が上昇し、特に冪等性トークンの処理やAuto Scalingに影響が出ました。復旧はJSTで、14時51分に冪等性トークンとAuto Scalingの問題が解消、15時21分に冷却システムが復旧、16時05分にEC2コントロールプレーンが復旧し、18時30分までに大半のインスタンスとボリュームが回復しました。

ここで強調すべきは、これが単一AZの事象だったという点です。公式は、リージョン内の他のAZのEC2インスタンスとEBSボリュームは影響を受けなかったと明記しています。「東京リージョン全体が停止した」わけではありません。

なお、根本原因分析の完了日、サードパーティ（ベンダー）の特定、影響を受けた顧客数や台数の具体は公式PESに記載がありません。本記事でも推測しません。

ここからは設計の話：事実と原則を分けて読む

以下の設計原則は、公式PESが「こう設計せよ」と述べているものではありません。障害の事実（前章）と、AWS Fault Isolation Boundaries や Well-Architected などが示す一般原則を切り分けたうえで、後者を教訓として接続します。今回の最大の教訓は、公式が明言した「複数のAZにまたがって運用していた顧客は可用性を維持できた」という一文に集約されます。

B① 単一AZ依存を捨てる（マルチAZが効いた実例）

決めるのは「重要系をどのAZ構成に置くか」です。EC2やEBSはAZに局所のリソースで、AZ障害の影響を直接受けます。公式が「マルチAZ運用の顧客は可用性を維持した」と明言した事実は、最も再現性の高い教訓です。重要なワークロードは最低でも2つのAZに分散します。

コンポーネント	単一AZ依存	2AZ化の手立て
EC2	あり	複数AZへ分散配置・ASGのAZ分散
EBS	あり（AZ内資源）	スナップショット・別AZ再アタッチ前提
RDS	構成次第	Multi-AZ配置（別AZに同期スタンバイ）

この背景には、AWS Fault Isolation Boundaries が示す原則があります。AZは電源・冷却・ネットワークを共有しない独立した障害ドメインとして設計され、相関した故障を避けるとされています。今回の冷却系の故障が単一AZにとどまった事実は、この境界が機能した一例と読めます。

注意したいのは、「マルチAZに置く」ことと「マルチAZが効く」ことは別だという点です。インスタンスを複数AZに並べていても、片方のAZが落ちたときに残りのAZだけで処理をさばける容量がなければ、結局はサービスが劣化します。AZを2つに分散するなら、片側が失われても耐えられる容量を見込んでおくこと、そしてフェイルオーバーが実際に機能するかを平時にテストしておくことが、「効かせる」設計の条件になります。トレードオフは、AZ分散には構成の複雑さと余剰容量のコストが伴う点です。すべてを多重化するのではなく、停止が許されない重要系から優先します。

B② ステートフル資源（EBS）の冗長化

決めるのは「状態をどう守るか」です。EBSはAZ内のリソースのため、AZ障害では道連れになり得ます。スナップショット（S3に保存されリージョン耐久性を持つ）やレプリケーション、別AZへの再アタッチを前提とした運用が要点です。

ステートフル資源	AZ障害時の挙動	冗長化策
EBSボリューム	性能劣化・アクセス不能の恐れ	スナップショットのリージョン保管・別AZ再アタッチ
自前DB on EC2	AZと運命を共にする	別AZへのレプリケーション
RDS	Multi-AZなら自動退避	RDS Multi-AZ配置の採用

データベースは、RDSのMulti-AZ配置を使うと、別AZに同期スタンバイを維持し、障害時に自動でフェイルオーバーします。状態を持つ資源ほど、AZ境界を越えた退避先を平時から用意しておくことが効きます。

B③ 回復局面の冪等性とAuto Scaling

決めるのは「回復のときに自分が二次被害を起こさない設計」です。今回はRunInstancesの冪等性トークン処理やAuto Scalingがエラー率の上昇で詰まりました。API呼び出しが失敗したときのリトライと冪等性を正しく設計しておくと、回復局面での連鎖を抑えられます。

具体的には、指数バックオフにjitter（リトライ時刻のばらつき）を加えて再試行の集中を防ぎ、副作用を伴う操作には冪等キーで二重実行を避けます。これは障害の規模が違っても共通するクライアント設計の基本で、リージョン規模の障害を扱った別記事のクライアント設計とも呼応します。

B④ リージョン障害とAZ障害を分けて考える

決めるのは「障害の粒度ごとに対策を変える」ことです。障害には粒度があり、効く対策も異なります。粒度の地図を持っておくと、過不足のない投資ができます。

粒度	典型的な事象	効く対策
AZ規模	単一AZの設備・冷却障害（本件）	マルチAZ分散・ステートフル資源の冗長化
リージョン規模	コントロールプレーンの連鎖障害	マルチリージョン・依存の切り離し

本件はAZ規模・ステートフル資源の話で、足元のAZ境界を固める回です。一方、コントロールプレーンの連鎖でリージョン規模に広がる障害は、別の粒度の対策（マルチリージョンや依存の隔離）を要します。両者を混同すると、AZ分散だけで安心してリージョン規模の連鎖に無防備になったり、逆に過剰にマルチリージョン化してコストを払いすぎたりします。まず自分のワークロードがどの粒度の障害に弱いかを見極め、そこから順に手当てするのが現実的です。

設計レビューでは、Well-Architected Tool などを使い「このコンポーネントは単一AZに依存していないか」を観点として組み込みます。粒度の地図を持っておくと、レビューでの抜け漏れも減ります。

B⑤ 東京で明日できる備え

最後に、明日から着手できる点検をまとめます。

備え	具体策
重要系の2AZ以上展開	単一AZ偏在の洗い出し
Auto Scalingの分散	ASGが複数AZにまたがる設定か確認
データベースの冗長化	RDS Multi-AZ配置の採用
バックアップの保管先	EBSスナップショットをリージョンに保管
縮退運転の手順	一部AZ喪失時に主機能を維持する運転
障害検知の自動通知	Health DashboardとEventBridgeの連携

まとめ

マルチAZは「置く」だけでは効きません。AZ障害を前提に、ステートフル資源の退避先を用意し、回復局面の冪等性まで設計して初めて「効かせる」ことができます。今回の教訓は、単一AZ依存を捨てる、状態を持つ資源を冗長化する、回復のときに二次被害を起こさない、という3点でした。これらはAZ規模の足元を固める対策であり、リージョン規模の障害への備えとは粒度が異なります。粒度ごとに対策の地図を持つことが、過不足のない信頼性投資につながります。仕様は改定されうるため、設計の適用前に公式の最新情報をあわせてご確認ください。