コンテナ Lambda の CI/CD パイプラインの考え方

~コンテナ利用者に捧げる AWS Lambda の新しい開発方式 ! ~ 第 5 回~

2021-09-02
デベロッパーのためのクラウド活用方法

Author : 下川 賢介

こんにちは、サーバーレス スペシャリストソリューションアーキテクトの下川 (@_kensh) です。

第 1 回 コンテナ Lambda の ”いろは”、AWS CLI でのデプロイに挑戦 !」では、AWS CLI を使ってコンテナ Lambda 関数を実際に AWS Lambda サービスにデプロイして動作確認をしてみました。
第 2 回 コンテナ Lambda を開発、まずは RIC と RIE を使ってみよう !」では、開発者のローカル環境でコンテナ Lambda 関数の動作確認をする方法を紹介しました。
第 3 回コンテナ Lambda をカスタマイズして、自分好みの PHP イメージを作ろう !」では、コンテナイメージサポート Lambda 関数のカスタムイメージ作成方法について紹介しました。
第4回コンテナ Lambda を AWS SAM でデプロイしよう !」では、コンテナ Lambda の Infrastructure as Code の考え方について紹介しました。

今回は AWS SAM で Infrastructure as Code 管理された、コンテナ Lambda アプリケーションの CI/CD パイプラインってどんなものがあるのか、ご紹介したいと思います。

この連載記事のその他の記事はこちら

選択
  • 選択
  • 第 1 回 コンテナ Lambda の”いろは”、AWS CLI でのデプロイに挑戦 !
  • 第 2 回 コンテナ Lambda を開発、まずは RIC と RIE を使ってみよう !
  • 第 3 回 コンテナ Lambda をカスタマイズして、自分好みの PHP イメージを作ろう !
  • 第 4 回 コンテナ Lambda を AWS SAM でデプロイしよう !
  • 第 5 回 コンテナ Lambda の CI/CD パイプラインの考え方
  • 第 6 回 コンテナ Lambda の CI/CD パイプラインを SAM Pipeline で作ろう !
  • 第 7 回 コンテナLambdaでサイドカーパターンは実現可能なの ?

ご注意

本記事で紹介する AWS サービスを起動する際には、料金がかかります。builders.flash メールメンバー特典の、クラウドレシピ向けクレジットコードプレゼントの入手をお勧めします。

builders.flash メールメンバーへの登録・特典の入手はこちら »

*ハンズオン記事およびソースコードにおける免責事項 »


パイプラインが必要になる理由

前回までに Infrastructure as Code (IaC) を利用したサーバーレスの環境構築について説明しましたが、ここではさらに CI/CD としての考え方を進めてみたいと思います。IaC の整備はもちろん必要ですがそれだけでは複数の開発者の共同開発によるコード編集の競合が起きたり、変更に対する回帰テストが疎かになったり、デプロイ / デリバリー手順が属人化したりします。IaC + CI/CD の仕組みを整えることで、サービスのデリバリー速度を加速させることができるようになります。AWS SAM の利用により、IaC 手法が整ったのでさらに DevOps の考え方を進めて行きたいと思います。

継続的に開発者が自分の担当コード変更しターゲットとなるブランチにマージし (チームで開発する場合は Pull Request や Merge Request を利用)、その更新通知を元に自動化されたビルドとテストを実行する DevOps ソフトウェア開発の手法を取り入れて行きましょう。


サーバーレスの CI/CD パイプラインの代表的な構築方法と選択の仕方

サーバーレスでパイプラインを作る方法は多岐に渡ります。例えば AWS CodeStar の プロジェクトテンプレート から多種多様な雛形を選択できますし、AWS Lambda Application によるパイプライン構築Serverless Application Repository を利用してサーバーレスアプリケーションの雛形から独自のサービスを追加開発していくこともできます。

AWS Lambda Application による Zip 形式の Lambda のパイプライン構築については以下のブログを参考にしてください。

※ 2021/8 現在、AWS Lambda Application によるパイプライン構築については コンテナ Lambda に対応していません。

これらに登場するプロジェクトテンプレート以外にもサーバーレスは豊富なアーキテクチャパターンで利用されています。他のパターンを調べたい場合は以下のサイトを参考にしてください。

AWS で環境を構築する場合に AWS CloudFormation が IaC としてよく用いられます。AWS SAM もこの CloudFormation の拡張機能であり、SAM CLI のいくつかのコマンドは AWS CLICloudFormation のコマンド のエイリアスでもあります。パイプラインを構築するときに直接 CloudFormation を利用するのも良いですし、より抽象化されたコマンド群やコンストラクタ群を持つ AWS SAM や AWS CDK を利用して構築するほうが簡単に構築できるということもあるでしょう。

最近 (2021/8/14 執筆時点) では、AWS SAM のパイプライン構築機能として、SAM Pipeline が公開プレビュー が登場しており、また CDK Pipeline が一般提供開始 されました。

