AWS 上のシステムでリージョン切り替えの避難訓練を年末にやってみた

AWS マルチリージョン

f:id:nsmr_jx:20220104095954j:plain あけましておめでとうございます。 サーバーサイドエンジニアの @kimihiro_n です。

今日はAWSに載っているシステムの避難訓練を実施したことについて書いてみようと思います。

弊社が提供している FASTALERT というサービスでは、全国の災害や事件などを検知して報道機関や自治体、インフラを支える企業などにリスク情報として提供しています。 リスク情報を提供するという性質上、情報検知の素早さや網羅性に加えて「システムの可用性」も重要なサービスの要素となっています。

FASTALERT の多くのシステムは AWS の東京リージョンで動いており、複数データセンターを活用した冗長化(マルチAZ)がされています。 しかし、例えば大規模地震のような広域かつ被害の大きい災害の場合、東京リージョン全体にわたって問題が発生する可能性があります。 首都直下型の大きな地震は今後30年以内に70％の確率で発生すると予想されており*1、東京リージョンのみに頼らない構成が必要であると考えています。

また災害に限らず、AWSの特定のサービスで障害が発生した場合でも、別のリージョンへ切り替えることで素早く復旧できるケースもあるため、マルチリージョンでシステムを構成しておくことは可用性を高めてくれます。

マルチリージョン化の進め方

AWS のマルチリージョン化については、主要なコンポーネントから少しずつ進めていきました。 FASTALERT のシステムはマイクロサービス的に機能ごとに複数のコンポーネントに分かれており、止まってしまうと困る部分を優先的にリージョン単位で冗長化していきました。

実際の作業としては、リージョン間でネットワークの相互疎通できるよう土台を整え、それからデータベースやアプリケーションの冗長化に手をつけていきました。

要となるデータベースは Amazon Auroraを利用しているので、グローバルデータベース機能が利用できました。 グローバルデータベースを活用すると、データベースのリードレプリカが別リージョンへ簡単に作成できます。 また東京リージョンで障害が発生した際には、フェイルオーバー操作によって書き込み用の Writer へと昇格することが可能です。

コンポーネントの冗長化にあたっては、費用の面もあるのでホットスタンバイするものとコールドスタンバイにしておくものなど適宜使い分けるようにしています。 データベースなどリージョン切り替えに時間を要するものはホットスタンバイとして常時動かしておき、ECSで動くサービスなど素早く起動して利用できるものは停止した状態で冗長化しています。

システム自体の冗長化に加えて、欠かせないのが移行手順のドキュメント化です。 東京リージョンがまるごと利用困難になるレベルの災害を想定すると、東京にいるエンジニアも対応できない状況になっている可能性が高いです。 こうした非常時に、リモートで動けるエンジニアへバトンタッチ出来るようしっかりとしたドキュメントを用意しておく必要があります。

避難訓練の実施

個々のコンポーネントの冗長構成と動作確認は適宜行っていたのですが、全体を通して「東京リージョンの機能がほぼ使えなくなった」シナリオでの検証はやったことがありませんでした。 シナリオを想定してみることで、どの順序で何をすべきかや、どれくらい時間がかかるかなどを洗い出すことが出来ます。

ちょうど年末年始の休みで開発のキリがいいタイミングがあったため、避難訓練を実施してみることにしました。

ちなみにAWS のマネジメントコンソールは使える仮定でやっていました。実際になってみないと何が使えて何が使えないのかは分からないですが、何もかも使えないことに対処しようとすると無限に工数と費用がかかってしまうため、出来る範囲で対処できるケースを増やしていくのが大事だと思います。

避難訓練は、メンバーの1人に画面共有してもらい、マニュアル通りにリージョンの切り替え作業を行ってもらう形で実施しました。 他のメンバーは手順が正しいことを確認しつつ、サービスの状態を監視したり、どのタイミングで何を操作したかの記録を取っていきました。 マニュアルで分かりづらい点や不具合、エラーがでた箇所なども適宜メモしています。

避難訓練を実施してみて

元の状態に戻すところまで含めて1時間ぐらいで終わるかなと思っていたのですが、実際は2時間かかってしまいました。

時間がかかった要因としては、マニュアル通りにうまくいかなかったことがあったことが挙げられます。 ドキュメントを作成してからシステム自体に変更が入りそのままでは動かなくなってしまっているケースや、ターゲットのリージョンで操作すべき項目を東京リージョン側で操作してしまったケースなどがありました。 練習なので落ち着いて調査出来ましたが、実際に障害が発生しているときだと大変です。 事前に不備を訓練で洗い出すことが出来たのはよかったです。

またこうすればもっと省力化できそう、みたいなアイデアも出てきたので避難訓練を実施した価値は十分あったかなと思います。 大規模な災害は起こってほしくないですが、万が一の際でも安定して提供できるサービスを作っていきたいですね。

*1:https://www.mlit.go.jp/hakusyo/mlit/r01/hakusho/r02/html/n1222000.html

© 2022 JX PRESS Corp.