障害報告書から読み解くAWSの仕組み

障害概要

2020年11月25日に北バージニア・リージョン（US-EAST-1）で発生した障害報告書（https://aws.amazon.com/jp/message/11201/）を読み解いて、AWSの中をのぞいてみようという企画です。

今回の障害の発端はAmazon Kinesisサービスを構成するサーバ群のうち、Kinesis利用サービスからのリクエストを受け付けるフロントエンド構成するサーバ群に小規模な容量追加を行ったことです。

フロントエンドのサーバ群の各サーバはシャードマップというバックエンドのメンバシップや所有権情報のキャッシュを保持しています。これらの情報はDynamoDBに格納された情報やフロントエンドのサーバ間での情報交換によって更新されます。
フロントエンドのサーバは、フロントエンドを構成する他のサーバとの通信をするためのスレッドを生成します。報告書には明記されていませんが、おそらく通信相手となるサーバ単位に１スレッドを生成していると思われます。
今回、新規にフロントエンドにサーバを追加したことにより、サーバ間通信を行っているスレッドがスレッド生成上限を超えてしまったことにより、前述のシャードマップの更新が正常に行えず、Kinesisサービスの全体が機能不全を起こしたと報告されています。

影響を受けたサービス

今回の障害で良くわかりましたが、Amazon KinesisのサービスはAWSの各種サービスの中に組み込まれており、Kinesisのサービス不全がAWSサービス全体に影響を及ぼします。
例えば、Amazon Cognitoはデバイスからの認証APIの呼出実績をKinesisを利用して収集し、不正な利用がないかを検知するアダプティブ認証サービスを提供しています。
また、CloudWatchにおいても、メトリクスやログデータの収集にKinesis Data Streamを利用しています。そのため、今回の障害時にはメトリクスデータの収集やロギング機能が正常に行えず、特にメトリクスデータを利用するAuto Scaling機能にも影響を与えました。その他にもLambda関数の呼び出しにおいても、CloudWatchのメトリクスは利用されており、直接関連していなさそうなLambda関数でもエラーが発生しています。

まとめ

ちょっと雑ですが、AWSの障害報告から障害概要と障害を受けたサービスについての解説をしてみました。
今回の事例で思ったことは、AWSのサービスの中でもAWSサービスが活用されており、直接、間接的に障害の影響を受けるということが分かりました。こういった報告をきちんとアップしてもらえると大変助かりますし、勉強になりますね。