先週の木曜日の午後に AWS で障害が発生しました。AWS EC2 では Region と Availability Zone という概念で区画されています。障害が発生した Region は us-east-1 (米国 東海岸) でした。この us-east-1 は一番古く、顧客も多いので、数の論理と古い資産という意味で、価格が他の Region より安価で、個人的に AWS を使っている私は、ネットワーク・レイテンシーよりもお値段という事で、この Region を愛用しています。
さて、AWS からの障害通知 (AWSWatch ありがとうございます) を受けて、us-east-1 で稼動している、私の instance 達を確認したところ、問題なく元気に動いていました。instance はそれぞれ別の AZ でバラけさせて稼働させています。EBS backed instance が便利なので、EBS backed instance に移行し、新規構築する場合も EBS backed にしていました。ただし一番古い 1 つの instance のみ instance store になっていました。この blog が稼動している(た)のが、この古い instance なのです。
この instance には MySQL 用に EBS Volume を attach しています。
障害が長引くにつれて、us-east-1 の EBS に障害が発生しているという事が報告され、つまり、私は障害が影響する可能性はあったのですが、稼働状況を確認しても不具合は無く幸運に恵まれたかもと、その日は就寝しました。
翌日、起床後すぐに稼働状況を確認したところ、金曜日の午前1時ごろから munin のグラフで異常があるのを見つけました。この blog の稼動しているサーバの iowait が高くなっていました。他の instance は異常はありませんでした。
サーバに login して、EBS の中身を見ると、アクセスは可能であり、この段階で backup を取るコマンドを投入したところ失敗しました。blog の閲覧はこの時点でも問題なくできており、varnish や memcache をつかった構成であったのが幸いして、cache からコンテンツは参照できてたようです。
この段階で、EBS の snapshot を取るという作戦はあったと思います。しかし、EBS 全体の障害であるという事と長期化しているという事を考えて、下手に動くと余計に悪くなるという経験上の判断があり、個人のサイトでもあり、Amazon の Ops の活躍を待っておこうと手は付けずにいました。
金曜日の午後になって、障害が1つの AZ のみになったとの報告が出た時点で、そろそろ対策をした方がいいかなと感じ始め、また該当 instance のOSがもう EOL 寸前なので、EBS backed でカレント・バージョンのOSで環境再構築する準備を始めました。他の AZ では EBS backed instance の起動は出来ていたので、古い instance から環境を移し、あとは、障害が発生している、MySQL の DB の移行のみという所まで構築しました。
障害報告によると、該当のAZで障害があるEBSは detach するな、reboot するなとの事
その日夜までは、cache からコンテンツの参照はできていましたが深夜には MySQL に引きずられて、apache が動かなくなりました。この為、AWSの障害時のノウハウを得るために冒険に出ました。EBS の snapshot を試みるも取れない、EBS の強制 detach もダメ。instance を reboot してもダメ。AWS からの報告を見るとdetach の API を殺しているとの事。がんばれー > AWS Ops という事でその日は就寝。
土曜日になりました。まだ復帰していない。なんと長い障害でしょう。AWSで初めての事かもしれません。
朝8時頃に snapshot が取れるようになっていました。もうこうなったら楽勝。健全な AZ で EBS Volume を作成し、昨日つくっておいた EBS backed instance に attach して、設定確認して、Elastic IP すげ替えて一件落着。このあたりが素晴らしく楽で、もう絶対に昔に戻れないとしみじみ思うところですね。
さて、障害を起こしたことはきちんと postmortem をしてもらう事は当然。今回の障害のイケテナイ所は、EBS の設計ですね。一旦障害がおこったら re-mirror の嵐になる。ちょうど銀行の取り付け騒ぎと同じですね。 このイケテナイ所よりもっとイケテナイ所は、1つの AZ に閉じていなかった所です。これはイカン。
さて、私たち Ops 側としても、今回は重要な経験を得たと思います。AWS は究極のセルフサービスであると私は事あるごとに言っていましたが、このセルフサービスを使うコツ、これを意識する事が重要なのです。
さてさて、勉強勉強。