デブサミ2022夏に登壇してきました! ――信頼性とアジリティを同時に上げろ!モノタロウのカナリアリリース導入

ソフトウェアデリバリーチームの市原です。先週、社内の有志メンバー3人でISUCONに参加してきました。私自身は初参加でした。結果は予選突破ならずでしたが、それなりに手ごたえもあり、学びも多くあり、何よりめちゃくちゃ楽しかったです。

さて、2022年7月21日にオンライン開催されたDevelopers Summit 2022 Summer(主催: 株式会社翔泳社 CodeZine編集部) で登壇してきましたので、ご紹介します。

発表内容について

モノタロウでは、サイト開発をレベルアップして信頼性とアジリティを両立させようという取組みを組織的にすすめています。 この活動の一環として、サイトのデプロイメントの仕組みにカナリアリリースを導入しました。 発表では、どういった経緯でカナリアリリースを導入したのか、導入してどのような変化が生まれたか、今後どのように改善を展開していきたいのかについて紹介しました。

資料

質問に回答します

有難いことに、発表中にチャットで多くのご質問をいただきました。あらためて回答させていただければと思います。 ※ その場で手元にメモしたので、網羅できていない可能性があります。悪しからずご了承ください。

Q プロジェクトの仕切り直しは、内部品質起因なのでしょうか?要件などの上流工程にも課題がありそうに思いました。

スライド P12~P16の内容についてのご質問ですね。

A ご指摘の通り、上流工程でも課題がある可能性があり、こちらについても社内では取り組みが進んでいます。内部品質の観点では、例えば要件定義が遅れたというような課題をさらに分解すると、我々が長年開発・運用しているシステムが複雑になっているため、現行仕様の把握が困難という問題が隠れています。要件を定義するための調査工数や、開発段階における手戻りが発生しやすい構造なのです。

長年メンテナンスしてきたシステムを把握可能なものにするためには、システムの内部品質改善は重要です。 今後のことを考えると、抜本的なシステム再設計などのメンテナンスしやすい・把握しやすい構造をつくりたいです。内部品質を整えておくことで、こういった飛躍的な打ち手をとるための下準備となるはずです。

全ての問題が内部品質に帰するわけではありませんが、内部品質の問題を改善することがより仕事しやすいシステムをつくることに貢献すると考えています。

Q 経過観察の日数は何日間くらいですか?

カナリアリリース導入を、経過観察しながら徐々に行ったということについてのご質問ですね。

A システムの完全移行には6週間かけました。また、リリース回数を増やすためにさらに4週間かけています。

これには二つの意図があります。

  1. 新たなシステムが問題ないことを十分に観察する
  2. リリースの仕組みを変更するため、開発者に慣れてもらった上で本移行する

2番については、仮移行期間中は徐々に参加するメンバーを増やしてもらって、チーム内にノウハウを持ち帰ってもらえるようにということも意図していました。徐々に移行を進めることで結果として認知負荷をかけずスムーズに移行できました。

Q デプロイの自動化は何かツールを使いましたか?

A モノタロウではJenkinsをCIやデプロイメントのツールとして利用しており、今回もJenkinsとスクリプトを組み合わせて実装しました。

※ Jenkins活用については、以下のブログ記事をご参照ください。

Jenkins Day Japan 2021に登壇させていただきました - MonotaRO Tech Blog

Q テストをすべて自動化することは、かなりテストコードの作成にも工数を要すると思いますが、それ以上にデプロイ頻度が多いのでメリットが出るという理解であっていますでしょうか?

テスト自動化についてのご質問ですね。

A ご指摘の通りです。テスト回数が増えれば増えるほど大きくなるものです。

そのためデプロイ頻度とそれに伴うテスト実行回数が増えると、非常に大きなメリットを享受できます。

ただし、テストの自動化のコストは、思ったよりも小さいものかもしれません。

スライド中でもご紹介したt_wada 氏の講演資料 質とスピード(2022春版、質疑応答用資料付き) / Quality and Speed 2022 Spring Edition - Speaker Deck では、内部品質投資の損益分岐点は1か月以内に現れるとあります。また、テスト自動化におけるコストは、テスト実行回数が4回を超える程度で回収できるのではないか、という話もあります。

このように、テスト自動化は予想以上の早さでメリットがコストを上回ると考えております。

モノタロウでも、実際にテスト自動化の計り知れない恩恵を受けており、今後も自動化をすすめていく方針です。

Q カナリアリリースの成功失敗の判定基準はどのようなものでしょうか?

A 安定版と比較して、新たなエラーが発生していないかを一つの基準としています。

残念ながら、現在はある程度目視での確認に頼っていますが、今後カナリア失敗時の自動通知・遮断を実装する予定で計画をすすめています。

感想

今回の講演では、社内の多くの方に助けていただきました。 特に、当社のテックブログ編集チームにはガッツリとバックアップ体制を敷いていただき、スライドのアウトライン作成から最終レビューまで全面サポートしてもらえました。 チームメンバーの伊藤さんには、何度も壁打ちに付き合ってもらいました。 また、社内で開いた発表練習には20名以上の方に参加してもらえて、発表内容やスライドの体裁についてたくさんのアドバイスをもらいました。

おかげで、当日はあまり緊張することもなく自信をもって発表することができました。

デブサミ当日は、想像していた以上に多くの方に聴いていただくことができました。 多くの質問もいただくことができて、社外にも同じような課題感を持って共感してくれる方がいたと分かったことも収穫でした。 全ては出られませんでしたが、デブサミの懇親会でも、開発生産性などについて意見交換できて大変有意義でした。

お聴きいただいた皆様、デブサミ運営の皆様、協力いただいた社内のみなさん、ありがとうございました。

エンジニアコミュニティに、一つの事例として情報を提供できたとすれば幸いです。

最後に

モノタロウでは、全方位で開発生産性向上に興味あるエンジニアを募集しています。 CICD、デプロイメント改善、カナリアリリース、IaC、テスト自動化、開発者体験向上、開発環境整備、などなど一緒に改善していきませんか?

興味あるかも?という方は、是非カジュアル面談や選考へのご応募を検討いただければと思います!

careers.monotaro.com

docs.google.com