それぞれ、ブログに詳細な利用方法が公開されていますので参考にしてください。

また CDK を使った コンテナ Lambda の開発方法については以下のブログにもまとめられています。

このようにパイプラインの構築方法は多岐に渡り、どれが相応しいかは、プロジェクトやチームのケーパビリティや達成したいデリバリーのスタイルによって決定すると良いでしょう。たとえば IaC の中でも動的にリソース参照を解決するためにプログラミング言語で記述したいなら CDK が良さそうですし、YAML のような静的な宣言的構造で記述して、サーバーレスサービスをローカルでテストしたい場合は SAM が良さそうです。

CDK と SAM をハイブリッドで使うこともできます。CDK の Python Lambda モジュールNode.js LambdaモジュールGo Lambda モジュール を利用することでサーバーレス部分は SAM で構築しローカルテストの効率を上げて、それ以外の AWS リソース (例えば VPC や RDS) は CDK で作り組み合わせることもできます。また、プレビューの SAM CLI Beta を使ってCDKとSAMの両者を組み合わせて両方の良いとこ取りをすることもできます。

さて、これまでコンテナ Lambda シリーズでは AWS SAM の利用方法についてご紹介してきたので、この回でも SAM Pipeline によるサーバーレスパイプラインの構築方法について紹介して行くことにします。


パイプラインの全体図を把握する

ここではよくあるサーバーレスの CI/CD の流れを見ていきます。

  1. Developer は IDE やエディタを使用してローカルでコーディングします。
  2. Developer は修正内容を開発用の Git ブランチに push します。(この図ではCodeCommit)
  3. Pull Request / Merge Request を受けたチームメイトが内容を確認し、ターゲットブランチにマージ または プッシュします。
  4. マージまたはプッシュイベントが EventBridge に通知され、そのサブスクライバーである CodePipeline をトリガーします。
  5. パイプラインの最初のステージでは、CodeCommit からソースをダウンロードします。
  6. 次のステージではソースをビルドしてデプロイパッケージを生成します。
    1. この際に自動テストが組み込まれていれば実行されます。
    2. AWS SAM を利用している場合は sam build コマンドが実行されます。
    3. 生成されたイメージは ECR に登録されます。Zip 形式 Lambda の場合は S3 Bucket に格納されます。
  7. 最後のステージでは、CloudFormation によるデプロイが実行され、アプリケーション用の Stack が実際にクラウドにデプロイされます。
img_new-lambda-container-development-5_01

図の中には様々な AWS リソースが登場しますが、このなかで SAM Pipeline による環境構築で作ってくれないリソースは AWS CodeCommit のリポジトリ、ブランチと、アプリケーションの成果物である feature Stack です。 feature Stack は SAM Pipeline で生成されるパイプラインによって自動ビルドされてデプロイされるアプリケーション側のスタックに含まれるため SAM Pipeline 自体のスタック内には含まれません。

パイプラインのスタックと、feature Stack のような実際にパイプラインでビルド・デプロイされるスタックとの関係はこちらのようになります。

img_new-lambda-container-development-5_02

SAM Pipeline や CDK Pipeline を使わずに、ご自身で CloudFormation スタックを構築される場合も、このようにライフサイクルの違うスタックは分けて作るのがセオリーです。

アプリケーションとして実装される AWS Lambda は頻繁にスタック更新が走ることが予想されるのに対して、パイプラインのスタックはステージの追加変更などもあるかもしれませんが、アプリケーション自体よりは更新頻度が下がるでしょう。

スタックを適切にライフサイクルの種類で分けることによりビルド時間を短くしたり、作業チームを分割できたり、作業ミスの影響範囲を小さくしたり、IaC のテンプレートを再利用できたりと便利なことがたくさんあります。パイプラインスタックだけでなく、データベースやネットワーク環境構築用のスタックとアプリケーション用スタックを分けたり、関連性の薄いマイクロサービスのスタックを分けたり、組織のチーム構成によってスタックを分けることもデリバリーサイクルの効率化に貢献します。

スタックを分割した場合に、気になるのがスタック間の参照をどのように解決するかです。たとえば下位スタックで生成したリソースの ARN や名称そして ID を、上位スタックに受け渡したいといったことはよくあります。AWS SAM の場合は デプロイ時に渡せる パラメータのオーバーライド機能 が使えます。下位スタックの出力 から必要なパラメータを抽出して上位スタックの入力パラメータとすることができます。

今回は詳しくは触れませんが、CDK によるスタック分割では コンテキスト としてスタック間のパラメータを受け渡すことができます。また CDK はプログラミング言語で記述され、動的なリソース探索が可能なため、たとえば下位スタックで生成した VPC リソースの VPC ID を上位スタックから発見 して利用することもできます。これにより、互いのスタックを密に関連させることなく探索によって発見して結びつけるようなプログラミング的解決ができるのが CDK の特徴でもあります。

