こちらは「コドモン Advent Calendar 2025」20日目の記事です🎄
こんにちは、SREの三口です！私は今年の初めより、コドモンの各サービスにおけるSLI/SLOの策定に取り組んできました。PdMや開発チームの皆さんと連携しながら、この取り組みを進める中で気づいたこと、学んだことを今回まとめてみようと思います。
ちなみに、1歳5ヶ月になる娘はイヤイヤ期に突入し、エラーバジェットは常に消費、機嫌のSLOは永遠に満たせていません😭
SLIの指標選定と測定箇所
まず最初に考えたのは「何を指標にするか」と「どこで測定するか」という問題です。
指標の選定
SLIとしては、リクエスト成功率とレイテンシーの2つを採用しました。どちらもユーザー体験に直結する基本的な指標です。レイテンシーは平均値ではなくP95のパーセンタイル値を使用しています。
測定箇所の選定
弊社の各サービスは主に「ユーザーのブラウザ → CloudFront → ALB → APPサーバー」という構成になっています。それぞれの箇所で測定した場合の特徴を整理しました。
| 測定箇所 | 考慮点 |
|---|---|
| ユーザーのブラウザ | 環境依存が大きく、安定した測定が難しい |
| CloudFront / ALB単体 | 詳細な値（APIごとのレイテンシなど）が取りにくい |
| APPサーバー | ネットワークレベルの遅延やエラーを拾いきれない |
検討の結果、ALBとAPPサーバー上のAPI単位で測定する方針としました。ALBでシステム全体の健全性を把握しつつ、APIごとの詳細なデータで問題の切り分けができる体制を目指しています。
また、APIごとのSLOはHTTPメソッドも分けた状態で設定しています。例えば「GET /api/users」と「POST /api/users」は別々のSLOとして管理しています。これにより、問題が発生したときに「どのAPIで問題が起きているのか」を素早く特定できるようになっています。
APIレベルでの測定にはDatadog APMを使用しています。APMが入っていないサービスには、各開発チームと連携しながら導入を進めていきました。
開発チームへのヒアリング
APMの導入が完了し、いよいよSLI/SLOの策定に入ります。
最初は、各開発チームに対して「担当サービスの重要な機能や処理に関わるAPIを教えてください」とヒアリングを進めていきました。しかし、このアプローチではなかなかうまく進みませんでした。開発チームとの対話を重ねる中で気づいたのは、ユーザーにとって重要な機能や処理について詳しいのは、PdMだということでした。
もちろん、開発チームの皆さんも担当のサービスにおける重要な機能や処理について理解はされているものの、「ユースケースとしてどこがもっとも重要か」という点は、ビジネスサイドの観点も必要だったためです。
そこで、PdMに相談することにしました。
PdMとの連携でCUJを特定する
PdMとの連携により、各サービスのCUJ（Critical User Journey）を一緒に特定していくことができました。
例えば、あるサービスであれば「ログイン → 一覧表示 → 詳細確認 → 登録完了」というユーザージャーニーがあり、その中で「登録完了」の処理がもっとも重要である、といった形で整理していきました。
開発チームとSLI/SLOを策定する
PdMとCUJを特定した後、改めて開発チームにヒアリングを行いました。
今度は「この処理に関わるAPIはどれですか？」という具体的な形で聞くことができました。そのため、「この処理はこのAPIを呼んでいて、内部でこのAPIも呼ばれています」といった詳細な情報を共有してもらうことができました。
SLOの目標値については、リクエスト成功率は開発組織全体で99.9%と設定しました。一方、レイテンシーについては、開発チームの負担にならないよう、まずはSLO違反にならない水準で設定しています。最初から厳しい目標を設定するのではなく、運用しながら徐々に調整していく方針です。
SLI/SLOの見直し会
SLI/SLOは策定してからがスタートです。各チームと定期的に見直しを行う場を設けています。
見直し会では、以下のようなことを一緒に議論しています。
- レスポンスタイムの目標値の調整
- エラーバジェットを用いた運用への移行
- パフォーマンス改善のための取り組みの洗い出し
チームによって状況が異なるため、それぞれに合った運用を一緒に考えています。
例えば、数値が安定しているチームには「普段は見なくてもいいが、エラーバジェットの消費が進んだときに確認する」という軽めの運用を提案しました。
一方、まだ改善の余地があるチームには「まずは現状の数値をベースラインとして、これ以上悪化しないことを目指す」という形で、段階的に改善していくアプローチを一緒に検討しました。
各チームが前向きに取り組んでくれているおかげで、少しずつ運用が定着してきています。
この取り組みを通して得た気づき
ここまでSLI/SLOの策定プロセスを振り返ってきましたが、この取り組みを通して大きな気づきがありました。
そもそも私は、SLI/SLOはSREや開発チームが主に取り組んでいくべきものだと考えていました。しかし、実際に進めてみて感じたのは、SLI/SLOを運用していくためには、PdMやビジネスサイドの人たちにも理解してもらい、進めていくことが大事なんじゃないかということです。
なぜPdMを巻き込む必要があるのか
弊社においては、PdMがCUJをもっとも深く理解しており、その観点に基づいて開発の優先順位やリソース配分を判断しているためです。
各開発チームにはそれぞれPdMの方がいて、ビジネスサイドの要件やユーザー価値を考慮した上で開発の優先順位を決定しています。チーム全体で合意したロードマップに向かって走っている中で、開発チームのメンバーが単独の判断で、機能開発以外の部分に大きくリソースを割くことは現実的に難しい側面があります。
そんな状況で、突然SREが「SLI/SLOをやりましょう」と言っても、「今リソースがないです」となってしまうのは当然です。
だからこそ、PdMの方にSLI/SLOの意義を理解してもらうことが大切だと感じました。PdMの理解があることで、新規機能の開発だけでなく、既存サービスの改善にもリソースを割いてもらえるようになります。「既存サービスでレイテンシが悪くなってきているので、改善にリソースを割いてもらえないか」といった会話ができる関係性を作っていくことが重要だと感じています。
そのためのコミュニケーションや文化を作っていくのは、SREである自分たちの役割なのかなと感じています。
ビジネスサイドにわかりやすい指標を作りたい
もう一つ感じたのは、ビジネスサイドの方にもわかりやすい指標があるといい、ということです。
「リクエスト成功率」や「レイテンシー」は技術的な指標であり、ビジネスサイドの方には直感的に理解しづらい部分があります。例えば、これらの指標の低下が売上や契約継続率にどう影響するのかを示すことができれば、PdMの方もリソース配分を検討しやすくなるのではないかと考えています。
これはまだ構想段階ですが、今後取り組んでいきたいテーマです。
おわりに
今回のSLI/SLO策定は、多くの方々の協力があって実現できました。快くヒアリングに応じてくださったPdMのみなさん、APM導入やSLO策定に協力してくださった開発チームのみなさん、本当にありがとうございました。
新機能開発に安心して集中できる環境を作るためにも、引き続きサービスのオブザーバビリティを充実させていきたいと思います。SLI/SLOはその土台になるものだと考えています。
これからSLI/SLOの導入を検討している方の参考になれば幸いです！
