CloudFrontの継続的デプロイを試してみたはなし

2024年4月4日に行われたクラメソさっぽろIT勉強会 (仮) #1で発表したスライドです。

Transcript

1. CloudFrontの継続的デプロイを 試してみたはなし 2024.04.04 クラメソさっぽろIT勉強会 (仮) #1 Takuya Shibata 公開版
2. 2 自己紹介 Takuya Shibata • AWS事業本部 コンサルティング部 • ソリューションアーキテクト • 2018年12月入社 • Japan AWS All Certifications Engineer (2023) • ex-APN AWS Top Engineer (2020, 2021) • ex-Microsoft MVP (2016 – 2022)
3. 3 はじめに クラメソさっぽろIT勉強会 (仮) はAWS以外の話題も絶賛募集中です！
4. 4 本日のテーマ 「CloudFrontの継続的デプロイ」
5. 5 CloudFrontの継続的デプロイとは？ 2022年11月(re:Inventちょっと前)に登場した新機能 • 2つのCloudFrontディストリビューションを 「Primary (本番)」「Staging (ステージング)」 の形で紐づける • Staging環境へは「重みベース」「ヘッダベース」 でアクセス可能 • 「昇格」するとStagingからPrimaryへ設定を コピーする しばらく2023年の新機能だと誤解していた…
6. 6 CloudFrontの継続的デプロイとは？ 「重みベース」or「ヘッダベース」のアクセス
7. 7 CloudFrontの継続的デプロイとは？ 「昇格」時の挙動
8. 8 特徴・注意点 • Stagingにもドメイン名(cloudfront.net)は付くが 名前解決はできない • 名前解決はPrimaryのみ可能 • 昇格はあくまでも Staring → Primary への設定コピー • Blue/Greenデプロイメントとは異なる • 昇格時のディストリビューションは通常のデプロイ時と同じ 挙動をする • 昇格時にすべての設定をコピーするわけではない • 少なくとも「説明」「代替ドメイン」「ログ設定」はコピー されない
9. 9 特徴・注意点 • キャッシュ管理はPrimary、Stagingそれぞれ別 • キャッシュの共有、といったことは不可 • その他いくつか機能制限がある • HTTP/3は非サポート • 高トラフィック時などの特定ケースにおいてすべての リクエストをPrimaryに流すことがある • note株式会社: noteがEKSへの完全移行までにやったこと https://engineerteam.note.jp/n/nd4ef85f85cc0
10. 10 動作確認のために
11. 11 ポートフォリオサイトを作ってみた https://www.shibata.tech/
12. 12 構成図 https://www.shibata.tech/website-architecture
13. 13 気づき 今日までサイト運営して得た気づきを適当に列挙 1. そもそも使いどころが悩ましい • オリジンの種類(アプリケーション、コンテンツ) によってデプロイの在り方は変わりうる • オリジン側で既に継続的デプロイがある場合どうする？ 2. 切り戻しをどうすべきかも悩ましい • 変更前の設定で再デプロイするしかないのだが… 自動化しようとすると一気にめんどうくさい感じに 3. キャッシュコントロールは自前で頑張る必要あり • Invalidationをどのタイミングで行うかは利用者次第
14. 14 気づき 今日までサイト運営して得た気づきを適当に列挙 4. リクエストヘッダを改変できるソフトが存外少ない • ModHeaderは(行儀の悪い) アドウェアと化してしまった… • おススメの代替ツールがあれば教えてほしい 5. 地球は広い • 最初S3をバージニア北部にしていたが、キャッシュを 使わない場合のレイテンシーが900ミリ秒程度発生 • 東京リージョンにしたら100ミリ秒未満に • ちゃんとレイテンシー計測サイトの値と同程度だった 他にもたくさんあり、実際に試すことは学びが多い。
15. 15 発表後の追記 発表後のワイガヤタイム(質疑応答)での内容から 1. 使いどころに関して、対オリジンではなくCloudFront 自体の機能テストとデプロイ自動化のために使うもの では？ • 確かに！！！ • 「CloudFront(自体の)継続的デプロイ」は凄くしっくりくる • 改めてドキュメントを見ると確かに とある。 With Amazon CloudFront continuous deployment you can safely deploy changes to your CDN configuration by testing first with a subset of production traffic.
16. 16 発表後の追記 発表後のワイガヤタイム(質疑応答)での内容から 2. CloudFront Functionsは昇格対象に含まれる？ • ビヘイビアの「関数の関連付け」が昇格によりコピーされる • 別名の関数(例えばFunction-v2みたいな別名)をStaging環境に関連付け れば安全に動作検証は可能 • 実際に試した事はないが、KeyValueStoresも環境を分ければ Staging環境で動作検証可能なはず ← Primary Distributionに関連付けられ動作中 ← Staging Distributionに関連付けて検証可能 (昇格予定)
17. 17 まとめ？ どんな技術も 実際に試すことは学びが多いヨ！