インプレースデプロイと Blue/Green デプロイ

AWS でのデプロイの自動化

Dunieski Otano

Amazon Web Services Solutions Architect

午前2時の障害

• 一括デプロイが失敗する
• すべてのサーバーが不具合のあるバージョンを実行する
• 顧客が1時間エラーを目にする
• ロールバックにはもう一度フルデプロイが必要

デプロイ戦略が重要な理由

• 不具合のあるリリースはサービスを停止させる可能性がある
• 一括デプロイ = 最速だが最もリスクが高い
• 段階的ロールアウト = 低速だが安全
• デプロイ戦略は失敗時の影響範囲を制御する

インプレースデプロイ

• トラフィックを処理している同じインスタンスにデプロイする
• 一度に1バッチずつ: 半分ずつ、または1台ずつ
• 次に進む前に各バッチをヘルスチェックする
• 低コストで、追加のインフラは不要

Blue/Green デプロイ

• Blue = 現行の本番環境フリート
• Green = 新バージョンを搭載した新規フリート
• ロードバランサーが Blue から Green へトラフィックを切り替える
• 旧フリートは迅速なロールバックのために利用可能な状態を維持する

Lambda と ECS は設計上 Blue/Green デプロイ

• Lambda: エイリアスのバージョンポインターでトラフィックを切り替える
• ECS: 置き換えタスクセットでトラフィックを切り替える
• EC2のようなフリートの複製は不要
• それでもデプロイ設定を選択する必要がある

インプレースと Blue/Green の選択

• 予算が限られ低リスクなパッチの場合 → インプレース
• ダウンタイムなしまたは即時ロールバックが必要な場合 → Blue/Green
• レガシーサーバーが1台のみの場合 → インプレースが唯一の選択肢
• Lambda や ECS の場合 → Blue/Green デプロイが標準装備

CodeDeploy でのロールバック

• ロールバック = 直前に成功したリビジョンを再デプロイすること
• デプロイの失敗で自動的にトリガーされる
• CloudWatch アラームで自動的にトリガーされる
• Blue/Green のロールバック: ロードバランサーを元に戻す

練習しましょう！

AWS でのデプロイの自動化