に投稿に更新AWS / DevOps13分で読む (約1967語)

Lambda CI/CD アーキテクチャ - 1. CI/CD環境構築における方針

ドキュメント構成

免責事項

本記事はAI(Claude)を活用して執筆しています。内容の正確性については保証いたしかねますので、重要な情報は必ず一次情報源をご確認ください。

この章で理解すること

なぜこの設計なのか？ の答えがここにあります。

  • デプロイとリリースの分離
  • TerraformとLambrollの使い分けの本質
  • エイリアス戦略が全ての鍵
  • 設計の3つの原則

デプロイとリリースの分離

従来の課題

多くのLambda環境では、デプロイ = リリース となっています。

1
2
3
コード変更 → デプロイ → 即座に本番反映
                      ↑
                   危険！

問題点:

  • 本番環境でいきなりコードが実行される
  • 問題発見時のロールバックに時間がかかる
  • テスト環境と本番環境の切り替えが曖昧

解決策: エイリアスによる分離

1
2
3
4
5
6
7
8
9
10
デプロイ: Lambda関数にコードをアップロード
    ↓
   （バージョン16が作成される）
    ↓
stagingエイリアス → v16 に自動更新
productionエイリアス → v15 のまま（手動まで待機）
    ↓
   （QA・検証）
    ↓
手動承認 → productionエイリアス → v16 に更新

メリット:

  • デプロイしても本番に影響なし
  • staging環境で十分に検証
  • リリースは承認後に即座に実行（エイリアス切替のみ）
  • ロールバックも瞬時（エイリアスを戻すだけ）

TerraformとLambrollの使い分け

なぜ2つのツールを使うのか？

核心: 変更頻度とライフサイクルの違い

特性 Terraform Lambroll
変更頻度 低い（月1回以下） 高い（日5回以上）
管理対象 インフラ全般 Lambda関数のみ
実行時間 長い（10-30分） 短い（1-3分）
影響範囲 広い（全体） 狭い（特定関数）

Terraform: インフラの真実の源泉

責任範囲:

  • VPC、Subnet、Security Group
  • IAM Role、Policy
  • RDS、DynamoDB（共有）
  • S3 Bucket
  • EventBridge、SQS/SNS（共有）
  • Lambda Layer（ARNのみ）

なぜTerraformで管理？

  1. 変更が稀 → 慎重な変更管理が必要
  2. 複数サービスで共有 → 一元管理
  3. セキュリティ重要 → インフラチームが管理

Lambroll: Lambda関数に特化

責任範囲:

  • Lambda関数のコード
  • 関数設定（function.jsonl）
  • エイリアス管理

なぜLambrollを選んだのか？

SAMではなくLambrollを採用した理由：

  1. インフラリソースを管理しない

    • SAM: IAM、VPC等も管理 → Terraformと重複
    • Lambroll: Lambda関数のみ → 責任が明確

  2. Terraform stateを直接参照

    • SAM: SSM Parameter Store経由で連携
    • Lambroll: terraform outputを環境変数で参照 → シンプル

  3. 軽量で高速

    • SAM: CloudFormation経由（遅い）
    • Lambroll: AWS API直接（速い）

例: function.jsonl

1
2
3
4
5
6
7
8
9
10
11
12
13
14
{
  "FunctionName": "user-auth-function",
  "Runtime": "python3.11",
  "Role": "{{ must_env `TF_ROLE_ARN` }}",
  "VpcConfig": {
    "SubnetIds": {{ env `TF_SUBNET_IDS` | json_array }},
    "SecurityGroupIds": {{ env `TF_SG_IDS` | json_array }}
  },
  "Environment": {
    "Variables": {
      "DB_ENDPOINT": "{{ must_env `TF_RDS_ENDPOINT` }}"
    }
  }
}

Terraform outputsを環境変数として直接参照できます。

エイリアス戦略の核心

エイリアスとは

