この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
昨日のアップデートですが、CloudFront の機能だけで、オリジンのフェイルオーバが実装できるようになりました。
従来は Route 53 の DNS フェイルオーバー を利用して実装されていたかと思います。CloudFront 側でフェイルオーバのコントロールが出来るようになったことで、より管理がシンプルになりそうですね！また、サイト単位でのフェイルオーバではなく、動作としてはオブジェクト単位でのフェイルオーバになります。
では、さっそく試していきましょう！
試してみた
今回はオリジンアクセスアイデンティティ（OAI）を使った S3 オリジンを、東京とオレゴンに作成しました。S3 バケット間はクロスリージョンレプリケーションしておくことで、仮に東京リージョンの S3 に障害があっても、オレゴンリージョンでコンテンツ公開が継続できるように可用性を高めた構成です。
もちろん CloudFront ですので、キャッシュが残っている場合は、まず、キャッシュからレスポンスを返します。キャッシュミスが発生し、かつ、プライマリオリジンがフェイルオーバー用に設定されたエラーステータスを返した場合、セカンダリオリジンにルーティングされます。
設定
事前に S3 バケットは東京、オレゴンに作成し、それぞれの index.html にはフェイルオーバーが判るように Tokyo! と Oregon! が表示されるようにしました。また、S3 オリジン（東京） のみを指定した CloudFront ディストリビューションは作成済みの状態です。
作成済みのディストリビューション設定から Origin and Origin Groups タブを開き、Create Origin をクリックします。
セカンダリ用のオリジンを追加しますが、以下の点に注意してください。
- OAI を使用する場合、両方の S3 バケットで同じ OAI を設定する
- カスタムオリジンと OAI を使用した S3 オリジンを同じオリジングループに登録することは出来ません
今回は OAI を使用しているので、必ずプライマリオリジンと同じ OAI を指定します。
次に Create Origin Group をクリックします。Origins のプルダウンメニューから、プライマリおよびセカンダリオリジンを追加します。今回は東京リージョンをプライマリとして指定しています。Failver criteria で、どのエラーステータスをプライマリオリジンが返したときにフェイルオーバするかを指定します。今回はすべて選択して create します。
次に、Behaviors タブを開き、各 Behavior のオリジン設定を変更します。Origin or Origin Group のプルダウンメニューに、さきほど作成したオリジングループ ID が追加されていますので選択して更新します。ディストリビューションのステータスが In Progress から Deployed に変わりましたら完了です。
動作確認
まず、通常時のアクセスです。
では、東京リージョンの S3 から、index.html を削除し、リロードします。（今回は検証で即時確認するために、CloudFront の TTL は 0 にしています）
フェイルオーバされたことが確認できました！
Lambda@Edge があるとき
今回は検証していませんが、公式のガイドを参照すると、キャッシュミスによってオリジンリクエストで Lambda@Edge が発火し、レスポンスがエラーステータスであった場合、セカンダリオリジンに対して、もう一度、Lambda@Edge を発火してくれるようです。
さいごに
これまで Route 53 の DNS フェイルオーバの利用が必要でしたが、CloudFront によるフェイルオーバのほうがオブジェクト単位であったり、OAI の S3 オリジンに対してもフェイルオーバー設定できるので、より柔軟なアーキテクチャに出来そうですね！
まだ Re:Invent 前だというのに、続々とアップデートが流れてくるので追っかけるのが大変ですが、出来るかぎりキャッチアップして、最適なアーキテクチャにしていきましょう！
以上！大阪オフィスの丸毛（@marumo1981）でした！
4
