WebサイトやWebシステムが、顧客・利用者への情報提供や各種手続き、業務上の重要な接点となっている場合、サーバー障害による停止は、情報提供やサービス利用、業務継続そのものに影響します。
サーバーを複数台用意するなど、同じリージョン内で障害に備える方法もあります。一方、リージョン全体に影響する障害では、同じリージョン内に用意した複数の環境が同時に影響を受ける可能性があります。
今回紹介するリユース事業会社では、こうした障害も想定し、AWS上で運用するWebシステムについて、通常利用するリージョンとは別のリージョンにDR（Disaster Recovery）環境を設けています。
さらに、通常環境のWebサイトが正常に利用できない状態を検知すると、利用者のアクセス先をDR環境へ自動で切り替える構成としています。
別リージョンにDR環境を用意していても、障害発生後の切り替えを人が行う場合は、状況確認や切り替え判断、操作が必要です。担当者が対応を開始するまでの時間や確認作業によっては、DR環境への切り替えに時間を要し、サービス停止時間にも影響します。
本記事では、別リージョンにDR環境を用意したうえで、障害時の切り替えをどのように自動化し、その後の復旧をどのように運用しているのかを紹介します。
障害時の切り替え先として、別リージョンにDR環境を用意
このWebサイトでは、通常利用する環境に問題が発生した場合でも別の環境へ切り替えられるよう、AWS上の異なるリージョンにDR環境を用意しています。
同じリージョン内での復旧だけを前提とせず、通常環境とは別のリージョンにも、サービスを継続するための切り替え先を持つ構成です。
また、DR環境側でも必要なデータを利用できるよう、通常環境と別リージョンの間で必要なデータを連携・保持する構成としています。
通常時から通常環境とDR環境の双方を管理し、サーバーリソースだけでなく、Webサービスやデータ連携に関わる仕組みも監視しています。
つまり、障害が起きてから復旧先を用意するのではなく、あらかじめ別リージョンにサービスを継続するための切り替え先を用意しているということです。
DR環境があっても、手動切り替えでは人が対応する工程が残る
別リージョンにDR環境を用意していても、通常環境に障害が発生した際、自動的にサービス提供先が変わるとは限りません。
DR環境への切り替えを手動で行う場合、例えば次のような工程が発生します。
- 異常を検知する
- 担当者が状況を確認する
- DR環境へ切り替えるか判断する
- 切り替え操作を行う
- DR環境でサービスが利用できることを確認する
監視によって異常を検知できても、切り替えに人の確認・判断・操作が必要であれば、それらの工程が完了するまでDR環境には切り替わりません。
そのため、障害を検知してから担当者が対応を開始するまでの時間や、状況確認・判断にかかる時間が、サービス停止時間に影響します。
特に夜間・休日や大規模障害時など、すぐに担当者が対応できるとは限らない状況では、人による切り替えを前提としていること自体が復旧までの時間に影響します。
もちろん、すべての環境で自動切り替えが必要なわけではありません。一定時間の停止を許容できる場合や、すぐに対応できる運用体制が整っている場合は、手動切り替えも選択肢になります。
一方、人の操作を待たずにDR環境へ切り替えるのであれば、何をもって「通常環境を利用できない」と判断するのかを、あらかじめ決めておく必要があります。
今回のリユース事業会社では、この判断から切り替えまでを仕組み化しています。
Webサイトの異常を検知し、DR環境へ自動で切り替える
今回の環境では、Webサイトの状態を監視し、異常を検知するとDR環境へアクセス先を自動で切り替えます。切り替え後はエンジニアへ通知し、通常環境を復旧したうえで、正常な状態に戻ったことを検知するとアクセス先も自動で戻します。
全体の流れは以下の通りです。
利用者がWebサイトを正常に使える状態かを監視
今回の環境では、単にサーバーが起動しているかを見るのではなく、利用者が実際にWebサイトへアクセスできる状態かを継続的に確認しています。
監視しているのは、WebサイトのHTTPS応答です。
TOPページへアクセスし、正常な応答が返っているかを確認します。正常な応答を確認できない状態が複数回続いた場合に異常と判断することで、一時的な通信エラーが発生しただけですぐにDR環境へ切り替わらないようにしています。
この監視にはAmazon Route 53のヘルスチェックを利用しています。
サーバーそのものが動いているかではなく、利用者がWebサイトを正常に利用できる状態かを基準に、DR環境への切り替えを判断する構成です。
異常を検知すると、利用者のアクセス先をDR環境へ自動で変更
通常環境を正常に利用できない状態と判断すると、利用者のアクセス先を、別リージョンに用意したDR環境へ自動で切り替えます。
利用者をどの環境へ接続させるかを管理するDNSを切り替えることで、通常環境ではなくDR環境へアクセスが向かう仕組みです。この切り替えにもAmazon Route 53を利用しています。
手動であれば、異常を検知した後に担当者が状況を確認し、切り替えるか判断したうえでアクセス先を変更する必要があります。
今回の構成では、Webサイトの監視結果をもとにアクセス先を自動で切り替えるため、担当者が状況を確認し、切り替え操作を開始するまで待つ工程を減らしています。
通常環境が正常に戻ると、アクセス先も自動で戻す
DR環境への切り替え後も、通常環境が再び利用できる状態になったかを継続して確認します。
通常環境が正常に応答する状態へ戻ると、利用者のアクセス先も通常環境へ自動で戻ります。
一方、通常環境で何が起きているのかを調査し、必要な復旧作業を行う部分まで自動化しているわけではありません。
今回のDRでは、サービスを継続するためのアクセス先の切り替え・切り戻しは仕組みで行い、障害そのものの調査・復旧はエンジニアが行うという役割分担にしています。
自動で切り替えるだけでなく、切り替わったことも把握する
DR環境へ自動で切り替わったとしても、そのまま通常環境の障害を放置してよいわけではありません。
そこで今回の環境では、アクセス先を自動で切り替えるだけでなく、切り替えが発生したことも通知する仕組みとしています。
切り替えが発生するとエンジニアへアラートが通知され、通常環境の状態を確認します。通常環境へ戻った場合や、監視データを取得できなくなった場合についても通知されます。
これにより、「サービス継続のための切り替えは自動化し、その後の原因調査・復旧はエンジニアが担当する」という運用にしています。
DR側でサービスを継続している間に、通常環境を復旧する
自動フェイルオーバーを導入していても、すべての障害対応が自動になるわけではありません。
DR環境への切り替え後は、エンジニアが通常環境の状態を確認し、原因調査や復旧作業を行います。
通常環境をすぐに復旧できない場合には、状況に応じてサーバー環境を復旧・再構築します。また、必要に応じてDR側に保持しているデータを利用して通常環境を再構築できるよう、復旧方法も想定しています。
DR環境を用意する目的は、障害そのものをなくすことではありません。
通常環境の復旧に時間がかかる場合でも、その間のサービス提供先を別に確保し、サービス停止時間を抑えることにあります。
今回の構成では、さらにその切り替えについても、人の操作を待たずに行えるようにしています。
手動切り替えと自動切り替えでは、障害時に人が行うことが変わる
手動切り替えと自動切り替えは、別リージョンにDR環境を用意するという点では共通しています。
違いは、異常が起きてからDR環境へ切り替えるまでを、どこまで人が担当するかです。
| 工程 | 手動切り替え | 自動切り替え |
| Webサイトの異常監視 | 実施 | 実施 |
| 切り替え判断 | 人が確認・判断 | 事前に設定した条件 |
| アクセス先の切り替え | 人が実施 | 自動 |
| 切り替え発生の確認 | 人が確認 | アラートを受けて確認 |
| 通常環境の原因調査 | 人が対応 | 人が対応 |
| 通常環境の復旧 | 人が対応 | 人が対応 |
| 通常環境への切り戻し | 運用に応じて対応 | 正常状態を確認して自動で切り戻し |
自動切り替えでは、障害発生後に担当者が状況を確認し、アクセス先を変更するまで待つ工程を減らせます。
一方、自動化するためには、
- 何をもって異常と判断するか
- 一時的なエラーをどう扱うか
- 切り替え先のDR環境をどう維持するか
- 切り替え発生後に誰が障害対応するか
まで事前に決めておく必要があります。
そのため、すべてのWebサイトで自動切り替えが必要というわけではありません。
重要なのは、「自動化した方がよいか」ではなく、「自社ではどの程度のサービス停止を許容でき、そのためにどこまで備える必要があるか」を考えることです。
DR環境があるなら、「障害時にどう切り替わるか」まで確認する
DR環境を用意していても、通常環境の障害時にサービスがすぐDR側へ切り替わるとは限りません。
現在の環境について、例えば次のような点を確認すると、障害時に実際にどう動くのかが見えやすくなります。
- DR環境への切り替えは手動か、自動か
- 何をもって通常環境の異常と判断するか
- 切り替えに人の確認や操作が必要か
- DR側にはサービス提供に必要なデータがあるか
- 切り替わったことを誰が把握するのか
- 通常環境の復旧は誰が行うのか
- 通常環境が復旧した後、どうアクセス先を戻すのか
確認したいのは、単に「DR環境があるか」ではなく、「障害が起きたときにサービスをどう継続する設計になっているか」です。
まとめ｜DR環境があるだけでなく、切り替え方法まで確認する
別リージョンにDR環境を用意していても、障害時の切り替えを人が行う場合には、状況確認や判断、操作が必要です。そのため、DR環境があることと、短時間でサービスを継続できることは同じではありません。
今回紹介したリユース事業会社では、Webサイトが正常に利用できるかを監視し、異常を検知した際には別リージョンのDR環境へアクセス先を自動で切り替える構成としています。
重要なのは、自動切り替えそのものではなく、自社が許容できるサービス停止時間に対して、現在のDR構成や切り替え方法で十分かを確認することです。
クロジカでは、現在のDR構成や障害時の切り替え方法を確認し、必要に応じて別リージョンのDR環境、自動フェイルオーバー、監視・復旧まで支援しています。「DR環境はあるものの、実際に障害時どう切り替わるのか分からない」という場合は、現在の構成確認からご相談ください。
コーポレートサイトをクラウドでセキュアに
クラウドサーバー管理
クロジカガイドブック
- コーポレートサイト構築・運用の課題を解決
- クロジカクラウドサーバー管理の主な機能
- 導入事例
- 導入までの流れ
