なぜデプロイが大事だと思うのか

前提

現在筆者は PipeCD という継続的デリバリーのOSSを開発しており、携わって1年と数ヶ月です。平たく言えばデプロイツールです。

携わる前からCI/CD、特にデプロイに関心があり、以下2つの考えがありました。

※背後にはもちろんデプロイの辛みの経験があるのですが、それは割愛します。

考え1. やはり「信頼性を壊すのはデプロイ」

jacopenさんのセッションにもありましたが、「障害の大半はデプロイが原因」
- 「デプロイ周りどうにかしないと信頼性も上がらないだろう」と考えるのは自然かと
もちろん、アクセススパイクによって信頼性が破壊されるケースもある
- このセッションが非常に印象的でした

考え2. Poorなデプロイは“生産性”やビジネス面にも弊害が多い

本記事では"生産性"の定義はボカします。デプロイ頻度とか、エンジニアの工数あたりです。

弊害の例をいくつか挙げます。

リリース頻度が下がる
- 「リリースは危険・手間だから頻度を落とそう」
- リリースを遅らせることによる機会損失は無視して良いのか？
継続的なパッチ当てが困難になる
- ライブラリ更新が放置され、いずれビッグバン更新せざるを得なくなる
- セキュリティリスクにもなる
デプロイ起因の障害時の修正時間・影響範囲が拡大する
- 検出+一次復旧(ロールバックなど)が遅れる分だけ、ビジネス上の損失となってしまう
- 障害の影響範囲が世界中のユーザだった大事故は記憶に新しい
作業ミスのリスク
- 特にデプロイフローに手動作業がある場合
- 人力承認が必要な場合、承認の手間が発生する + 承認基準がブレる
  - 完全に無くすのは難しい。そもそもコードレビューが人力
夜間リリースによるエンジニアへの負荷
- 「障害時の影響範囲を抑えるために、夜間にエンジニアで作業しよう」
- 年数回とかビッグイベントなら耐えられそう。頻繁な夜間リリースがあるチームは持続可能か？採用面での影響は？

このセッションがまさに「不便なデプロイによる弊害」の話で学びが多かったです。

デプロイの”理想”像

ではどんなデプロイならいいのか？MECEでも何でもないですが、いくつか挙げてみます。DORAのDevOps Capabilitiesも少し含んでいます。

デプロイしたい時に速やかにデプロイできる容易性・速度
- デプロイの自動化、チーム”内”でのテスト、小さなバッチ単位の作業、変更承認の効率化など
デプロイ前に検出可能な問題（セキュリティ含む）は、デプロイ前に潰されている
- CIの強化、セキュリティのシフトレフト
デプロイ後に本番環境で問題がないかを検出できる状態になっている
- Observability
デプロイ後に本番環境でしか検出できない問題に遭遇した場合は、速やかに安全な状態に修正できる
- 修正まで自動だとベスト
- DBの変更管理も含められるとなおよし
デプロイ後に本番環境で問題が発生した場合にも、その影響範囲は最小限に限定されている
- CanaryやBlue/Green
上記を低コストで実現する
- デリバリー基盤のインフラコスト、運用コスト、導入/改善コストを減らす
- 理想のデプロイのためになんでもかんでも導入すると、それはそれで認知負荷含めてコストかかりすぎる

プロセスに人間が入るとどうしてもボトルネックとなってしまうので、上記が自動化されているのが理想です。

“理想”のデプロイの実現は難しい

理想的なデプロイ/リリースを実現するのは当然簡単ではないです。”理想”から遠い原因は怠慢ではないと思います。

ハードルをいくつか挙げます。

費用面
- Blue/Greenであれば、デプロイ中に2環境分のコストがかかる。これはペイするとは限らない
  - 「”金で殴る”はSREとしては負け」に対して、デプロイにおいてどう立ち向かうか
前提条件の多さ
- そもそもCIが最低限整っていないと、いくらデプロイだけを整えたところで「そもそもまともにデプロイできない」「デプロイしてもバグだらけ」になる
- Observabilityを整えないと、Canaryリリースでも手動判断が必要で、全自動デプロイフローのメリットを享受できない
  - SREのHierarchyでいえば、まずMonitoring(あるいはObservability)の整備が必要。 “Release procedures”はそれよりも上にある
- デプロイ成否の判定基準はどうするか？
  - テレメトリデータから簡単に判定できるものか？
  - 人間の勘・経験を機械向けに翻訳できるか？
  - その基準は今後も不変か？
- アプリケーションコードにも工夫が必要
  - ロールバック不可な実装だと面倒
    - 特にDBのマイグレートがあると面倒
  - Canaryであれば、複数バージョンに同時対応させる必要がある
信頼性と生産性のトレードオフ・関連性が厄介
- 「信頼性を爆上げして、別口で生産性を爆上げすれば解決！」する問題でもない
  - 特に「デプロイ成否判定の自動化」や「手動承認の排除」が困難
  - 開発ツールの改善などは比較的トレードオフがないので、良さげなのを選んでいけば生産性向上に寄与する
  - 「信頼性がなければ生産性は上がらない、生産性がなければ信頼性は上がらない」部分もある
    - 例）ライブラリ更新の自動化
- Progressive Deliveryはトレードオフを和らげる一つ手段だと考えている

全ての理想を満たすのはコストに見合わない可能性もあるので、諦めが肝心でしょうか？

とはいえ、Engineeringで解決していかないと常に辛いままでしょうか？

結論のようなもの

「デプロイが大事」という考えは自分の中でまだ変わっていない
とはいえ、「高度なデプロイの実現」の前に立ちはだかる壁は高い＆多い
- デプロイにFocusしても「まずはObservabilityの獲得から始めよう」なのか？？
Engineeringで打破すべき壁はどこまで？？全部？？

めも

ラフに書きます

なぜデプロイが大事だと思うのか整理する -SRE Kaigi 2025に参加して-