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

Slide 1

Slide 1 text

CloudFrontの継続的デプロイを試してみたはなし 2024.04.04 クラメソさっぽろIT勉強会 (仮) #1 Takuya Shibata 公開版

Slide 2

Slide 2 text

2 自己紹介 Takuya Shibata • AWS事業本部コンサルティング部 • ソリューションアーキテクト • 2018年12月入社 • Japan AWS All Certifications Engineer (2023) • ex-APN AWS Top Engineer (2020, 2021) • ex-Microsoft MVP (2016 – 2022)

Slide 3

Slide 3 text

3 はじめにクラメソさっぽろIT勉強会 (仮) はAWS以外の話題も絶賛募集中です！

Slide 4

Slide 4 text

4 本日のテーマ「CloudFrontの継続的デプロイ」

Slide 5

Slide 5 text

5 CloudFrontの継続的デプロイとは？ 2022年11月(re:Inventちょっと前)に登場した新機能 • 2つのCloudFrontディストリビューションを「Primary (本番)」「Staging (ステージング)」の形で紐づける • Staging環境へは「重みベース」「ヘッダベース」でアクセス可能 • 「昇格」するとStagingからPrimaryへ設定をコピーするしばらく2023年の新機能だと誤解していた…

Slide 6

Slide 6 text

6 CloudFrontの継続的デプロイとは？「重みベース」or「ヘッダベース」のアクセス

Slide 7

Slide 7 text

7 CloudFrontの継続的デプロイとは？「昇格」時の挙動

Slide 8

Slide 8 text

8 特徴・注意点 • Stagingにもドメイン名(cloudfront.net)は付くが名前解決はできない • 名前解決はPrimaryのみ可能 • 昇格はあくまでも Staring → Primary への設定コピー • Blue/Greenデプロイメントとは異なる • 昇格時のディストリビューションは通常のデプロイ時と同じ挙動をする • 昇格時にすべての設定をコピーするわけではない • 少なくとも「説明」「代替ドメイン」「ログ設定」はコピーされない

Slide 9

Slide 9 text

9 特徴・注意点 • キャッシュ管理はPrimary、Stagingそれぞれ別 • キャッシュの共有、といったことは不可 • その他いくつか機能制限がある • HTTP/3は非サポート • 高トラフィック時などの特定ケースにおいてすべてのリクエストをPrimaryに流すことがある • note株式会社: noteがEKSへの完全移行までにやったこと https://engineerteam.note.jp/n/nd4ef85f85cc0

Slide 10

Slide 10 text

10 動作確認のために

Slide 11

Slide 11 text

11 ポートフォリオサイトを作ってみた https://www.shibata.tech/

Slide 12

Slide 12 text

12 構成図 https://www.shibata.tech/website-architecture

Slide 13

Slide 13 text

13 気づき今日までサイト運営して得た気づきを適当に列挙 1. そもそも使いどころが悩ましい • オリジンの種類(アプリケーション、コンテンツ) によってデプロイの在り方は変わりうる • オリジン側で既に継続的デプロイがある場合どうする？ 2. 切り戻しをどうすべきかも悩ましい • 変更前の設定で再デプロイするしかないのだが… 自動化しようとすると一気にめんどうくさい感じに 3. キャッシュコントロールは自前で頑張る必要あり • Invalidationをどのタイミングで行うかは利用者次第

Slide 14

Slide 14 text

14 気づき今日までサイト運営して得た気づきを適当に列挙 4. リクエストヘッダを改変できるソフトが存外少ない • ModHeaderは(行儀の悪い) アドウェアと化してしまった… • おススメの代替ツールがあれば教えてほしい 5. 地球は広い • 最初S3をバージニア北部にしていたが、キャッシュを使わない場合のレイテンシーが900ミリ秒程度発生 • 東京リージョンにしたら100ミリ秒未満に • ちゃんとレイテンシー計測サイトの値と同程度だった他にもたくさんあり、実際に試すことは学びが多い。

Slide 15

Slide 15 text

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.

Slide 16

Slide 16 text

16 発表後の追記発表後のワイガヤタイム(質疑応答)での内容から 2. CloudFront Functionsは昇格対象に含まれる？ • ビヘイビアの「関数の関連付け」が昇格によりコピーされる • 別名の関数(例えばFunction-v2みたいな別名)をStaging環境に関連付ければ安全に動作検証は可能 • 実際に試した事はないが、KeyValueStoresも環境を分ければ Staging環境で動作検証可能なはず ← Primary Distributionに関連付けられ動作中 ← Staging Distributionに関連付けて検証可能 (昇格予定)