司会者、調理担当、配膳担当。AWSのCI/CDを例えで理解した

おはようございます、YASUです。

Lambda、API Gatewayと見てきましたが、DVAではもう一つ、CI/CD(継続的インテグレーション・継続的デリバリー)の仕組みも重要な範囲です。以前GitHub Actionsの仕組みを紹介しましたが、今日はAWS版のCI/CDサービス、CodePipeline・CodeBuild・CodeDeployの役割分担を整理します。

結論

この3つは、料理の配膳に例えると分かりやすいです。CodePipelineが「全体の進行を仕切る司会者」、CodeBuildが「料理を作る調理担当」、CodeDeployが「できた料理を席まで運ぶ配膳担当」という役割分担になっていました。それぞれ単独では完結せず、組み合わさって初めて1つの自動化フローが成立します。

そもそも、なぜ手作業のデプロイは問題なのか

複数の記事で共通して指摘されていたのが、手作業デプロイの3つの問題でした。

以前Gitのコミット・pushを手動で何度も繰り返してきましたが、「人がやる以上、いつかは手順を間違える」というのは、実務でも避けられないリスクです。CI/CDパイプラインは、まさにこの問題を自動化によって解消するための仕組みでした。

CodePipeline:全体を仕切る司会者

CodePipelineは、「ソース→ビルド→デプロイ」という一連の流れ全体を管理する、いわばオーケストラの指揮者のような存在です。GitHubにコードがpushされたことを検知すると、自動的にパイプラインを開始し、各ステージ(段階)を順番に実行していきます。

[Git Push]
    ↓
[CodePipeline] ← 全体の進行を管理
    ├─ Sourceステージ:GitHubからコードを取得
    ├─ Buildステージ:CodeBuildに依頼
    └─ Deployステージ:CodeDeployに依頼

CodePipeline自身はビルドやデプロイの作業そのものは行わず、「次は誰の番か」を管理する司会進行役に徹しています。

CodeBuild:コードを調理する担当

CodeBuildは、ソースコードをテストして、実際に動く形に変換(ビルド)する役割を担います。何をどう調理するかは、buildspec.ymlというレシピ(設定ファイル)に書いておきます。

# buildspec.ymlのイメージ
version: 0.2
phases:
  build:
    commands:
      - npm test
      - npm run build

以前紹介したGitHub Actionsの.github/workflowsにあたる部分が、CodeBuildではbuildspec.ymlという形になっている、と考えると理解しやすいと思います。テストが失敗すれば、ここでパイプライン全体が止まり、次のデプロイには進みません。

CodeDeploy:できあがった料理を届ける配膳担当

CodeBuildが作り上げた「出来上がったアプリケーション」を、実際にEC2やECSなどの環境へ届けて配置する役割がCodeDeployです。配置の仕方はappspec.ymlという、こちらも設定ファイルで指定します。

特徴的なのが「Blue/Greenデプロイ」という手法です。これは、今動いている環境(Blue)とは別に、新しいバージョンの環境(Green)をまるごと新しく用意しておき、準備ができたら通信の向き先をBlueからGreenへ一気に切り替える、という方式です。

[今まで]  Blue環境(旧バージョン) ← ユーザーのアクセスはここ
[新環境]  Green環境(新バージョン) ← 裏で準備中

切り替え完了後
[新環境]  Green環境(新バージョン) ← ユーザーのアクセスはここに切り替わる
[今まで]  Blue環境(旧バージョン) ← そのまま残しておけば、何かあってもすぐ戻せる

この方式なら、切り替えの瞬間もユーザーは一瞬で新環境に誘導されるだけなので、ダウンタイムがほぼ発生しません。しかも旧環境(Blue)をすぐには消さずに残しておけるので、万が一新環境に問題があれば、通信の向き先を元に戻すだけで即座にロールバックできる、という安心感もあります。

3つを繋げて、全体の流れをもう一度見てみる

1. 開発者がGitHubにコードをpushする
2. CodePipelineがそれを検知し、パイプラインを開始する
3. CodeBuildが呼ばれ、buildspec.ymlに従ってテスト・ビルドを行う
4. ビルドが成功したら、CodeDeployが呼ばれる
5. CodeDeployがappspec.ymlに従って、Blue/Greenデプロイなどの方式で配置する
6. 全ステージが完了し、新しいバージョンが本番環境で稼働する

以前紹介したGitHub Actionsの記事では「考えるのは自分、形にするのはAI(あるいは仕組み)」という話をしましたが、CI/CDパイプラインもまさに同じ発想です。「何をビルドし、どう配置するか」というレシピだけ用意しておけば、あとは全部自動で進んでいく、という設計思想が共通しています。

試験で問われそうなポイント

調べていて、各サービスの「責任範囲の境界線」を問う問題が多そうだと感じました。例えば「テストが失敗した場合、どのステージで止まるか」「IAMロールは、どのサービスにどんな権限を与えるべきか」といった形です。CodePipeline用のロールにはS3への読み書きやCodeBuild・CodeDeployの呼び出し権限、CodeBuild用のロールにはECRへのプッシュ権限、というように、サービスごとに必要な権限が分かれている、という点も意識しておきたいところです。

まとめ

以前のGitHub Actionsの理解があったおかげで、AWS版のCI/CDも「役割分担」という観点でスムーズに整理できました。それでは、また明日!