Production load testing as a guardrail for SLOsの意訳
Qiita Advent Calendar 2025の海外SRE関連セッション意訳の9日目です。ひとりアドベントカレンダーですが、完走できるように頑張ります。
このアドベントカレンダーでは、海外のSRE関連のセッションを翻訳しながら、私の意見や疑問や補足を追加したものです。私の誤解から誤った説明になっている箇所は、コメントでご指摘お願いします。
前回は、Corporate Open Source Anti-Patterns: A Decade Laterの意訳でした。OSSを持つ企業が陥りがちなアンチパターンを社会契約という側面で話をしました。
このアドベントカレンダーでは、私の意見やコメントは可能な限り、下記の記法で要約と区別します。ただ、そこまで厳密にできないため、要約文中に私の思想が混じってしまうことはご容赦ください。(気がついたらご指摘ください)
紹介するセッションについて
セッション詳細:Production load testing as a guardrail for SLOs | SLOconf 2021
今回のセッションは、本番環境での負荷試験についてです。セッション中にも出ていますが、SLO-driven load testing in productionという単語が非常に新鮮に感じました。
要約
背景：複雑で頻繁に変わる本番環境
私が支援した新しいSREチームが扱ったシステムは、現代的である一方、サードパーティ連携やレガシー要件も混在した非常に複雑なものだった。開発チームは高速なデリバリー文化を持っており、頻繁な本番リリースが当たり前。そのぶん、スタック全体が不安定になりやすく、オンコール疲労が慢性的に発生していた。
最も深刻だったのは、「メトリクスは取れているのに、ユーザー体験がどう悪化しているのかが誰にも分からない」という状態だった。CPUやメモリが逼迫しているのは分かる。しかし、それがユーザーの体験にどんな影響を与えているのか、どのエンドポイントが本当に問題なのかが見えない。結果として、深夜に鳴るアラートの多くは「実際にはユーザー影響のないノイズ」だった。
SLOの導入で“何を重要とするか”を取り戻す
そこで導入したのがSLOだった。まずはユーザー体験のSLOを定義し、それをサービスやコンポーネントに落とし込んでいく。
たとえば以前は「サービスXのコンテナが15分で10回再起動した」というだけでアラートが鳴っていた。しかし、SLOを導入してユーザー影響を基準にアラートを再設計すると、「再起動してもSLO上は問題なし」という状況が可視化され、不要なアラートは消えていった。深夜に起きる必要がなくなり、翌朝に確認すればいい場面が増えた。本当に重要なものだけに集中できるようになったのである。
しかし、そこに至るまでが最も大変だった。
SLOの理解を開発・プロダクト・経営陣すべてに広め、メトリクス品質を改善し、レビュー文化を根付かせる——技術的にも社会的にも巨大な取り組みだった。
SLOだけでは終わらない：「進化」をどう導くか
SLOを定義し、チームに浸透させ、運用の仕組みも整った。では次に何をすべきか？
ここで生まれた疑問が 「複雑なシステムが時間とともに進化していくとき、その進化をどう導くか？」 だった。
私はここで、進化的アーキテクチャの概念である 適応度関数(fitness function) に出会う。
ソフトウェアにも望ましい進化の方向性を示す関数があってよい。ではSLOにおける適応度関数とは何か？
彼らの答えはこうだった。
パフォーマンス関連のSLOに対する適応度関数として、本番環境での負荷試験を使う
Load test in prod:なぜ本番なのか？
本番で負荷試験を行うという発想は、多くの組織でタブー視される。しかし私の主張は明確だ。
- システムは必ず劣化し、ゆっくりとSLOから外れていく
- 大きな障害を招く前に意図的に小さなストレスを与えて、問題を前倒しした方が安全
- エラーバジェットは危険を伴う変更に使う資産でもあり、負荷試験に使うことも合理的
- これは「小さなショックで適応することで大きなショックに耐える」という反脆弱性の概念にも合致する
つまり、負荷試験は破壊行為ではなく、将来の大障害からSLOを守るためのガードレールとして働く。
「ユニットテストやE2Eテストなど、Shift left(前工程での実施)が適切」とされる世界でも、負荷試験は例外で、本番でなければ見えない現象があまりにも多い。だからこそ、これはカオステスティングにも近いアプローチになる。
小さく始める：SLOドリブン本番負荷試験
彼らはリスクを最小にしながら、次のように始めた。
- 毎週1回だけ、本番で負荷試験を実行
- 過去7日間のピークトラフィックを25%上回るレベルまで負荷をかける
- 手動の事前調整は一切行わない
- SLOのエラーバジェットをX%以上は消費しないように制御
- 試験は30秒以内に停止可能にする
さらに、最も高レベルのSLOに影響しうるエンドポイントから順に試験した。
結果は驚くべきものだった。
- 多くのケースで、負荷を高めてもSLOは問題なく保たれた
- システムが大きく変化しても、まだ安全マージンが残っていることが確認できた
- 他チームから「自分たちもこの負荷試験を行いたい」という相談が来た
- 私は言った。「では、まずSLOを定義しましょう」
→ そして組織全体でSLO採用が加速した
本番負荷試験は、新たな障害を誘発するのではなく、組織が信頼性を向上させる文化を促進する装置になったのだ。
結論：適応度関数としての本番負荷試験
最後にまとめとして、
- SLOを設定したら、それを守るために安全マージンを作る必要がある
- 適応度関数という概念はそのために非常に強力
- 本番環境での負荷試験は、SLOの適応度を測る優れた関数になりうる
- 大事なのは「まず始めること」。小さく、慎重に、しかし確実に
本番での負荷試験は怖い。しかし、複雑なシステムにとっては、SLOを未来まで守るための最も現実的で強力な手段なのだと、このセッションは静かに説得してくれる。
全体を通してコメント
Load testing in prodについては私が個人的にとても興味があることでもあり、SRE NEXT 2025ではAbemaさんの事例セッションを聞き、その後話をし、さらについ先日も改めて会って話にいった程度に興味があるトピックです。
このセッションは2021年のものですが、私のさらに先をずいぶん遠くまで行っていて、本番環境負荷試験をあるチームで初めて、
その取り組みを真似たい他チームにSLOをさらに導入して、というループになっていた点は非常に参考になりました。
次回は、99.99% of Your Traces Are (Probably) Trashの意訳というトレーシングデータのサンプリング戦略についてのセッションです。
Discussion