諸般の事情でConoHaのVPSで非冗長構成でWebアプリケーションをホスティングしている。
先日、ConoHaのVPSでホスト障害が発生して、そのWebアプリケーションのインスタンスが該当した。
障害は往々にして連鎖するもので、ファイルシステムが破損してインスタンスが起動しなくなってしまった。
なかなか出会うことのない状況なので、やったことと所感をメモしておく。
リカバリ
リカバリー自体は特に問題なかった。
インスタンスのスナップショットを（小労力で障害から回復できるように）自動取得するように設定していたので、以下の手順で事足りた。
- ConoHaの障害対応を待つ
- 収容ホストが変わったようだった（完全に壊れたのだろう）
- DNSからレコード削除（少し乱暴だったかもしれない）
- 一応TTL待つ
- インスタンスを落とす
- バックアップのディスクスナップショットからサーバーを再構築
- アプリケーションを再デプロイ
- DNSのレコードを再登録
これで特に問題なく復旧した。
うまく行かなかったら新規のインスタンスをゼロから作ったり、それに伴ってネットワークの設定を変えたりと（IaCはしていなかったので）手間が相当にかかりそうだったので助かった。
最小限のリカバリープランとして、バックアップを取っておいてとても良かった。
コントロールパネル上での自動バックアップの設定。手抜きで復旧できるようにするなら大事。
インスタンス停止中は再構築を選択できる。取得しておいた無事なスナップショットから復元すれば、その状態に戻る。
サービスレベル感
今回の例では、障害が発生してアプリケーションが停止しても、そのうち、少労力で復元できるように、程度のサービスレベル感で障害時の復元を計画していた。
つまり、非冗長構成で、定期的なバックアップ取得だけ。
止まってもいい、というポリシーならこの程度でいいのではなかろうか。
止まってはマズいのであれば、ホスト障害程度のレベルの障害には対応できるように冗長構成をしておきたい。
大手のクラウドサービスならマルチAZで構成すれば確実だし、ConoHaであっても各インスタンスの収容ホストは提示されているので、別々のホストのインスタンスで構成すればいいだろう。
『コンピュータは停止するものである』
というのは大前提だ。
極端な話、強烈な太陽フレアが地球に降り注いだら、イレブンナインの耐久性をSLAしているS3だってデータが破損するだろうし、100%のSLAをうたっているRoute53だって止まるだろう。 （そもそも、インターネットがどうこうって状況じゃなくなるだろうけれど）
SLAはしょせんはそのサービスレベルを約束しているだけで、それを満たせるわけではない。 （ConoHaのVPSのSLAは99.99%、今回はそれには抵触したはず）
そんなことをしみじみと思った。
