orangeitems’s diary

クラウドで働くインフラエンジニアの日々の感想です(ほぼ毎日更新)。

AWS、Direct Connect障害の報告書を意訳してみた

f:id:orangeitems:20210907164624j:plain

 

はじめに

2021年9月2日に話題となったAWSのDirect Connect障害について、詳細なレポートがAWSから発行されています。

 

aws.amazon.com

 

ただ、日本語がちょっと読みにくいと感じたので、わかりやすく意訳してみました。

内容についてはうのみにせず、原文をお読みください。

 

以下、意訳

--------------------------

日本時間2021年9月2日に東京リージョン(AP-NORTHEAST-1)で発生した AWS Direct Connect サービスの中断に関する追加情報を提供いたします。

 

(事象)

日本時間2021年9月2日午前7時30分以降、Direct Connect をご利用中のお客様が、東京リージョンに向かうトラフィックについて、断続的な接続の問題とパケットロスの増加が発生しました。

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

お客様は午後12時30分に復旧を観測しはじめ、午後1時42分に接続の問題は完全に解決されました。

AZ間のトラフィック、リージョンへのインターネット接続、AWS Virtual Private Network (VPN) 接続 (一部のお客様が Direct Connect へのバックアップとして使用) など、他のすべてのネットワーク接続は影響を受けませんでした。

他の AWS リージョンへの Direct Connect トラフィックも影響を受けませんでした。

 

(経緯と暫定対応)

2021年9月2日午前7時30分に、AWSのエンジニアは、お客様が東京リージョンに接続する Direct Connect のパケットロスの増加について内部アラームを検知しました。

このアラームにより、Direct Connect ネットワークの単一レイヤー内にあるいくつかのデバイスの障害によって、事象が引き起こされたことを特定しました。

これらのデバイスはトラフィックを正しく転送していませんでした。

ですが、障害が発生したネットワークデバイスは、機器障害時に自動削除を行う通常のプロセスを通じてネットワークから除外されませんでした。

その代わりにこの自動プロセスは、通常よりもデバイスの故障率が高いことを検知し、エンジニアに調査し修復措置を講じるよう警告しました。

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

並行して、チームは故障の原因を調査していました。

問題のあるデバイスを除外することで一時的に修復しましたが、その後いくつかの他のネットワークデバイスでも同じ障害が発生しました。

その結果、Direct Connectを利用中のお客様のネットワークに輻輳、接続障害、またはパケットロスの増加が発生しました。

AWSのエンジニアは、故障したデバイスをリセットして徐々にサービスに戻すなど、いくつかの緩和を試みました。

しかし、障害は継続しました。

AWSのエンジニアは適切な機器能力を維持し、顧客への影響を完全に軽減することができませんでした。

AWSのエンジニアは障害を引き起こした可能性のある最近の変更対応を確認しました。

午後12時までに、AWSのエンジニアはこの障害の原因は以下の2つが起因しているのではないかと考えました。

①頻度の低いネットワークコンバージェンスイベント(経路情報の交換イベント)

②ファイバー切断に対するネットワークの反応時間を最適化するために導入された、新しいプロトコル

この新しいプロトコルは何ヶ月も前に導入されそれ以来問題なく運用されていました。

AWSのエンジニアは、結論として、今回の障害がDirect Connectネットワークのあるレイヤーを構成するネットワークデバイス上において、新しいプロトコルと新しいトラフィックパターンが相互作用して発生したと考えました。

AWSのエンジニアは、問題が発生している単一のAZでこの新しいプロトコルを無効化しました。

結果として障害の状況は解消し、持続的なリカバリーが確立したことを確認しました。

並行して、東京リージョン全体に展開するための変更対応を準備し、実施しました。

お客様は午後12時30分よりアプリケーションの復旧を確認し始めました。

そして、午後1時42 分に影響を受けたネットワークデバイスが安定した動作状態に復元され、Direct Connect サービスが通常の動作に戻りました。

 

(根本原因と対応)

