Lambda CI/CD アーキテクチャ - 4. トレードオフと運用上の考慮点

ドキュメント構成

• 1. CI/CD環境構築における方針
• 2. 構成要素と役割
• 3. 実装ガイドライン
• → 4. トレードオフと運用上の考慮点

免責事項

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

この章で理解すること

このアーキテクチャの現実的な評価と、採用判断に必要な情報を提供します。

• メリット・デメリット
• 適用すべき規模と環境
• よくある失敗パターン
• 段階的な導入戦略
• FAQ

メリット・デメリット

メリット

1. デプロイ速度の劇的な向上

実測値（50関数の環境）:

• デプロイ時間: 15分 → 2分（87%削減）
• デプロイ頻度: 週2回 → 日5回（17倍）

理由:

• Terraformの実行が不要（インフラ変更時のみ）
• Lambrollは関数のみデプロイ（高速）
• 並列デプロイ可能

2. 本番障害リスクの最小化

エイリアス戦略による保護:

• staging環境で十分な検証
• 手動承認により意図しないリリースを防止
• カナリアリリース（10% → 100%）で影響範囲を制御

実績:

• 本番障害: 月1回 → 四半期1回
• ロールバック時間: 10分 → 5秒（120倍高速化）

3. チーム間の責任分離

明確な境界:

• インフラチーム → Terraform（インフラ全般）
• アプリチーム → Lambroll（Lambda関数）

効果:

• コンフリクト削減
• レビュー速度向上
• オンボーディング容易化

4. ロールバックの確実性

バージョン不変性:

• 過去の全バージョンが保持される
• エイリアス切替のみで瞬時にロールバック
• 監査証跡が残る

デメリット

1. 初期構築コスト

学習コスト:

• Lambrollの習得（ただしドキュメントは簡潔）
• Terraform outputsの連携方法
• エイリアス管理の理解

構築時間:

• 初回構築: 約2-3週間
• 既存環境からの移行: 約1-2ヶ月

2. リポジトリ管理の複雑化

2リポジトリ運用:

• terraform-infrastructure
• lambda-applications

課題:

• リポジトリ間の連携（GitHub Actions）
• outputsの同期
• ドキュメントの分散

対策:

• monorepo化の検討（規模次第）
• 明確なドキュメント整備

3. バージョン管理の手間

Lambda Versionの増加:

• デプロイごとにVersion作成
• コードストレージ上限（75GB/リージョン）に到達リスク

対策:

• 週次で古いVersionを自動削除
• エイリアス保護により安全に削除

4. Lambrollの限定的なエコシステム

SAMとの比較:

• SAM: AWS公式、豊富なドキュメント、大規模コミュニティ
• Lambroll: サードパーティ、限定的なドキュメント

懸念:

• 長期的なメンテナンス
• 新機能への対応速度
• トラブル時の情報不足

現実的な評価:

• 機能はシンプルで安定
• AWS APIを直接利用（依存度は低い）
• 必要ならSAMへの移行も可能

適用すべき規模と環境

このアーキテクチャが最適

環境特性:

• Lambda関数: 20個以上
• デプロイ頻度: 週5回以上
• チーム規模: 3人以上
• 本番環境: ダウンタイム許容不可
• インフラとアプリの分業: 必要

ユースケース:

• マイクロサービスアーキテクチャ
• イベント駆動アーキテクチャ
• サーバーレスAPI（API Gateway + Lambda）
• 大規模なバッチ処理

オーバーエンジニアリング

環境特性:

• Lambda関数: 10個未満
• デプロイ頻度: 月1-2回
• チーム規模: 1-2人
• PoC・検証環境

推奨:

• Terraformのみで十分
• CI/CDも最小限（terraform apply）

境界線上（慎重に判断）

Lambda関数: 10-20個

判断基準:

• デプロイ頻度が高い → このアーキテクチャ
• チーム分業が必要 → このアーキテクチャ
• 単純な構成 → Terraformのみ

よくある失敗パターン

