ブログ

AWSの運用における大規模障害対応ガイド

AWS を運用する上で、利用中のリージョンにおいて大規模な AWS 障害が発生した時の対策（ディザスタリカバリー）はどのようにすればよいのでしょうか？

今回は目標復旧時間（RTO*）と目標復旧時点（RPO**）の観点から対策を考えていきます。

*… RTO：復旧したい時間の目安。「1時間で復旧して欲しい」場合には RTO は1時間となります。

**… RPO：復旧したい（必要になる）バックアップファイルがいつのものになるかを指します。設定の際には、日時分秒で指定します。

このコンテンツを掲載するきっかけ

お客様から障害発生時の対応について「バックアップへのリストアより速く障害に対応できるオプションはないか」とのご要望をいただきました。

このご要望に対して、当社ではリカバリサイトの構築を提案させていただき、以下の条件でサーバを構築する対応を行いました。

目標復旧時間（RTO）：3時間

目標復旧時点（RPO）：1日

サーバ構成 :メインと同じ構成のサーバをホットスタンバイサーバとして別リージョンに用意し、障害時にはサーバを入れ替える

当社が行なった構成内容

今回の対応で当社が構成した内容は以下の通りです。

・東京のメインサーバと同じ構成のリカバリサーバを大阪リージョンに構築

・大阪リージョンのリカバリサーバはホットスタンバイサーバとして常時起動

・メインサーバとリカバリサーバは1日1回自動で同期を行う

上記の構成にすることで、

・リカバリサイトへの切り替えは数分で完了するため、RTO の3時間までに十分対応可能

・1日1回の同期により、RPO の1日にも対応

といった利点が生まれます。

また、メインサーバのヘルスチェックが失敗した場合にメールで通知を送信するように設定しており、障害が起こった際にもリアルタイムな対応が可能になりました。

障害発生時の対応

障害が発生した際には、以下の対応を行います。

Route53-healthCheck
  1. Route53 のヘルスチェック機能にてメインサーバの障害を検知、メールで通知
  2. 障害を検知したら Route53 で、CloudFront のオリジンサーバの DNS レコードを書き換え、ホットスタンバイサーバに切り替える
  3. 数分でリカバリサーバに切り替わり障害解消、メールで通知

具体的な構成手順

ここからは当社が行なった具体的な構成の手順を紹介します。

ヘルスチェックを使用しリカバリサーバを用意

route53-recovery

必要なリソース

EC2 インスタンス x 2

　プライマリインスタンス

　セカンダリインスタンス（プライマリとは別のリージョンに作成）

Route53 ヘルスチェック

　プライマリ用

　セカンダリ用

Route53 レコード

　プライマリ用

　セカンダリ用

CloudWatch アラーム

　プライマリ用（ヘルスチェック作成で自動作成）

　セカンダリ用（ヘルスチェック作成で自動作成）

SNS トピック

　プライマリ用（ヘルスチェック作成で自動作成）

手順1. オリジンの作成

EC2 インスタンスを、2つのリージョンに1つずつ作成します。

例えば今回の場合は、東京リージョンと大阪リージョンの2つです。

手順2. ヘルスチェックの作成

Route53 ヘルスチェックをプライマリ用、セカンダリ用それぞれ作成します。

ヘルスチェック作成時に CloudWatch アラーム、SNS トピックが自動的に作成されます。

また、作成された段階で SNS トピックから、登録したメールアドレスに認証メールが届きます。

メールから認証を完了しないと通知が来ないので早めに認証作業を完了させましょう。

ヘルスチェック設定例

Route53 ヘルスチェック設定例1
  • 名前 : 適当なものを記載
  • モニタリングの対象 : エンドポイント
  • エンドポイントの指定 : ドメイン名
  • プロトコル : HTTP
  • ドメイン名 : EC2 のパブリック IPv4 DNS
  • ポート : 80
Route53 ヘルスチェック設定例2
  • アラームの作成 : はい
  • 通知の送信先 : 新しい SNS トピック
  • トピック名 : 適当なものを記載
  • Eメール受取人のアドレス : 適当なものを記載

手順3. Route53 レコードの作成

Route53 レコードをプライマリ用、セカンダリ用をそれぞれ作成します。

Route53 ヘルスチェック設定例3
  • レコード名 : ドメイン
  • レコードタイプ : A か AAAA
  • 値 : EC2 インスタンスを指定
  • エイリアス : いいえ
  • TTL : 用途に応じて
  • ルーティングポリシー :フェイルオーバー
  • フェイルオーバーレコードタイプ : プライマリ、セカンダリ
  • ヘルスチェックID : Route53 ヘルスチェック
  • レコードID : プライマリとセカンダリで別のID

手順4. CloudWatch アラームの設定追加

Route53 ヘルスチェック作成時に、自動的に CloudWatch アラームが作成されます。

そのままでもヘルスチェックのエラーは、CloudWatch アラームが設定したメールに通知してくれますが、エラー状態の解除は通知してくれません。

エラー状態の解除も通知するように設定を追加しましょう。

Route53 ヘルスチェック設定例4
  1. 作成された CloudWatch アラームを Route53 ヘルスチェックから確認
  2. アクションのプルダウンから編集を選択
  3. アクションの設定で通知の追加をクリック、OKを選択

手順5. 動作テスト

プライマリインスタンスを手動で停止し

・セカンダリに切り替わること

・再起動後にプライマリに戻ること

の２つを確認します。

（なお、動作テスト中は CloudFront の TTL を一時的に短くすると、プライマリインスタンスを停止してから、セカンダリインスタンスに切り替わるまでが早いです。参考までに、 TTL 10sec でのプライマリ停止後に切り替わるまでの時間は3分弱でした）

例 :

>dig [レコード名] @1.1.1.1
~
;; ANSWER SECTION:
[レコード名]. 60 IN	A	[primary Elastic IP]
~

プライマリ停止

>dig [レコード名] @1.1.1.1
~
;; ANSWER SECTION:
[レコード名]. 60 IN	A	[secondary Elastic IP]
~

プライマリ起動

>dig [レコード名] @1.1.1.1
~
;; ANSWER SECTION:
[レコード名]. 60 IN	A	[primary Elastic IP]

手順6. EBSの同期スクリプトの作成

EBSの同期スクリプト

wordmove( https://github.com/welaika/wordmove )を用いて、プライマリインスタンスからセカンダリインスタンスに、1日1回データ同期を実施します。

まとめ

今回は、AWS の運用において備えておいて損はない、大規模障害に対応するための当社の取り組みを実際の例を用いて紹介してきました。

しかし

「自社の構成に合った対応方法が知りたい」

「障害への対策は必要だが、担当できるエンジニアがいない」

といった企業様もいらっしゃるかと思います。

そんな時は当社にご相談ください！

当社は設立当初から WordPress を取り扱っており、AWS に関してもセミナーへの参加や登壇、コミュニティへの貢献など、多方面の知識を持っています。

お問い合わせいただければ、専門のスタッフがお客様の課題をヒアリングし、ご希望に応えられる提案をさせていただきます。右下のチャットボタンからお問い合わせください。

詳しくは下記ページよりご覧ください。

https://labworks.digitalcube.jp/services/

また、WordPress 専用のフルマネージドホスティング「Amimoto」も提供しています。特徴は下記よりご覧ください。

特徴

お勧めの記事