Lambda関数の特定バージョンへの名前付きポインタです。

1
2
3
4
5
6
7
8
9
10
11
Lambda関数: user-auth-function
├── $LATEST（常に最新コード）
├── Version 1
├── Version 2
...
├── Version 15（現在の本番）
├── Version 16（新バージョン）
└── Aliases（ポインタ）
    ├── development → $LATEST
    ├── staging → Version 16
    └── production → Version 15

3環境の戦略

Development環境

1
development エイリアス → $LATEST
  • 常に最新コードを参照
  • 開発者の動作確認用
  • 不安定でも問題なし

Staging環境

1
staging エイリアス → 最新Version（自動更新）
  • mainブランチにmerge → 自動デプロイ → Version発行 → staging更新
  • QA・統合テスト用
  • 本番リリース前の最終確認

Production環境

1
production エイリアス → 承認されたVersion（手動更新）
  • staging検証完了 → 手動承認 → production更新
  • エンドユーザー向け
  • 最も慎重に管理

なぜこの戦略なのか？

開発速度 × 本番安全性 の両立

  • Development: 制約なし → 開発速度最大化
  • Staging: 自動化 → 検証サイクル高速化
  • Production: 手動承認 → リスク最小化

設計の3原則

原則1: 単一責任の原則

各ツールは1つの責任のみを持つ

1
2
3
4
5
6
7
8
9
10
11
Terraform:
  ✓ インフラ管理
  ✗ Lambda関数のコード

Lambroll:
  ✓ Lambda関数
  ✗ インフラリソース

GitHub Actions:
  ✓ CI/CDパイプライン
  ✗ リソース管理

メリット:

  • 変更の影響範囲が明確
  • トラブルシューティングが容易
  • チーム間の責任分界点が明確

原則2: 疎結合の原則

コンポーネント間は間接的に連携

1
2
3
4
5
Terraform outputs
    ↓
環境変数
    ↓
Lambroll

メリット:

  • Terraformの変更がLambrollに影響しない
  • 独立してデプロイ可能
  • テストが容易

原則3: 不変性の原則

Lambda Versionは不変

1
2
3
Version 15 → 一度作成したら変更不可
             ↓
          削除のみ可能

メリット:

  • ロールバックが確実
  • 監査証跡が残る
  • エイリアスの切替のみでリリース・ロールバック

まとめ

この設計の核心

エイリアスによる環境分離 + ツールの責任分離

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
┌─────────────────────────────────┐
│ Terraform（インフラ）            │
│  - VPC, IAM, RDS, S3...         │
│  - 変更が稀                      │
│  - インフラチームが管理           │
└─────────────────────────────────┘
              ↓ outputs
┌─────────────────────────────────┐
│ Lambroll（Lambda関数）           │
│  - コード、設定                  │
│  - 頻繁に変更                    │
│  - アプリチームが管理             │
└─────────────────────────────────┘
              ↓ deploy
┌─────────────────────────────────┐
│ Lambda Versions + Aliases       │
│  - development → $LATEST        │
│  - staging → v16（自動）         │
│  - production → v15（手動）      │
└─────────────────────────────────┘

実現すること

  1. 高速デプロイ: 2分以内
  2. 安全リリース: 手動承認
  3. 瞬時ロールバック: 5秒以内
  4. 明確な責任: チーム間の分業
  5. 段階的展開: カナリアリリース

次のステップ

方針を理解したら、具体的な構成要素を見ていきましょう。

次へ: 2. 構成要素と役割

#

タグ

AWS Lambda5
Bedrock1
CI/CD5
Cloudflare1
DNS1
Email1
GitHub Actions3
Lambroll5
Linux1
Node.js1
Python2
Route531
Slack1
Terraform5
Zed1
bash1
mise1
sshd1
uv1
zsh1
アーキテクチャ4
インフラ2
エイリアス1
実装1
運用1

カテゴリ

最近の記事

アーカイブ

×