失敗しないSLO策定：New Relicを使った実践的アプローチ

はじめに

「SLOを設定したものの、誰も見ていない」「目標値が厳しすぎて常に達成できない」。こうした声を、現場でよく耳にします。

SLO（Service Level Objective）は、サービスの信頼性を測る重要な指標です。しかし、ただ数値を設定しただけでは形骸化してしまいます。重要なのは、ビジネス価値と直結した「意味のあるSLO」を作り、組織の意思決定に活かすことです。

この記事では、New Relicを使ったSLO策定の実践的なアプローチを紹介します。ユーザー視点での指標選定から、具体的な設定手順、運用での落とし穴まで、実務で役立つ知識をお届けします。

1. SLO策定前の準備：ユーザー視点で考える

SLO設定で最も重要なのは、技術的な指標ではなく「ユーザーにとって何が重要か」を起点に考えることです。

1.1 クリティカル・ユーザー・ジャーニーを特定する

まず、そのサービスでユーザーが絶対に失敗してはいけない体験を明確にします。これをクリティカル・ユーザー・ジャーニー（CUJ）と呼びます。

例えば、ECサイトなら「商品検索」よりも「カート追加」や「決済完了」の方が重要です。SNSなら「プロフィール閲覧」よりも「投稿の送信」が優先されます。

ここで大切なのは、エンジニアだけで決めないことです。プロダクトマネージャーやビジネス担当者を巻き込んで、「このサービスの核となる価値は何か」を議論しましょう。そうすることで、組織全体が納得できるSLOになります。

1.2 インフラ指標ではなくユーザー体験を測る

CPU使用率やメモリ使用量といったインフラ指標は、技術的には重要ですが、ユーザーには直接関係ありません。SLOでは、ユーザーが実際に体験する「成功率」や「応答速度」を測ることが基本です。

サービスレベルは、一定期間内にユーザーに提供されるサービスを、測定可能な形で表したものです。つまり、ユーザー視点での測定が前提になっています。

1.3 完璧を求めず、適切な目標を設定する

「99.99%」といった高い目標は理想的に見えますが、実現困難な目標は逆効果です。達成できない目標は、チームの士気を下げ、SLO自体が無視されるようになります。

現在のパフォーマンスを基準に、少し背伸びすれば届く程度の目標が適切です。最初は「99%」から始めて、安定してきたら「99.5%」に引き上げるという段階的なアプローチが現実的でしょう。

2. New RelicでのSLI作成：最初の一歩

準備ができたら、実際にNew RelicでSLI（Service Level Indicator、サービスレベル指標）を作成していきます。

2.1 Service Levels UIにアクセスする

New Relicにログインしたら、左側のメニューから「Service levels」を選択します。ここがSLO管理の中心となる場所です。

初めての場合は空の画面が表示されますが、右上の「+ Add service level objective」ボタンから新規作成を始められます。

2.2 測定対象のエンティティを選択する

New Relicでは、SLOを設定する対象を「エンティティ」と呼びます。エンティティには以下のようなものがあります。

APMサービスは、バックエンドAPIやアプリケーションを監視する場合に選択します。Browserアプリケーションは、フロントエンドのユーザー体験を測定したい場合に使います。Synthetic Monitorは、外形監視で可用性をチェックする際に選びます。

まずは、ビジネスインパクトが最も大きいサービス一つに絞って始めることをお勧めします。

2.3 推奨SLIを活用する

New Relicには便利な機能があります。APMサービスやBrowserアプリケーションを選択すると、New Relicが最新のデータを分析して、そのエンティティタイプに適したSLIとクエリを提案してくれます。

これにより、以下の2つのSLIが自動的に提案されます。

Success SLI（成功率）は、エラーなしで完了したリクエストの割合を測定します。Latency SLI（応答速度）は、指定した時間内に完了したリクエストの割合を測定します。

