Blue/Green デプロイと安全性と複雑性と - #AWSDevDay 2022 登壇解説 -

2022-11-13

はじめに

今年も AWS Dev Day で登壇しました。私が AWS に入社したのが2019年でそこから毎年何かしら登壇して、今年が４回目でした。過去の登壇資料なんかは巻末に貼り付けておきます。

今年は運営メンバーにも加わってイベント作りから関わり、 CFP の選定や他のセッションのレビュー、総合司会なんかもやりました。

そもそも AWS Dev Day は、AWS が開催するイベントの一つで、名前の通り特に開発者の方、普段ソフトウェア・アプリケーションを開発している方、プログラミングしている方というところに焦点を絞って、「開発者の方に登壇いただき、開発者の方に楽しんで欲しい、開発者の方が今日から役立てるコンテンツをお届けしたい」そういうイベントです。

登壇資料/動画

兎にも角にもまずは以下を一度ご覧いただくことをこの記事ではおススメします。その上で補足・解説していくような立て付けの記事です。

資料

動画

この登壇に向けてのあれこれ

私仕事柄、多くの方と技術的なディスカッションをするのですが、その中で Amazon ECS の Blue/Green デプロイを採用するメンタルモデルについて3年間モヤモヤしてきたのが、今回ついにちゃんと言葉として整理できたので、「Blue/Green デプロイと安全性と複雑性と」と題して今回登壇することにしました。

このセッションどんなセッションに該当するかというと、技術解説とかでもなければ、事例セッションでもない。デモがあるわけでもないし、ライブコーディングもしない。強いて言うのであれば、僕の考えていることやソリューションアーキテクトとして信念を持っていることを話す、そういうセッションでした。

セッション解説

セッション解説ですが、セッション全てを文字に起こすくらいのこともできなくもないですが、わざわざ文字にしなくてもスライド見ればわかるページも多く、この記事ではおそらく理解が難しい・文字で解説された方がスッキリしやすいスライドをいくつかピックアップして解説していきます。

セッションをリアルタイムでご覧になった方は曖昧だった部分を改めて補足します。資料だけ見ていただいた方は、資料だけだとよくわからなかった部分のコンテキストをお伝えできれる記事になればと思います。

また、近いうちにセッション動画も公開される予定ですので、そちらも是非ご覧ください。公開され次第本記事を更新します。

課題定義

Blue/Green デプロイ自体は安全性の観点やリリース・ロールバックにかかる時間の観点でも効果的なデプロイ方法です。最高です。ただ、例えば

「リリース時の起きる障害が多く、心配なので安全なBlue/Green デプロイを採用します！」
「破壊的変更とかビッグバンリリースをしやすいので、とりあえずBlue/Green デプロイにします」

これって、安全性を損ねている問題の本質と本当に向き合えているのでしょうか？安全性という言葉を振りかざして思考停止していないでしょうか？

こういうメンタルモデルで Blue/Green デプロイを採用した結果、安全性を高めたかったのに、どんどん複雑なプロセスやフローになっていって、結果安全性をさらに損ねているケースを見かけることがあります。

このセッションは Amazon ECS のおけるデプロイメントを例にして「必要十分な設計であれ」という話をしています。

デプロイ関連の問題の大半は、複雑で不安定なデプロイである

「安全なデプロイとは？」というセクションの最後のスライドでした。安全なデプロイとは、「意図した変更が本番環境にデプロイされること」「意図しない状況が発生した場合の影響を最小限にできること」と定義しました。

このページは Lean と DevOps の科学という書籍からの抜粋です。この書籍、DevOps について数年にわたる調査と分析の結果がまとめられています。自身の常識や固定観念をぶち壊すのにもすごくいい書籍なので、今回僕のセクションを見て「ハッとした」とかそういう感想を持った方は是非一度読んでみることをおススメします。

その中でデプロイ関連の問題の大半は複雑で不安定なデプロイだと書かれています。そしてこのスライドでは複雑で不安定なデプロイを引き起こす典型的な 3 つの要因を紹介しました。

1つ目が 「そもそもソフトウェアを作る段階でデプロイの容易性を念頭に置いていない。」 そもそもデプロイ容易性とは何かって話ですがこの書籍においては「アプリケーションを、それが依存する他のアプリケーションやサービスからは独立した形で、デプロイまたはリリースできる」状態と定義しています。いわば自律的にデプロイができる状態です。

