マルチAZ設計は、その一本の回線を守ってくれない — 2021年9月 東京リージョン Direct Connect障害に学ぶ
2021年9月2日に東京リージョンで発生したAWS Direct Connect障害を、AWS公式のポストイベントサマリーの記載だけを材料に整理します。原因はネットワークデバイスOS内の潜在的な不具合で、影響はDirect Connect経由の通信に限定されました。マルチAZ設計の外側にある接続経路をどう冗長化するかという設計論点に落とします。
- #Direct Connect
- #AWS障害
- #ネットワーク設計
- #BGP
- #SRE
2021年9月2日、AWSの東京リージョン（AP-NORTHEAST-1）でDirect Connectの通信障害が発生し、復旧の宣言までおよそ6時間強を要しました。AWSが公開しているポストイベントサマリーは、原因を「ネットワークデバイスのオペレーティングシステム内に存在していた潜在的な不具合」と説明しています。報道では冷却設備の障害と混同されることがありますが、それは対象外の別インシデント（2019年8月）の話であり、本障害の公式説明とは異なります。
この記事は、AWS公式サマリーに書かれている事実だけを材料に、何が起きたのかと、Direct Connectの接続経路がマルチAZ設計の外側にどう位置しているのかを整理します。対象は、オンプレミス環境とAWSをDirect Connectで接続している設計者・SREの読者です。
Direct Connectの位置づけ — マルチAZ設計が守らない範囲
Direct Connectは、顧客のデータセンターとAWSのVPCを専用線で結ぶサービスです。AWS公式サマリーの記載によれば、AWSと顧客が相互接続するエッジロケーションから、東京リージョンのデータセンターネットワーク（顧客のVPCが存在する場所）まで、複数のネットワークレイヤーを経由してトラフィックを転送する構成になっており、各レイヤーには冗長なネットワークデバイスが多数配置されています。
一方、AZ（アベイラビリティーゾーン）はリージョン内の独立した設備群で、多くのアーキテクチャはAZをまたいで冗長化することで、1つのAZが失われても稼働を継続できるように設計されます。しかし、このマルチAZ設計が守るのはAWSのリージョン内部の話です。オンプレミス環境からAWSまでの接続経路——つまりDirect Connectそのもの——は、AZ冗長化の設計方針の外側にある、独立した障害ドメインです。VPC内部をどれだけAZ分散しても、その手前の接続経路が単一障害点であれば、接続自体が失われる可能性は残ります。
何が起きたか — 発生時刻・影響範囲・復旧までの時系列
AWS公式サマリー「Summary of AWS Direct Connect Event in the Tokyo (AP-NORTHEAST-1) Region」によると、障害は2021年9月2日午前7時30分JSTに始まりました。この時刻、社内アラームが東京リージョン向けDirect Connect通信のパケットロス増加をエンジニアに知らせ、顧客は断続的な接続障害とパケットロスの増加を経験し始めました。
エンジニアの調査で、Direct Connectネットワークのあるレイヤーで複数台のデバイスが正常にトラフィックを転送できなくなっていたことが判明しました。本来であれば、故障したデバイスを監視・除去する通常の自動化プロセスによってネットワークから切り離されるはずでしたが、このときは切り離されていませんでした。自動化は通常より高い故障率を検知してエンジニアに調査を促し、エンジニアは冗長性が十分にあると判断して影響デバイスを順次サービスから外し始めました。並行して原因調査も進められましたが、デバイスを除去する対応は一時的な緩和にとどまり、他の複数デバイスでも同様の故障が続けて発生し、ネットワークの輻輳・接続障害・パケットロスの増加につながりました。
正午（12:00 PM JST）、エンジニアは、ネットワークの収束時間短縮のために導入されていた新しいプロトコルが関係している疑いを持ちました。このプロトコルは数ヶ月前から本番投入されており、それまで問題なく稼働していたものです。エンジニアは、この新プロトコルと、当該レイヤーのネットワークデバイス上での新しいトラフィックパターンとの相互作用を疑い、まず単一のAZでプロトコルを無効化して復旧の兆候を確認しながら、東京リージョン全体へ変更を展開する準備を並行して進めました。顧客側で回復の兆候が見え始めたのが12:30 PM JST、影響を受けたネットワークデバイスが安定稼働の状態に戻り、Direct Connectサービスが通常運用に復帰したのが1:42 PM JSTです。
この間、AZ間の通信、リージョンへのインターネット接続、AWS Virtual Private Network（VPN）接続（一部の顧客がDirect Connectのバックアップとして利用しているもの）、そして他のAWSリージョンへのDirect Connect通信は、いずれも影響を受けなかったとAWSは明記しています。
AWSが説明する原因 — ネットワークデバイスOS内の潜在的な不具合
AWSは障害発生後も根本原因の特定を続け、原因は「ネットワークデバイスのオペレーティングシステム内に存在していた潜在的な不具合」であったと公式に結論づけています。冷却設備の障害ではありません（冷却設備が原因とされたのは、本障害とは対象が異なる2019年8月の別インシデントです）。
このOSバージョンは、ネットワークのフェイルオーバー時間を改善するための新しいプロトコルを有効化するものでした。新しいOSとプロトコルは2021年1月に初めて本番投入され、その後8ヶ月にわたって全AWSリージョンへ段階的に展開され、この潜在的な不具合の兆候なくDirect Connect顧客のトラフィックを処理し続けていました。AWSは、専用ラボでのストレステストを含む、制御・自動化・テスト済みの手順でOS変更を行っていると説明しつつ、それでもラボ環境ですべてのトラフィックとパケットの組み合わせを検証することはできないとも述べています。
調査の結果、この不具合は「非常に限定的な、特定のパケット属性と内容の組み合わせ」がそろったときにのみ発現することが判明しました。この条件は極めて限定的かつ発生しにくいものですが、今回はある顧客のトラフィックが、たまたまこの条件に一致するパケットを継続的に生成していたことで障害が引き起こされました。AWSは、悪意のあるトラフィックを疑う理由はないとも明記しています。
設計論点 — Direct Connectという独立した障害ドメインへの備え
AWS公式サマリーの記載から読み取れるのは、Direct Connectの接続経路が、マルチAZ設計とは独立した障害ドメインだという点です。AZをまたいで冗長化された構成であっても、オンプレミスからAWSまでの接続経路そのものが単一の物理拠点・単一の回線に依存していれば、その経路の障害は防げません。加えて、今回の原因がネットワーク機器のOS内の潜在バグであり、しかも特定のパケット条件でのみ発現する性質だったことは、通常の監視だけでは事前に検知しにくいという教訓でもあります。
この前提に立つと、設計上の備えは大きく3つに整理できます。
1. 複数のDirect Connectロケーションでの接続：AWSはDirect Connectを、地理的に離れた複数の物理ロケーション（Direct Connectロケーション）から確立できる構成を用意しています。1つのロケーション・1本の回線に依存する構成では、そのロケーションや経路上のデバイス層に障害が起きたときに接続そのものが失われます。複数ロケーションからの接続は、この単一障害点を分散させる基本の備えです。
2. Direct ConnectとSite-to-Site VPNのフェイルオーバー構成：今回の障害でAWSは、「一部の顧客がDirect Connectのバックアップとして利用しているVPN接続は影響を受けなかった」と明記しています。Direct Connectを主経路、Site-to-Site VPNをインターネット経由の代替経路として構成しておけば、Direct Connect側の障害ドメインで問題が起きても、通信そのものを維持できる可能性があります。
3. BGP経路切替の実運用テスト：複数経路を用意していても、実際に切り替えが機能することを事前に検証していなければ、障害発生時に初めてつまずくことになります。BGP（経路制御プロトコル）による経路切替やフェイルオーバーの動作を、平常時に計画的なテストとして実施しておくことが、備えを機能させる前提になります。
まとめ
- 2021年9月2日の東京リージョンDirect Connect障害は、午前7時30分から午後1時42分までの約6時間強、Direct Connect経由の通信のみに影響を及ぼしました。AZ間通信・インターネット接続・VPN接続・他リージョンへのDirect Connectは影響を受けていません。
- 原因はAWS公式が明記する通り、ネットワークデバイスOS内の潜在的な不具合であり、特定のパケット属性と内容の組み合わせがそろったときにのみ発現する条件付きのバグでした。冷却設備の障害ではありません。
- マルチAZ設計は、オンプレミスからAWSまでの接続経路そのものの単一障害点までは守ってくれません。複数ロケーションでの接続、VPNとのフェイルオーバー構成、BGP経路切替の実運用テストという3つの備えが、この障害ドメインに対する設計上の論点です。