CloudFormation による 
Blue-Green Deployment 
Ⓒ Classmethod, Inc. 
1 
DevIO MTUP11-SAPPORO-003 
渡辺 修司, クラスメソッド 
2014年11月19日
渡辺 修司 
• AWSコンサルティング部 
• ソリューションアーキテクト 
• 2014年8月入社 
• 前職 
• Java業務システムの開発 
• Web関連のサービス開発 
• 現在 
• メンバーズポータル開発 
• 開発系のAWS環境のコンサル、開発支援 
• 趣味 
• ロードバイク、スノーボード、猫 
Ⓒ Classmethod, Inc. 
2
Blue-Green Deployment 
3
Deployment / 配備 
• アプリケーションを配置し、利用できる状態にする 
• ビルド 
• サーバへの転送 
• アプリケーションサーバの再起動 
• 初期リリース時やアップデート時に実施 
• デプロイ用ツールなどを使って自動化する 
• 複数サーバを手動でやるのは手間 
• 人為的ミスの防止 
Ⓒ Classmethod, Inc. 
4
Deployment時の課題 
• ダウンタイム 
• メンテナンス時間として利用不可 
• 切り戻し 
• アップデートが原因によるシステム障害 
Ⓒ Classmethod, Inc. 
5
Blue-Green Deployment 
• ダウンタイムゼロのデプロイメントパターン 
• マーチン・ファウラ̶が提唱 
• プロダクション環境を2系統用意(Blue/Green) 
• 一方をアクティブ系、もう一方をスタンバイ系 
• スタンバイ系にデプロイを行う 
• デプロイが完了したならばRouterで切り替える 
• http://martinfowler.com/bliki/BlueGreenDeployment.html 
Ⓒ Classmethod, Inc. 
6
Blue-Green Deploymentの課題 
• 2系統のサーバが必要 
• コストが2倍 
• トランザクションデータの扱い 
• RDBのデータ移行時間が発生 
• データベースのスキーマ変更 
Ⓒ Classmethod, Inc. 
7
AWSによる解決と妥協点 
• Blue-Green環境は必要に応じて構築 
• 不要な時は破棄することでコストを抑える 
• アップデート後、切り戻しが不要と判断したら破棄 
• DBレイヤはBlue-Greenとしない 
• 妥協する部分 
• Multi-AZならば冗長化もされている 
• 問題発生時はレストアの方針 
• DBのスキーマ変更 
• クリティカルならばダウンタイムを許容 
• 変更前と変更後に対応できるような実装もあり 
• 切り替え時のユーザ操作の整合性 
Ⓒ Classmethod, Inc. 
8
Cloud Formationによる 
Blue-Green Deployment 
9 
AWS 
CloudFormation
CloudFormationでリソースを構築 
• 繰り返し作業に効果的な自動化 
• 手作業はNG 
• ヒューマンエラー防止 
• AMIイメージを予め作成(Chefなど) 
Ⓒ Classmethod, Inc. 
10 
AWS 
CloudFormation
RDSは妥協 
• Blue/Greenにするデメリットが大きい 
• データの同期問題 
• スキーマ変更の影響 
• アプリレイヤで吸収(必要に応じて) 
• 問題発生時はバックアップからリストア 
• どうにもならない場合は止める 
• 最終的にはコストバランスを考慮 
Ⓒ Classmethod, Inc. 
11 
Amazon 
RDB
テンプレートはレイヤ毎に分割 
• Base / Green / Blue のテンプレートを用意 
• Base にはVPC関連と共通リソースを定義 
• GreenとBlueにはアプリレイヤーを定義 
• GreenとBlueは独立してStackを構築/撤収可能 
Ⓒ Classmethod, Inc. 
12 
CloudFormation 
Template
BlueとGreenはパラメータで指定 
• 共通テンプレートでOK 
• パラメータを活用し違いを吸収 
Ⓒ Classmethod, Inc. 
13 
"Parameters": { 
"Env": { 
"Type": "String", 
"Default": "Blue", 
"AllowedValues": [ 
"Blue", 
"Green" 
] 
} 
}, 
"Resources": { 
"FrontWeb1": { 
"Type": "AWS::EC2::Instance", 
"Properties": { 
"SubnetId": { 
"Fn::FindInMap": [ 
"Subnet", { "Ref": "Env" }, "AppA" 
] 
} 
} 
"Mappings": { 
"Subnet": { 
"Blue": { 
"AppA": "subnet-xxxxxxxxx", 
"AppC": "subnet-xxxxxxxxx" 
}, 
"Green": { 
"AppA": "subnet-xxxxxxxx", 
"AppC": "subnet-xxxxxxxx" 
} 
} 
} 
CloudFormation 
Template
1)デプロイの準備 
• Base環境を構築 
• 基本的に1回だけ(必要に応じてUpdate) 
Ⓒ Classmethod, Inc. 
14 
CloudFormation 
Stack
2)初回リリース 
• Blue環境を構築(初回リリース) 
• アプリはデプロイツールでデプロイ 
Ⓒ Classmethod, Inc. 
15 
CloudFormation 
Stack
3)初回アップデート 
• Green環境を構築 
• Green環境にアップデート版をデプロイし検証 
Ⓒ Classmethod, Inc. 
16 
CloudFormation 
Stack 
検証できたら 
Route53の設定を 
Green側に変更
4)Blue環境の撤収 
• Blue環境を削除してコストを押さえる 
• 不安がある場合はしばらく残してもOK 
Ⓒ Classmethod, Inc. 
17 
CloudFormation 
Stack
まとめ 
• 最小のダウンタイム 
• アップデート時のリスク対策 
• Cloud Formationを活用し、省コスト 
• Deployの自動化でヒューマンエラーを防止 
Ⓒ Classmethod, Inc. 
18
Ⓒ Classmethod, Inc. 
#cmdevio 
ご静聴ありがとうございました。 
スライドは後日ブログで公開します。 
19 
DevIO MTUP11-SAPPORO-003

