US-EAST-1でのAmazonKinesisの大規模な混乱に関するポストモーテム（11月25日）

約transl。：先週、AWSサービスの1つが停止したため、この主要プロバイダーの多数のクラウドサービスが利用可能/正しく機能しました。インターネット会社のエンジニアによって即座に投稿された公式出版物は、事件の詳細、その原因、そして最も重要なことに、事件から学んだ教訓について述べています。私たちはあなたの注意にその翻訳を提示します。



この投稿では、2020年11月25日にバージニア北部（US-EAST-1）で発生したサービスの中断の詳細を共有したいと思います。



Amazon Kinesisは、ストリーミングデータをリアルタイムで収集、処理、分析します。顧客による直接使用に加えて、多くのAWSサービスに関与しています。これらのサービスも停止に見舞われました。このイベントのトリガー（主な原因ではありません）は、サービスへの容量の比較的小さな追加でした。これは、PSTの午前2:44に開始され、午前3:47に終了しました。

キネシスデバイスについて

Kinesisは、データストリームを処理するセル（セル）の多数の「バックエンド」クラスターを使用します。これらはKinesisの主力製品です。彼らは、ストリーミングの配信、アクセス、スケーリングを担当します。ストリームは、シャーディングを使用してフロントエンドサーバーからバックエンドサーバーに配信されます。バックエンドクラスターは多くのシャードを「所有」し、一貫したスケーリングと障害分離を提供します。私たちの場合のフロントエンドの作業は小さいですが、重要です。これは、バックエンドクラスター上の正しいスレッドシャードへの要求の認証、調整、およびルーティングを担当します。



フロントエンドのマシンフリートに新しい容量を追加していました。各フロントエンドサーバーは、メンバーシップとシャード所有者（バックエンドクラスター間）を含むデータのキャッシュを形成し、いわゆるシャードマップを形成します。メンバーシップ情報を提供するサービスに要求を送信し、DynamoDBから構成データを取得することにより、この情報を取得します。



さらに、各サーバーは他のKinesisフロントエンドサーバーからのメッセージを継続的に処理します。これを行うために、各フロントエンドサーバーの各フロントエンドマシンのOSにスレッドが作成されます。新しい容量が追加されると、フロントエンドパークですでに動作しているサーバーが新しいメンバーについて学習し、対応するストリームを作成します。既存のすべてのフロントエンドサーバーが新しいマシンについて認識するのに最大1時間かかります。

診断と問題解決

5:15 PSTに、Kinesisレコードの書き込みと取得中に最初のエラーメッセージが表示されました。私たちのチームはすぐにログの調査を開始しました。疑惑はすぐに新しい容量に落ちましたが、エラーのいくつかは新しいマシンにまったく関係がなく、新しい容量をすべて削除したとしても、おそらくどこにも行きませんでした。



それでも、予防策として、他のエラーの原因を突き止めるために、それらを削除し始めました。それらの多様性は私たちの診断を遅らせました。フロントエンドマシンフリートの既存および新規メンバーによるあらゆる種類の呼び出しのあらゆる側面でバグが発生したため、副作用を根本原因から分離することは非常に困難でした。



PSTの午前7:51の時点で、容疑者を少数の候補者に絞り込み、最も可能性の高い原因のいずれかが完全なフロントエンドの再起動を必要とすることを確認しました。キネシスチームは、このプロセスが遅くて詳細であるべきであることを完全によく知っていました。



実際のところ、シャードカードへの入力は、フロントエンドサーバーのリソースに対する着信要求の処理と競合します。したがって、フロントエンドサーバーのオンラインへの復帰が速すぎると、2つのプロセス間に競合が発生し、着信要求を処理するには少なすぎます。結果は予測可能です。エラー率の増加と待ち時間の増加です。さらに、遅いフロントエンドサーバーは、異常の兆候として認識される可能性があります。これにより、使用可能なサーバーのリストからサーバーが削除され、リカバリプロセスがさらに遅くなる可能性があります。



