🌟

Accelerate EventHub

4 min read

この記事は EventHub Advent Calendar 2021 11 日目の記事です。
昨日は yutanakano さんの中野で食べたいランチベスト3でした。

はじめに

EventHub に先月(2021 年 11 月)入社した、ソフトウェアエンジニアの原です。
趣味は Podcast を聞くことで、最近のお気に入りは Pod de Engineerもう一度読む SRE、殿堂入り級に好きなのが texta.fmです。よろしくお願いします。

Lean と DevOps の科学(Accelerate)

今回は 「Lean と DevOps の科学」 (原題: Accelerate) をテーマでお話します。
「Lean と DevOps の科学」は、規模や業界を問わない多数の開発組織を対象にした学術的な調査をもとに、ソフトウェアのデリバリーや組織のパフォーマンスを向上させるためには、どんな取り組みが効果的か、「科学的に」検証した本です。
t_wada さんの講演 (質とスピード) をはじめ、多くの講演やブログ記事で紹介されているため、ご存知の方も多いかもしれません。
私は texta.fm の第 5 回 でこの本を知りました。
ちなみにこの texta.fm の第 5 回は超神回で、20 回以上リピートして聴いているくらい面白いです。
この Podcast を聞くだけで、プロダクトと開発組織に何が必要なのかが分かり、聞き終わる頃にはこの本を手に取りたくなっていることでしょう。

4 つのキーメトリクス

「Lean と DevOps の科学」では開発組織のパフォーマンスを可視化するための指標として以下の4つを挙げています。

リードタイム

機能を開発してからデプロイされてユーザーに価値を届けられるまでの時間です。
当然、リードタイムは短いほうがいいです。

デプロイ頻度

文字通りサービスがデプロイされる頻度です。
デプロイ頻度 = デプロイ回数 ÷ 開発者 ÷ 日数 で数値化できます。
デプロイ頻度は高い方がよく、パフォーマンスが高い組織では人数が増加するほどデプロイ頻度が高まるそうです。
これは個人的には驚きで、人数が増え組織が大きくなったらその分コミュニケーションコストが増加するので、良くてもデプロイ頻度を維持できるくらいだと思っていましたが、逆に高まるというのは衝撃でした。

MTTR

Mean Time To Repairの頭文字で、日本語だと「平均修復時間」と呼ばれたりします。
障害発生から修復までの時間なので、短いほうがいいです。

変更失敗率

システムへの変更(デプロイやインフラの構成変更)をきっかけに障害が発生した割合です。
当然、変更失敗率は低いほうがいいです。

EventHub の現在

では、上記の 4 つのメトリクスを EventHub の現状と照らし合わせてみます。

リードタイム

リードタイムが短くなるような取り組みとして、feature toggleを用いた開発が行われています。
feature toggle とは大きめな機能を開発する際に、すべての機能が揃ってから master ブランチにマージするのではなく、本番ではユーザーが機能を触れないように制御しながら、より小さい単位でマージするという取り組みです。
これにより、レビューの負荷が低下して短期間でマージできるようになります。
本の中で書かれている「トランクベースの開発」のように、1 日未満でマージするとまではいきませんが、作業ブランチが長期間マージされないという状況は避けられています。

デプロイ頻度

緊急対応を除くと、週に 1 度の定期リリースになっています。
毎週ある曜日に、前日にコードフリーズした master ブランチを QA 環境にデプロイし、一週間かけてパートナー企業に QA 検証を依頼します。
それと同時に前の週に QA 環境にデプロイしたものを本番環境にデプロイするというフローです。

このフローのメリットとして

  • しっかり QA 検証された状態でデプロイされる
  • デプロイが週1だと、最新のリリース内容をビジネスメンバー含めて理解しやすい

といった点が考えられます。

しかし、このままではエンジニアが増えれば増えるだけ、エンジニア一人あたりのデプロイ頻度は下がり続けてしまい、健全な状態とは言えません。

MTTR

まだ入社して間もないため正確には把握できていません。
MTTR の短縮に効果がありそうな取り組みとしては、ユーザーに与える不具合の深刻度によってエラーレベルを設定し、どのように対応していくか定義できており、障害が発生したら素早く意思決定して動く準備は出来ていると思います。
しかし、監視体制がまだ整っているとは言えず、潜在的なエラーを見過ごしている可能性があります。
また CI/CD に時間がかかりすぎていて、そこは改善の余地があります。

変更失敗率

こちらもまだ正確には把握できていませんが、デプロイ頻度の項で述べたような堅い QA プロセスを踏んでいるため変更失敗のリスクは軽減できているのではないかと思います。
また、Production Readiness Checklist を作成していて、リリース前に毎回チェックを満たしているか確認するという取り組みも行っています。

着目すべきメトリクス

ここまで「Lean と DevOps の科学」の 4 つのキーメトリスと、EventHub の現状を照らし合わせてきましたが、一番気になる項目はデプロイ頻度ではないでしょうか。
texta.fm でも紹介されていた NewsPicks さんの取り組みでもあったように、デプロイ頻度は他のメトリクスより計測しやすいです。
またパフォーマンスが高い組織はどのメトリクスの指標が高いため、どれか一点に着目すると割り切っても十分な効果がありそうです。

https://speakerdeck.com/uzabasetech/18-e-5-uzabase-gao-shan-wen-debusamideng-tan-zi-liao?slide=28

考えてみれば当然な気がしますが、デプロイ頻度だけ上がったものの、障害が毎回発生してしまうという状況は許容されないはずで、デプロイ頻度を高めるためにはそれと同時にリスクを最小限にするための力学が働き、結果的に全メトリクスが改善されるようになるはずです。

Accelerate EventHub

ということで、EventHub でもデプロイ頻度を高められる体制にできたらと思ってます。
現状の週一デプロイになっているのには先に述べたようなメリットもあり、開発だけでなく全社的に関わるので、一朝一夕に改善できるものではないですが、開発組織内でできる改善点は多くありそうです。

  • CI/CD の時間削減

    • 並列実行や依存関係の見直し、Docker build の効率化など
  • 影響範囲を狭めたリリース

    • カナリアリリースでリクエストの一部だけ新バージョンに向ける
  • 問題があったらすぐに戻せる体制

    • Blue/Green デプロイの導入

などが効果的な施策になりそうです。
こうした取り組みでデプロイが速く・安心にできるようになれば、デプロイ容易性が高まり、結果的にデプロイ頻度の改善に繋がると思います。

すでにこれらの課題に対して、外部のプロフェッショナルな SRE チームをパートナーに迎えてアドバイスを頂きながら、取り組みを開始しています。

ということで、加熱するイベントプラットフォーム市場で EventHub をさらに加速させる取り組みを一緒にしたいエンジニアを大募集しています !

https://jobs.eventhub.co.jp/

明日は CTO の井関さんです!

Discussion

ログインするとコメントできます