AWS障害による影響を小さくするための設計(2011/4/21の障害を踏まえて) – よかろうもん!

youRoomでの障害対応と、SonicGardenの運用の考え方について、先日id:mat_akiがブログを公開しました。 

youRoomにおいて発生した 2011/4/21 のAWSの障害について技術的な観点から

今回のブログでは、”今回のAWSの障害を通じて、AWSを今後も活用していくための振り返りを、より技術的な観点からしたいと思います”。

今回は、us-east-1リージョンにおけるEBSのサービス障害が問題となりましたが、この影響を受けて多くのWEBサービスがダウンし、サービス再開までに多くの時間を費やしていました。

なぜEBSのサービス障害で(まだ断定はできませんが…)、これほど広範囲に影響が出たのでしょうか?

今回、幸いにも『youRoom』のサービスは1時間たらずでサービス復旧できましたが、もちろん課題もいくつか見つかりました。

課題と対策を考えていく上で、様々なことを検討しましたので、そのアウトプットの一部を公開しすることで、AWSの今後の発展に貢献出来ればと思います。

私も今回のサービス障害で影響を受けましたが、AWSが優れたサービスであり、今後も活用したいサービスであるという思いに変わりはありませんでした。

では、今回のEBS障害を踏まえ、AWSを今後も活用し、安定したサービスを提供できるようにするためにはどのような対策が必要かを気づいたレベルで簡単にまとめておきます。

(1) EBSのバックアップとしてsnapshotだけではなく、実データをS3や別ストレージに保存しましょう

EC2を活用している多くの方が、ユーザがアップロードするファイルなどのデータの格納領域としてEBSボリュームの領域を利用していたかと思います。

そして、バックアップとしてEBSボリュームのスナップショット(S3に保存されます)を活用していたかと思います。

この仕組みは、シンプルで実現しやすいですが、この仕組みだと、今回のEBSサービス障害時には、SnapshotからEBSボリュームを生成することもできなかったのではないでしょうか?(※1)

SonicGardenの運用ポリシーとして、”EBSに格納するデータはsnapshotだけでなく必ずS3にいつでも取り出せる形式で保存しておく“というのがあります。

例えば、EBS領域にMySQLのデータベース領域を配置していた場合、EBSのsnapshotだけではなく、mysqldumpコマンドを活用してDBのデータを別ファイルに吐き出し、それをS3に保存しておくという具合です。(※2)

このような設計にしておくことで、今回のEBSのサービス障害が発生した場合でも、EBS領域に保存しておいたデータを完全な状態のデータではないにしろ取り出すことはできたのではないでしょうか。

データが取り出せる状態になってさえいれば、最悪の事態(EBS領域のデータが完全ロスト)を免れることができますし、サービス復旧のことも考えられます。

そのため、今後はEBSのバックアップとしてsnapshotだけではなく、実データをきちんとS3などEBSに依存しない形でのバックアップも取得しておくとよいでしょう。

(2) snapshot生成のステータスも監視しましょう

EBSボリュームのバックアップで、定期snapshot取得を保存するバッチを仕込んでおいて、数世代分だけsnapshotとして保存しておくようなやり方をしている方は多いかと思います。

このやり方、仕組みによってはsnapshotが使い物にならないものになってしまう可能性がありました。

4/21の16:00頃からEBSボリュームのsnapshot作成がなかなかできない状況(ステータスがpendのまま)になっていたのはご存知でしょうか?

このことに気づくことができなかった場合、snapshotを自動で作成/削除していたにもかかわらず、いつのまにか全てのsnapshotがpendの状態のものになってしまい、バックアップとして意味をなさないようになってしまいます。

そのため、新しいsnapshotを作成する場合には、過去に取得したsnapshotのステータスなども確認し、きちんとバックアップできているかの確認をすることを怠らないようにしておきましょう。

こちらに関しては、後日、SonicGardenで利用している仕組み(RightScaleが公開しているright_awsを利用したもの)を公開したいと思っています。しばしお待ちを。

(3) EBSの障害が発生してもインスタンスが起動できる仕組みにしておきましょう

EC2にはAMI(インスタンスイメージ)の格納方法として、インスタンスストアタイプとEBSタイプの2種類があり、最近はAMIの作成などが容易なEBSタイプが主流になっています。

ですが、今回の障害時にEBSタイプのAMIしか準備していなかった場合、新しいインスタンス(仮想サーバ)を起動することすらできない状態になった方もいらっしゃるのではないでしょうか?(※1)

あくまで私の個人的な見解ですが、今回、AWSを利用しているWEBサービスの長時間のサービスダウンの原因として、EBSタイプのAMIしか準備しておらず、新しいインスタンスを起動することができず、手詰まりだった方が多かったのではないかと考えています。

幸いにもというか偶然にも「youRoom」のAMIは両方の形式で保存していたため、新しいインスタンスをすぐに準備することができましたが、もしEBSストアのものだけしか準備できていなかった場合、サービス復旧により多くの時間を要したかもしれません。

結論としては、サービス復旧の時間を短くするためには、楽ができるEBSタイプのAMIだけではなく、インスタンスストアタイプも準備しておく、もしくは別のロケーションで新しいインスタンスを起動できるようにしておく仕組みを準備しておくべきでしょう。

以上、大きく3点のことについて振り返りをしました。

これから対策しなければならない点も多々ありますが、今後もAWSをはじめとするIaaS/PaaSのクラウドサービスを活用しつつ、安定性/信頼性の高いサービス実現に向けて取り組んでいきたいと考えています。

最後に。

私は大きく上記の3点のことに関して検討・振り返りしましたが、他の観点でいろいろと考えている方もいらっしゃるかと思います。

そのような方はぜひ、障害情報および対策情報をオープンにし、今後のAWSの発展に貢献していただけないでしょうか

AWS以外のIaaS/PaaSのサービス提供者への良いインプット情報にもなるかと思いますので、積極的な情報公開を期待しています。

※1 実際に私が経験した訳ではなく、EBS障害中はsnapshotへのアクセスおよびEBSタイプのインスタンス起動もできなかったのではないかという想定のもと、このような記述をしています。詳しい情報をお持ちの方がいらっしゃいましたら、コメントで情報提供をしてくださいますと幸いです。

※2 S3ではなくAWSに依存しない場所に保存しておいた方が、データロストの心配は減りますし、AWS障害時に迅速なサービス復旧を実現できるのかもしれませんが、S3の高信頼性(99.999999999% の耐久性と、99.99% の可用性を提供)を考慮した上で、SonicGardenではバックアップストレージとしてS3を利用しています。

広告

コメントを残す

以下に詳細を記入するか、アイコンをクリックしてログインしてください。

WordPress.com ロゴ

WordPress.com アカウントを使ってコメントしています。 ログアウト / 変更 )

Twitter 画像

Twitter アカウントを使ってコメントしています。 ログアウト / 変更 )

Facebook の写真

Facebook アカウントを使ってコメントしています。 ログアウト / 変更 )

Google+ フォト

Google+ アカウントを使ってコメントしています。 ログアウト / 変更 )

%s と連携中