この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
はじめに
清水です。AWSのCDNサービスであるAmazon CloudFrontにContinuous Deployment（継続的デプロイ）機能がやってきました！本日（日本時間2022/11/19、現地時間2022/11/18）AWS Blogsにポストされたアップデートについてお届けします！！
これまでのCloudFront Distributionの設定変更
本番環境のCloudFront Distributionの設定変更、他のリソースの設定変更よりも神経を使う作業だったかと思います。Distributionの設定変更を行う場合は変更完了までに数分の反映待ち時間が発生します。新たな設定を投入したDistributionを用意してDNSレベルで切り替えを行うという方法も検討できそうですが、CloudFrontでCNAMEが重複できないという制限があるため、ALBなど他リソースに比べると気軽に行えない方法でした。
それでもCNAME重複の制限については、従来はAWSサポートとの連携が必須だったものが、一定の条件下であればユーザ自身で変更が完了するようになるなどのアップデートがなされてきました。（昨年2021年のアップデートですね。）
なおこのDNSレベルでのDistributionの切り替えが難しい点、CloudFrontがいわゆるName-based Virtual Hostのような挙動をしていると考えると（個人的には）しっくりきます。
CloudFrontで継続的デプロイをサポート
今回のアップデート、CloudFrontのContinuous Deployment（継続的デプロイ）では、Distributionの設定変更がより安全に行えるようになります。
既存の（変更前の）設定を持つDistribution（これを新たにPrimary Distributionと呼びます）に対して、Staging Distributionというリソースを作成できます。このStaging DistributionにはPrimary Distributionの設定をベースに、Distributionで変更を行う箇所の設定をしていきます。
このStaging Distributionは作成後、任意のタイミングからリクエストを振り分けることができます。リクエストの振り分け方法はカスタムヘッダをベースにするもの、またリクエスト総数の一定の割合を振り分けるもの（Weightベース）の2通りが選択できます。このStagingフェーズで実際のリクエストを振り分けながら、新しい設定のDistributionの動作確認を行えます。
Weightベースの例ですが、冒頭に示したAWS Blogs記載の図を引用します。www.example.comへのアクセスの（この例では）10%のトラフィックがStaging Distributionに振り分けられる、というぐあいですね。
Use CloudFront continuous deployment to safely validate CDN changes | Networking & Content Delivery
設定変更したDistributionの動作確認ができたら、このStaging Distributionを昇格（Promote）します。このPromote操作により、Staging Distributionの設定内容がPrimary Distributionにコピーされ、安全に（動作確認したDistribution設定内容で）Distributionの設定変更ができる、というわけです。
なおAmazon CloudFront Developer Guideには使用方法のほか、細かな制約などもまとまっています。実際に使用する前に確認しておきましょう。
CloudFront Continuous Deploymentを使ってみた
アップデートのポイントが確認できたところで、実際にこのCloudFront Continuous Deployment機能を使ってみたいと思います。
動作検証のシナリオとオリジンサーバ準備
動作検証のシナリオとして、オリジンサーバ（Apache HTTP ServerとPHPが動作するEC2インスタンス）で以下の2つのパスを準備しました。
- http://origin.example.com/version1/
- テキスト
ver.1を返す
- テキスト
- http://origin.example.com/version2/
- テキスト
ver.2を返す
- テキスト
CloudFrontでは、まず変更前のDistributionのOrigin path設定で/version1を指定しておきます。CloudFrontに設定した独自ドメイン（のインデックスルートドキュメント）にアクセスするとテキストver.1が返る状態ですね。
- 変更前のDistribution設定
- https://www.example.com/
- テキスト
ver.1を返す
- テキスト
- https://www.example.com/
続いてDistributionの設定変更で、Origin pathを/version2にします。これで変更後は独自ドメイン（のインデックスルートドキュメント）にアクセスするとver.2が返る状態となります。
- 変更後のDistribution設定
- https://www.example.com/
- テキスト
ver.2を返す
- テキスト
- https://www.example.com/
この設定変更の際にContinuous Deploymentを使ってみる、という動作検証シナリオとなります。
初期状態のDistributionの作成
まずは通常の手順どおりCloudFront Distributionを作成していきます。Apache HTTP ServerとPHPが動作するEC2インスタンスをオリジンに指定し、Origin pathでは/version1を指定しました。
その他のOriginの設定はデフォルトのまま進めます。Default cache behaviorではCache設定としてCachingDisabledのCache policyを使用しました。動作検証ということもあり、Cacheは無効にしている状態です。
Settingsの項目で、独自ドメインAlternate domain name (CNAME)の設定をしておきます。また独自ドメインに対応したACM証明書も設定します。
Security Policyもデフォルトのままです。なおHTTP/3はDeveloper Guide記載の通りContinuous Deploymentに現在のところ非対応となりますので注意しましょう。（デフォルトで無効ではありますが。）Descriptionだけ記入して[Create distribution]します。
Distributionが作成できました。
Route 53でA ALIASレコードを設定して、独自ドメインでCloudFrontにアクセスできるようにします。
独自ドメイン（のインデックスルートドキュメント）にアクセスしてみましょう。ver.1のテキストが返ってきますね。
% curl https://cloudfront-continuous-deployment.example.net/
ver.1Continuous DeploymentによるStaging Distributionの作成
変更前のDistributionが作成できました。ここからContinuous Deploymentを使ってDistributionを更新していきましょう。先ほどのDistributionの詳細画面ですが、Settingsの項目からさらに下にスクロールすると、新たにContinuous deploymentの項目が追加されています！
[Create staging distribution]ボタンで進みましょう！まずはStaging Distributionの動作説明がありますので確認しつつ、New staging distributionのDescriptionに「version2」の記載だけしておきます。
Configure settingsの画面に遷移します。Distributionの設定（Settingsの項目）については、変更できる項目に制限があるようです。例えばSSL証明書の設定については変更できないようでした。（詳細はDeveloper Guideを参照ください。）
Originsの項目で該当Originを選択し、[Edit]ボタンで進みます。Edit origin画面でOrigin pathを/version1から/version2に変更しました。
画面はStep 1に戻りましたが、再度Step 2のConfigure settingsに進みます。
変更したOrigin path部分が反映されていますね。
Origin groupsやBehaviorsなども変更可能なようです。
またAdditional settingsの項目を展開すると、以下のようにError pages、Geographic restrictions、Tagsが現れました。
Step 3ではTraffic configurationです。TypeとしてはWeight-basedとHeader-basedの2種が選択できます。今回はWeight-basedで進めました。Weightは10 %を指定します。session stickinessも指定できるようですね。その下のEnabledはDistributionのStatusとしての有効/無効を指定する箇所のようです。（Staging Distribution作成後、いきなりリクエストを振り分けたくないならEnalbedをoffにしておけばよさそうです。）
最後はStep 4 Review and createです。内容を確認して[Create staging distribution]ボタンでStaging Distributionを作成します。
Staging Distributionが作成できました。
初期状態のDistribution詳細画面を再度確認してみると、Continuous deploymentの項目にStaging distribution IDが記載されていますね。また冒頭にこのDistributionがPrimary Distributionであることが明記されています。
このStaging distribution IDの部分をクリックしてみましょう。Staging distributionの詳細画面に遷移します。ここでは冒頭にこのDistributionがStaging Distributionであることが明記されています。また独自ドメイン設定のAlternate domain namesの項目は空欄ですね。その他、Distribution IDが異なることと同様にDistribution domain name自体もPrimary Distributionと異なっています。
OriginsタブからOriginの設定項目を確認してみましょう。Origin Pathは先ほど変更したとおり、/version2となっています。
Continuous DeploymentでStaging Distributionの動作確認
Staging Distributionが作成できました。この状態で動作確認が行えるわけですね。リクエストの10%をStaging Distributionを振り分ける設定にしているので、10回リクエストしてみましょう。
$ for i in {1..10}; do curl https://cloudfront-continuous-deployment.example.net/; done
ver.1
ver.1
ver.1
ver.1
ver.1
ver.1
ver.2
ver.1
ver.1
ver.110回のリクエストのうち1回だけ、ver.2のテキストが返ってきました。ちょうど10%の割合でStagingのDistributionにリクエストが割り振られていることが確認できますね。（なお上記検証はN. VirginiaリージョンのCloudShell上で確認しています。）
このStaging Distributionの動作ですが、「特定のIPアドレス（CloudFrontドメインの名前解決結果）がStaging Distributionの動作をする」というわけではなく、実際にIPアドレス内で一定の割合をStaging Distributionの動作にしているようです。以下のように名前解決結果のIPに直接リクエストを行って確認してみました。（この動作確認、digコマンドのためにClouｄShell上でsudo yum install bind-utilsしています。）
$ dig cloudfront-continuous-deployment.example.net +short
18.165.83.65
18.165.83.10
18.165.83.42
18.165.83.45
$ for i in {1..10}; do curl --resolve cloudfront-continuous-deployment.example.net:443:18.165.83.65 https://cloudfront-continuous-deployment.example.net/; done
ver.1
ver.1
ver.1
ver.2
ver.1
ver.1
ver.1
ver.1
ver.1
ver.1その他、興味深い点としては、Primary Distributionのdomain nameのみ名前解決可能で、Staging distributionのdomain nameは名前解決不可である、といったところでしょうか。
% curl http://d2daxxxxxxxxxx.cloudfront.net/
ver.1
% curl http://d3h5xxxxxxxxxx.cloudfront.net/
curl: (6) Could not resolve host: d3h51qs4ai2391.cloudfront.netContinuous DeploymentでStaging Distributionを昇格
Staging Distributionで動作の確認ができたら、いよいよこのDistributionを本番環境用に昇格（Promote）します。PrimaryもしくはStagingのDistributionのGeneralタブ、Continuous deploymentの項目に[Promote]ボタンがあるので、これを使用します。
今回はStaging Distributionの画面から[Promote]ボタンを押下してみました。Promote configurationsの画面が現れます。操作がもとに戻せないことなどの注意点を確認して、confirmをタイプして[Promote]ボタンを押下します。
いざ昇格！
画面上部に「Successfully updated distribution E2HSXXXXXXXXXX settings」のメッセージが表示されました。
Primary Distribution側のStatusを確認してみると、Deployingになっています。
Primary Distributionの設定を確認してみましょう。Staging Distributionに設定していたOrigin pathの設定がPrimary Distributionにも設定されていました。Distributionを入れ替えているというよりか、StagingのDistribution設定をPrimaryにコピーしている、という挙動になるかと思います。
Primary DistributionでStatusがDeployingからEnabledに変わったあと、実際に設定が変わっているか確認してみます。
$ for i in {1..10}; do curl https://cloudfront-continuous-deployment.example.net/; done
ver.2
ver.2
ver.2
ver.2
ver.2
ver.2
ver.2
ver.2
ver.2
ver.2Staging Distributionに設定した変更がPrimary Distribution側にも反映されていますね！
まとめ
Amazon CloudFrontの新機能、Continuous Deploymentについて速報としてお届けしました。変更後の設定となるStaging Distributionを作成、一定量のリクエストを割り振って動作確認が行なえます。動作確認後はStaging Distributionを昇格させることで、その設定内容がPrimary Distributionに反映されます。これまで少なからず気を使う必要があったCloudFrontのDistribution設定変更作業、今回のアップデートでとても安全に、そして簡単に行えるようになったのではないでしょうか。じっくりとStaging環境のDistribution動作が問題ないことを確認して本番Distributionに反映するというステップを踏み、安全・安心なDistributionの更新を行いましょう。
15
