ログの出口が詰まった日 — 2024年7月 Kinesis内部障害に学ぶ、マネージドサービスの「見えない依存」
2024年7月30日、Amazon Kinesis Data Streamsの内部セルで発生した障害が、CloudWatch LogsやLambda、ECS、API Gatewayなど一見無関係な複数サービスを同時に不調にしました。AWS公式ポストモーテムをもとに、時系列と根本原因、そこから導ける設計上の学びを整理します。
- #Amazon Kinesis Data Streams
- #CloudWatch Logs
- #AWS障害
- #可観測性
- #SRE
2024年7月30日、Amazon Kinesis Data Streamsの内部セルで発生した障害により、CloudWatch LogsやAmazon Data Firehose、S3イベント通知の配信が遅延し、それらに依存するLambda・ECS・API Gateway・Redshift・Glue・MWAAなど複数のサービスが同時に不調になりました。これらのサービスはユーザーからは互いに無関係に見えますが、内部ではAWS自身がオブザーバビリティ基盤として利用するKinesisセルを共有しています。この記事は、AWS公式ポストモーテム（2024年7月時点の記載）をもとに、何が起きたのかと、そこから導ける設計上の学びを整理します。
時系列（2024年7月30日・PDT）
| 時刻（PDT） | できごと |
|---|---|
| 9:09 AM | 単一アベイラビリティーゾーンでルーチンのデプロイメントが開始 |
| 2:45 PM | 影響を受けたKinesisセルへのリクエストでレイテンシとエラー率が上昇 |
| 4:25 PM | 低優先度の内部ワークロードの負荷を軽減するデプロイメントを実施 |
| 5:39 PM | エラー率とレイテンシに改善の兆候 |
| 5:55 PM | セル管理システムが安全接続を効果的に確立 |
| 6:04 PM | 影響を受けたセルへの着信リクエストの大部分が正常に処理される状態に |
| 6:32 PM | 接続プロビジョニング容量を追加し、エラー率がさらに低下 |
| 7:21 PM | Kinesis Data Streamsセルへのリクエストの大部分が通常どおり処理される状態に |
| 9:37 PM | 完全復旧（CloudWatch Logsの遅延も解消） |
| 7/31 5:50 AM | CloudWatch Logsのバックログ処理が完了 |
| 8/1 2:38 AM | S3イベント通知のバックログ処理が完了 |
復旧が段階的である点に注目してください。エラー率の改善開始（5:39 PM）から「大部分が正常処理」（7:21 PM）までに約1時間40分、そこから遅延分のバックログ処理完了までさらに丸1日以上かかっています。
何が壊れていたか — セル管理システムの誤判定
AWS公式ポストモーテムによれば、影響を受けたのは新しいKinesisセルアーキテクチャです。このアーキテクチャは冗長性・性能・スケールの弾力性を高める狙いで、セル内の全ホストの健全性を監視し、Kinesisシャードの処理をより効率的に分配する「セル管理システム」を持ちます。
根本原因は、次のような連鎖でした。
- 内部ワークロード用のセルに、非常に多数の低スループットシャードが存在していました。
- ホストをサービスから外す・デプロイする・サービスに戻すという通常の運用作業（今回は9:09 AMのルーチンデプロイ）が、セル管理システムに「サービスから外れるホストの処理を他のホストへ移す」動作を引き起こしました。
- このとき、スループットなどのI/O指標にもとづく負荷分散の結果、少数のホストに大量の低スループットシャードが偏って割り当てられる状態になりました。
- 各ホストがセル管理システムへ定期送信する状態メッセージには、担当する各シャードの情報が含まれます。シャードが偏在したホストではこの状態メッセージが肥大化し、セル管理システムへ時間内に送信・処理されなくなりました。
- セル管理システムはこれを誤って解釈し、健全なホストを不健全と判定、それらのホストが処理していたシャードの再分配を開始しました。この結果、シャード再分配の実行率が急増しました。
- 急増した再分配処理が、Kinesisのデータプレーンサブシステムとの通信に使う安全な接続をプロビジョニングするコンポーネントを過負荷にし、Kinesisのトラフィック処理全体が損なわれました。
つまり、ホストの入れ替えという日常的な運用操作が引き金となり、シャードの偏在→誤検知→過剰な再分配→接続プロビジョニングの過負荷という連鎖でKinesisの処理能力が損なわれた、というのが公式説明です。
なぜ無関係に見えるサービスまで巻き込まれたか
CloudWatch LogsとAmazon Data Firehoseは、ログのバッファリングにKinesisを内部利用しています。今回のセル障害で、CloudWatch Logsはインジェスションが遅延し、Data FirehoseはPutRecord/PutRecordBatch APIでの失敗増加とストリーム配信の遅延に見舞われました（ポストモーテムはデータ損失なし・影響期間中の全レコードを最終的に配信、と記載しています）。S3イベント通知の配信も2:45 PMから7:21 PMまで遅延しました。
この3つの直接被害から、さらに間接的な影響が波及しました。
| サービス | 影響内容 |
|---|---|
| ECS | awslogs ログドライバをブロッキングモードで使うタスクが、ログをCloudWatch Logsへ送れずブロックし、ヘルスチェックに応答できなくなった（非ブロッキングモード設定のタスクは正常動作） |
| Lambda | 関数実行のCloudWatch Logsが欠落。ログAPI直接呼び出しでもエラー増加・レイテンシ増加が発生し、全関数が正常実行できているかの判断が困難に |
| API Gateway | ログ配信の障害と、Logging設定に関するエラー率上昇。API呼び出し自体は通常どおり処理を継続 |
| Redshift | Query Editor v2やJDBC/ODBC/Pythonドライバ経由の接続で断続的な問題。CloudWatchメトリクスの表示でもエラー率上昇 |
| Glue／MWAA | リソースの作成・更新やログ記録のメトリクス取得でレイテンシ上昇とAPI失敗 |
これらのサービスはKinesisを直接使っているわけではなく、CloudWatch Logsという共通の依存先を介して間接的に影響を受けました。
この障害から学ぶ設計論
1. マネージドサービスにも「内部の内部依存」がある。 CloudWatch LogsやLambdaのログ配信は、AWSが自社のオブザーバビリティ基盤として内部利用するKinesisセルの上に構築されています。この依存関係はユーザーには見えません。複数の一見無関係なサービスが同時に不調になったときは、「共通の内部コンポーネントに障害が起きている可能性」を疑う視点を診断の初手に持っておく価値があります。
2. 「実行は継続、ログだけ欠落」という部分劣化に備える。 今回、Lambda関数の実行自体は継続していたケースがある一方で、実行ログだけが欠落し、正常に動いているかどうかの判断が困難になりました。API Gatewayも同様に、API呼び出しは通常どおり処理されつつログ配信だけが障害を起こしています。フルダウンではなくログや可観測性の経路だけが劣化するパターンは、ログの有無を前提にしたアラート設計・障害診断フローでは見落としやすい部分です。ログ欠落そのものを検知する仕組み（メトリクスの継続性チェック等）を、アプリケーションの可用性監視とは別に持つ設計が有効です。
3. 復旧は非同期に進む前提で運用する。 「大部分のリクエストが正常処理される」までの回復（7:21 PM）と、遅延データのバックログ処理完了（CloudWatch Logsは7/31、S3イベント通知は8/1）の間には、丸1日以上の差がありました。障害の「復旧」通知を見ても、遅延して届くデータやイベントがしばらく降り続ける可能性を前提にした運用（重複処理やタイムスタンプのずれに強い設計、復旧直後のバースト流入への耐性）を検討しておく必要があります。
まとめ
- 2024年7月30日、Kinesisの内部セルでホスト入れ替えを引き金にしたシャード偏在→誤検知→過剰な再分配→接続プロビジョニングの過負荷という連鎖が発生しました。
- CloudWatch LogsとData Firehose、S3イベント通知が直接影響を受け、それらに依存するLambda・ECS・API Gateway・Redshift・Glue・MWAAへ間接的に波及しました。
- 完全復旧は同日9:37 PM PDTですが、遅延データのバックログ処理完了は翌日以降（7/31・8/1）までかかっています。
出典
- Summary of the Amazon Kinesis Data Streams Event in the US-EAST-1 Region（AWS公式ポストモーテム。2024年7月30日発生・2024年7月時点の記載）