リリース安定性と顧客体験の向上を目指す Progressive Delivery のご紹介 | Offers Tech Blog

こんにちは、Offers を運営している株式会社 overflow CTO の 大谷旅人 です。
今回は、リリースの安定化に向けて弊社で整備が進んでいる Progressive Delivery に関するお話です。

※ 社内 LT 会からの転載です

はじめに

Progressive Deliveryとは

ネットを漁ると、次世代の継続的デリバリだ、Analyze と組み合わせてロールバック自動化する技術だ、と色々と出てきますが提言者である James Governor さんは以下のように言っています。

“Progressive delivery is continuous delivery with fine-grained control over the blast radius.”
— James Governor, RedMonk

出典: https://www.infoq.com/presentations/progressive-delivery/

で、なに?

Progressive Delivery とは特定の手法のことではなく、リリースに伴う様々な影響を最小限に抑え顧客体験を継続的に向上させるために、新しいソフトウェアを徐々にリリースしていく、最新のソフトウェア開発および DevOps/SRE 戦略全般を指します。

戦略や手法全般を指すため、以下のような色々な技術要素とともに語られているのが現状です。

• Feature Flags
  • A/B Testing
  • Phased Rollouts
• Canary Releases
  • with Analyze
• Blue-Green deploy
• Service Mesh
• Chaos Engineering

Service Mesh やカオスエンジニアリングも混じってきているので、一体全体何なのよとなりますが広義の意味では何語っても OK なのです。
以下からは、参考として Progressive Delivaery の文脈内で語られる技術要素について紹介していきます。

Feature Flags/Toggling

コードを変更することなくシステムの振る舞いを変えることができる手法^[1]です。

デプロイとリリースを分離できるため、以下のような効果が望めます。

• ユーザー影響を最小化しながら公開
• 小さい単位でデプロイ可能 → クソデカ PR 防止
• やらかしちゃっても切り戻せる → さよならポストモーテム

Canary Releases

出典: https://configcat.com/blog/2022/01/14/progressive-delivery/#canary-releases

従来バージョンを並行稼働させ、一部ユーザーだけを新バージョンにアクセスさせるデプロイ手法です。

• not Feature Flags, ユーザごとの振り分けではなくトラフィックでの振り分け
• L7 制御

Canary Releases + Analyze(SLO)

出典: https://static.sched.com/hosted_files/kccncna19/f2/Progressive Delivery %26 Argo Rollouts.pdf

昨今 Progressive Delivery はこの文脈で語られることが多いように感じます。
Canary Releases に既存のモニタリング手法を組み合わせることで、段階的なリリースをしつつ、SLO などの主要なメトリクスが閾値を下回った場合に自動でロールバックするようなデプロイ手法です。

実現するための、ツールとしては以下のようなものがあります。

• PipeCD
• ArogCD Rollouts
• Flagger

ほとんどが Kubernetes の導入を前提として設計・実装されています。

Canary Releases + Analyze(SLO)を導入するまでの課題

上記が、我々 Offers における SLO ですが、評価期間が 7days, 30days と長くとっています。
また、機能単位で細分化された指標を伴っておらず、切り戻しの判定するためのメトリクスとしての解像度が不足しています。
1 日に複数回、細かい機能単位のデプロイしている現状に合わせて、SLO も機能単位で計測し、短期間で評価をできるように定義することが求められます。

ユーザーへの影響をできるだけ小さく保ちながら公開することが主題なので、

1. FeatureFlags 導入
2. Canary Releases
3. SLO 整備
4. Canary Releases + Analyze(SLO)

といくつかは並行で行いながらも、順に進めていっています。
Feature Flags 導入までの整理は、そのうちまたここで書くことになりそうです(誰かが)。

あとがき

というわけで、Progressive Delivery の概要を示しつつ、現在行っている内容を軽シェアしていきました。
ソフトウェアリリースで起こる影響というのは、開発フローやテストで予防できますが完全に無くすことはできません。
一定エラーは発生するものとして考え、様々な影響を最小限に抑え復旧速度を上げていくことが現実的な判断です。

日々成長するプロダクトの維持と発展のために、課題と向き合い続けることに興味ある方、ぜひ一緒にやりましょう。

その他、対応中の課題はこちらでもまとめていますので、よければご一読を。

https://zenn.dev/offers/articles/20220714-develop-issues-part3

関連記事

https://zenn.dev/offers/articles/20220707-develop-issues-part1

脚注

1. https://martinfowler.com/articles/feature-toggles.html#:~:text=modify system behavior without changing code