失敗例1: エイリアス管理の不徹底

問題:

1
2
3
4

# 悪い例: AutoPublishAlias（SAM時代の名残）
AutoPublishAlias: live

# 結果: デプロイ = リリース（本番に即反映）

対策:

1
2
3

# 良い例: エイリアスは手動管理
# staging: GitHub Actionsで自動更新
# production: 手動承認後に更新

学び:

• エイリアスの自動更新は staging のみ
• production は必ず手動承認

失敗例2: Terraform outputsの参照忘れ

問題:

1
2
3
4
5
6

// 悪い例: ハードコード
{
  "Role": "arn:aws:iam::123456789012:role/lambda-role"
}

// 結果: Terraform変更が反映されない

対策:

1
2
3
4

// 良い例: 環境変数で参照
{
  "Role": "{{ must_env `TF_ROLE_ARN` }}"
}

学び:

• すべてのインフラ情報はTerraform outputs経由
• ハードコードは絶対にしない

失敗例3: バージョン削除の失敗

問題:

1
2
3
4
5

# 悪い例: エイリアス保護なし
for version in all_versions:
    delete_version(version)

# 結果: productionエイリアスが参照するVersionを削除

対策:

1
2
3
4
5

# 良い例: エイリアス保護
protected_versions = get_alias_versions()
for version in all_versions:
    if version not in protected_versions:
        delete_version(version)

学び:

• エイリアスが参照するVersionは削除禁止
• 削除スクリプトは慎重にテスト

失敗例4: Layer管理の分散

問題:

1
2
3
4
5
6

# 悪い例: LambrollでLayer管理
lambda-applications/layers/

# 結果: 
- Terraform outputsとの整合性が取れない
- 複数関数で共有しづらい

対策:

1
2
3
4

# 良い例: TerraformでLayer管理
terraform-infrastructure/layers/

# Lambrollは参照のみ

学び:

• Layerは変更頻度が低い → Terraform
• ARNをoutputsで提供 → Lambrollが参照

段階的な導入戦略

Phase 1: 小規模で検証（1-2週間）

対象:

• Lambda関数: 1-2個
• 重要度の低い機能

目標:

• Terraform + Lambrollの連携確認
• エイリアス戦略の検証
• CI/CDパイプライン構築

成功基準:

• staging自動デプロイが動作
• production手動リリースが動作
• ロールバックが5秒以内

Phase 2: 段階的拡大（1-2ヶ月）

対象:

• Lambda関数: 5-10個
• 複数チームで利用

目標:

• チーム間の責任分離を確立
• ドキュメント整備
• トラブルシューティング手順の確立

成功基準:

• 複数チームが独立してデプロイ可能
• 障害時のロールバックが確実

Phase 3: 全面展開（2-3ヶ月）

対象:

• 全Lambda関数
• 全チーム

目標:

• 標準CI/CDパイプラインとして確立
• 運用自動化（バージョン削除等）
• メトリクス収集と改善

よくある質問（FAQ）

Q1: SAMではなくLambrollを選んだ理由は？

A: 責任分離の明確化とシンプルさ

Lambrollは「Lambda関数のみ」に特化しており、Terraformとの責任分離が明確です。

Q2: Lambda Layerは誰が管理すべき？

A: Terraformで管理（推奨）

理由:

• 変更頻度が低い（月1回以下）
• 複数の関数で共有される
• ARNをoutputsで提供すればLambrollから参照可能

例外:

• 特定関数専用のLayer → Lambrollでも可
• ただし、Terraformで統一する方がシンプル

Q3: バージョンはどれくらい保持すべき？

A: 最新10個 + 90日以内 + エイリアス参照中

保持ルール:

1. エイリアス（development、staging、production）が参照中 → 必ず保持
2. 最新10個 → 保持（ロールバック用）
3. 90日以内に作成 → 保持（監査用）
4. 上記以外 → 削除

コードストレージ上限対策:

• 50関数 × 10バージョン = 500バージョン
• 1関数あたり50MB → 25GB（上限75GBの1/3）

