はじめに
サービスの品質を維持しつつ、ユーザー体験を向上させるにはどうすれば良いのでしょうか？
その課題に取り組むため、今回は New Relic の SLM ( Service Level Management ) を使って、サービスのパフォーマンスを可視化してみました。
しかし、SLI ( 指標 ) や SLO ( 目標値 ) をどのように決めるべきか、まず何から始めるべきか迷う方も多いのではないでしょうか。
この記事では、SLI / SLO の定義から、New Relic を使った計測・可視化まで、実際にやってみた手順を紹介します。
※ 本記事は、2024年11月時点の情報から作成しています。
SLI / SLO を定義し、New Relic で可視化する手順
今回は例として、オープンソースの EC サイト構築プラットフォームである EC-CUBE を利用した検証環境を用意しました。
この通販サイトをサービスと仮定し、SLI / SLO の定義から New Relic による計測・可視化まで、実際に設定を行ってみました。
1. ユーザージャーニーの確認
ユーザージャーニー = ユーザーがサービスを利⽤する際の⼀連の動作です。
- トップページ
- 商品ページ
- カートページ
- 購入ページ
- 購入完了ページ
2. アーキテクチャの確認
サービスを提供するシステムの構成要素を確認します。
3. SLI を策定する
ユーザージャーニーを元に、SLI として重要と考えられるものを以下2つとしてみました。
①トップページのページ表⽰速度が2秒以内である割合
②注⽂確定のトランザクションのHTTPレスポンスコードが2XXまたは3XXである割合
「SLIはいくつ設定すればいいの？」と思う方もいるかもしれませんが、数に制限はありません。
サービスにとって重要な指標であれば、その分だけ定義して問題ありません。
SLI を決定したときに考慮したポイント
- サービスを利用するユーザーが期待しているようなことを指標とする。
- 流入元であるユーザージャーニーの始点ページの表示速度や、終点での処理は機会損失につながりやすいため、これらを指標に含めてみる。
- Google が提唱する測定データの種類から決定してみる。
- Google が提唱する Core Web Vitals に準拠できるよう決定してみる。 ( https://web.dev/i18n/ja/vitals/ )
- Largest Contentful Paint ( LCP ) – 最大視覚コンテンツの表示時間
読み込みのパフォーマンスを測定するための指標です。優れたユーザーエクスペリエンスを提供するためには、ページの読み込みが開始されてからの LCP を 2.5 秒以内にする必要があります。 - Interaction to Next Paint ( INP ) – 次の描画までのインタラクション時間
インタラクティブ性を測定するための指標です。優れたユーザーエクスペリエンスを提供するには、ページの INP を 200 ミリ秒未満にする必要があります。 - Cumulative Layout Shift ( CLS ) – 累積レイアウトシフト
視覚的な安定性を測定するための指標です。優れたユーザーエクスペリエンスを提供するためには、ページの CLS を 0.1 以下に維持する必要があります。
- Largest Contentful Paint ( LCP ) – 最大視覚コンテンツの表示時間
また、New Relic が SLI の候補として挙げている以下の指標も参考にしてみましょう。
| サービスの種類 | SLIの種類 | 説明 |
|---|---|---|
| リクエスト レイテンシー |
可用性(Availability) | 正常に応答したリクエストの比率 |
| 遅延(Latency) | しきい値より早く応答したリクエストの比率 | |
| 品質(Quality) | 特定の品質を満たしたリクエストの比率 | |
| データ処理 | 新鮮さ(Freshness) | ある特定の時間を閾値にして、それより最近に更新されたデータ比率 |
| 正確性 (Correctness) | 正しい値の出力につながったデータ処理への入力レコードの比率 | |
| カバレッジ (Coverage) | バッチ:ターゲット量以上のデータを処理したジョブの比率 ストリーム処理:ある時間ウィンドウ内に処理に成功した入力レコードの比率 |
|
| ストレージ | Durability(耐久性) | 書き込みレコードのうち、正常に読み出せるものの比率 |
4. SLI 計測⼿法の決定
| NewRelic機能 | 取得対象データ |
|---|---|
| Browser | ショップサイトの実ユーザーのブラウザから取得したサイト稼働情報 |
| Synthetics | ショップサイトの外形監視 |
| Infrastructure | ショップサイトを稼働させているサーバーのインフラリソース情報 |
| APM | ショップサイトのサーバーサイドから取得したアプリケーション稼働情報 |
上記データは上からユーザーとの距離が近い順にリストしてみました。
一般的にはユーザーに近い指標が望ましいですが、今回は下記のように選定してみました。
| SLI | NewRelic機能 | 対象データ |
|---|---|---|
| ①トップページのページ表⽰速度が2秒以内である割合 | Browser | ウェブページ：https://xxxxxxx/ |
| ②注⽂確定のトランザクションのHTTPレスポンスコードが2XXまたは3XXである割合 | APM | トランザクション：/shopping_checkout EC-CUBEの決済処理のnameがshopping_checkoutであることを確認 https://zenn.dev/ta_toshio/books/d7332514b60346/viewer/a841df |
5. SLI 計測のためのエージェント導入
計測に必要な New Relic エージェントを導入します。
- Browser Agent
- Apache Integration
- PHP Agent
6. New Relic で SLI を計測する
エージェントが導入できれば、あとは New Relic 側での NRQL 作成のみで割合を計測可能となります。
まず、SLI を可視化できるかの確認のため、過去30日間の時系列データとして表示してみましょう。
■トップページのページ表⽰速度が2秒以内である割合（Browser）
SELECT percentage(count(*), WHERE duration <= 2) FROM PageView WHERE pageUrl = 'https://xxxxxxx/' SINCE 30 day ago TIMESERIES
■注⽂確定のトランザクションのHTTPレスポンスコードが2XXまたは3XXである割合（APM）
SELECT percentage(count(*), WHERE httpResponseCode < '400') FROM Transaction WHERE name = 'WebTransaction/Action/shopping_checkout' SINCE 30 day ago TIMESERIES
7. SLO を策定する
検証環境には顧客データが存在しなく、SLI を可視化した際の数値が 100％ を下回ることがないため、目標値としては最大値を設定してみます。
障害から復旧までの自動化は実装していないため、有人で調査・修正・解決するのに十分な時間を確保できるような目標値を設定する必要があります。
これらを踏まえ、SLO は 99.9％ と設定してみます。
- 99.9% – ⼈が調査、修正、解決するのに⼗分な時間がある
- 99.99% – ⾃動化を実装して、停電を検出し、リダイレクトし、セルフヒーリングを実⾏する必要がある
- 99.999% – 分散システムのうち、ごく⼀部の機能だけが使えなくなる程度
SLO を決定したときに考慮したポイント
- 障害~復旧において自動化されていなければ、どんなに高くとも 99.9% であることに留意する。
- 定めた SLI に対して、計測した実際の値から目標値を設定する
- 現状のサービスの状態が十分信頼性を満たしている場合は、現状の値を元にしてそれよりも悪化しないことを目標とした値を設定
- 現状のサービスが信頼性に欠けていると判断する場合は、ユーザーが満足するであろう理想的な値を設定
8. SLI / SLO の管理方法を策定する
New Relic 機能を用いてサービスレベルを効果的に管理できないか運用を考慮して決定してみましょう。
- ダッシュボード: (魅せる)
- 情報を共有し、ステークホルダーに認識してもらう
- サービスレベル管理機能: (観る)
- 担当範囲のより詳細な解析と深い洞察を得る
ここまでくれば、SLM 機能を利用して可視化するのは至って簡単です。
[Service Levels] → [+Add a service level] から設定画面を開き、先ほど可視化してみた NRQL を入力するだけです。
以下はトップページのページ表⽰速度が2秒以内である割合の NRQL を入力した例です。
Query for valid events ( 総イベント ) は母数なので、2秒以内と絞っている WHERE 文を除いて入力します。
Query for good responcses ( 良いイベント ) はサンプル数で、2秒以内と絞るためだけのクエリを入力します。
設定後、しばらく時間をおくと New Relic で自動的に計測が完了します。
9. 結果を評価し、改善する
SLI / SLO は定期的な評価・改善をするサイクルを組むことがよいでしょう。
必要に応じて、以下のような見直しも検討しましょう。
- SLO の変更
- 設定した SLO を満たしていても、ユーザーの満足度に結びついていない場合 → 上げる
- SLO 違反が発生しても、ユーザーへの影響が認められない場合 → 下げる
- SLI の実装の変更
- なるべくユーザの体験に近い方法に実装を変更する…等
まとめ
サービスの品質向上には、ユーザー体験を意識した SLI / SLO の定義と、その継続的な見直しが欠かせません。
今回の手順を通じて、New Relic を活用したパフォーマンスの可視化と改善プロセスの重要性を確認しましたが、これで終わりではありません。運用を続ける中で、ユーザーの声や新たなデータを参考にしながら、SLI / SLO を定期的に見直し、より適切な目標へと調整していくことが重要です。
最も大切なのは、ユーザーの声を可能な限り集め、それに基づいて SLI / SLO を改善し続けることです。
弊社では、このような SLI / SLO の設計から設定まで一貫してサポートしています。
また、以下のような課題でお困りのお客様もぜひ当社にご相談ください。
- サービス障害時にインフラ観点だけでなく、俯瞰的なボトルネック調査を行い、問題の特定・解決を早めたい
- New Relic の導入は決まったものの、ノウハウもなくどうしたらいいかわからない
お客様の課題に合わせて、「AWS 運用・保守サービス」、「New Relic One 導入支援サービス」、「New Relic One 請求代行サービス」等、当社が提供するサービスをご提案させていただきます。
ぜひお気軽にアイレットへご相談ください。
