Amazon EC2クラッシュレポート

Amazonは4月21日木曜日に失敗の理由に関する詳細なレポートを最終的に公開しました。その結果、米国東海岸のアクセスエリアの1つが2日間ほとんど機能せず、同じ地域の他のエリアはしばらくバグがありました。



そのため、障害の根本原因は、スケーラビリティの変更に関する通常の作業中のAmazon Elastic Block Store（「EBS」）クラスターのネットワーク設定のエラーでした。 ネットワーク設定は、メインネットワークの容量を増やすことになっています。 この手順の標準的な手順の1つは、輻輳しているルーターの1つからトラフィックを削除してアップグレードすることです。 トラフィックはメインネットワークに向かう必要があります。 ただし、エラーのため、トラフィックルーティングが誤って変更されました：メインネットワークの代わりに、低帯域幅ネットワークに移動しました（EBSは、トラフィック用のメインネットワークとクラスター内のEBSノード間の通信とレプリケーションの2つのネットワークを使用します）。



2番目のネットワークはこのような量のトラフィック用に設計されていないため、EBSノードは相互に接続できなくなりました。 ネイバーが応答していない場合、ノードは複製する別のノードを探し始めます。 ネットワークを再構築した後、これにより、ミラーバックアップの雪崩を含む一連のイベントがトリガーされました。 EBSクラスターの空き領域がほぼ瞬時になくなった。 さらに、エクストリームモードでの操作により、一部のEBSノードで障害が発生し始め、リクエストが増加しました。



別のニュアンス：ミラーバックアップのプロセスで、インスタンスは（データの整合性を維持するため）読み取りと書き込みが一時的にブロックされ、ゾーンの1つにあるEBSクラスター全体が読み取りと書き込みに使用できなかったため、この状況では、これにアクセスしたすべてのEC2インスタンスストレージもブロックされました。



これらのインスタンスを復元し、このゾーンでEBSクラスターを安定させるには、復元作業が実行されているほぼすべての時間で、EBSのすべての管理API（ボリュームの作成、ボリュームの接続、ボリュームの切断、スナップショットの作成を含む）を無効にする必要がありました。



初日には、影響を受けた地域の破損したEBSクラスターが東海岸地域の他のゾーンの動作に悪影響を与える2つの期間がありましたが、これは理論的にも起こるべきではありませんでした（Amazonサービス条件によると、1つの地域のアクセスゾーンも互いに完全に独立しています友人から）。 しかし、ここで起こったのは、EBS APIの劣化により、EBSは上記の2つの期間に他のゾーンからこれらのAPIを呼び出して遅延を処理し、高レベルのエラーを返しました。 実際、地域全体のEBS API管理システムは、すべてのアクセスゾーンに地理的に分散されていますが、実際には単一のサービスです。 したがって、他のゾーンのユーザーも、新しいインスタンスを作成しようとしたときにエラーメッセージを受け取りました。



Amazon Relational Database Service（RDS）もデータベースとログを保存するためにEBSに依存していたため、状況は悪化しました。そのため、1つのEBSクラスターの障害後、RDSデータベースの一部が利用できませんでした：ピーク時に、このゾーンで選択したインスタンスの最大45％つまり、1つのRDSデータベースがストレージ用に複数のEBSノードを使用してパフォーマンスを向上させるため、直接EBS拒否（ピーク時にパーティションの18％に影響を及ぼします）よりもホスティングクライアントに対してはるかにマイナスの影響がありました。



12時間の闘争の後、状況は1つのEBSクラスターで隔離され、その後このクラスターの注意深い復元が開始され、一部のパーティションは手動で復元する必要があり、0.07％が完全に失われました（「シングルAZ」データベースの0.4％）。 バックアップからのみ復元できます。 API機能とクラスターへのアクセスは4月23日（最初の障害から2日後）に復元されましたが、最後のパーティションの復元は月曜日まで続きました。



Amazonは、障害のあるEBSクラスターにいるかどうかに関係なく、インスタンスが影響を受けるエリアにあるすべての顧客に、現在の使用量でのEBSボリューム、EC2インスタンス、およびRDSデータベースインスタンスの10日間の無料使用を約束しました。 補償を受けるために何もする必要はありません。自動的に最寄りの口座に反映されます。 AWSアカウントアクティビティページで、補償が適用されるかどうかを確認できます。



独立した専門家は、Amazonを最大限に開放し、EBSとEC2の技術インフラストラクチャについて非常に詳細に説明していると称賛しました。 レポートの唯一の欠点は、初期障害に関する控えめな表現です。つまり、ネットワーク設定のエラーは正確に何でしたか、これについては何も言われていません。 明示的には述べられていませんが、報告書のあるフレーズから、エラーの原因は人的要因であることが明らかです。「変更のプロセス[設定]を監査し、自動化のレベルを上げて、将来このようなエラーを防止します」と公式声明は述べています。 。



EBSの作業に伴う問題に関しては、この失敗は「相互に関連するいくつかの要因によって引き起こされる非常に複雑な運用現象であり、将来のこうしたイベントの繰り返しからサービスを保護する方法を多く提供します」と報告書は述べています。