[セッションレポート] DVO401 AWSでのブルー・グリーン・デプロイメントに関するディープダイブ #reinvent

ウィスキー、シガー、パイプをこよなく愛する大栗です。 re:Invent 2015のセッションをレポートします。

レポート

このセッションへの期待

• 一般的なデプロイのリスクの概要
• Blue/Greeデプロイの概念
• AWSでのBlue/Greenの利点
• AWS上でのアプリデプロイでののBlue／Greenパターン
• データ層のベストプラクティス
• コスト最適化

デプロイは簡単ではない

• 伝統的な環境では適切なアップグレードを好む
• リソースの制約
• ダウンタイム
• 依存性
• プロセスの協調
• 難しいロールバック

一般的なデプロイのリスク

課題

• アプリケーションの失敗
• インフラノ失敗
• 容量の問題
• スケーリングの問題
• 人の失敗
• プロセスの失敗
• ロールバックの問題

ビジネスインパクト

• ダウンタイム
• データ損失
• 悪いカスタマ・エクスペリエンス
• 収入源
• 気難しいマネージャー
• 燃え尽きたスタッフ
• 無駄にした時間/資源

AWS上のBlue/Greenデプロイの定義

Blue/Green Deploymentとは？

• Blue：既存の商用環境
• Green：アプリケーションの異なるバージョンを動作させる並列環境 ->例えば、アプリケーションコンポーネント、アプリ層、マイクロサービス
• デプロイ：二つの環境を切り替える機能 ->例えば、DNS、ロードバランサ

AWSでの環境のスコープ

狭い ↑　AMI、Auto Scaling Group ｜　Amazon EC2 Container Service ｜　AWS Elastic Beanstalk ｜　AWS OpsWorks ↓　AWS CloudFormation 広い

環境境界の定義

全てのデプロイはスコープとリスクがあり難しい ->決まったパワフルな自動ツールのプラットフォームが必要

AWSでのBlue/Greenデプロイの利点

• 素早いデプロイ
• 柔軟なオプション
• スケーラブルな容量
• 使った分だけの課金
• 自動化機能

アプリデプロイでののBlue／Greenパターン

EC2インスタンスを使う場合

1. 古典的なDNSカットオーバー
2. Auto Scaling Groupの交換
3. ローンチ・コンフィグレーションの交換

ECSを使う場合

1. DNSを経由したECSサービスの交換
2. ELBの背後のECSサービスの交換
3. ECSタスク定義の交換

一般的なシナリオ：環境自動化

デプロイの成功は以下のリスクに依存します。

• アプリケーションの問題
• アプリケーションの性能
• 人/プロセスのエラー
• インフラストラクチャーの失敗
• ロールバック機能
• 大きなコスト

特に「人/プロセスのエラー」、「インフラストラクチャーの失敗」に対して自動化プラットフォームの強みが有ります。

CloudFormationは最も包括的な自動化プラットフォームです。

• ネットワークからソフトウェアまでのスタックの範囲
• 高レベルな自動化サービスコントロール：Elastic Beanstalk、ECS、OpsWorks、Auto Scaling

パターン：古典的なDNSカットオーバー

• 現在のアプリケーション環境を開始する
• 新しいアプリケーション環境をデプロイする
• Greenスタックをテストする
• DNS経由のトラフィックを徐々に減らす
• 環境を監視する
• 必要であればBlueへロールバックする

パターン：Auto Scaling Groupの交換

次はDNS使わない方法です。

• 環境境界の外側にELBを配置します
• 現在のAuto Scaling Groupを開始します。
• 新しいAuto Scaling Groupをデプロイ、スケールアウトします。
• Greenスタックをテストします
• GreenスタックをELBに登録し、Blueスタックを切り離します。

パターン：ローンチ・コンフィグレーションの交換

更に環境境界を減らします。

• ELBの背後で現在のオート・スケーリング・グループとローンチ・コンフィグレーションで起動します
• オート・スケーリング・グループにBlue/Greenのローンチ・コンフィグレーションを取り付けます
• 元のサイズの2倍まで徐々にオート・スケーリング・グループを拡張します
• 元のサイズにオート・スケーリング・グループを縮小します
• さらなるコントロールのために、古いインスタンスを待機します

DNSを経由したECSサービスの交換

コンテナを起動している場合はどうなるか？

• タスク定義とELBで構成されるBlueサービスを開始します
• Docker imageの新しいバージョンと新しいELBで新しいタスク定義を作成します
• 新しいタスクの定義とELBでGreenサービスを作成します
• トラフィックを新しいELBエンドポイントからRoute 53のエイリアスレコードを更新します
• 不要になったらBlueサービスをクリーンアップします

ELBの背後のECSサービスの交換

• タスク定義とELBで構成されるBlueサービスを開始します
• Docker imageの新しいバージョンで新しいタスク定義を作成します。
• 新しいタスク定義とGreenサービスを作成し、既存のELBに取り付けます
• タスクの数をインクリメントすることにより、Greenサービスをスケールアップします
• タスク数を0に設定することでBlueサービスの使用を停止します

ECSサービスのアップデート

• ECSサービスで参照されるBlueタスク定義を開始します
• 既存のタスク定義のGreenリビジョンを作成します
• 更新されたタスク定義を使用するために既存のECSサービスを更新します
• ECSはローリング方式でコンテナインスタンスに新しいタスク定義をデプロイします

スキーマ変更はどうするか？

スキーマ変更とコード変更を切り離すには2つのアプローチが有ります。

• データベース更新が後方互換性を持つ
• コード変更は古いスキーマに対して後方互換性を持つ

DB外部の環境境界 シンプルさとリスクのトレードオフ

スキーマ変更が切り離せないか、リージョン間でデプロイする場合はどうするのか？

書き込みプロセスの一元化

• 書き込みプロセスを一元化して集約しデプロイします
• 共通のデータ基準：データストア特有のレプリケーションを使用します
• 集約したワーカーは両環境ノデータ変更に影響します。
• 遅れ/待ち時間を配慮するアカウント

一元化した書き込みプロセスをシンプルにします

• Greenアプリは両方のDBに書き込みます。 非同期でGreenアプリがBlueデータベースに変更を行います 一貫性の要件に不一致が有るか（古いアプリは強い一貫性を必要とします）
• 各アプリは各々のDBへ書き込みます 非同期で他のDB変更をプッシュします 完全に分離したアーキテクチャ 例えば、DynamoDBのテーブル＋Stream＋triggers＋Lambdaファンクション

Blue/Greenデプロイパターンのまとめ

パターン

デプロイプロセスに慣れる

デプロイは常にリスクと関連します

• デプロイと自動化フレームワークはプロセスエラーとヒューマンエラーを低減します
• 商用環境のような複製環境を使用してデプロイに慣れます
• AWSは迅速はプロビジョン済みリソース、新しいアプローチを実験する柔軟性を手頃な価格で提供します

さいごに

デプロイ方法の解説では、アプリケーション層の切り替えについて言及することは多いですが、スキーマ変更を伴うDB変更についての解説は少ないと思います。今回のセッションはDB変更時の考え方が学べたので、ほんとうに勉強になりました。