本記事はNew Relic Advent Calendar 2023の25日目の記事となります。
はじめに
こんにちは。はたらこねっとのユーザー向けサイトのバックエンドエンジニアをしている大塚です。
はたらこねっとではサービスのモニタリングなどにNew Relicを活用しています。
New Relic にはアプリケーションのモニタリング以外にも様々な機能が用意されています。
その中でも「Service Levels」の機能を使ったSLI/SLOの策定と設定を行っているので、そちらについてご紹介させて頂きます。
なお、細かい操作方法などは本記事では触れません。
本記事で登場する用語について
クリティカル ユーザー ジャーニー（CUJ）
ユーザーがサービスを利用する際の重要な経路やプロセスを表したものです。
サービスレベル指標（SLI）
サービスレベルを測定するための具体的な指標です。サービスの品質や性能を評価するための重要な指標で、サービスが期待どおりに機能しているか、改善が必要かなどを特定することができるものです。
サービスレベル目標（SLO）
サービスレベル指標を達成するための目標値です。サービスの品質を維持し、ユーザーの満足度を維持するための重要な基準となるものです。
背景
まず、New Relicを用いてSLI/SLOを設定した背景についてです。
弊社ではNew Relicを用いてログ監視やインフラのメトリクス監視を行っております。
ただ、従来のログ監視やインフラのメトリクス監視では、アプリケーションの動作にフォーカスした監視になり、ユーザーがどのような影響を受けているのかなどが考慮出来てませんでした。
New Relicではアプリケーションの動作やユーザーへの影響を観測する機能が充実しています。 New Relicの活用するにつれてユーザーへの影響を観測することの重要性を再認識したため、SLI/SLOを設定することになりました。
CUJの策定
CUJを検討するにあたっては、企画サイドのメンバーに対して「よりサービスのコアの部分の分析をしたいので、ユーザーから見たサービスに求めるものも検討したい」と伝え、協力して検討を進めました。 そうすることで、エンジニア目線だけではなく、ビジネスサイドの考えも考慮しながらCUJの策定を進めることが出来ました。
はたらこねっとは求人サイトになるので、求人に応募することをゴールと考え、そのゴールに至るまでのユーザーのアクションをCUJとして定義しました。
策定したCUJはこちらです。
SLIの策定
策定したCUJをもとにSLIを定義していきます。
SLIについては、何を見ればユーザーが求める動作を達成しているか判断できるかという部分をベースに、New Relicで計測しているさまざまな指標を見ながら検討しました。
策定する際に、CUJで設定した言葉だけで考えると失敗することがあるので、アプリケーションの設計や実装も把握した上で検討する必要があります。
ここで私の失敗を1つご紹介します。
「仕事を探す」というCUJに対して、「仕事が探せる=仕事検索画面」の指標を見れば良いのではないか安直に考えてしまいました。
しかし、仕事検索画面の指標では、仕事検索画面から実行される「仕事を検索する」と言うアクションについての考慮が出来ていませんでした。
こういったことがあるので、CUJとそれを達成するためのサービスの設計や実装を考慮しなければ、意味のない指標となってしまいます。
最終的には、仕事検索画面で検索を実行し、「検索した条件で仕事一覧が表示されること」をみるのが「仕事を探す」ことのSLIになるのではないかと結論付け、こちらを画面の指標をSLIとしました。
可用性
対象の画面の500のレスポンスコードの割合をSLIとしました。
レイテンシ
レイテンシは、有効なリクエストのうち、ユーザーにとって良好な体験として設定された閾値よりも早く処理された割合を測定する指標です。
New Relicのドキュメントでは、下記のようなNRQLを使用し算出することを推奨しています。
SELECT percentile(duration, 95) FROM Transaction WHERE entityGuid = '{entityGuid}' since 7 days ago limit max
様々な検討の末、「仕事を探す」というCUJに対して策定したSLIはこちらです。
| 名称 | SLIの定義 | SLIの実装 |
|---|---|---|
| 仕事一覧画面の可用性 | Job/JoblistController@list へのリクエストに対する全てのレスポンスのうちHTTPレスポンスコードが500以外を返すものの割合 | New RelicのTransactionsからhttpResponseCodeを特定する |
| 仕事一覧画面のレイテンシ | Job/JoblistController@list へのリクエストに対する全てのレスポンスのうちレスポンスタイムが〇〇s以下のものの割合 | New RelicのTransactionsからdurationを値を計測する |
SLOの策定
SLIの目標値であるSLOを定義していきます。
目標値は過去の実績の数値とサービスに対してのユーザーからの問い合わせ数とビジネス目標の達成度を考慮しました。
| 名称 | SLOの定義 | SLOの根拠 |
|---|---|---|
| 仕事一覧画面の可用性 | 過去28日間のJob/JoblistController@list へのリクエストに対する全てのレスポンスのうち、〇〇%のHTTPレスポンスコードが500以外を返さなければならない | 過去に〇〇%であれば、不具合の報告がなく、ビジネス目標を達成出来たため |
| 仕事一覧画面のレイテンシ | 過去28日間のJob/JoblistController@list へのリクエストに対する全てのレスポンスのうち、〇〇%のレスポンスタイムが〇〇s以下でなければならない | 過去に〇〇%であれば、不具合の報告がなく、ビジネス目標を達成出来たため |
New RelicでのSLI/SLOの設定
それでは策定したSLI/SLOをNew Relicに設定していきます。
設定手順についてはNew Relicのドキュメントに詳しく記載があるので省きます。
https://docs.newrelic.com/jp/docs/service-level-management/create-slm/
一部黒塗りになってますが、実際に作成したSLI/SLOがこちらです。
「Key Transactions」という機能で仕事一覧画面のトランザクションをまとめているので、仕事一覧画面のSLI/SLOも一緒に確認することができます。
また、Nameがリンクになっているので、そちらをクリックするとより詳細なSLIの推移とエラーバジェットの数値を確認することが出来ます。
今後の展望
今回SLIとSLOを設定してみましたが、これらを用いていきなりエラーバジェットやバーンダウンレートの変化を観測し、それをもとに優先度の入れ替えのような動きを行うことは考えていません。
まずはエンジニア組織内でSLI/SLOと言う指標への理解を進め、それらの価値をエンジニアが見出していく必要があると感じています。
エンジニア組織でSLI/SLOの定期的な観測と、変動に対するアクションが取れるようになってから、企画サイドのメンバーと協力して優先度の入れ替えなどの本来想定されている動き方をしていけると良いと思っています。
まとめ
SLIとSLOをNew Relicを用いて策定し、可視化をしてみました。
策定にあたってはサービスのビジネス的な観点であったり、実装や仕様をしっかりと把握する必要がありますが、数値の可視化や設定はNew Relic上で簡単に設定をすることができます。
昨今サービスレベル（サービスの信頼性）などについての重要性が高まってきているので、New Relicを用いてサービスレベルの監視を始めてみてはいかがでしょうか。
