この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
西澤です。8/23(金)に東京リージョンにおいて大規模な障害が発生し、多くのシステムが影響を受けました。この障害に際して、可用性を担保する設計の重要性を考えさせられた一方で、切り捨てるものを決め、迅速に復旧し、障害の影響を最小限に抑えることも大切なことだと痛感しました。シングル構成のシステムを運用されていて、復旧に苦労された方も、運良く被害に遭わずに済んだ方も、一緒に考える機会となればと思い、考えたところを残しておきたいと思います。ご意見大歓迎です。
前提
そもそもAWSのベストプラクティスとしては、すべてのシステムはMultiAZで動作するように設計すべきです。では、SingleAZ構成で本番システムを運用することは論外ですか？果たしてそうでしょうか？
初期コストも運用コストも無限にかけられる状態なのであればもちろんベストプラクティスに即した設計にすることが望ましいですが、そうすることができない環境も当然存在すると思いますし、予算上それを許さないケースも当然あり得ると思います。また、可用性を維持したいからといって、いたずらにシステムを複雑に構成することが必ずしも良いことではないとも考えています。必要以上に複雑に構成した仕組みによって、障害発生時の切り分けが困難となり、結果として障害からの復旧に時間がかかるようなシステムも数多く目にしてきました。
ということで、今回はEC2が1台のみで動作しているようなシンプルなシステムの運用を想定し、障害が起こったときにどのように対応するのかを整理し、被害を最低限に食い止めたいと考えました。
障害は発生する
最近は"Design for Failure"という言葉を耳にすることが減ったように思いますが、私がAWSに初めて触れたときに衝撃を受けた考え方の1つでした。障害はどんな環境であれ起こるものです。AWSに限らず、どのようなシステムにおいても障害は発生するものという覚悟と準備をしておく必要があります。
当然リージョン単位での障害まで考慮しておくことが理想ではありますが、東京リージョンが全滅するような大規模な天災が起こった際にも存続し続けなければならないシステムもそう多くは無いはずですので、一旦ここでは考えません。AWSを利用する上で、Availability Zone単体での障害は発生するものと考えておく必要があります。
最低限のバックアップを必ず取得しておく
今回の障害で特に個人的にショックが大きかったのは、大規模なEBS障害が発生したことでした。これまでAWSを利用してきた中で、EBSは単一AZで動作するサービスであることは理解しつつも、データが壊れて使えなくなるというようなケースは極めて稀であったという経験から、インスタンス障害によりサービスダウンは発生したとしても、データが消失することはそう発生しないだろうと高をくくっていたところがありました。正直ここは私自身が認識を改めるきっかけとなりました。お恥ずかしい限りです。
ローカルに一切データを持たず、再構築も容易にできるようコード化されているようなシステムで無い限りは、とにかく必ずバックアップを取得しておきましょう。AWSであれば、専用サーバやソフトウェア、サードパーティツールもなしに、簡単にバックアップを取得することができますので、必ずいずれかの方法をご準備いただきたいと思います。バックアップきちんと取ろうね、というこの当たり前のこと、が実はこの記事で最もお伝えしたいことです。具体的な実現方法は、例えば以下からご検討いただければと思います。
- 【新サービス】 AWSの各種サービスのバックアップを管理するAWS Backupが登場！ ｜ DevelopersIO
- AWS上でEBSスナップショットを取得とそのライフサイクル管理を自動化するのであれば、現状ではAWS BackupによりEBSスナップショットを取得しておくのが最もシンプルな手法かと思いますが、EBSボリューム単位のバックアップとなる点、静止点を持たないオンラインバックアップになる点にはご注意ください（※それでも無いよりはずっとマシです！）
- EBSスナップショットだけでなく、システム全体のAMIを取得することもご検討ください
- AWS運用かんたん自動化ツール opswitch（オプスウィッチ） by クラスメソッド
- クラスメソッドメンバーズのプレミアムプランにご加入のお客様には、かんたんにAMIも取得できるバックアップツール=opswitchがおすすめです
リストアする手順について迷いなく実施できるようテストしておく
今回のような大規模障害時に発生するオペレーションは、正直すべて自動化できるようなものでは無いと感じています。障害が発生している現場では、Stop->Startも正常に動作しない中で、試行錯誤をしているような状況に陥っていました。そんな環境下でも取得したバックアップからリストアが必要になった際に迷いなく操作できるように事前にテストして操作に慣れ、手順を残しておきましょう。
SingleAZでしか動作しない前提のシステムで障害発生時にできること
障害発生直後に、多数のお客様よりお問い合わせをいただきましたが、我々も障害が悪化しているのか、復旧の目処が立っているのか、等の情報をほとんど持ち合わせていない中でお問い合わせ対応を行っていましたが、実際には復旧を待つ以外にできることがほとんどありませんでした。今回の障害も半日程度で(完全ではなかったものの）ほぼ自動復旧したことになります。ユーザからすると、自分から動くことができないのは何とももどかしい時間とはなりますが、オンプレ環境で保守ベンダーを手配して修理を依頼することを考えれば、待つだけで自然に復旧に向かうというのはありがたい限りです。
SingleAZでのみ動作すれば良いと割り切ったシステムであれば、ユーザ側で取れる対応は概ね以下となると思います。
- stop->startを試す(※こちらを試しても正常に動作しないケースが多数発生し、結果待つことになりました)
- EBSディスク差し替えでのリストアを試す
- とにかく待つ
いくつか注意点もありますが、EBSディスク差し替えによるリストアは、インスタンスIDもプライベートIPも既存設定をそのまま流用することができ、オンプレでディスクを抜き差しするのとほぼ同じような操作感覚でリストアすることができますので、ディスク不調による障害の際に試すことができるようにしておくと良いと思います。その際、ブロックデバイスマッピングにてデバイス名だけ間違えないように注意しましょう。
別AZへのリストアを想定してテストしておく
平時はSingleAZ構成で運用しているシステムも、別AZへのリストアが可能な状態になっていれば、復旧を早めることのできる可能性が一気に広がります。障害が発生しているAZを捨てて、新しい環境をすぐに用意することができます。
- ホスト名やプライベートIPに依存しない構成となっている(必要であれば、Private DNS等を利用するように設定しておく)
- EIP付け替えで同等の機能が提供できるようにしておく
- EC2インスタンスのアベイラビリティーゾーンを変更する ｜ DevelopersIO
- Single構成であってもELB配下に配置しておく
- １台のEC2でもELBを使うメリットについてまとめてみました ｜ DevelopersIO
実際には、サブネットを変更してリストアをしても問題なく稼働するのかもしれませんが、テストをしたことが無いためにその決断ができないようなケースも多いのではないかと思います。事前にテストを行い、実現可能かどうか把握しておくことも重要です。
その他、リストア時の注意事項
その他、EC2のリストアを行う際に注意したい点について、思いつく範囲で記載しておきます。
- スナップショットに含まれない各種設定情報が控えてあるか？
- 接続用アカウント情報、SSH鍵、WindowsローカルAdministratorのパスワードは利用可能か？
- Windows環境の場合、sysprepをする必要がないか？
- Windows Server 2016以降はルート情報に注意
- Windows Server EC2インスタンスを別サブネットに移行する際に注意すべきこと ｜ DevelopersIO
まとめ
当初考えていたよりも内容が薄くなってしまったという反省もありますが、少しは頭が整理されたように思います。今回の東京リージョン障害の経験を糧に、より良い設計、運用指針をお客様と一緒に考えて行きたいと考えています。
どこかの誰かのお役に立てば嬉しいです。
15
