11 月になりました。 すっかり肌寒くなり、いよいよ年の瀬も少しずつ近づいて来ましたね。 西です。
さて、皆さんの中には Amazon CloudFront (CloudFront) を使われている方は多いのではないかと思います。 CloudFront はとても便利なサービスですが、デプロイ時間はその性質上長くなりがちなのがネックです。 「いざ新しい Version をデプロイして動作確認してみると NG → 切り戻し」というツラいことになった方は少なくないと思います。 すると事前の動作確認を踏まえたデプロイが課題になってきますが、デプロイフローはシンプルに思えても切り替えなどがある都合上、複雑になりがちです。
この問題に対して CloudFront には Continuous Deployment というデプロイ機能が実装されています。 CloudFront への変更を本番環境へデプロイすることなく安全にテストが可能となり、その設定をそのまま本番環境の設定に昇格させることもできます。 切り替えが難しいデプロイフローをシンプルかつ手軽に実現できる素晴らしい機能です。
そこで今日は Continuous Deployment の要素やライフサイクルを絵を交えつつご紹介できればと思います。
Amazon CloudFront おさらい
言わずと知れた CloudFront ですが、例によって軽くおさらいです。
Amazon CloudFront は、ユーザーへの静的および動的なウェブコンテンツ (.html、.css、.js、イメージファイルなど) の配信を高速化するウェブサービスです。CloudFront では、エッジロケーションというデータセンターの世界的ネットワークを経由してコンテンツを配信します。CloudFront でサービスを提供しているコンテンツをユーザーがリクエストすると、リクエストはエッジロケーションにルーティングされ、レイテンシー (遅延時間) が最小になります。これにより、コンテンツは可能な限り最高のパフォーマンスで配信されます
ということで、AWS マネージドな CDN (Contents Delivery Network) サービスが CloudFront です。 ウェブコンテンツのキャッシングだけでなくエッジコンピューティングである Lambda@Edge や CloudFront Functions の利用、オリジンとなる他サービスと AWS WAF の組み合わせのために活用されるケースもあります。
CDN としてだけでなく、幅広く柔軟に活用可能なサービスです。
Continuous Deployment とは?
では、本稿のタイトルにもあります Continuous Deployment とはなんでしょうか。 公式ドキュメントでは以下のように説明されています。
Amazon CloudFront の継続的デプロイを使用すると、最初に本番トラフィックのサブセットでテストすることで、CDN 設定に変更を安全にデプロイできます。ステージングディストリビューションと継続的デプロイポリシーを使用して、実際 (本番環境) のビューワーからのトラフィックを新しい CDN 設定に送信し、正常に動作することを検証できます。新しい設定のパフォーマンスをリアルタイムでモニタリングし、準備ができたら、新しい設定を昇格させてすべてのトラフィックをプライマリディストリビューションで処理できます。
ということで、いわゆる継続的デプロイメントを CloudFront で実現できる機能です。 Continuous Deployment を使い、変更を安全に動作確認した上で OK 時だけ本番環境にデプロイする、というフローが可能になります。 この機能を使えば CloudFront で A / B テストや BG デプロイライクなデプロイが実現できますのでとても便利ですね。
Continuous Deployment がなかったら?
ここからはこの機能は具体的にどう便利なのかをお伝えできればと思います。 そのためにまず Continuous Deployment がない世界をイメージしていきましょう。
CloudFront の新しい設定をデプロイする際のことを考えます。 CloudFront の Distribution A がユーザーに向けて公開されていますね。
ここに新しい内容を設定した Distribution B を設定していきます。
デプロイする際はこの Distribtion B の設定が想定通りか確認したり検証、テストを実施することになります。
そして問題ないことが確認できた時に DNS レコードの向け先を変更します。
というフローを踏むことになりますがここで気になる点がいくつか存在します。
Continuous Deployment を利用しない場合、最後には自分たちで DNS 名の切り替え作業を行う必要があります。 手動運用の場合であれば言うまでもなくオペミスの格好の温床になる箇所かと思います。 IaC や CLI を利用しての自動化の場合、切り替え作業の部分は作り込みが大変になりやすい箇所です。 切り替わりの確認も必要になり、実装コストの高い複雑な処理での実現となります。
また、Amazon S3 をはじめとする 他 AWS サービスをオリジンとしている場合、Distribution ID や ARN でアクセスを制御しているケースもあるかと思います。 著名なのは S3 バケットポリシーを利用した OAC ですね。 こういった場合、Distribution が他のものに変わるに併せて修正が必要になってきます。 幸いこれらは DNS 操作前の動作確認で気づきやすい箇所ではありますが、オリジンの場所が多いほどチェック対象が増えてしまうため、これも地味に厄介な点かと思います。
Continuous Deployment はどう便利なの?
ではこれを踏まえて Continuous Deployment がある世界について考えます。
Continuous Deployment ではまず、本番環境の Distribution (Primary) が稼働している状況で、新たな Distribution config (以降、設定) を 検証用の Distribution (Staging) にデプロイします。
その後、Continuous deployment policy と呼ばれるポリシーを使って、Staging に対してリクエスト振り分けを行い、動作確認や検証が可能になる機能です。 Continuous Deployment では Staging へリクエストをルーティングするポリシーを以下の 2 種類のポリシーから選択することができます。
- Header-based: 特定のヘッダーが付与されたリクエストを Staging へルーティングするポリシー
- Weighted-based: 設定した一定の割合のリクエストを Staging へルーティングするポリシー
加重ルーティング的に確認やテストを行いたい場合は Weighted-based を、アプリケーション等のデプロイには Header-based を利用するのがありそうなユースケースでしょうか。
ちなみに Header-based のポリシーを利用する場合、ヘッダーのプレフィックスに aws-cf-cd- という文字列を含む必要があります。
地味ながら注意が必要なポイントです。
さらに、検証後は Staging に適用していた設定をそのまま Primary に Promote (昇格) させることも可能です。
ここで嬉しいポイントは、たとえ Promote させても本番稼働している Distribution は変わらず Primary Distribution である点です。 あくまでも Promote で実行されるのは Staging Distribution の設定をシームレスに Primary Distribution に反映しているだけであり、オリジンをはじめ Route53 や AWS WAF のようなその他 AWS サービスが関連付いているのは Primary Distribution のままです。
つまり先ほど挙げた DNS レコードの設定をせずとも、ましてや Distribution ID や ARN に関わる記載を修正する必要もありません。 この点はとても便利で、開発者がデプロイする上でケアせねばならない点を大幅に減らしてくれる素晴らしいポイントではないでしょうか。
おわりに
今回は CloudFront のデプロイ機能である Continuous Deployment 機能について、絵を添えてご紹介しました。 CloudFront はとても便利なサービスだと思います。 しかし便利な一方で、動作の確認や検証に時間がかかりがちになるデプロイフローをどうするかは悩みの種になりがちではないでしょうか。 本稿ではその問題に対する一つの解決策として利用可能な Continuous Deployment をご紹介しました。
本稿は紹介編と銘打っている通り、次の記事では実際にこの機能を使っていく上での Tips や詳細についてもご紹介できればと思います。 この機能もなかなか事例や情報が少ない機能かと思いますので、皆さんの技術選定や CloudFront のデプロイフロー設計の一助になれると嬉しいです。