Q4: カナリアリリースは必須？

A: 規模と重要度による

必須ケース:

• ユーザー影響が大きい（決済、認証等）
• トラフィックが多い（1000 req/sec以上）
• 過去に本番障害経験あり

不要ケース:

• 社内ツール
• バッチ処理（定期実行）
• トラフィックが少ない

推奨:

• 重要な関数のみカナリア
• 10% → 10分監視 → 100%

Q5: Terraformの実行頻度は？

A: 必要な時のみ（週1回以下）

実行タイミング:

• インフラ変更時（VPC、RDS追加等）
• IAMポリシー変更時
• Layer更新時
• 新規Lambda関数の初回作成時（関数名だけTerraformで予約）

Lambrollの実行頻度:

• 日5-10回（mainへのpush）

Q6: 既存環境から移行するには？

A: 段階的移行（2-3ヶ月）

ステップ:

1. Week 1-2: Terraform化（インフラのみ）
2. Week 3-4: 1-2関数をLambroll化（検証）
3. Week 5-8: 段階的に全関数を移行
4. Week 9-12: CI/CD整備、ドキュメント化

注意点:

• 一度に全移行しない
• 重要度の低い関数から開始
• ロールバック手順を必ず準備

Q7: Lambrollがメンテされなくなったら？

A: AWS APIを直接利用しているため影響は限定的

現実的な対応:

1. 短期: forkして自社でメンテ（コードは非常にシンプル）
2. 中期: AWS CLI + シェルスクリプトで代替
3. 長期: SAMやTerraformに移行

Lambrollの依存度は低い:

• 単なるAWS API のラッパー
• function.jsonl → API呼び出しの変換のみ

Q8: コストは増えますか？

A: GitHub Actions実行時間が増えるが、わずか

コスト増:

• GitHub Actions実行時間: 月500分 → 800分（+60%）
• 金額: 約$0（無料枠内）

コスト減:

• デプロイ失敗による手戻り削減
• 障害対応時間の削減
• 人件費削減（自動化）

結論: 実質的なコスト増はほぼゼロ

Q9: Lambda以外のサーバーレスリソースは？

A: 基本的にTerraformで管理

例:

• API Gateway: Terraform（複雑な設定、複数Lambda連携）
• Step Functions: Terraform（ワークフロー定義）
• EventBridge: ケースバイケース
  • 共有Rule → Terraform
  • 特定関数専用 → Lambroll（または Terraform）
• DynamoDB: Terraform（データストア）

原則: 共有リソース → Terraform

Q10: チーム構成のベストプラクティスは？

A: インフラ1-2名、アプリ3-5名

役割分担:

コミュニケーション:

• 週1回: outputsの確認
• Terraform変更時: アプリチームに事前通知
• Slack連携: デプロイ通知

まとめ

このアーキテクチャの本質

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

1

速度（Lambroll） × 安全性（エイリアス） = 最適なCI/CD

採用判断のチェックリスト

• Lambda関数が20個以上ある
• 週5回以上デプロイする
• チームが3人以上いる
• インフラとアプリの分業が必要
• 本番障害リスクを最小化したい
• ロールバックを高速化したい

3つ以上当てはまる → 採用を検討

次のアクション

1. 小規模で検証: 1-2関数で試す
2. チームで議論: メリット・デメリットを共有
3. 段階的導入: Phase 1から開始

さらに学ぶ

公式ドキュメント

• Terraform Lambda Provider
• Lambroll GitHub
• AWS Lambda Versions and Aliases

参考記事

• 1. CI/CD環境構築における方針（原理原則）
• 2. 構成要素と役割（全体像）
• 3. 実装ガイドライン（実装手順）

シリーズ完

お疲れ様でした！このアーキテクチャが、あなたのチームのLambda運用を改善する一助となれば幸いです。

質問やフィードバックは、ブログコメントまたはTwitter（@yourhandle）までお願いします。

目次に戻る