※この記事は 開発生産性 Advent Calendar 2022 カレンダー2 の20日目の記事です。 前回記事の16日目は nakayamaatsushiさんの 『Findy Team+ Award 受賞の裏側~開発生産性向上の取り組みを振り返る~』でした。計測した開発指標をどのように開発生産性向上に結び付けているのか、具体的なアクション事例が紹介されており非常に参考になりました！
この記事の内容
カナリアリリースを実践した結果いくつかの成果が出ましたが、価値を出しきれたのかよくわからないというモヤモヤを感じていました。
振り返ってみると、いつの間にか一つの施策でこの世の全てを解決しようと考えてしまっていたことに気づきました。
ある施策が直接的に解決可能な課題は何か？をとらえた上で、引き続き改善活動をしていきたいです。
カナリアリリースを導入しました
ソフトウェアデリバリーチームの市原です。
私たちは、開発アジリティを向上する！という目標を掲げて、ECサイトのデプロイメントシステムの改善を行っており、その一環としてカナリアリリースを導入しました。
モノタロウでは、システム規模の拡大や組織の成長に従って、その開発速度が鈍化しているという課題感がありました。
この課題を解決するための突破口として考えられた施策のひとつが、デプロイメントの仕組みの改善です。より安全で迅速なデプロイメントプロセスを実現できれば、システムの再設計や機能改善のサイクルを加速することができるとの考えでした。
具体的な施策としては、カナリアリリースの導入とデプロイ頻度の向上をセットで行いました。変更を一部のトラフィックにだけ先行して配信するカナリアリリースを行い、変更に伴うリスクを低減させた上で、デプロイ頻度を向上させることを狙いました。
2021年末頃から企画がはじまり、2022年5月頃から段階的に導入を行いました。その後いくつかの改善を入れながら現在まで運用を継続しております。
背景や詳細につきましては、今年の夏にDevelopers Summit 2022 Summer で発表させていただいた資料がありますので、ご興味あればそちらをご参照ください
この記事では、上記の発表から5ヶ月ほどカナリアリリースを運用してみて、実際のところどうだったのか感想を述べていきたいと思います。
やってみての感想
カナリアリリースの導入プロジェクトでは、DevOps Four Keysも踏まえつつ、改善したい要素は何か、事前にいくつかの目論見を立てていました。 (※ DevOps Four Keysについては当社テックブログ 100人規模のエンジニア組織で DevOps Four Keys を導入し、アジリティー向上を目指した取り組み - MonotaRO Tech Blogもご参照ください)
実際にやってみると、思った通りうまくいった！ということと、なんかそれほど指標が反応せず、期待どおりじゃないなという項目がありました。
- うまくいったこと
- デプロイ頻度が上がる
- 本番で発覚するバグのユーザー影響を抑えられる
- 試しやすくなる
- 期待通りじゃなかったこと
- 開発リードタイムが短縮される⇒それほどでもない
- 機能開発のスループットがあがる⇒べつに上がらない
- マージが分散して衝突しづらくなる⇒ならない
- 本番環境の不具合は起こりづらくなる⇒そうとはいいきれない
うまくいったこと
思った通りうまくいった項目では次のようなものがあります。
デプロイ頻度が上がる
前掲の発表資料にもありますが、これは圧倒的にあがりました。当然です。デプロイ頻度を増やすことそのものが施策の一部だったのです。カナリアを含めた本番デプロイは1回/週から12回/週に増やすことができました。
本番で発覚するバグのユーザー影響を抑えられる
カナリア環境に先行してリリースすることで、実際いくつかのトラブルを小さな影響で止めることができました。多くのお客様に影響する前に問題を見つけられるようになったことは、サイトの信頼性向上に役立つことを実感できました。
試しやすくなる
システムの変更を行うときに、本番環境と同等の環境ではないと満足に検証できないというケースがあります。こういったケースの検証の場として、カナリアリリースが利用できる場合があります。実際、OSや言語のアップデートの最終段階の検証手段としてカナリアリリースを利用する例も出てきました。お客様への影響をおさえつつ、少しずつ本番稼働を試していく場合の選択肢になりました。
期待通りじゃなかったこと
一方で、事前に期待したほどに成果が見えないこともありました。ものすごく頑張ったのでもっと効果が出ていいのに、と思ってしまいました。
開発リードタイムが短縮される⇒それほどでもない
ここでいうリードタイムは、最初のコミットから本番へのデプロイまでの所要時間を指します。仮説では、この値が短縮される想定でした。なぜなら、１週間に１回のリリースよりも週に何回もリリースできたほうが、実装完了からデプロイまでの待ち時間が短縮できるためです。
ところが、実際に運用をしていくと、カナリアリリース対象のリポジトリだけで見ても、どうも平均値に変化がみられません。個別のチケットで、カナリアリリース導入前想定でのリリース日と比べてみるとたしかに一定の効果はでているように思えますし、リードタイムが１週間未満であるようなチケットは増加していましたが、平均ではそうは見えませんでした。多少短縮されたように見えても、年間単位で見ると、それ以上に大きくリードタイムが変動していることもわかりました。
つまり、開発チーム全体としてよくなったと言い切るほどには、顕著に指標の向上がみられませんでした。
仮説としては、開発期間が長めのPullRequestがマージされるとそれに引っ張られてリードタイム平均値が大きくなることになることや、開発プロジェクトごとの難易度や開発スタイルがリードタイムに与える影響が大きいために、わずかな短縮では指標に出るほどに改善結果がみえないこともありそうでした。実際、カナリアリリースの導入後のリードタイムの変動は、過去1年間での変動に比べて大きいとは言えませんでした。その場合、開発文化が重要になるので、当然仕組みを変えたからといって結果に影響するわけではありません。
機能開発のスループットがあがる⇒べつに上がらない
スループットはマージされるPullRequestの数で見てみました。デプロイ頻度が上がれば、開発組織になにかすごい化学変化がおこって、機能変更をバンバン出していくのかというと、そんなことはありませんでした。
そもそもどのチームも既に非常に多くの改善を日常的にマージして価値を出していて、デプロイの頻度の変化ぐらいで加速するはずもありませんでした。また、スループットとデプロイ頻度は直接の関係はないので、直ちに影響するわけではありません。
マージが分散することで、衝突が起こりづらくなる⇒ならない
実際の衝突事例の頻度を追跡したわけではありませんが、これは特に変化がなさそうです。
一日に何度かカナリアリリースを実施するフローにしたので、開発者は任意の時間でマージするようになることが想像されていたことでした。実際には、多くのメンバーは朝一番の便に乗車しているため、その点においては導入以前とさして変わりが無いように思われます。
なぜこのようなことになるのか分析はしきれていませんが、わざわざバラけさせるようなインセンティブ設計にはなっていないので、当然早めに仕事を片付けられる朝一番に集中するなという感想があります。
本番環境での不具合は発生しなくなる⇒そうとはいいきれない
カナリアリリースでいくつかの不具合は検知できるものの、全体の一部のトラフィックしか流れていないこともあり、全ユーザーに展開して初めて検出されるバグがあります。
また、アプリケーションの論理的な不具合による機能不全や画面崩れなどは、必ずしもカナリアリリースですべて検出できるわけではないので、全展開されてから発見されてロールバックする場合もありました。
カナリアリリースを根拠にしてデプロイ頻度を増やしましたが、一般にシステム障害の多くは変更により発生するため、これは不具合の発生リスクを上昇させます。障害検知率の上昇とのバランスが重要で、今のところは問題なさそうですが、注視していく必要があります。
難しいポイントのもう一点としては、カナリアリリースでのサンプル数があまりにも少なすぎると、確率的にバグを発生させるようなトラフィックが発生しないということです。この問題の改善のための手は、割合を増やすか期間を伸ばすことになります。しかし、割合を増やすとお客様への影響度が増加し、期間を伸ばすとデプロイサイクルが長くなっていくというトレードオフを考慮する必要があります。
このように、カナリアリリースを導入したからと言って、なんだかわからないけどみんなハッピーになって開発が爆速になるわけでもない、ということはよくわかりました。
カナリアリリースの成果はたしかにあり、やってよかったと胸を張って言えるものの、なんだか少々肩透かしに感じる面もありました。
| 項目 | 期待 | 結果 |
|---|---|---|
| デプロイ頻度 | 上がる | 上がった🎉 |
| リスク | 低減できる | できた🎉 |
| 試しやすさ | 良くなる | 良くなった🎉 |
| 不具合ゼロ | ？ | そうはいかない😐 |
| 開発リードタイム | 短縮する | 変化なし➡ |
| スループット | 向上する | 変化なし➡ |
| 衝突 | 減る | 減らない➡ |
わかったこと：期待しすぎず成果をみとめる
なんで期待どおりじゃないとがっかりしたのか？ということの原因を考えると、「期待しすぎてしまった」ということになるのではないかと感じます。「アジリティを向上する」というスローガンで考えていたときの「アジリティ」の意味合いが実はふんわりとした理解をしていて、多くの意味を含めてしまっていたと思うのです。
もちろん計画当初には、この項目は直接向上できる、この項目はそうでもない、といった想定はおいていて大体その通りになっていました。
いつの間にか、心のどこかで「きっと良くなるに違いない」という形のない理想が先行していたのです。
通常、デプロイメントの改善そのものは生産性を直接向上させるものではありません。そういったことを自覚的に運用しないと、改善施策を打てばみんながハッピーになるとつい考えてしまうことになるのだと思いました。
落ちついて考えてみると、ちゃんと予想通りのところの数値に反応があって成果は出ています。予想通りでないところも仮説が立っているので悪い状況ではありません。やったことの成果と課題として普通に受け止めればよかったのです。
当初あまり考えていなかったけれど、よかったこともいくつかあります。
例えば、静的コンテンツの変更を主に担当しているデザイナーさんや販促を企画しているメンバーもカナリアリリースの恩恵を受けられるようになったことです。それまで、静的コンテンツリリースはサイトのリリースと独立していたのですが、カナリアリリースを機にフローを整理して相乗りしてもらえるようになりました。これにより、個別に実施していた作業工数を削減できたことに加えて、静的コンテンツのリリース機会の増加や、サイトの開発メンバーにとっては変更の見える化などの効果がありました。
運用面の自動化がすすんだことも副作用的な成果でした。高頻度にリリースを実現するためには、週に1回時代は手動でやっていたデプロイのシステムの多くの部分を省力化する必要があります。自動化でリリースのオペレーションを行う担当メンバーの工数を削減できました。
チームの知見も増えました。サイトのリリースフローの改善にガッツリ取り組むことで、現状のデリバリーの課題やあるべき姿についての理解を深められて、今後の改善アイディアをどんどん出せるようになりました。
これからどうする
実際のところ、しっかりと成果は出ていました。部内からも良い声が聞こえています。
100人規模のエンジニア組織で DevOps Four Keys を導入し、アジリティー向上を目指した取り組み - MonotaRO Tech Blog でも触れられていますが、ものごとには先行指標と遅行指標があって、先行指標と考えている事柄には価値を出しつつあると考えています。
今後も、DevOps FourKeysを道しるべにしながら、手を打っていきたいと考えています。
組織全体の生産性向上にもソフトウェアデリバリーチームとして貢献していくつもりです。
例えば我々はCI/CDにJenkinsを利用していますが、この機能強化や安定性向上は重要なミッションです。GitHub Actions導入なども検討しています。
ビルド・デプロイメントのさらなる自動化やブランチ戦略の見直し、コンテナ化、システム再編、テスト戦略などやりたいことはまだまだ多くあります。
こういった施策によって、会社として本来やりたい機能開発がパワーアップしていき、よりよいサービスをつくれるようになれれば、デリバリーにフォーカスしたチームとしてのミッションを果たせているといえるようになるはずです。
最後になりますが、モノタロウではDevOps/SRE領域やソフトウェアデリバリーにおいて一緒に課題を倒してくれるメンバーを募集しています。開発生産性をガンガン上げていくことに興味がある方は、ぜひチェックしてみていただければと思います。
