CHAPTER 06 / D3
テストとデプロイ
SAM・CI/CD・コンテナ・段階リリースを理解する。
01 / CI/CDは工程の責任で読む
コードを更新するだけでは本番に届きません。テスト、成果物の作成、環境への配置、トラフィック切り替え、異常検知時の切り戻しをつなぎます。DVAでは、既存のパイプラインを利用し、設定や失敗を理解する観点を重視します。
| サービス・ファイル | 担当 |
|---|---|
| CodePipeline | ソース、ビルド、承認、デプロイなどのステージを連携 |
| CodeBuild / buildspec.yml | コマンドの実行、テスト、成果物の出力 |
| CodeDeploy / AppSpec | リビジョンの配置、トラフィック移行、フック |
| S3 / ECR | ビルド済みファイル / コンテナイメージの保管 |
| CloudFormation / SAM / CDK | インフラやサーバーレスリソースをコードで定義 |
02 / CloudFormation・SAM・CDK
CloudFormationはテンプレートを使ってスタックを作成・更新します。パラメーターで環境差分、Outputsで作成したリソース情報を表します。変更セットは実行前に変更内容を確認するための機能です。ロールバックや削除時の保持方針も確認します。
SAMは、LambdaやAPIなどの定義を短く記述するためのCloudFormation拡張です。CDKはプログラミング言語でインフラを表現し、CloudFormationテンプレートへ合成します。いずれも実行時のIAM権限やアプリのバグを自動で解消するものではありません。
AWSTemplateFormatVersion: "2010-09-09"
Transform: AWS::Serverless-2016-10-31
Resources:
HelloFunction:
Type: AWS::Serverless::Function
Properties:
Runtime: python3.13
Handler: app.handler
CodeUri: src/
MemorySize: 256
Timeout: 10
AutoPublishAlias: live
DeploymentPreference:
Type: Canary10Percent5Minutesこの例はsrc/app.pyにhandlerがある構成を想定しています。AutoPublishAliasは公開バージョンとエイリアスの管理に使い、DeploymentPreferenceで段階移行を指定します。実運用では監視アラームや事前・事後検証も組み合わせます。
| コマンド | 役割 |
|---|---|
| sam validate | テンプレートを検証 |
| sam build | コードと依存関係をビルド |
| sam local invoke | コンテナを使ってローカルでイベントを渡す |
| sam deploy | CloudFormationを通じてAWSへデプロイ |
公式資料：SAM Function リソース
03 / テストの範囲を区別する
| 種類 | 検証すること | 例 |
|---|---|---|
| 単体テスト | 関数や業務ロジックの振る舞い | 不正な注文数量でエラーを返す。外部依存はモック |
| 統合テスト | サービス間の接続・権限・データ形式 | API → Lambda → DynamoDBで保存・取得できる |
| 契約・スキーマのテスト | 入出力の合意 | イベントの必須属性、APIレスポンス形式 |
| 負荷・性能テスト | 目標負荷でのレイテンシと容量 | p95、スロットリング、下流の接続数 |
| デプロイ後検証 | 配置した環境が正常か | ヘルスチェック、スモークテスト、主要な業務操作 |
モックは速く安定したテストに便利ですが、本物のIAM、VPC経路、クォータまでは検証しません。sam local invokeが通っても、本番の統合がすべて正しい証明にはなりません。正常系に加え、重複イベント、期限切れトークン、部分失敗、タイムアウトもテストします。
version: 0.2
phases:
install:
commands:
- pip install -r requirements-dev.txt
build:
commands:
- python -m pytest tests --junitxml=report.xml
reports:
unit-tests:
files:
- report.xml
file-format: JUNITXMLこの例はrequirements-dev.txtにpytest等が定義され、tests/が存在する構成です。実際のパイプラインでは成果物のパッケージングや保存先の権限も設定します。テスト失敗は、通常は後続の本番配置へ進めないようにします。
04 / リリース方式を要件で選ぶ
| 方式 | どう切り替えるか | 性質 |
|---|---|---|
| All at once | 一斉に新版へ | 速いが影響範囲が大きい。基盤によって停止を伴う |
| Rolling | 対象をバッチに分けて順番に更新 | 旧版・新版が混在。更新中の処理容量に注意 |
| Blue/Green | 旧環境と新環境を用意して切り替える | 切り戻ししやすい。環境を二つ維持するコスト |
| Canary | 少量を新版へ送り、観測後に残りを移す | 問題の影響を限定しやすい。観測期間と判断基準が必要 |
| Linear | 一定割合ずつ段階的に移す | 少しずつ進める。Canaryの一回の少量検証とは区別 |
Lambdaならバージョンとエイリアスを使い、CodeDeployで加重トラフィックやアラームを組み合わせます。たとえば「10%を5分観測して残りを切り替える」がCanaryの例です。CodeDeployがコードのテストを勝手に完成させるわけではないので、フックやテストの実装も必要です。
Elastic Beanstalkでは、Rolling、Rolling with additional batch、Immutable、Traffic splittingなどを見分けます。Immutableは新しいインスタンス群を用意して検証する方式で、Rolling中の部分更新と区別します。
公式資料：CodeDeploy のデプロイ設定
05 / コンテナと環境別設定
ECRはコンテナイメージのレジストリ、ECSとEKSはコンテナを管理する基盤です。Fargateはサーバーを直接管理せずにコンテナを動かす実行基盤の選択肢です。
| 概念 | 押さえること |
|---|---|
| ECSタスク定義 | イメージ、CPU・メモリ、環境変数、ポート、ロール等を定義 |
| タスクロール | コンテナ内のアプリがAWS APIへアクセスする権限 |
| タスク実行ロール | ECRからの取得やログ送信など、ECS側が起動を支援する権限 |
| イメージのタグ / digest | 動く成果物を追跡。タグの再利用は設定次第なので、固定タグやdigestで再現性を考える |
| Readiness / Liveness | トラフィックを受けてよいか / プロセスが生きているかを別に確認 |
devとprodは、アカウント・スタック・設定・参照する秘密などで分離します。API Gatewayのステージとステージ変数、Lambdaエイリアス、AppConfigなどを使うと、コードと環境差分を分けて扱えます。
CloudFormationの動的参照で秘密を参照しても、秘密のローテーションだけで既存リソースの設定が必ず更新されるとは限りません。アプリが実行時に取得する構成とは更新のタイミングが異なります。
リリース練習：障害の影響を小さくする
Lambdaの新版を全員へ出す前に、5分間だけ一部のトラフィックでエラー率を見たい。何を組み合わせる？
考え方・解答例
公開バージョン＋エイリアスを使い、CodeDeploy/SAMのCanary設定で一部を新版へ送ります。CloudWatchアラームと検証フックを設定し、失敗時の切り戻し条件を決めます。
06 / 確認問題
07 / この章の到達点
上のチェックは、このページでの振り返り用です。章単位の進捗は下のボタンで記録できます。
公式資料
内容確認日：2026年11月8日。仕様の詳細や更新情報は、各公式資料で確認できます。
理解を確認できたら、章の進捗を記録できます。