デプロイ容易性のないソフトウェアが産まれると、ソフトウェアが環境との厳密な依存関係を必要とし、その要件からいかなる逸脱も許されないそんな環境でのデプロイは、複雑かつ組織的なデプロイを取らざるを得なくなります。

2つ目が 「手作業による本番環境への変更・追加がデプロイプロセスの一部になっている」。こうなってくると人的ミスが増えていき、デプロイの失敗率も高まっていきます。そしてこうした手作業が増えていく要因は、デプロイにおける種々のプロセスが自動化しにくい状況がそうさせています。

そして、ソフトウェアのデプロイ容易性がない状況は自動化を難しくします。人の心理上この自動化が「おこないにくい」とどうしても手作業に走りがちです。

そして3つ目が 「デプロイが複雑なため、チーム間の作業の引き継ぎが多くなる」 特に顕著なのは、データベース・ネットワーク・開発・セキュリティ・テストをそれぞれ別個のチームが担当しているような組織で起こりがちです。

複雑性が増してくる中で、結果として安全性というのは損なわれていくわけです。デプロイ戦略のみに目を向けず、さまざまな観点でデプロイフローを考えていく必要があります。

Blue / Green デプロイと複雑性

「Blue / Green デプロイと安全性と複雑性と」というプレゼンのタイトルと同じタイトルのセクションの最初のトピックでした。

Blue/Greenデプロイでは、動作確認をした上で最終的にルーティングを新環境に切り替えて良いかどうかの判断が入ることが前提です。「何をトリガーに切り替えを行うのか」「どうしたら切り戻すのか」といった運用も考える必要があります。

そして、もちろん自動化しようとなります。「自動化の仕組みはどうするのか」例えば自動テストを走らせてエラーが一定期間なければ切り替えるとか、何かしらのメトリクスをもとに一定の閾値を超えたら切り戻しを行うとか、自動化するための手間や複雑性は増していくでしょう。

自動化をあえてしないというのは選択肢の一つだとは思います。だが前述の通り、手作業によるデプロイプロセスは複雑性が増し、また別のデプロイの問題を引き起こしそうです。

Canaryや線形デプロイも同様ですね。高度なデプロイの仕組みをとることで、そのためにどんどんデプロイは複雑化していきます。このように Blue/Green デプロイ自体が複雑というより、高度なことができるがゆえに考えるべきポイントも多く、結果的に複雑になりがちなデプロイ手法だと思います。

安全性を求めて Blue / Green デプロイを進めた結果、複雑性だけが増し安全性も失うケース1

安全性を求めてBlue/Greenデプロイを進めた結果、複雑性だけが増し安全性も失ってしまうようなケーススタディを 2 つ紹介しました。

1つ目が「本番リリース時の障害が多く、安全な Blue/Green デプロイを採用したい」というケースというかメンタルモデルです。これ何が問題かというと「安全性を高める」を大義名分に叫んでいますが、そもそも問題となっているのは意図した変更が本番環境にデプロイできないことです。つまりデプロイ前の検証や動作確認がちゃんとできていないことに原因がありそうです。

テスト手法やプロセスなどを改善するという問題の本質から目を背けて、Blue/Green デプロイというデプロイ戦略に負担を押し付けているだけです。そしてそれが適切な押し付け先ともいえません。

このようなメンタルモデルで採用すると、そもそもの不具合が減るわけではないので、今度は手動での確認作業が増えていきがちです。結果安全性も保てなくなるでしょう。

安全性を求めて Blue / Green デプロイを進めた結果、複雑性だけが増し安全性も失うケース2

2つ目のケーススタディが「破壊的変更やビッグバンリリースをしやすいので、とりあえずBlue/Green デプロイを採用したい」というメンタルモデルです。

これ何が問題かというと、このケースではそもそものソフトウェアとしてのデプロイ容易性が低いことに起因していることが多いです。他のアプリケーションやコンポーネントに依存したデプロイが必要で、大きな単位でのリリースしかできないような構造になっています。

こちらのケースでも、ソフトウェアのデプロイ容易性がないことから目を背けて、Blue/Greenデプロイというデプロイ戦略に負担を押し付けているだけです。

もちろん理想論的なところもあり、既存のアプリケーションや組織規模の問題でそうならざるを得ないケースがあるのはわかっていますが、やはりもやっとします。

このようなメンタルモデルで採用すると、デプロイにおけるさまざまなコンポーネントを巻き込んだテストをやりたくなっていきます。最初はそうでなくてもだんだんそうなりがちです。

