いつの間にか 1 月が終わってもう 2 月半ばですね、今年もあっという間に終わりそうな気がしています。西です。
昨年は CloudFront Continuous Deployment (CloudFront CD) について何度かご紹介しましたが、2024 年最初の記事も CloudFront CD についてです。 これまでの記事では概要や操作方法を紹介する色が強い記事でしたが、今回の記事では実際のデプロイに寄った点について考えてみます。
実際のデプロイでは必要な API 実行の自動化に加えて「動作確認 / テストを実行するフェイズを組み込みたい」のようなニーズがあるかと思います。 こうした複数のニーズを組み込んで自動化することを考えると、デプロイの流れは一つのワークフローとして捉えることができます。 ワークフローといえば、AWS には ワークフロー制御 / 管理のための サービス AWS Step Functions (Step Functions) が存在しますね。
そこで今回は Step Functions を利用して CloudFront CD のための API 操作を連結させ、一連の流れをワークフローとして自動化する場合の一例をご紹介します。 また、開発者体験の手軽さも考慮して Step Functions の開発や管理には AWS SAM (SAM) を利用する想定でお話しします。
AWS Step Functions & AWS SAM おさらい
Step Functions は各種 AWS サービスを複数連結させ、それぞれの処理を段階的に実行していくワークフローとして制御 / 管理が可能なサービスです。 主には複数の AWS Lambda (Lambda) の処理を組み合わせたフローを構築する際に利用されることが多いのではないでしょうか。 Step Functions では、ワークフローは State (状態) の集合である State machine として表現され、各 State 内で Lambda 関数の実行や条件分岐の判定などが実行されます。
さて、Step Functions の開発や管理をする上で忘れてはならないのが SAM です。 SAM はサーバレスアプリケーションの開発用ツールで、ビルドからデプロイまでが専用コマンドで簡単に実行できます。 SAM には Amazon API Gateway や Amazon DynamoDB といった主なサーバレスサービスと Lambda を組み合わせた雛形用のテンプレートがたくさん用意されています。
用意されているテンプレートの中には Step Functions で複数の Lambda を連携させるための雛形もあり Step Functions を利用した開発でもお手軽に開発を始めることが可能です。 アプリケーションやインフラリソース用のファイルと一緒に、ワークフロー定義のためのファイルも管理 / デプロイすることができて使いやすい構成が実現できるのではないでしょうか。
ワークフローを設計する
今回は CloudFront に対して Lambda から API を適切な順番 / タイミングで実行して CloudFront CD を実現する State machine を考えます。
ポイント
注意が必要なのは Primary や Staging といった CloudFront distribution に変更を加えた際は API で加えられた変更が distribution に対して完全に反映されて distribution の状態が "Deployed" になるまで待機する必要があります。 そのため、ワークフローを設計する際は API を実行する度に状態をチェックして "Deployed" になるまで待つ処理を何度か組み込む必要があるという点です。 この点は CloudFront を API で扱う場合特有の注意点です。
また、ワークフローの中身は基本的に「CloudFront に対して API を実行 → 反映待ち → 次の API を実行」で設計することができます。 一方で Lambda で利用する AWS SDK には Waiter 機能があり API 実行後にその完了を待つことが可能です。 ですので Lambda に Waiter 機能を組み込んでワークフローを組み立てることも可能です。 しかし、この場合は Lambda の実行時間が長くなる原因となってしまうため、その分コストがかかってしまいます。 そのため
- API 実行 → Lambda
- 設定変更の反映まで待機 → Step Functions
に役割を棲み分けるのがコスト面からおすすめです。
出来上がったワークフロー例
以上で挙げた注意点を考慮しつつ、実現のためのワークフローとして起こすと以下のような形となります。
所々でグルグルしていて思わずウッとなりそうな長さですね。 しかし処理だけを見れば比較的シンプルな一本道です、本当なんです。 この長い長いワークフローをいくつかのステップに整理すると以下の図のようになります。
ワークフローは図に示してある通り、大まかに分けると以下の 5 ステップから成り立ちます。
- Staging の作成 & CD Policy の作成と Attach
- Test 実行と結果確認
- Staging の Promote
- CD Policy の Detach & Staging の無効化
- Staging & CD Policy の削除
簡単に補足していきます。 CloudFront CD ではまず、本番として稼働している CloudFront distribution (Primary) に対して動作検証用の distribution (Staging) を作成します。 その後で Primary に Continuous Deployment Policy (CD Policy) という専用のリソースを関連づけることから始まります。このステップを実現するのが 1. です。
その後、動作検証やテストを行って Staging の設定に問題がないことを確認します。このステップを実現するのが 2. です。 ここでは API 呼び出し結果が想定通りかどうかや、リクエストが正常に疎通しているかを確認します。 結果次第でワークフローを "Fail" させて終了させることも出来ます。
Staging の設定に問題がないことを確認できたら Staging の設定をそのまま Primary に反映する Primote 処理を行ってデプロイが完了します。 これは 3. で実現します。
Promote が完了したら CD Policy と Primary の関連付けを外して Staging を無効化します。 CloudFront CD で利用したリソース一式を無効化するステップですね。これが 4. です。
そして最後に 4. で無効化したリソースを後掃除として削除するのが 5. です。 後掃除まで自動化しておけば削除漏れも起こりませんが、例えば「デプロイ後に想定外の挙動となった際の調査用にリソースしばらくを残しておき、その後に削除したい」といった場合は後掃除させるかどうかをフラグで制御できるようにしておくのがいいと思います。
各 API の実行時の詳細は以前の記事で整理していますので、よろしければご活用ください。
おわりに
今回は Amazon CloudFront Continuous Deployment を利用したデプロイを AWS Step Functions のワークフローとして自動化した場合のユースケースをご紹介しました。
ワークフローは一見長くて何度もグルグルしているものになりましたが、これは CloudFront の操作を自動化するために必要なステップになっており、実現するステップはシンプルで一本道になっています。 デプロイの自動化は最初に作り込むのが大変ですが、一度出来上がってしまうとそれ以降の作業がずっと楽になるので CloudFront Continuous Deployment の自動化を検討されている方やこの機能が気になっている方々の一助になれると嬉しいです。
