Release Engineering / CDについて最近読んだ記事のメモ

Deploy != Release (Part 1)

同じような意味で使われがちだが、Deploy と Release は全く別の営み
- 混乱して使われがちなこれらの用語の定義を整理し、言葉をより正確に使うことで、Software Release,CDなどの問題をより解像度高く考えることができる
用語の定義
- Deploy : Production環境にSoftwareをInstallする作業
- Release : DeployされたSoftwareに対し、Production TrafficをRe-routingする作業
Release In Place, つまり、ビルドしたアプリケーションを既存のアプリを全入れ替えする形でリリースすると、DeployとReleaseを同時に実行することになるので、Deployのリスクが顧客に転嫁されてしまう。そうではなく、DeployとReleaseを疎結合(decouple)にすることでリスクを分割することが重要で、方法としてBlue / Greenがある(詳細はPart２)
Release In Place,により(耐障害性的な意味で)壊れてしまったアプリケーションが、Rollbackによって復旧されるとは限らない。壊れる前のState*1が復旧される保証はどこにもないのだから。

*1 これは多義的で、Systemのhealth , DataのConsistency両方を含む?

個人的に、Release, Deployの定義は有用だと感じました。上記の定義に従うならば、「k8s manifestで定義のアプリを更新したら、起動に失敗した / liveness Probeに失敗した」はDeploy Failureであり、「更新したアプリがユーザーからのhttpリクエストを受け取ったが処理に失敗し500を返した。この種のリクエストはそれまでは処理に成功していた」みたいなRelease Failureとは別の問題と考えることができます。

前者と後者を分けて考えることのできる語彙を活用すると、我々がCDのDeployment Strategyでやりたいことをより解像度高く考えることができるのではないか？と思いました。

ReleaseによるSoftware故障の解決策として、Rollbackが万能ではないという話に同意します。以前から漠然と思っていたことを言語化してもらった気持ちになりました

Part1を受けて、DeployとReleaseを疎結合にする手段としてのBlue/Greenデプロイメントの話
BllueGreenデプロイメントではリスク低減のためにDeployとReleaseを分けて別個に実行する。
- まず先にDeployだけする。アプリケーションを配備・起動し、特定のPortでListenさせる状態までもっていく
- 次にProduction Trafficを向ける前に何らかのTestingを行い、、Production Trafficを向けても大丈夫だよね？ということを確認する
- その後初めて、商用トラフィックをReroutingする

Production Trafficをclone/forkして、テスト用の別システムに流すことで安全にReal World Testingする Dark Traffic (Dark Canary) という手法の話が面白かったです
- Linkedinでも同様の手法を採用している模様
- Chatworkのこちらの記事の終盤でも、同様の手法が語られています

一般に、ProductionにSoftwareをReleaseするときに、Release直後の監視メトリクスの挙動を見て問題がないかどうかを確認したりするが、そうであるならば、そこで行っていることは本質的には、Production環境でTestingをしているという事に他ならない
経済活動において、BenefitがCostを上回れば「利益がある」ということでそれをやることの正当性が担保されるように、TesingにおいてもBenefitがCostを上回るのであればそれを行うことは正当である。そう考えると、Production Tesingは適切に実行するとBenefitがCostを大きく上回る

「Testが十分になされ、安全性が確認されてからリリースする」という感覚自分の中にあったので、「Real World Tesing」的な思想は苦手なのですが、Prudction環境においてObserbabilityを適切にEnginneringしつつ、ユーザー影響の発生しないRelease Enginneeringをすることで単位時間における学習量、得られた知見の量を最大化しようという方向性が今後は増えてくるのかなと思いました。(Chaos Engineeringもそうですが)

そうしますと、最適なシステムの在り方も少し変わってくると思いますので、観点として頭の片隅に置いておこうと思います。