Database の更新テストなどもしたいので、Database も一緒に Blue/Green 環境を用意したいとか、依存関係のあるサービスを巻き込んで Blue/Green デプロイをするとか、どんどん自律性のないデプロイに走りがちです。そして、そのための Database や別サービスの並行環境へ繋ぐための設定値はどう扱うのか？など、本来関係のない方向に力を裂いていくことになります。結果、複雑化していき、安全性も保てなくなっていきます。

今自分たちにおいて問題となっているポイントはどこなのか？そもそも問題の本質を隠蔽するためのデプロイ戦略の選択は結果誰も幸せになりません。

「とりあえず Blue /Green にしておきたい」という思考

Blue / Green デプロイというデプロイ戦略は安全性が高く、多機能なデプロイ戦略です。リリース作業やロールバックプロセスも Blue 環境から Green 環境へのトラフィックの向き先を切り替えるだけであり分かりやすいです。

では、このセッションで何を伝えたいのかというと、「とりあえず Blue /Green にしておきたい」というメンタルモデルに課題があるのです。なぜそのようなメンタルモデルに陥りがちかちかというと、多機能だからです。多機能なのでいろんなことをやりたくなり、結果フローやプロセスの複雑性が増しがちです。

デプロイ時の障害が多いのであれば、

そもそもデプロイ容易性のあるソフトウェアを開発しているか？
ちゃんとテストは機能しているのか？
小さい単位で継続的にデプロイできているのか？
メトリクスやログの収集は十分か？

「今ある課題はデプロイ戦略で解決すべき課題なのか」を一度立ち止まって考えましょう。

Keep it simple, stupid.

登壇の直前まで考えては消し、考えては消しをやり続けたスライドです。結果スライドもシンプルになりましたw

複雑なデプロイが悪なのではなく、チームやプロダクトに沿わない「必要以上に」複雑なデプロイこそに課題があるというセクションで、KISS の原則というソフトウェアエンジニアリングにおける有名な原則を紹介しました。

Keep it simple, stupid. ~ by Kelly Johnson(American aeronautical and systems engineer)~

設計の単純性（簡潔性）は成功への鍵だということと、「不必要な複雑性」は避けるべきだという金言です。

この原則を話すと決めた段階で、「ソフトウェアエンジニアリングにおけるシンプルとは？」 という非常に深いテーマと向き合わないといけないというのはわかっていました。

ただただ「簡単な」っていうのも違和感あり、コンポーネントが少ないからといってシンプルでもない。登壇直前までいろんな同僚とディスカッションしました。

結果 「無駄がなく」「理解しやすい」 ことだと、私は到達しました。

「無駄がない」についてですが、ひいてはやるべきことに対して無駄がないという方がイメージがつきやすい気がします。

ここまでお伝えした誤ったBlue/Green デプロイにおけるメンタルモデルの話をすると、例として出した「デプロイ時に障害が多いから」というメンタルモデルでの採用は、本来の課題は「そもそもテストがちゃんとできてない」ことであり、やるべきことはテストの見直しのはずした。その本来のニーズに対して必要以上に多機能なデプロイ戦略を導入するのは、無駄が多いですよね。つまりシンプルではない、必要以上に複雑になってしまっています。

続いて「理解しやすい」ですが、これは誰が見てもわかるということです。

ソフトウェア開発の文脈ではコードの「可読性が高い」「再利用しやすい」「変更しやすい」といったことが考えられます。

デプロイについてだと、コードではなくここはフローやプロセスに当たります。

誤ったBlue/Green デプロイにおけるメンタルモデルの話では、デプロイサイクルの長いビッグバンリリースをするためだけの Blue/Green デプロイの採用ではデプロイにおけるさまざまなコンポーネントを巻き込んだテストをやりたくなり、Database も含めた Blue/Green デプロイなど自律性のない選択肢をとりがちだと話しました。これでは誰が見てもわかるようなプロセスにならないのは想像に難くないです。シンプルではないですね。

シンプル・・・深いです。

さいごに

ここ数年モヤモヤしてきたことをちゃんと言語化して、アウトプットできて本当によかったです。

今回、特に自身の気持ちが強く乗ったアウトプットをしたこともあり、みなさんからいただけるTwitter での反応が、いつもよりもものすごーーーーく嬉しいです。ありがとうございました。

正直今はネタ切れなので、来年に向けて年末年始はたくさんインプットしていきます！