ご挨拶
ソニービズネットワークス 開発本部 インテグレーション部の濱田 一成です。 この度NURO Bizとマネージドクラウド with AWSの統合に伴い、NUROのお客様にも弊社のAWS事業をもっと知っていただこうと、エンジニアによる技術ブログを開設する運びとなりました。 提案事例や好きなサービスの紹介等、各エンジニアの個性が出る内容にしていけたらいいなと思っています。
AWSエンジニアの定番の自己紹介といえば、やはり好きなAWSサービスですね。 タイトルに記載があるのでお察しだと思いますが、私の好きなAWSサービスはCloudFormationです。 初めてAWSに触れた際、定義したリソースが一気に立ち上がる便利さに感動した覚えがあります。
そんな訳で私の最初の投稿は、CloudFormationの面白さを、実際の提案事例を交えてお伝えしたいと思います。 ……が、その前に。 今回は事例の紹介に文字数を使い過ぎてしまった為、CloudFormationまでたどり着きません。 予めお詫び申し上げます。
提案事例
2021年にAWSでDirect Connect(以降DX)起因の大きな障害があったのは、皆さん記憶に新しいと思います。 あの時は弊社の提供するDXも利用不可となり、多くのお客様に多大なる影響を及ぼしました。
その後、とあるお客様より 「東京リージョンの障害時、大阪リージョンに切り替えて業務を継続したい。」 というご相談を頂きました。
整理すると、今回のお客様のご要件はこんな感じです。
- ・東京リージョンでの障害発生時、大阪リージョンにDRしたい
- ・大阪リージョンは非常時にしか使用しない
- ・今回のようなDX障害に耐えられる構成にしたい
- ・なるべくコストを抑えたい
- ・社内システムなので、RTO & RPO はそこまで厳しくない
以下がお客様の構成図です。
オンプレミス環境とVPCをDXで接続し、内向けロードバランサー経由でWebシステムへアクセスする。 冗長構成の取れた、理想的な設計です。 しかし、DX障害時はロードバランサーまでの経路が使用不可となり、業務停止に陥ったそうです。
なるほどなるほど。 1つずつ要件を押さえていきましょう。 まず、DRと言えば、以下の方法が定石です。
- バックアップ・リストア方式
- コールドスタンバイ方式
- ホットスタンバイ方式
今回はなるべくコストを減らしたい、かつ、多少のRTO & RPO が許容されるという事から、バックアップ・リストア方式を採用します。 こちらは障害発生時にバックアップからリソースをリストアする方法です。 コストは最も押さえられますが、リソースを都度作成する為、RPO & RTO が長くなります。 EC2とRDSのスナップショットを継続的に大阪リージョンへコピーし、障害時に立ち上げる構成としましょう。
次に、DX障害に耐えられる構成という事で、東京リージョンを経由しない経路を用意します。 今回はコストを押さえたいので、オンプレミスと VPC を Site To Site VPN で接続する経路が良いでしょう。
最後にもう1つ、WebとRDSの接続点を修正します。 RDSはマネージドサービスで、IPアドレスではなくCNAMEレコードで接続します。 このCNAMEレコードには、以下の命名規則があります。
- ・<ユーザ任意の識別子>.<アカウントの特定の地域の固定識別子>.<リージョン名>.rds.amazonaws.com
つまり、別リージョンに立ち上げるとCNAMEレコードが変更され、Webサーバの参照設定を都度編集する必要があるのです。 それを避ける為に、WebサーバはRoute 53のプライベートホストゾーンを参照する様に設定変更します。
さて、ようやく完成形が見えましたね。 障害発生時、以下の赤枠の様な構成でリソースを作成してあげればいいのです。
これで完璧です！ ……しかし、これらのリソースを手動で作成しいちいち設定していたら、完了する頃には障害が復旧していそうですね。
そこで、満を持して、CloudFormartionの出番という訳です。 これらのリソースをまるっと立ち上げ、工数の大幅削減を狙います。 しかし、今回はここで文字数上限です。 次回以降でこれらのアーキテクチャを実装する方法をご紹介します。 お楽しみに！
