Blue / Green デプロイと安全性と複雑性と #AWSDevDay

Slide 1

Slide 1 text

© 2022, Amazon Web Services, Inc. or its affiliates. All rights reserved. © 2022, Amazon Web Services, Inc. or its affiliates. All rights reserved. Blue / Green デプロイと安全性と複雑性と C - 3 Shinichi Hama（はまーん） / track3jyo Startup Solutions Architect, West Japan Amazon Web Services Japan G.K.

Slide 2

Slide 2 text

© 2022, Amazon Web Services, Inc. or its affiliates. All rights reserved. Shinichi Hama / track3jyo Startup Solutions Architect Amazon Web Service Japan --- work: - ⻄⽇本のスタートアップ⽀援 - コンテナ技術のあれこれ過去のスライド: https://speakerdeck.com/track3jyo 趣味︓家のアーキテクチャを考えること

Slide 3

Slide 3 text

© 2022, Amazon Web Services, Inc. or its affiliates. All rights reserved. セッション対象者とゴール想定聴講者 • ソフトウェアのデプロイフローやアーキテクチャを普段から考えている • デプロイ関連の問題がなにかと多く、⽇々悩まされている開発者の⽅ • アプリケーションコードを安全にデプロイするための考え⽅やプラクティスが知りたいゴール • 「安全な」デプロイとはどんなデプロイなのかを改めて理解し、⾃分達のデプロイの安全性を阻害する原因は何かと改めて考えるきっかけにする • 必要⼗分なデプロイフロー/アーキテクチャをデザインし続ける必要性を知り、実践できるようになる前提︓2022/11/09 時点の Amazon Elastic Container Service(Amazon ECS) のデプロイを題材に話していきます

Slide 4

Slide 4 text

© 2022, Amazon Web Services, Inc. or its affiliates. All rights reserved. ⼀般的なソフトウェアのリリースプロセス Source Build Test Production • ソースコードのチェックイン • コードのピアレビュー • コードのコンパイル • ユニットテスト • スタイルチェッカー • コンテナイメージ、関数デプロイパッケージの作成 • 周辺システムとの統合テスト • 負荷テスト • UI テスト • セキュリティテスト • 本番環境へのデプロイ • エラーを素早く検知するための本番環境のモニタリング

Slide 5

Slide 5 text

Slide 6

Slide 6 text

Slide 7

Slide 7 text

Slide 8

Slide 8 text

Slide 9

Slide 9 text

Slide 10

Slide 10 text

Slide 11

Slide 11 text

Slide 12

Slide 12 text

Slide 13

Slide 13 text

Slide 14

Slide 14 text

© 2022, Amazon Web Services, Inc. or its affiliates. All rights reserved. Blue / Green デプロイ • AWS CodeDeploy, ALB でコントロール • Green タスク群に本番トラフィックを流す前にテストを実施 Blue tasks: v1 code Green tasks: v2 code ALB 100% Prod traffic 100% Test traffic

Slide 15

Slide 15 text

© 2022, Amazon Web Services, Inc. or its affiliates. All rights reserved. Blue / Green デプロイ • AWS CodeDeploy, ALB でコントロール • Green タスク群に本番トラフィックを流す前にテストを実施 Green tasks: v2 code ALB 100% Test traffic Blue tasks: v1 code

Slide 16

Slide 16 text

Slide 17

Slide 17 text

Slide 18

Slide 18 text

© 2022, Amazon Web Services, Inc. or its affiliates. All rights reserved. こういった話を⽿にすることがありますリリース時の起きる障害が多く、⼼配なので安全な Blue / Green デプロイを採⽤します︕ 破壊的変更を⼊れやすいので、とりあえず Blue / Green デプロイにします︕ 安全性を損ねている問題の本質と本当に向き合えているのでしょうか︖ デプロイフロー/プロセスの複雑化が進み、安全性を損ねる結果につながっていないでしょうか︖

Slide 19

Slide 19 text

Slide 20

Slide 20 text

Slide 21

Slide 21 text

© 2022, Amazon Web Services, Inc. or its affiliates. All rights reserved. デプロイにおける “安全” を考える • 意図した変更が本番環境にデプロイされること Ø 「意図した変更が、きちんと反映される」整備されたデリバリープロセスがある • 意図しない状況が発⽣した場合の影響を最⼩限にできること Ø 意図しない状況を絶対に起こさない、全ての状況を事前に想定するのは現実不可能 Ø 意図しない状況が発⽣した場合のユーザーや関連サービスへの影響をできるだけ⼩さくする

Slide 22

Slide 22 text

Slide 23

Slide 23 text

