目的
2017/3/1 に us-east-1 の S3 大規模障害がありました。過去にもいくつか発生しているのと、いつ使っているリージョンで同じ事態が起きてもおかしくないと思い、これを機に過去どのような障害があったのか遡って調べました。
所感
-
毎年どこかのリージョンで大規模な障害が起きている
- ap-northeast-1 で起きていないのはたまたま、運がいいだけ
- AWS は復旧時間の改善・可用性向上に全力を尽くしているものの、未知の障害はいつかどこかで起きるもの
- ステータスダッシュボードは時に嘘をつく
- クラウドシェアトップである AWS はインターネット全体の SPOF になりつつある
- Chaos Monkey の思想は必須
- 報告書読むの面白い
- AWS の中身がすこし透けて見えてきます
- 前回データセンターについて調べたことが役に立った
-
SLA を理解しておこう
- リージョン障害なので Single-AZ 障害は SLA の対象ではないとか
- us-east は呪われている
AWS 障害一覧
- 報告書が出ているものを網羅できているかとおもいます
- SimpleDB の障害だけ除外しました。
- 最近起きたものから過去に遡っていきます
2017/3/1 us-east-1：オペミスにより S3 が逝く [new!]
- ニュース記事
- 報告書
報告書サマリ
- 障害リージョン
- us-east-1：米国東部（バージニア北部）
- 障害サービス
- S3 がアクセス不可
- 影響した利用者
- Imgur、IFTTT、Zapier、Slack、Trello など
- 障害内容
- 通常作業である S3 のサーバ停止時に停止指定する範囲を誤り、多数の S3 サーバ群がシャットダウン、アクセス不可となる
- EBS Snapshot、Lambda にも影響が出る
- 復旧内容
- S3 を再起動
- 整合性チェックを実施
- 今後の対応
- 運用ツールの修正
- S3 の管理範囲見直し
- 復旧までの時間
- 5 時間
2016/6/4 ap-southeast-2：豪雨でシドニーの EC2 が逝く
- ニュース記事
- 報告書
報告書サマリ
- 障害リージョン
- ap-southeast-2：アジアパシフィック (シドニー)
- 障害サービス
- EC2、Redshift、RDS 等
- 影響した利用者
- 障害内容
- 豪雨により停電
- UPS への切替時に異常な電圧低下が起きる
- EC2 落ちまくる
- 復旧内容
- 手動で UPS への電源切替を実施
- 大部分の EC2 は インスタンス管理ソフトにより自動復旧してきた
- 一部の EC2 インスタンスはインスタンス管理ソフトのバグにより自動復旧されなかったため、手動で回復する
- 今後の対応
- 電源周りの見直し
- 定期的なリカバリテストの実施
- 復旧までの時間
- 1.5 時間
2015/9/20 us-east：新機能追加で DynamoDB が逝く
- ニュース記事
- 報告書
報告書サマリ
- 障害リージョン
- us-east-1：米国東部（バージニア北部）
- 障害サービス
- DynamoDB がアクセス不可
- 影響した利用者
- Netflix、 Reddit 等
- 障害内容
- DynamoDB に グローバルセカンダリインデックス(GSI) の機能追加がされる
- グローバルセカンダリインデックス の利用者増加により、DynamoDB 内部メタデータが急増
- 内部メタデータを格納しているストレージサーバの容量割当が小さく、メタデータのパーティショニングが発生
- メタデータの読込性能が劣化し、DynamoDB のエラー率増加
- 内部的に DynamoDB を使用している EC2 Auto Scaling、SQS、CloudWatch も連鎖的にエラー率増加
- 復旧内容
- メタデータサービスの容量追加
- 今後の対応
- メタデータサービスの容量割当変更
- 顧客のサービス利用規模の監視
- 復旧までの時間
- 5 時間
2012/12/24 us-east：オペミスにより ELB が逝く
- ニュース記事
- 報告書
報告書サマリ
- 障害リージョン
- us-east：米国東部
- 障害サービス
- ELB
- 影響した利用者
- Netflix など
- 障害内容
- オペレーションミスにより、ELB 管理アプリケーションから ELB の状態管理データが一部論理削除
- ELB の新規作成はできるが、既存 ELB の状態変更ができない事態へ
- 復旧内容
- ELB 状態管理データの手動復旧
- 今後の対応
- 運用データへのアクセスポリシー見直し
- データ復旧プロセスの変更
- 復旧までの時間
- 12 時間
2012/10/22 us-east-1：設定ミスにより EBS が逝く
- ニュース記事
- 報告書
報告書サマリ
- 障害リージョン
- us-east：米国東部
- 障害サービス
- EBS
- 影響した利用者
- 障害内容
- EBS ストレージ管理サーバの交換作業の一貫で、内部 DNS 設定変更を行ったが設定値にミスがあった
- ミスった DNS 設定値がなぜか EBS 管理サーバの一部だけに反映される
- 反映された EBS 管理サーバに、データ収集サーバに接続できないとメモリリークが起きるという潜在バグが発生
- EBS 管理サーバがメモリ不足によりフェイルオーバーしまくり、フェイルオーバー先が枯渇
- EBS アクセス不可になる
- RDS も EBS にアクセスでず、シングル構成のものは死亡、一部 Multi-AZ もバグでフェイルオーバーしなかった
- ELB も EBS に置いてる構成情報にアクセスできないので自動フェイルオーバーするも、EIP が枯渇して死亡
- 復旧内容
- EBS ストレージ管理サーバのメモリ手動解放により、EBS 復旧
- ELB 手動回復
- 今後の対応
- EBS 管理サーバのメモリ監視見直し
- EBS 管理サーバのフェイルオーバー方法見直し
- DNS 設定が一部にしか反映できないものを修正
- RDS フェイルオーバーの不具合修正
- ELB に追加の EIP を確保
- 復旧までの時間
- 14 時間
2012/6/29 us-east-1：嵐により、全体的に逝く
- ニュース記事
- 報告書
報告書サマリ
- 障害リージョン
- us-east-1：米国東部（バージニア北部）
- 障害サービス
- EC2、EBS、RDS 等
- 影響した利用者
- Netflix、Instagram、Pinterest、Heroku、Flipboard 等
- 障害内容
- 落雷のため停電が複数回発生
- 二度目の発電機への切り替えに失敗、UPS 運用となる
- 発電機復旧前に UPS 電力枯渇して電源喪失
- EC2、EBS、RDS など AZ サービスが死亡
- ELB はフェイルオーバー処理を開始するも、潜在バグによりスケールアップし始める
- 一部の Multi-AZ RDS は不具合によりフェイルオーバーできず
- 復旧内容
- 発電機復旧
- EC2 インスタンス管理ソフト はブートプロセスにボトルネックがあり復旧が遅れる
- EBS は整合性チェックに時間がかかり復旧が遅れる
- 今後の対応
- 不具合の修正
- 復旧までの時間
- 4時間程度
2011/4/21 us-east：設定ミスで EBS、EC2、RDS が逝く
- ニュース記事
- 報告書
報告書サマリ
- 障害リージョン
- us-east：米国東部
- 障害サービス
- EBS、EC2、RDS
- 影響した利用者
- Heroku 等
- 障害内容
- NW 増強のための設定変更実施時に、ルーティング設定のミスが発生
- ルータがトラフィックを捌ききれず、EBS ノードが NW 分離状態となる
- 一部ノードがオフラインとなった EBS がミラーリングのために一斉に容量確保を開始、リソース枯渇に陥る
- 全ノードがオフラインとなった EBS はデータ一貫性が確保できず
- EC2 インスタンスも起動できなくなる
- RDS も可用性が低下
- 復旧内容
- 障害の起きた EBS ノードを手動切り離し、容量確保
- データ復旧にとりかかるも、AZ 内データの 0.07% が復旧できなかった
- 今後の対応
- ストレージの増強
- EBS クラスタ制御の改善
- ヘルスツールの改善
- 復旧までの時間
- 4 日
2011/4/14 eu-west：電源喪失で EBS、EC2、RDS が逝く
- 報告書
報告書サマリ
- 障害リージョン
- eu-west：欧州
- 障害サービス
- EBS、EC2、RDS
- 影響した利用者
- 障害内容
- 変圧器の故障により、電力喪失
- PLC が不具合により発電機に接続できなかった
- UPS に切り替わるも電力が不足
- EC2 でエラー率上昇
- 一部ノードがオフラインとなった EBS がミラーリングのために一斉に容量確保を開始、リソース枯渇に陥る
- 全ノードがオフラインとなった EBS はデータ一貫性が確保できず
- EC2 インスタンスも起動できなくなる
- RDS も可用性が低下
- 一つ上のと同じ事象です
- 復旧内容
- 手動で発電機に接続、その後電源復旧
- 不整合の起きた EBS ボリュームのデータ復旧
- 今後の対応
- 電源復旧時の EBS ボリュームを自動復旧するよう機能追加
- EBS スナップショットのバグもついでに見つかり、修正する
- 復旧までの時間
- 1 日