初めての場合は、この推奨SLI機能を使うのが最も簡単で確実です。提案されたクエリをそのまま使うこともできますし、必要に応じてカスタマイズすることもできます。約10分でデータが表示され始めます。

2.4 カスタムSLIで細かく調整する

自動作成されたSLIをベースに、より詳細な設定が必要な場合は、カスタムSLIを作成できます。

例えば、ヘルスチェックのリクエストを除外したい場合や、特定のエラーコードだけを「失敗」とカウントしたい場合などです。New RelicではNRQLというクエリ言語を使って、柔軟にSLIを定義できます。

ただし、最初は標準的な設定で始めて、運用しながら調整していく方が失敗が少ないでしょう。

3. SLO目標値の設定：現実的な基準を作る

SLIが定義できたら、次はSLO（目標値）を設定します。

3.1 現在のパフォーマンスから逆算する

目標値は、理想から決めるのではなく、現状から決めるのが鉄則です。

New Relicのプレビュー機能を使うと、過去数日間の実際の達成率が表示されます。例えば、過去7日間の平均が98.5%だったなら、目標を99%に設定するのは現実的ですが、99.9%は厳しすぎるかもしれません。

ユーザーが現在の体験に満足しているなら、SLO目標値を現在のベースラインに合わせて設定するのが妥当です。そこから少しずつ改善していく方が、チームにとっても無理のないアプローチになります。

3.2 期間の選択：ローリングウィンドウを理解する

SLOには「どの期間で測定するか」という設定があります。New Relicでは、1日、7日、14日、28日、30日のローリングウィンドウをサポートしています。

ローリングウィンドウとは、常に「直近N日間」を計算する方式です。例えば28日間のウィンドウなら、毎日、過去28日分のデータで達成率を計算し続けます。

一般的には28日間を選ぶことが多いです。これにより、週末の影響を含めた安定した評価ができます。短期的な変動を素早く検知したい場合は7日間、より長期的な傾向を見たい場合は30日間を選ぶこともあります。

3.3 エラーバジェットの概念を理解する

SLOを設定すると、New Relicは自動的に「エラーバジェット」を計算してくれます。

エラーバジェットとは、「目標を達成しつつ、あと何回失敗できるか」を示す指標です。例えば、99%のSLOを設定した場合、1%分は失敗しても許容されます。これがエラーバジェットです。

New Relicでは、残りのエラーバジェットがパーセンテージで表示されます。25%以上なら緑色で「余裕あり」、25%未満なら黄色で「注意」、0%なら赤色で「予算使い切り」という状態です。

このエラーバジェットが、次に説明する意思決定の重要な基準になります。

4. アラート設定：予算切れを防ぐ仕組み

SLOを作っただけでは不十分です。エラーバジェットが枯渇しそうになったら、すぐに気づける仕組みが必要です。

4.1 Burn Rate Alertの概念

New Relicでは、「Burn Rate Alert」という特別なアラート機能を提供しています。これは、「今のペースでエラーが続くと、期間終了前にバジェットを使い切ってしまう」というタイミングで通知してくれるアラートです。

通常のアラートが「閾値を超えたら通知」なのに対し、Burn Rate Alertは「使い切るペース」を監視します。この違いが重要です。

4.2 Fast-burn と Slow-burn の使い分け

New Relicでは、2種類のBurn Rate Alertを推奨しています。

Fast-burn Alert（高速消費アラート）は、急激な問題を検知します。例えば、「1時間でバジェットの2%を消費した場合」に通知します。このペースだと50時間でバジェットを使い切ってしまうため、緊急対応が必要です。

Slow-burn Alert（低速消費アラート）は、緩やかな劣化を検知します。例えば、「6時間でバジェットの5%を消費した場合」に通知します。このペースだと5日間でバジェットを使い切るため、計画的な対応が必要です。

両方を設定することで、急な障害と緩やかな品質低下の両方に対応できます。

4.3 通知先の設定

アラートは、適切な人に適切なタイミングで届かなければ意味がありません。

