AWSとCloudflareを使ってマルチクラウドのようなCDNを構築してみた
こんにちは、こんばんは
DELTAのインフラエンジニアの馬場です。
以前、Cloudflareの社内勉強会を行った際のレポートをNoteの記事にまとめさせていただきました。
今回は社内でもCloudflareを使っていく中で出てきた可用性向上のためのアーキテクチャ変更について記事を書いていこうと思います！
今回の記事を書くに至った背景
Cloudflareは以前にちょいちょいサービス障害があったため、悪いイメージがついてしまい、サービスが停止すると売り上げが多く減ってしまうサービスに利用するには、不安だという声が聞こえていました。
なので、通信費を浮かせるために普段はCloudflareのCDNを利用しつつ、障害が起きたときにはAWSのCloudFrontに切り替わるようなアーキテクチャを少しのコストで実現し、１部分だけマルチクラウドのような構成にすることで可用性の向上を狙うことにしました。
今回実現する構成
AWSで構築したサービスの前にCloudflareを配置するのは前回の記事と同じだが、Cloudflareの障害があった際に備えてCloudflareをプライマリとして普段使いのCDNとして使いつつ、障害が起きたときにはCloudFrontに切り替わるようにする。
実際にやっていく！
AWS上にwebサイト等の既存リソースがすでに構築されている前提で話を進めます。
私の環境では下記で簡単に構築して解説していきます。
Route53,＋CloudFront＋S3
まずはプライマリのCDNとするためにCloudflare側の設定を行います。Cloudflareのサイトを追加します。
サイトを追加をクリックし、Zone Apexを入力します。
ビジネスプランを選択します。
年間払いにして絶望を味わったので、支払いプランはお気をつけて、、、
画面右下からPartial Setupモードにします。
モード変更をするとTXTレコードが払い出されるのでメモっときます。
次のステップでRoute53に登録します。
cloudflare-verify.ドメイン に、払い出された値をTXTタイプとして登録し、レコードを作成します。
Cloudflareの画面から下記のエラーが消えていることを確認する。
CDNの設定を行っていく
プライマリとして利用するCloudflareのCDNを登録します。
ここからが難しいのですが、今はNSはRoute53にある状態です。
権威NSに関してはRoute53にあるものの、Cloudflare側にもDNSのコンソールがあります。
Cloudflare側のDNSコンソールはDNSだけではなくCDNのエッジ・オリジンの関係を登録する画面を兼ねています。
ここで、Cloudflare側のDNS兼CDNコンソールに、もともとやりたかったCNAMEレコード（＝オリジン）が登録されている必要があります。
例えば、www.sample.jp ⇒ XXX.cloudfront.net というレコードです。
Cloudflare上ではZone Apexが省略されるので名前が"www"でコンテンツがCloudFrontのディストリビューションが設定されることになります。
これ自体は、もともとRoute53に設定があれば、読み込みのステップでここに入っているはずなので基本的にはそれを探してもらえば大丈夫です。
なければ作成してください。
そのうえで、それが「Proxied」と設定されているかを確認してください。
Route53側をCloudflare CDNに向ける
先ほど作成したプライマリになるCloudflareのCDNにルーティングするようにRoute53の設定を行います。
もともとのドメインのCNAMEは そのドメイン.cdn.cloudflare.net に向けてください。
sample.domainと変えてしまっているが適宜読み替えてください。
イメージとしては、
(Route53)
ターゲットとなるドメイン ⇒ そのドメイン.cdn.cloudflare.net
(Cloudflare)
ターゲットとなるドメイン(実体としてはそのドメイン.cdn.cloudflare.net) ⇒ オリジンサーバーのドメイン名(or IP)
となります。
ここまでで、プライマリのCDNの設定作業は完了！
フェイルオーバーをするための設定を行っていく！！
流れとしては
Route53のヘルスチェックの作成
↓
Route53で対象サービス/サイト用のフェイルオーバールーティングの
プライマリレコードの設定を行う。
↓
セカンダリレコードの設定を行う。
以上！
Route53のヘルスチェックの作成
プライマリが利用できない状態を判断するためのヘルスチェックを作成。
自身の管理している対象サービス等のヘルスチェック用の設定を入力して「次へ」
通知について聞かれるので好きに答える。
今回はわざと失敗させたりして挙動を試したいので通知は切っておく。
プライマリレコードの設定を行う
Route53のホストゾーンに戻って、CloudflareのCDNに向けていたレコードを編集する。
”ルーティングポリシー”を”フェイルオーバー”に設定。
”フェイルオーバーレコードタイプ”を”プライマリ”に
”ヘルスチェックID”は先ほど作成したヘルスチェックを設定し
”レコードID”は好きな値を入れていいらしいのでCloudflare用という意味を込めてrecord-for-Cfとした。（後続のセカンダリと被らなければなんでもいいっぽい）
セカンダリレコードの設定を行う
本当はソーリーページとかを表示したりする用だと思うが、Cloudflareが落ちたときにCloudFrontにフェイルオーバーさせるために設定するので
Cloudflare側で設定したCloudFrontを値に持つレコードをプライマリと同名で登録する。
”レコード名”はプライマリとそろえる。
普通だと一意制約違反で怒られるがセカンダリとして登録する場合は怒られない。
”値”は最初の方の手順でCloudflareに登録したものと同じものを登録。
”ルーティングポリシー”を”フェイルオーバー”に設定。
”フェイルオーバーレコードタイプ”を”セカンダリ”に
”ヘルスチェックID”は設定しなかった。
”レコードID”は好きな値を入れていいらしいのでAWS用という意味を込めてrecord-for-awsとした。
設定完了！！
では動作検証を行っていく。
普通に動くのか？を見ていく。
まぁ動くよね
Cloudflareを見てる
ちゃんとIPレンジの中に入っている。
お楽しみのフェイルオーバーの挙動を見ていく
エラーを起こすのに手っ取り早いのでCloudflareのDNSレコードを消す。
消えた。
ヘルスチェックの方を見てみる。
この記事を書くのに時間がかかって消した状態で放置されてたのでついたり消えたりしているがフェイルオーバーしたときにヘルスチェックが成功していることが分かると思う。
設定してすぐの場合は”ヘルスチェッカー”のタブから確認してもらうのが良いと思います。
一方でサイトには変わらず接続できる
切り替わってるはずなので再度digってみる
CloudFrontを見てる＝セカンダリに切り替わっている！
一応Cloudflare側のDNSからだと動かないことも確認
Cloudflare側からは確認できなかったので
CloudflareのCDNが使えなくなったとしても、CloudFrontに自動で切り替わってサービスが止まらない挙動になるはず！！
何ができるようになったのか
当初の目的通り、通常時はCloudflareの安いCDNを利用し
Cloudflareで障害が起きた場合には自動でCloudFrontに切り替わるアーキテクチャに変更できた。
これによって、安価で追加の管理コストが不要なより可用性の高いアーキテクチャを実現することが可能になりました。
Team DELTAについて
ここまで読んでくださってありがとうございます！
インフラエンジニアに限らず、幅広いメンバーが活躍しているので、一緒に働きたい、どんなことをやっているのか聞いてみたい等、なんでも答えますので、下記の申し込みフォームからご連絡ください！