CloudFront continuous deploymentで、frontendでのカナリアリリースを実現する
参考になった
4
株式会社TOKIUM / 對馬克
チームリーダー / SRE / 従業員規模: 101名〜300名 / エンジニア組織: 51名〜100名
| 利用プラン | 利用機能 | ツールの利用規模 | ツールの利用開始時期 | 事業形態 |
|---|---|---|---|---|
All | continuous deployment、function、アラーム | 10名以下 | 2025年1月 | B to B |
| 利用プラン | All |
|---|---|
| 利用機能 | continuous deployment、function、アラーム |
| ツールの利用規模 | 10名以下 |
| ツールの利用開始時期 | 2025年1月 |
| 事業形態 | B to B |
アーキテクチャ
アーキテクチャの意図・工夫
- TOKIUMでは、監視基盤として主にDatadogを利用しているが、問題の即時検知をするために、CloudWatchアラームを利用することにした。
- デプロイメントポリシーとディストリビューションの作成を同時に行えないため、Terraform上で作成可否を環境変数で制御できるよう設定した。
導入の背景・解決したかった問題
導入背景
ツール導入前の課題
これまでのプロダクトでは、問題があるアプリケーションがデプロイされても、リリースされた後でないと検知できないものもあった。
どのような状態を目指していたか
frontendのリソースに対し、カナリアリリースを導入し、問題発生時は自動で切り戻しが行われることを目指した。
選定理由
frontendのカナリアリリースが実現可能であること
導入の成果
カナリアリリースは実現できたものの、infraデプロイからfrontendのデプロイを分離するために、Terraformの一部コードをignoreの対象にする必要があった。
導入時の苦労・悩み
インフラのデプロイとfrontendアプリのデプロイの分離に苦労した。 弊社ではインフラをTerraformでプロビジョニングしていますが、continuous deploymentで動的に変更される設定が、Terraformのapply時に影響が出ないよう注意を払った。
導入に向けた社内への説明
上長・チームへの説明
backendはECSにデプロイすることが決まっていたため、CloudFront自体の導入はAWS公式ドキュメントのSPAパターンに則って実装することを説明した。 Link
カナリアリリース自体の導入効果については、POに説明し、同意を得た。
活用方法
continuous deploymentを使い、以下の自動リリースを構築
- ステージングdistributionへfrontendの新バージョンをデプロイ。全リクエストのうち10%をステージングdistributionに
- 待機期間を設け、ステージングでエラーが頻発したら、デプロイを中止する
よく使う機能
- continous deployment
- アラーム
ツールの良い点
- CloudFront単体でfrontendのカナリアリリースを実現可能であること
ツールの課題点
- TerraformなどのIacを利用している場合、continuous deploymentによって設定変更される箇所については、両者に影響がでないよう考慮が必要
- 自動リリースを構築する場合、結構な量のシェルスクリプトを書く必要がある
ツールを検討されている方へ
CDNにCloudFrontを利用している場合、continous deploymentは選択肢として検討する価値があると思われる。
とはいえ取り扱いが難しい点もあるので、その他とりうるデプロイ方法とも比較して、選ばれるのがよいと思う。
株式会社TOKIUM / 對馬克
チームリーダー / SRE / 従業員規模: 101名〜300名 / エンジニア組織: 51名〜100名
よく見られているレビュー
株式会社TOKIUM / 對馬克
チームリーダー / SRE / 従業員規模: 101名〜300名 / エンジニア組織: 51名〜100名
レビューしているツール
目次
- アーキテクチャ
- 導入の背景・解決したかった問題
- 活用方法