New Relicでは、Slack、PagerDuty、ServiceNow、JIRAなど、様々なツールと連携できます。Fast-burn Alertは緊急性が高いのでPagerDutyなどのオンコール連絡先に、Slow-burn Alertは計画的な対応が可能なのでSlackやJIRAに送るといった使い分けが効果的です。

重要なのは、アラートを受け取った人が「何をすべきか」を明確にしておくことです。単に通知するだけでなく、対応手順やエスカレーションルールも合わせて整備しましょう。

5. 運用フェーズ：SLOを組織に定着させる

SLOは作って終わりではありません。組織全体で活用し、継続的に改善していくことが重要です。

5.1 ダッシュボードへの統合

SLOは、チーム全員が毎日見る場所に配置すべきです。

New Relicでは、SLOの状態をカスタムダッシュボードに追加できます。朝会で使うダッシュボードの最上部にSLOチャートを配置すれば、自然と全員の目に入ります。

エラーバジェットの残量が一目で分かるようにすることで、「今週は攻めのリリースができる」「今は安定化を優先すべき」といった判断が、データに基づいてできるようになります。

5.2 意思決定ルールの確立

SLOの真価は、意思決定に活用されて初めて発揮されます。

例えば、こんなルールを設定します。「エラーバジェットが50%以上残っている場合は、新機能のリリースを積極的に進める」「エラーバジェットが25%を切った場合は、新規開発を一時停止し、信頼性向上の作業を優先する」「エラーバジェットが0%になった場合は、緊急対応モードに入り、すべてのリソースを安定化に投入する」

このルールをプロダクトオーナーや経営陣と合意しておくことで、エンジニアが自信を持って判断できます。

5.3 定期的なレビューとSLOの見直し

SLOは一度設定したら終わりではありません。定期的に見直しが必要です。

月に一度、SLOレビュー会議を開くことをお勧めします。そこで以下のような問いかけをします。

このSLOは達成できていたか。達成できなかった場合、原因は何か。達成できていたのにユーザーから不満が出た場合、SLI自体が間違っている可能性はないか。逆に、目標が緩すぎて常に100%達成している場合、もう少し厳しくすべきか。

SLOが100%達成されている状態が続く場合は、目標が安全すぎると考えられます。適度な緊張感を保てる目標設定が理想です。

5.4 小さく始めて徐々に拡大する

最初から全サービスにSLOを設定しようとすると、たいてい失敗します。

まずは最も重要なサービス一つに絞って、Success SLI（成功率）だけを設定することから始めましょう。3ヶ月ほど運用して、チームがエラーバジェットに基づく意思決定に慣れてきたら、Latency SLI（応答速度）を追加したり、他のサービスにも展開したりします。

段階的なアプローチが、組織への定着につながります。

まとめ

この記事では、New Relicを使ったSLO策定の実践的なアプローチを紹介しました。

SLO策定の第一歩は、ユーザー視点でクリティカル・ユーザー・ジャーニーを特定することです。インフラ指標ではなく、ユーザーが実際に体験する成功率や応答速度を測定します。

New RelicのService Levels機能を使えば、ベースラインSLOの自動作成から始められます。目標値は理想ではなく現状から逆算し、28日間のローリングウィンドウで測定するのが一般的です。

エラーバジェットという概念を理解し、Burn Rate Alertを設定することで、予算切れを未然に防げます。Fast-burnとSlow-burnの両方を設定し、急な障害と緩やかな劣化の両方に備えましょう。

そして最も重要なのは、SLOを組織の意思決定に活用することです。ダッシュボードに統合し、エラーバジェットに基づく意思決定ルールを確立し、定期的に見直すことで、SLOは形骸化せず、本当に価値のあるツールになります。

完璧なSLOを最初から作ろうとせず、小さく始めて徐々に拡大していく。このアプローチが、失敗しないSLO策定の秘訣です。まずは一つのサービスで、Success SLIだけを設定することから始めてみませんか。

この記事がどなたかのお役に立てれば幸いです。