新しいプロトコルを無効にすることでこの事象は解決しましたが、エンジニアリングチームは根本原因を特定するために引き続き取り組んできました。

この事象は、ネットワークデバイスのオペレーティングシステム内の潜在的な問題によって引き起こされたことを確認しました。

このバージョンのオペレーティングシステムでは、ネットワークのフェールオーバー時間を改善するために使用される新しいプロトコルが有効になります。

新しいオペレーティングシステムとプロトコルは、以前から実稼働環境で正常に実行されています。

AWSは、オペレーティングシステムを変更し新しいプロトコルを AWSネットワークに導入するときには、制御され、自動化され、試験され、計測された一連の手順を実施しています。

この手順は、専用の試験環境での一連のストレステストから始まり、ネットワークデバイスの有効パケットと無効パケット(不正な形式のパケットなど)の両方に対する回復力を検証します。

試験環境でのテストで特定された異常は、新しいコードが本番環境にリリースされる前に調査し根本原因を特定し修復します。

しかし、この包括的なテストでも試験環境ですべてのトラフィックとパケットの順列をテストすることはできません。

したがって、AWS はネットワークデバイスのオペレーティングシステムの変更を、段階的かつ制御された方法で本番環境にリリースするデプロイ手順を使用します。

このデプロイ手順では、アップグレードされたデバイスが実稼働トラフィックを処理を行い始めたとしても、アップグレードされていないデバイスに容易に切り戻すことができるようにします。これを前提に、個々のデバイスをアップグレードしていきます。

段階的に本番環境にデプロイしていく際は、アップグレードされたデバイスは、パフォーマンスの問題や機能エラーについて、広範囲に監視されます。

この段階的にアップグレードしていくデプロイ手順は何度も正常に使用されており、今回の最新のデバイスオペレーティングシステムのアップグレードでも遵守されました。

新しいプロトコルとオペレーティングシステムは、2021年1 月に初めて実稼働環境に導入されました。

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

そして、過去数日間で、AWSのエンジニアはネットワークオペレーティングシステムの欠陥を特定し、問題を引き起こす非常に特殊なパケット属性とコンテンツのセットが必要であると判断しました。

これらの条件は非常に特殊で稀であるものの、このシグニチャに一致するある顧客のトラフィックによってこのイベントが発生しました。

悪意のある振る舞いがあったとは考えておりません。

我々は、AWS 東京リージョンでこの問題が発生した新しいプロトコルを無効にしました。

また、この変更を他のすべての AWS リージョンに慎重に適用するために、お客様に影響が出る前にこの問題を検出して修復するための拡張方法も開発しました。

この問題によるお客様へのさらなる影響はないと確信しています。

 

(最後に)

AWS のサービスが日本のお客様と多くのビジネスにとって重要であるかを理解しており、今回の事象による影響を心からお詫び申し上げます。

AWS は、高い可用性でサービスを運営してきた長年の実績があり、お客様の信頼を維持し、お客様とビジネスに必要な可用性を達成するために全力を尽くします。

 

※意訳は以上です

--------------------------

 

ちょっと、感想

よく「ハードウェアの問題」と言いますけど、この文書のとおり完全にソフトウェアの問題ですよね。

ハードウェアの問題と言って、ばっちりハードウェアの問題なんて最近だとなかなか起きません。昔は、熱の問題で電源が停止したり、ネットワーク機器であればポートが使えなくなったりといろいろ体験したことはありますが、最近のハードウェアはいたって優秀な印象です。

一方で、ハードウェアが高機能化しました。高機能化の理由は、その中にあるソフトウェアが進化したことに尽きます。

ソフトウェアですから、不具合の一つや二つ抱えていても不思議ではなく、かつ、冗長構成にしていても、両方の機器に同じソフトウェアを入れるので、両方等も問題が起きちゃう、そんなロジックです。

もし神経質に設計するなら、違うベンダーで別ルートを作るという方法もありますが、それだと管理も2倍大変になります。

悩ましい話だな、と今回の話を見ても思いました。一方で、よくこんな短時間で原因までたどり着き切り戻したもんだな、と思いました。