ある企業は、Amazon CloudFront ディストリビューションでウェブサイトを配信しています。同社は、キャッシュの設定の変更をすべての利用者に反映する前に、本番のリクエストの一部だけを新しい設定で処理して、動作を確かめる必要があります。 この要件を満たすために、CloudOps エンジニアは何をすべきですか。
CloudFront の設定の変更を、本番のリクエストの一部で先に試してから反映する
CloudFront の継続的デプロイで、新しい設定のステージングディストリビューションと継続的デプロイポリシーを作成する。確認後に設定をプライマリへ昇格する。
CloudFront の継続的デプロイでは、新しい設定をステージングディストリビューションに置き、継続的デプロイポリシーで本番のリクエストの一部をそこへ送ります。CDN の設定の変更を、本番のリクエストの一部で試せます。
昇格すると、ステージングの設定がプライマリディストリビューションへコピーされ、すべてのリクエストが新しい設定で処理されます。動作を確かめてから、すべての利用者に反映できます。
AWS AppConfig で設定プロファイルを作成し、新しい設定を時間をかけて段階的に反映するデプロイ戦略を指定してデプロイする。
AppConfig は、アプリケーションが読み込む機能フラグや設定データを管理し、デプロイ戦略で時間をかけて段階的に反映するサービスです。デプロイした設定データは、アプリケーションが AppConfig から取得して使います。
しかし AppConfig のデプロイは CloudFront ディストリビューションの設定を変更しません。キャッシュの設定の変更を、本番のリクエストの一部で試すことはできません。
ディストリビューションのキャッシュの設定を変更し、CloudFront の無効化を作成して、エッジロケーションのキャッシュからすべてのファイルを削除する。
無効化は、ファイルが期限切れになる前にエッジロケーションのキャッシュから削除する操作です。次のリクエストでは、CloudFront がオリジンから最新のファイルを取得します。
しかしディストリビューションの設定を直接変更すると、すべてのリクエストが新しい設定で処理されます。無効化はキャッシュを消すだけで、一部のリクエストだけを新しい設定で処理する仕組みではありません。
Amazon CloudWatch Synthetics で canary を作成し、ウェブサイトの URL へ定期的にリクエストを送って、応答とレイテンシーを確認する。
CloudWatch Synthetics の canary は、スケジュールに沿って実行するスクリプトで、利用者と同じ操作をまねてエンドポイントを監視します。利用者のトラフィックがないときでも、可用性やレイテンシーを確かめられます。
しかし canary が送るのは合成のリクエストで、本番のリクエストを新しい設定へ振り分ける機能はありません。新しい設定を本番の一部のリクエストで試すことはできません。
設定の変更を本番に反映する前に試す問題では、何の設定を変えるかと、本番のリクエストを使うかでサービスを見分けます。
・CloudFront の継続的デプロイ — 新しい設定のステージングディストリビューションへ、継続的デプロイポリシーで本番のリクエストの一部を送ります。確認が済んだら昇格し、ステージングの設定をプライマリへコピーします。
・AWS AppConfig — アプリケーションが読む機能フラグや設定データを、デプロイ戦略で段階的に反映します。
・CloudFront の無効化 — エッジロケーションのキャッシュからファイルを削除します。設定の反映の範囲は変わりません。
・CloudWatch Synthetics の canary — スケジュールに沿って合成のリクエストを送り、エンドポイントを監視します。