考えられるすべての解決策には、各フロントエンドサーバーの構成を変更して再起動することが含まれていました。トラブルの原因（メモリに圧力をかけているように見える問題）の最有力候補は有望に見えましたが、間違っていると、すべてを修正して再起動する必要があるため、回復時間が2倍になるリスクがありました。再起動を高速化するために、調査と並行して、フロントエンドサーバーの構成の変更を開始し、フロントエンドネイバーからではなく、起動時にメタデータストアから直接データを受信できるようにしました。

主な理由

PSTの午前9時39分に、クラッシュの根本原因を最終的に確認することができました。それは記憶とは関係がないことがわかった。新しい容量が追加された結果、すべてのフロントエンドサーバーのスレッド数が、システム構成で許可されている最大数を超えました。制限を超えたため、キャッシュ（シャードカード）を作成できませんでした。その結果、フロントエンドサーバーはリクエストをバックエンドクラスターに転送できませんでした。



事前テストなしでOSのスレッド制限を増やしたくはありませんでした。また、その時点で追加容量がすでに削除されていたため、スレッド数のシステム制限を超えるリスクは最小限であると判断し、サーバーを再起動し続けました。新しいフロントエンドの最初のグループは、10：07PSTにKinesisトラフィックの受け入れを開始しました。



フロントエンドフリートは数千のサーバーで構成されており、上記の理由により、1時間あたり数百以下の速度でサーバーを追加できます。正午以降、Kinesisサービスエラーが着実に減少していることに注目して、フロントエンドにトラフィックをゆっくりと追加し続けました。サービスは午後10時23分PSTに完全に回復しました。

私たちは何を学びましたか

キネシス事件からいくつかの教訓を学び、近い将来修正を行う予定です。

• , CPU . , , , . , . , .
  
  
• .
• , . , .
• -. - AWS ( CloudWatch) , -.
• (cellularization) ( , ). ( -) . Kinesis , , , . / , , .

クラッシュは、Kinesisを使用する一部のサービスにも影響しました。



Amazon Cognitoは、Kinesis Data Streamsを使用して、APIアクセスパターンを収集および分析します。この情報はCognitoサービスの運用に非常に役立ちますが、配信される保証はありません（最善の努力）。データはローカルにバッファリングされ、Kinesis DataStreamsサービスでの遅延または短期間の使用不可にサービスが対処できるようにします。



残念ながら、Kinesis Data Streamsが長期間使用できなくなったため、バッファリングコードに潜在的なバグがあり、CognitoWebサーバーがKinesisDataStreamバッファのブロックを開始しました。その結果、Cognitoの消費者は、APIの不具合に直面し、CognitoユーザープールとIDプールの待ち時間が長くなりました。外部ユーザーは、一時的なAWS資格情報を認証または取得できませんでした。



停止の初期段階で、Cognitoチームは、容量を追加してKinesisの通話バッファリング機能を強化することにより、Kinesisのバグの影響を軽減しようとしました。当初、これはサービスに有益な効果をもたらしましたが、PSTの午前7:01までに、エラー率が大幅に増加しました。並行して、チームはCognitoのKinesisへの依存を減らすために取り組みました。午前10時15分に、このソリューションが展開され、エラー率が低下し始めました。午後12時15分までに、エラー率は大幅に低下し、PSTの午後2時18分には、Cognitoは正常に機能していました。この問題の再発を防ぐために、CognitoWebサーバーを変更しました。バッファを使い果たすことなく（ユーザーの問題につながる）、KinesisAPIエラーを許容できるようになりました。



CloudWatchKinesis DataStreamsを使用してメトリックとログを処理します。午前5時15分以降、CloudWatchではPutMetricDataAPIとPutLogEventsAPIのエラーと遅延が増加し、アラートが状態になりましたINSUFFICIENT_DATA。一部のCloudWatchメトリックは停止中も処理され続けましたが、それらのほとんどは多数のエラーと遅延の増加の犠牲になりました。



PSTの午後5時47分に、Kinesis Data Streamの状況が改善するにつれて回復の最初の兆候が現れ、午後10時31分までにCloudWatchのメトリックとアラートが完全に回復しました。次の数時間で、遅延メトリックとログの処理が続行されました。 CloudWatchがバグに苦しんでいる間、内部および外部のクライアントはメトリックデータをCloudWatchに配信できませんでした。その結果、CloudWatchメトリックデータにギャップがあります。



