猫でもわかるAPI Gateway Canaryデプロイ

ALBは何台必要？

0.方式によって異なる

DevOpsの勉強をしていた時にふともやもやしたので図にしてみました。
API Gateway Canary デプロイ時にはALBを1台にするか2台にするを考える必要があることの個人的な備忘録です。ちょっとややこしいと思ったのは私だけかもですが。
記事を読む前に「最後に」をご確認ください

1. 基本構成比較

項目	Method 1 (ALBx1台)	Method 2 (ALBx2台)
ALB数	1台	2台
EC2構成	同一インスタンス群	分離されたインスタンス群
環境分離	論理分離（アプリレベル）	物理分離（インフラレベル）
アプリケーション変更	必須	不要

2. 開発・運用面の比較

項目	Method 1	Method 2
アプリケーション変更	必須	不要
ヘッダー処理実装	必要	不要
テスト複雑性	高い（両パス）	低い（単一パス）

3. 技術的実装の違い

Method 1(Header Logic)

@app.route('/api/users')
def get_users():
    # HTTPヘッダーからステージ変数を取得
    env = request.headers.get('X-Stage-Variables-env', 'prod')

    if env == 'canary':
        return get_users_with_new_algorithm()  # 新ロジック
    else:
        return get_users_standard()            # 既存ロジック

5. リスク・安全性比較

Method 1のリスク

• コード品質依存: ヘッダー処理のバグリスク
• 共有インフラ: 一方の問題が他方に影響
• メモリリーク: 両バージョンが同一プロセス

Method 2の安全性

• 完全な環境分離: 影響範囲の限定
• 独立した監視: 個別のメトリクス・ログ
• 即座のロールバック: 設定変更のみで切り戻し

6. 適用シナリオ別推奨

Method 1が適している場合

• API仕様変更: エンドポイントの追加・変更
• 軽微な機能変更: 既存ロジックの小さな修正
• コスト制約: 追加インフラコストを避けたい場合
• 短期テスト: 数時間〜数日の短期検証

Method 2が適している場合

• アプリケーション全体更新: 大幅なロジック変更
• インフラ変更: OS、ミドルウェア、依存関係の更新
• リスク最小化: 完全な環境分離が必要
• 長期検証: 数週間〜数ヶ月の長期検証

7. 意思決定フレームワーク

選択基準マトリクス

基準	重要度	Method 1	Method 2	推奨
アプリ変更最小化	高	❌	✅	Method 2
コスト効率	高	✅	❌	Method 1
リスク最小化	高	❌	✅	Method 2
実装速度	中	❌	✅	Method 2

結論と推奨事項

一般的な推奨：Method 2 (Dual ALB)を推奨

理由:

1. アプリケーション変更が不要
2. 完全な環境分離による安全性
3. 実装・運用の複雑性が低い
4. 長期的な保守性が高い

例外的にMethod 1を選択する場合

• 極度のコスト制約がある
• 開発チームの技術力が高い
• 短期間の限定的な検証
• 既存システムの制約でMethod 2が不可能

最後に

この記事の大部分はQ Developer CLIに質問して、AWSドキュメントのMCPサーバを使って調べてもらいました。構成図もQ CLIくんが描いてくれました。ちょっと的外れなな回答もしますが丁寧に人間が指摘すればちゃんと答えてくれるのがうれしいです。