Slide 24

Slide 24 text

Slide 25

Slide 25 text

Slide 26

Slide 26 text

Slide 27

Slide 27 text

Slide 28

Slide 28 text

© 2022, Amazon Web Services, Inc. or its affiliates. All rights reserved. 安全性が保たれていないデプロイでは • サービスを利⽤するエンドユーザーへの影響 Ø Error Rate 上昇、レイテンシーの増加、サービス中断 • リリース時に⼈を介した確認作業が増えていく Ø e.g. ⼿動でのテスト、⽬視確認、ダブルチェック、段階的な承認プロセス..etc Ø 本来集中したいビジネスロジックの開発にかける時間が減っていく • デプロイにおける⼼理的安全性の低下により、⽣産性が著しく低下 Ø 「また⾃分の書いたコードで問題になるのではないか」と億劫になる

Slide 29

Slide 29 text

© 2022, Amazon Web Services, Inc. or its affiliates. All rights reserved. デプロイ関連の問題の⼤半は、複雑で不安定なデプロイである 1. そもそもソフトウェアを作る段階でデプロイの容易性を念頭に置いていない 2. ⼿作業による本番環境への変更・追加がデプロイプロセスの⼀部になっている 3. デプロイが複雑なため、チーム間の作業の引き継ぎが多くなる - 「 L E A N と D E V O P S の科学」より -

Slide 30

Slide 30 text

Slide 31

Slide 31 text

© 2022, Amazon Web Services, Inc. or its affiliates. All rights reserved. Blue / Green デプロイと安全性 • ⼀度新しい環境でテスト/動作確認をした上で切り替えができ、安全を確認した上で切り替えが可能 • 問題が発⽣した際も、トラフィックを元のバージョンの環境に切り替えるだけなので、迅速にトラフィックの切り戻しが可能

Slide 32

Slide 32 text

Slide 33

Slide 33 text

© 2022, Amazon Web Services, Inc. or its affiliates. All rights reserved. 安全性を求めて Blue / Green デプロイを進めた結果、複雑性だけが増し安全性も失うケース1 シチュエーション︓ • 本番リリース時の障害が多く、安全な Blue/Green デプロイを採⽤したい何が問題か︖︓ • そもそも問題となっているのは「意図した変更が本番環境にデプロイできないこと」どうなるか︖︓ • そもそもの不具合が減るわけではないので、結果的に⼿動での確認作業が増えていき、結果安全性も保てていない

Slide 34

Slide 34 text

© 2022, Amazon Web Services, Inc. or its affiliates. All rights reserved. 安全性を求めて Blue / Green デプロイを進めた結果、複雑性だけが増し安全性も失うケース2 シチュエーション︓ • 破壊的変更とかビッグバンリリースをしやすいので、とりあえず Blue/Green デプロイを採⽤したい何が問題か︖︓ • ソフトウェアとしてのデプロイ容易性が低く、他のアプリケーションやコンポーネントに依存したデプロイが必要で、⼤きな単位でのリリースしかできない構造になっているどうなるか︖︓ • ⾃律性のないデプロイプロセスや、Blue/Green デプロイ⾃体が複雑化しがちで、結果安全性も保てなくなってくる

Slide 35

Slide 35 text

© 2022, Amazon Web Services, Inc. or its affiliates. All rights reserved. 「とりあえず Blue /Green にしておきたい」という思考 • Blue / Green デプロイは安全性が⾼く、多機能なデプロイ戦略 • 「とりあえず Blue /Green にしておきたい」というメンタルモデルに課題がある • 多機能がゆえに、いろんなことをやりたくなり、結果フローやプロセスの複雑性が増しがち • 今ある課題は本当にデプロイ戦略で解決すべき課題なのか

Slide 36

Slide 36 text

© 2022, Amazon Web Services, Inc. or its affiliates. All rights reserved. Amazon ECS ローリングアップデートのデプロイサーキットブレーカー v1 v2 v2 ... v1 v1 v1 ... New Deployment Rollback v1 v1 v1 ... • ECS サービスのデプロイで異常が発⽣した際、以前のバージョンへの⾃動ロールバックが可能 • ⾃動ロールバックの実装を ECS に委ねて、マネージドな⾃動化が可能 • 異常が発⽣したタスクの起動によるコストの発⽣やコンピューティングリソースの消費を抑える

Slide 37

Slide 37 text

© 2022, Amazon Web Services, Inc. or its affiliates. All rights reserved. デプロイ失敗の判定 • ステージ 1、ステージ 2 の⼆段階で評価される • ステージ 1 Ø RUNNING 状態に遷移することなく、タスクの起動が “しきい値” まで連続して失敗する • ステージ 2 Ø ヘルスチェック #1 の失敗によりリプレースされたタスク数が “しきい値” に到達する #1: ELB / Cloud Map / コンテナのヘルスチェック