現時点では、CloudWatchサービスはKinesisを使用してメトリックとログを収集していますが、そのチームは間もなく変更を実装し、その後CloudWatchはデータをローカルストレージに3時間保存します。この変更により、CloudWatchメトリック（AutoScalingを含む）に関連付けられたユーザーとサービスが、（オンプレミスのCloudWatchデータストアで）新しく収集されたメトリックに直接アクセスできるようになります。このアイデアはすでにUS-EAST-1地域で実装されており、今後数週間でグローバルに展開する予定です。



さらに2つのサービスが、CloudWatchメトリックに関する問題の人質になりました。

• まず、CloudWatchメトリックに基づくAutoScalingポリシーでは、CloudWatchが跳ね返り始めた午後5時47分まで遅延が発生しました。
• -, Lambda. - CloudWatch. Lambda, , , CloudWatch . 6:15 PST , , -. : . 10:36 PST , .

CloudWatch EventsとEventBridgeでは、午前5時15分（ET）からイベント処理でAPIエラーと遅延が増加しました。可用性を向上させた後、Kinesis EventBridgeは、途中でイベントのバックログを処理しながら、宛先への新しいイベントの配信を再開しました。



Elastic Container Service（ECS）とElastic Kubernetes Service（EKS）は、内部ワークフローでEventBridgeを使用して、クライアントクラスターとタスクを管理します。これは、新しいクラスターのプロビジョニング、既存のクラスターのスケーリングの遅延、およびタスクのプロビジョニング解除に影響しました。PSTの午後4時15分までに、これらの問題のほとんどは解決されました。

顧客への通知

サービスの問題に加えて、インシデントの最初の段階で、サービスのステータスに関する情報を顧客に伝達する際に一定の遅延が発生しました。



運用イベント中にお客様と連絡を取る方法は2つあります。

1. Service HealthDashboard-大規模な運用上の問題を警告するための公的にアクセス可能なダッシュボード。
2. パーソナルヘルスダッシュボード-影響を受ける顧客に直接通知します。

このようなイベントの間、私たちは通常、サービスヘルスダッシュボードに情報を投稿します。ただし、この場合、クラッシュの開始時に、更新の公開に使用されるツールがクラッシュしたCognitoによって使用されているため、Service HealthDashboardの情報を更新できませんでした。



最小限のサービス依存関係でServiceHealthDashboardを更新するためのフォールバック方法があります。意図したとおりに機能しましたが、イベントの開始時にService HealthDashboardに情報を公開するときに遅延が発生しました。重要なのは、このバックアップツールは自動化されておらず、ヘルプデスクのオペレーターにはあまり馴染みがないということです。



影響を受けるすべての顧客に更新をタイムリーに配信するために、サポートチームは、パーソナルヘルスダッシュボードを利用して、潜在的なサービスの問題を警告しました。また、サービスヘルスダッシュボードに最新情報を含むグローバルバナーを表示して、ユーザーにインシデントについて完全に通知できるようにします。クラッシュが終了するまで、Service Health Dashboard（グローバルバナーの概要と特定のサービスの操作の詳細を含む）とPersonal Health Dashboardの組み合わせが継続され、サービスの問題の影響を受ける顧客を最新の状態に保つように努めました。私たちの経験に基づいて、定期的なサポートエンジニアトレーニングでサービスヘルスダッシュボードにメッセージを投稿するためのフォールバックシステムを備えた必須の演習を導入しました。

..。

最後に、今回の事件がお客様に悪影響を及ぼしたことをお詫び申し上げます。私たちはAmazonKinesisの高い可用性に誇りを持っており、このサービスやその他のAWSサービスがお客様、そのアプリケーション/エンドユーザー、およびそのビジネスにとってどれほど重要であるかを十分に認識しています。この事件から学び、アクセシビリティをさらに向上させるために最善を尽くします。

PS

私たちのブログも読んでください：

• «利用不可のポストモーテムQuay.io »;
• 「私たちのSRE時代からの実用的な物語。パート2 ";
• 「Kubernetesでのポッドの優先順位がGrafanaLabsでダウンタイムを引き起こした方法。」