Cloud FormationによるBlue-Green Deployment - Dev io mtup11 003

  • 1.
    CloudFormation による Blue-GreenDeployment Ⓒ Classmethod, Inc. 1 DevIO MTUP11-SAPPORO-003 渡辺 修司, クラスメソッド 2014年11月19日
  • 2.
    渡辺 修司 •AWSコンサルティング部 • ソリューションアーキテクト • 2014年8月入社 • 前職 • Java業務システムの開発 • Web関連のサービス開発 • 現在 • メンバーズポータル開発 • 開発系のAWS環境のコンサル、開発支援 • 趣味 • ロードバイク、スノーボード、猫 Ⓒ Classmethod, Inc. 2
  • 3.
  • 4.
    Deployment / 配備 • アプリケーションを配置し、利用できる状態にする • ビルド • サーバへの転送 • アプリケーションサーバの再起動 • 初期リリース時やアップデート時に実施 • デプロイ用ツールなどを使って自動化する • 複数サーバを手動でやるのは手間 • 人為的ミスの防止 Ⓒ Classmethod, Inc. 4
  • 5.
    Deployment時の課題 • ダウンタイム • メンテナンス時間として利用不可 • 切り戻し • アップデートが原因によるシステム障害 Ⓒ Classmethod, Inc. 5
  • 6.
    Blue-Green Deployment •ダウンタイムゼロのデプロイメントパターン • マーチン・ファウラ̶が提唱 • プロダクション環境を2系統用意(Blue/Green) • 一方をアクティブ系、もう一方をスタンバイ系 • スタンバイ系にデプロイを行う • デプロイが完了したならばRouterで切り替える • http://martinfowler.com/bliki/BlueGreenDeployment.html Ⓒ Classmethod, Inc. 6
  • 7.
    Blue-Green Deploymentの課題 •2系統のサーバが必要 • コストが2倍 • トランザクションデータの扱い • RDBのデータ移行時間が発生 • データベースのスキーマ変更 Ⓒ Classmethod, Inc. 7
  • 8.
    AWSによる解決と妥協点 • Blue-Green環境は必要に応じて構築 • 不要な時は破棄することでコストを抑える • アップデート後、切り戻しが不要と判断したら破棄 • DBレイヤはBlue-Greenとしない • 妥協する部分 • Multi-AZならば冗長化もされている • 問題発生時はレストアの方針 • DBのスキーマ変更 • クリティカルならばダウンタイムを許容 • 変更前と変更後に対応できるような実装もあり • 切り替え時のユーザ操作の整合性 Ⓒ Classmethod, Inc. 8
  • 9.
    Cloud Formationによる Blue-GreenDeployment 9 AWS CloudFormation
  • 10.
    CloudFormationでリソースを構築 • 繰り返し作業に効果的な自動化 • 手作業はNG • ヒューマンエラー防止 • AMIイメージを予め作成(Chefなど) Ⓒ Classmethod, Inc. 10 AWS CloudFormation
  • 11.
    RDSは妥協 • Blue/Greenにするデメリットが大きい • データの同期問題 • スキーマ変更の影響 • アプリレイヤで吸収(必要に応じて) • 問題発生時はバックアップからリストア • どうにもならない場合は止める • 最終的にはコストバランスを考慮 Ⓒ Classmethod, Inc. 11 Amazon RDB
  • 12.
    テンプレートはレイヤ毎に分割 • Base/ Green / Blue のテンプレートを用意 • Base にはVPC関連と共通リソースを定義 • GreenとBlueにはアプリレイヤーを定義 • GreenとBlueは独立してStackを構築/撤収可能 Ⓒ Classmethod, Inc. 12 CloudFormation Template
  • 13.
    BlueとGreenはパラメータで指定 • 共通テンプレートでOK • パラメータを活用し違いを吸収 Ⓒ Classmethod, Inc. 13 "Parameters": { "Env": { "Type": "String", "Default": "Blue", "AllowedValues": [ "Blue", "Green" ] } }, "Resources": { "FrontWeb1": { "Type": "AWS::EC2::Instance", "Properties": { "SubnetId": { "Fn::FindInMap": [ "Subnet", { "Ref": "Env" }, "AppA" ] } } "Mappings": { "Subnet": { "Blue": { "AppA": "subnet-xxxxxxxxx", "AppC": "subnet-xxxxxxxxx" }, "Green": { "AppA": "subnet-xxxxxxxx", "AppC": "subnet-xxxxxxxx" } } } CloudFormation Template
  • 14.
    1)デプロイの準備 • Base環境を構築 • 基本的に1回だけ(必要に応じてUpdate) Ⓒ Classmethod, Inc. 14 CloudFormation Stack
  • 15.
    2)初回リリース • Blue環境を構築(初回リリース) • アプリはデプロイツールでデプロイ Ⓒ Classmethod, Inc. 15 CloudFormation Stack
  • 16.
    3)初回アップデート • Green環境を構築 • Green環境にアップデート版をデプロイし検証 Ⓒ Classmethod, Inc. 16 CloudFormation Stack 検証できたら Route53の設定を Green側に変更
  • 17.
    4)Blue環境の撤収 • Blue環境を削除してコストを押さえる • 不安がある場合はしばらく残してもOK Ⓒ Classmethod, Inc. 17 CloudFormation Stack
  • 18.
    まとめ • 最小のダウンタイム • アップデート時のリスク対策 • Cloud Formationを活用し、省コスト • Deployの自動化でヒューマンエラーを防止 Ⓒ Classmethod, Inc. 18
  • 19.
    Ⓒ Classmethod, Inc. #cmdevio ご静聴ありがとうございました。 スライドは後日ブログで公開します。 19 DevIO MTUP11-SAPPORO-003