Slide 38

Slide 38 text

Slide 39

Slide 39 text

© 2022, Amazon Web Services, Inc. or its affiliates. All rights reserved. デプロイサーキットブレーカーの挙動 container 1 container 2 ver1 (Active) ALB End User Developer ECS サービスタスク定義 ver1 参照 ECS クラスター container 1 container 2 ver2 (Primary) タスク定義 ver2 参照 flask_app_ver3.py

Slide 40

Slide 40 text

Slide 41

Slide 41 text

Slide 42

Slide 42 text

Slide 43

Slide 43 text

Slide 44

Slide 44 text

Slide 45

Slide 45 text

Slide 46

Slide 46 text

© 2022, Amazon Web Services, Inc. or its affiliates. All rights reserved. 本当に最初からその⾼度な仕組みが必要ですか例えば、まだまだ成熟していないプロダクトやチームにおいて… • 本当に最初からその⾼度な仕組みが必要か • 複雑なデプロイプロセスやフローを導⼊することで満⾜していないか • チームやプロダクトに沿わない、わたしの考えた最強デプロイフローやアーキテクチャになっていないか安全性を⽬指して設計したはずの仕組みが、結果安全性を損なうのは、多くの場合チーム/プロダクトに沿わない、必要以上な仕組みを導⼊したことに起因します他の例）Blue/ Green デプロイ、DB のライブマイグレーション、派⼿なピタゴラスイッチアーキテクチャ

Slide 47

Slide 47 text

Slide 48

Slide 48 text

Slide 49

Slide 49 text

© 2022, Amazon Web Services, Inc. or its affiliates. All rights reserved. © 2022, Amazon Web Services, Inc. or its affiliates. All rights reserved. Invent and Simplify リーダーはチームにイノベーション（⾰新）とインベンション（創造）を求め、同時に常にシンプルな⽅法を模索します。リーダーは状況の変化に注意を払い、あらゆる場から新しいアイデアを探しだします。それは、⾃分たちが⽣み出したものだけに限りません。私たちは新しいアイデアを実⾏に移す時、⻑期間にわたり外部に誤解される可能性があることも受け⼊れます。シンプルな仕組みを⽬指しながら「常に思考を放棄しない」「リスクや要件と向き合う」ことが重要

Slide 50

Slide 50 text

© 2022, Amazon Web Services, Inc. or its affiliates. All rights reserved. 「必要⼗分な」デプロイフロー/アーキテクチャをデザインし続ける • デプロイフローやアーキテクチャはその時々で無駄なく、理解しやすい設計を⽬指す • ⽬の前にある課題から、少し視座を⾼く持って全体に⽬をむけ続ける Ø 少し要件を整理・⼯夫すればシンプルな仕組みにできないか︖

Slide 51

Slide 51 text

Slide 52

Slide 52 text

© 2022, Amazon Web Services, Inc. or its affiliates. All rights reserved. デプロイにおける安全性と複雑性は必ずしもトレードオフか︖ • 少なくても最初のうちは安全性を保つことと複雑な仕組みというのは必ずしもトレードオフではない • シンプルなデプロイフローを保ち続けることが安全性を保つことにつながる • デプロイ戦略以外にも必ず向き合い整理することが近道 Ø デプロイ容易性・テスト容易性のあるソフトウェアを書く Ø 簡単にロールバックできるように、⼩さくデプロイを繰り返す Ø チーム内で⾃律してデプロイが⾏えるような疎結合な設計

Slide 53

Slide 53 text

Slide 54

Slide 54 text

Slide 55

Slide 55 text

© 2022, Amazon Web Services, Inc. or its affiliates. All rights reserved. まとめ • 安全なデプロイとは • 「意図した変更が本番環境にデプロイされること」 • 「意図しない状況が発⽣した場合の影響を最⼩限にできること」 • デプロイにおける安全性と複雑性は必ずしもトレードオフではない • デプロイ関連の問題の⼤半は、複雑で不安定なデプロイが原因 • むしろシンプルなデプロイメントフローを保ち続けることが安全性を保つ • 必要⼗分なデプロイフロー/アーキテクチャをデザインし続ける • 複雑な仕組みが悪いわけではなく、「必要以上に」複雑になっていることが問題 • デプロイフローやアーキテクチャは変更可能な余⽩を持つ。常にその時々の最適を⽬指す

Slide 56

Slide 56 text