ここからは、SAM Pipeline がコンテナ Lambda に対応していることを確認して、パイプラインをどのように構築していくか一緒に見て行きましょう。

※ もちろん SAM Pipeline によって、ほとんど同じ手順で Zip 形式の Lambda のパイプラインを構築することもできます。
※ SAM Pipeline は現在 (2011/08/14)、公開プレビューとなっています。一般提供開始時には機能の追加や変更が発生することがありますので、ご注意ください。


SAM Pipeline について

AWS SAM Pipelineは、AWS CodePipelineJenkinsGitHub ActionsGitLab などの一般的な CI/CD 用のパイプラインテンプレートを提供します。パイプラインテンプレートには、マルチアカウントおよびマルチリージョンのデプロイに役立つ AWS デプロイメントのベストプラクティスが含まれています。

img_new-lambda-container-development-5_03

クリックすると拡大します

2 つの別々のコマンド sam pipeline bootstrap と、sam pipeline init が用意されているので、運用者と開発者の権限を別々に管理できます。

運用者は、bootstrap コマンドを使用してパイプラインに必要なアーティファクトリソース (ECR リポジトリや S3 Bucket) と CloudFormation の実行ロールをプロビジョニングしてアーティファクトリソースの管理や権限管理を行います。

開発者は sam pipeline init コマンドを実行することにより、bootstrap で作ったステージの構成を利用し、パイプライン用のテンプレートを生成することができます。生成されたテンプレートにターゲットブランチの情報を与えてデプロイすることにより、ブランチへのプッシュでトリガーできるパイプラインを構築することができます。

sam pipeline init --bootstrap を実行して、これら 2 つのコマンドを組み合わせて実行することもできます。

SAM Pipeline 自体の利用方法は、こちらのブログ「Introducing AWS SAM Pipelines: Automatically generate deployment pipelines for serverless applications」にもまとめられていますので、ご参考になさってください。


まとめ

コンテナ Lambda のデプロイに SAM Pipeline を使用して DevOps に必要な CI/CD 環境を構築するイメージが掴めたでしょうか。 SAM Pipeline はマルチアカウントやマルチリージョンでも適用でき、マルチステージで様々なユースケースに対応できますので幅広くご利用いただけると思います。また、AWS以外の様々な CI/CD システムと組み合わせてご利用いただけるので、開発プロジェクトに応じた CI/CD システムを選択ください。

プロジェクトやチームの慣れた CI/CD 環境を AWS SAM Pipeline で素早く構築して、サーバーレスアプリケーションのデリバリーやイテレーションを加速させてみてください!

次回はさらに、コンテナサポート Lambda 関数のパイプラインの作り方を追っていきたいと思います。

この連載記事のその他の記事はこちら

選択
  • 選択
  • 第 1 回 コンテナ Lambda の”いろは”、AWS CLI でのデプロイに挑戦 !
  • 第 2 回 コンテナ Lambda を開発、まずは RIC と RIE を使ってみよう !
  • 第 3 回 コンテナ Lambda をカスタマイズして、自分好みの PHP イメージを作ろう !
  • 第 4 回 コンテナ Lambda を AWS SAM でデプロイしよう !
  • 第 5 回 コンテナ Lambda の CI/CD パイプラインの考え方
  • 第 6 回 コンテナ Lambda の CI/CD パイプラインを SAM Pipeline で作ろう !
  • 第 7 回 コンテナLambdaでサイドカーパターンは実現可能なの ?

builders.flash メールメンバーへ登録することで
AWS のベストプラクティスを毎月無料でお試しいただけます

筆者プロフィール

photo_shimokawa-kensuke

下川 賢介 (@_kensh)
アマゾン ウェブ サービス ジャパン合同会社
シニア サーバーレススペシャリスト ソリューションアーキテクト

Serverless Specialist Solutions Architect として AWS Japan に勤務。
Serverless の大好きな特徴は、ビジネスロジックに集中できるところ。
ビジネスオーナーにとってインフラの管理やサービスの冗長化などは、ビジネスのタイプに関わらず必ず必要になってくる事柄です。
でもどのサービス、どのビジネスにでも必要ということは、逆にビジネスの色はそこには乗って来ないということ。
フルマネージドなサービスを使って関数までそぎ落とされたロジックレベルの管理だけでオリジナルのサービスを構築できるという Serverless の特徴は技術者だけでなく、ビジネスに多大な影響を与えています。
このような Serverless の嬉しい特徴をデベロッパーやビジネスオーナーと一緒に体験し、面白いビジネスの実現を支えるために日々活動しています。

AWS のベストプラクティスを毎月無料でお試しいただけます

さらに最新記事・デベロッパー向けイベントを検索

下記の項目で絞り込む
絞り込みを解除 ≫
1

AWS を無料でお試しいただけます

AWS 無料利用枠の詳細はこちら ≫
5 ステップでアカウント作成できます
無料サインアップ ≫
ご不明な点がおありですか?
日本担当チームへ相談する