SingleAZ配置のEC2インスタンスで障害発生時の影響を最小化する

SingleAZ配置のEC2インスタンスにおいて、障害発生時にどのような対応が取れるのか整理してみました。

#Amazon EC2

#AWS

にしざわ

2019.08.28

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

西澤です。8/23(金)に東京リージョンにおいて大規模な障害が発生し、多くのシステムが影響を受けました。この障害に際して、可用性を担保する設計の重要性を考えさせられた一方で、切り捨てるものを決め、迅速に復旧し、障害の影響を最小限に抑えることも大切なことだと痛感しました。シングル構成のシステムを運用されていて、復旧に苦労された方も、運良く被害に遭わずに済んだ方も、一緒に考える機会となればと思い、考えたところを残しておきたいと思います。ご意見大歓迎です。

前提

そもそもAWSのベストプラクティスとしては、すべてのシステムはMultiAZで動作するように設計すべきです。では、SingleAZ構成で本番システムを運用することは論外ですか？果たしてそうでしょうか？

初期コストも運用コストも無限にかけられる状態なのであればもちろんベストプラクティスに即した設計にすることが望ましいですが、そうすることができない環境も当然存在すると思いますし、予算上それを許さないケースも当然あり得ると思います。また、可用性を維持したいからといって、いたずらにシステムを複雑に構成することが必ずしも良いことではないとも考えています。必要以上に複雑に構成した仕組みによって、障害発生時の切り分けが困難となり、結果として障害からの復旧に時間がかかるようなシステムも数多く目にしてきました。

ということで、今回はEC2が1台のみで動作しているようなシンプルなシステムの運用を想定し、障害が起こったときにどのように対応するのかを整理し、被害を最低限に食い止めたいと考えました。

障害は発生する

最近は"Design for Failure"という言葉を耳にすることが減ったように思いますが、私がAWSに初めて触れたときに衝撃を受けた考え方の1つでした。障害はどんな環境であれ起こるものです。AWSに限らず、どのようなシステムにおいても障害は発生するものという覚悟と準備をしておく必要があります。

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も正常に動作しない中で、試行錯誤をしているような状況に陥っていました。そんな環境下でも取得したバックアップからリストアが必要になった際に迷いなく操作できるように事前にテストして操作に慣れ、手順を残しておきましょう。

EBSスナップショットからのレストア

SingleAZでしか動作しない前提のシステムで障害発生時にできること

障害発生直後に、多数のお客様よりお問い合わせをいただきましたが、我々も障害が悪化しているのか、復旧の目処が立っているのか、等の情報をほとんど持ち合わせていない中でお問い合わせ対応を行っていましたが、実際には復旧を待つ以外にできることがほとんどありませんでした。今回の障害も半日程度で(完全ではなかったものの）ほぼ自動復旧したことになります。ユーザからすると、自分から動くことができないのは何とももどかしい時間とはなりますが、オンプレ環境で保守ベンダーを手配して修理を依頼することを考えれば、待つだけで自然に復旧に向かうというのはありがたい限りです。

SingleAZでのみ動作すれば良いと割り切ったシステムであれば、ユーザ側で取れる対応は概ね以下となると思います。

stop->startを試す(※こちらを試しても正常に動作しないケースが多数発生し、結果待つことになりました)
EBSディスク差し替えでのリストアを試す
とにかく待つ

いくつか注意点もありますが、EBSディスク差し替えによるリストアは、インスタンスIDもプライベートIPも既存設定をそのまま流用することができ、オンプレでディスクを抜き差しするのとほぼ同じような操作感覚でリストアすることができますので、ディスク不調による障害の際に試すことができるようにしておくと良いと思います。その際、ブロックデバイスマッピングにてデバイス名だけ間違えないように注意しましょう。