9月2日木曜日に発生したAWS東京リージョンの大規模障害、原因はネットワークデバイスの新プロトコル処理に潜在的なバグがあったこと。AWSが報告書を公開

2021年9月2日木曜日午前7時半ごろに、Amazon Web Services（AWS）の東京リージョンで大規模な障害が発生しました。

NHKニュースの報道によると、三菱UFJ銀行やみずほ銀行のスマートフォン用アプリやSBI証券などネット証券のWebサイト、KDDIのau Payなど金融系サービスが影響を受けたほか、全日空では羽田空港などでチェックインを行うシステムに障害が発生、日本航空では貨物の情報に関わる一部のシステムに影響が出るなど、幅広い社会サービスが影響を受け、大きな問題となりました。

障害が発生したのは、企業のデータセンターなどからAWSへ専用線で接続するためのネットワーク接続サービス「AWS Direct Connect」。

障害は午後12時30分に復旧しはじめ、午後1時42分に解消しました。

この障害についてAWSが詳しい報告を「東京リージョン(AP-NORTHEAST-1)で発生したAWS Direct Connectの事象についてのサマリー」として公開しました。

長めで直訳調のやや読みにくい報告となっているため、本記事では、その概要を整理しつつ見ていきましょう。

午前7時半に障害発生、手動でネットワークデバイスを除外

報告によると、障害の原因はDirect Connectのロケーション、つまりDirect Connectが接続される場所から東京リージョンのデータセンターへの途中にあるネットワークデバイスで障害が起きたことだと説明されています。

「東京リージョン(AP-NORTHEAST-1)で発生したAWS Direct Connectの事象についてのサマリー」からポイントを引用します。

この事象は、Direct Connect ロケーションから、顧客の Virtual Private Cloud（VPC）が存在する東京リージョンのデータセンターネットワークへのネットワークパスに沿ったネットワークレイヤーの 1 つでネットワークデバイスの一部に障害が発生したことが原因です。

以下、障害発生から解決まで時系列でを、AWSの報告を基に整理していきましょう。

障害が発生した日、2021年9月2日の午前7時半、AWSのエンジニアがアラーム（警告）を検知。Direct Connectに関連したネットワークデバイスに障害が起きたことを知ります。

AWSの報告によると、障害が発生したネットワークデバイスは自動的にネットワークから除外される仕組みになっているようです。しかし今回の障害では、自動的に除外される代わりに、AWSのエンジニアに対して「修復せよ」との指示が発生していた模様。

これらのデバイスはトラフィックを正しく転送していませんでしたが、障害が発生したネットワークデバイスを監視および削除する通常の自動プロセスを通じてネットワークから除外されていませんでした。代わりに、この自動プロセスは、通常よりもデバイスの故障率が高いことを検知し、エンジニアに調査して修復措置を講じるよう警告しました。

エンジニアはこの警告に対し、修復するのではなく手動でデバイスを除外します。

エンジニアは、この警告を受けたとき、このレイヤに十分な冗長性があると判断し、正常なデバイスでトラフィックを処理できるように影響を受けているデバイスをサービスから除外しました。

しかし障害を起こすネットワークデバイスが増えていき、Direct Connectサービスの大規模障害へと拡大します。

その後いくつかの他のネットワークデバイスでも同じ障害が発生し、Direct Connect を利用中のお客様のネットワークに輻輳、接続の問題、またはパケットロスの増加が発生しました。

その後もエンジニアは復旧に努めたものの、サービス回復には至らず。

エンジニアは、故障したデバイスをリセットして徐々にサービスに戻すなど、いくつかの緩和を試みましたが、障害は継続し、エンジニアは適切なキャパシティを維持して顧客への影響を完全に軽減することができませんでした。

新しいプロトコルが原因と判明、午後1時42分に復旧

障害対応と並行して行われていた調査により、午後12時までに障害の原因が、何カ月か前にネットワークデバイスに導入された新しいプロトコルにあるのではないかと思い当たります。

しかし、エンジニアは、障害が Direct Connect ネットワークのある層にあるネットワークデバイス上における、新しいプロトコルと新しいトラフィックパターンの相互作用に関連していると考えました。

この新しいプロトコルを無効化すると、ネットワークデバイスの障害が復旧することを確認。

エンジニアは、単一のアベイラビリティーゾーンでこの新しいプロトコルを無効化して、持続的なリカバリの確立を確認しました。

この対応を東京リージョン全体に展開することで、午後1時42分には大規模障害から復旧しました。

並行して、東京リージョン全体に展開する変更を準備しました。お客様は午後 12 時 30 分よりアプリケーションの復旧を確認し始め、午後 1 時 42 分に影響を受けたネットワークデバイスが安定した動作状態に復元され、Direct Connect サービスが通常の動作に戻りました。

「非常に特殊なパケット属性とコンテンツのセット」が障害を引き起こした

AWSはこの報告の中で、次のようにネットワークデバイスのOSの潜在的な問題が根本原因であることを突き止めたとしています。

新しいプロトコルを無効にすることでこの事象は解決しましたが、エンジニアリングチームは根本原因を特定するために引き続き取り組んできました。この事象は、ネットワークデバイスのオペレーティングシステム内の潜在的な問題によって引き起こされたことを確認しました。

ネットワークデバイスのOSに追加された新しいプロトコル処理に問題があった模様です。しかしこれは8カ月ものあいだ問題なく稼働していたと。

新しいプロトコルとオペレーティングシステムは、2021 年 1 月に初めて実稼働環境に導入されました。過去 8 か月間にわたって、この新しいプロトコルとオペレーティングシステムは、すべての AWS リージョンで徐々に実稼働環境にリリースされ、潜在的な問題を示すことなく Direct Connect のサービスを提供してきました。

そのOSに追加された新しいプロトコル処理は、特殊なパケット属性とコンテンツのセットという条件がそろったときに問題を引き起こす欠陥があったことが、過去数日でAWSのエンジニアにより特定されました。

そしてこの欠陥に合致するネットワークトラフィックが顧客から発生したことが、今回の障害の引き金になったことが分かったと。

過去数日間で、エンジニアはネットワークオペレーティングシステムの欠陥を特定し、問題を引き起こす非常に特殊なパケット属性とコンテンツのセットが必要であると判断しました。これらの条件は非常に特殊で稀であるものの、このシグニチャに一致するカスタマートラフィックによってこのイベントが発生しました。悪意のある振る舞いがあったとは考えておりません。

これらの障害の原因について、下記の様に対応したとのこと。

AWS 東京リージョンでこの問題が発生した新しいプロトコルを無効にしました。また、この変更を他のすべての AWS リージョンに慎重に適用するためにお客様に影響が出る前にこの問題を検出して修復するための拡張方法も開発しました。この問題によるお客様へのさらなる影響はないと確信しています。

今回の大規模障害は、記事の冒頭で紹介したように金融や運輸など社会的にも大きな影響を与えました。それだけクラウドが社会的基盤としての重要性を高めていることの証であったといえます。

そうした社会的基盤を担うようになったクラウドが、障害について詳細な報告をわずか数日で迅速に一般公開したことは、クラウドベンダの持つ技術力と情報公開の在り方が、従来の「ベンダと顧客の関係による対応と報告」とは異なるものであることも、今回の対応で改めて浮き彫りになったのではないでしょうか。