s_tajima:TechBlog

渋谷で働くインフラエンジニアのTechブログです。

AWSでリージョン間の自動DR構成を構築してみた #vgadvent2013

こんにちは、
VOYAGE GROUP エンジニアブログ Advent Calendar 2013 の2日目担当の @s_tajima です。

僕は今インフラエンジニアとして働いているのですが、
障害が発生すると携帯にアラートメールや電話がとんできて対応を迫られます。

そして障害というのはたいてい楽しいイベントが行われているときに発生するものです。
そういうものと割り切ってせっせと対応をするのもよいのですが、
僕は年末の楽しいイベントを邪魔されたくありません。
それはもちろんAWSの東京リージョンのデータセンターがすべて同時に火事でなくなってしまうような非常事態でもです。

ということで今日はAWSのリージョン間自動DR構成をつくってみた話をしようと思います。


今回のDR構成を構築する上で、カギとなるAWSの機能は以下の3つです。

これらの技術を組み合わせてリージョン間自動DR構成を構築します。

DR構成の概要

  • 通常時

f:id:s_tajima:20131130130925p:plain

  • 障害発生時

f:id:s_tajima:20131130130921p:plain

具体的な設定 (※EC2やELBの構築方法などは省略)

Route53の設定
  • RecordSetを2つ設定します。(Primary, Secondary)

f:id:s_tajima:20131130132110p:plainf:id:s_tajima:20131130132015p:plain

RDSの設定
  • シンガポールリージョンを指定して、ReadReplicaを作成します。

f:id:s_tajima:20131130132248p:plain

監視サーバーで稼働させるスクリプト
  • 正常時に稼働しているELBの名前で解決できるIPと、サービスのFQDNで解決されるIPを比較します。
  • 上記のIPが食い違う場合はRoute 53によるDNSのFailOverが発生していると判断し、シンガポールリージョンのRDSに対してPromote Read Replicaを発行します。
  • このスクリプトを監視サーバーで定期的に実行します。

Check DNS Failover, and exec promote read replica.

実際にテストしてみた

上記のような構成を実際に構築し、自動フェイルオーバーのテストをしてみました。
時系列を示すと以下のようになります。

  1. [20:34:14] (仮)東京リージョンでの障害発生
  2. [20:35:12] 東京リージョンのELBのステータスがunhealthyに
  3. [20:36:47] Route53から返却されるIPがシンガポールリージョンのELBのものに
  4. [20:36:48] 監視サーバーで稼働しているfailover.rbがIPの変更を検知, Promote Read Replicaを発行
  5. [20:37:00] シンガポールリージョンのRDSのステータスがmodifyとなる
  6. [20:48:00] シンガポールリージョンのRDSのステータスがAvailableに

5. から6. にかけてが少し長いように見えますが実際にはAvailableになる前からMySQL的には書き込み可能な状態になっています。
よって障害発生から10分ほどで別リージョンでのサービス稼働ができていることになります。

まとめ

  • リージョン間のDR構成をこんなに簡単に作れるAWSすごい。
  • failover.rbの作りが雑なので実運用するならもう少し丁寧につくらないといけなさそう。
  • 今回は完全なホットスタンバイ構成をとりましたが要件によってはfailover時にEC2インスタンスを上げるとかしてもよさそうです。
  • フェイルバック時は、東京リージョンにリードレプリカを作成しPromote Read Replicaを行います。

以上です。これで年末も安心して飲み会にいけますね。
みなさまよい年末を。

明日のAdvent Calendarは @brtriver さんがお届けします!
お楽しみに!