Amazon の6月の障害

2012年6月にあったAmazon AWS の障害について。publickeyさんから、備忘録としてさらにまとめてみる。

6月14日にもあったようだが、こちらは比較的単純な電源断。ケーブル障害に発電機のクーリングファン障害が重なったというもので、障害時間も2時間弱。

一方2012年6月29日に起きた障害は、やはり電源障害に端を発しているが、もう少し話がややこしく、障害の範囲が広い。publickeyでは前編後編に分けて書かれている。

何が起きたのか

きっかけは、電源障害。UPSへ移行するも発電機の起動に一旦失敗、UPS作動停止10分後に発電機起動、20分後に復電ということで、電源断時間はわずか20分間。

EC2/EBS への影響

EC2/EBSはデータベースで管理されているが、このデータベースは当然複数のAZに複製されたプライマリ・スタンバイ構成になっている。障害時にはスタンバイへ切り替えるのだが、不完全な状態での切り替えを防ぐために、そこにマニュアル操作が必要な設定になっていた。このため切り替えに時間がかかり、その間リードオンリーの状態になりEC2の操作が全リージョンでできなくなっていた。

ELB への影響

ELBはロードバランサ。複数のAZのインスタンスへのロードバランスを行うモジュールだが、AZ障害時にはそちらのインスタンスへはリクエストを割り当てないようにする役割を果たす。内部的にはELBも仮想計算機インスタンスで実装されているらしい。ELBに関してはこの記事が参考になる。

ELBはAZへの電源断に対して正常に動作した。しかし、復電時にバグがトリガーされ、ELBインスタンスをより大きいインスタンスと切り替える動作になった。同時に、電源断に対応して生きているAZ上にELBインスタンスを起動する要求が入っていたため、キューにバックログが大量に溜まってしまった。このキューはリージョンで共有されているため、このリージョンのELB操作全体が遅くなった。

RDS への障害

RDS(Relational Database Service)は、複数のAZにまたがってプライマリ・スタンバイを構成することができる。プライマリのAZが落ちると、スタンバイが昇格することになっている。
多くのインスタンスではうまく行ったのだが、特定の通信障害パターンでトリガされるバグがあって、いくつかのインスタンスでは手動でフェイルオーバを完了させなければならない状況になってしまった。

所感

AWSほどの巨大システムになると、ひとつの障害の影響の範囲が非常に読みにくいことが分かる。とくに復電時。後発のクラウド事業者も同じ道をたどって学習していくんだろうか。大変そうだ。。