LoginSignup
5
2

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

New Relic 使ってみた情報をシェアしよう！ by New RelicAdvent Calendar 2024

Day 17
@himukai_blin株式会社BookLive

BookLiveにおけるSLI/SLO策定に向けた取り組み

Last updated at Posted at 2024-12-17

こちらはNew Relic Advent Calendar 2024、シリーズ2の12/17(火)の記事となります。

はじめに

こんにちは。株式会社BookLive システム開発部に所属しているSREエンジニアです。
BookLiveではSLO（Service Level Objective）の策定に取り組んでおり、モニタリングのツールとしてNew Relicを活用しています。
本記事ではBookLiveにおけるSLO策定の取り組みの流れや、New Relicでどのようにモニタリングしているかについてご紹介します。

担当しているサービスについて

私が所属しているシステム開発部では、BookLiveが運営するサービスのうち主に電子書籍ストアサービスである「ブックライブ」「ブッコミ」の開発・保守を担当しています。
簡単にサービスの紹介をさせていただきます。

  • ブックライブ
    2011年にサービスを開始した国内最大級の総合電子書籍ストアです。
    “いつも心に「マンガ部屋」を。”をコンセプトにユーザー体験を重視したサービスを展開しています。
    https://booklive.jp/

  • ブッコミ
    日本で初めて携帯電話向けのマンガ配信を開始した、月額会員制のドコモ・au・ソフトバンク各キャリア公式マンガサイトです。
    https://sp.handycomic.jp/

両ストアサービス共通で、購入した作品をそのままブラウザ上で閲覧することができる読書ビューワーの機能を提供していますので、気軽に読書をお楽しみいただけます。

現状について

試験的なSLI/SLOの策定

現在はSLOの試験的な運用を行っており、SREメンバーが電子書籍ストアサービスとしての特徴を考慮して暫定的なSLIとSLOを設定しました。
(閾値は最初期に設定した際のものです。状況次第で修正しているので現在のものとは異なります。)

  • SLI
    • 商品ページ表示時のレイテンシ
    • 読書ビューワー起動時のレイテンシ
  • SLO
    • 商品ページ表示時のレイテンシの99%が2.5秒以内であること
    • 読書ビューワー起動時のレイテンシの99%が2秒以内であること

SLOの設定方法

閾値に関しては、該当ページにおける過去1カ月分のレイテンシの99パーセンタイルの値を元に少し余裕を持たせたものとなっています。

レイテンシの99パーセンタイルの値の算出にはNew Relicの「Data explorer」の機能を利用しています。New Relicに取り込んでいるデータをかなり自由度高く抽出/加工できる機能で、パーセンタイルの値も一発で算出できるので便利ですね。

New RelicにはSLIとSLOの作成と編集に関するドキュメントがあるので非常に参考になります。
https://docs.newrelic.com/jp/docs/service-level-management/create-slm/

レイテンシのパーセンタイルを算出するNRQLもドキュメント上に記載されています。
例えば下記のNRQLは「APM」で計測しているサービスの過去7日間の95パーセンタイルのレイテンシを算出するものですね。

SELECT percentile(duration, 95) FROM Transaction WHERE entityGuid = '{entityGuid}' since 7 days ago limit max

SLOを決めるうえでは二通りの方針があると考えています。

  1. 厳しめの値を閾値として設定する方針
    • あえて厳しめの値を設定してエラーバジェットを消費しやすくすることで、パフォーマンス改善をしなければならない状況に追い込む
  2. 余裕を持たせた値を閾値として設定する方針
    • パフォーマンスが安定している前提で、新規の機能開発などを積極的に行っていく

BookLiveの場合は、

  • パフォーマンスが比較的安定している
  • ユーザーに対して新しい価値を提供するための機能開発を積極的に行うことを重視している
  • 試験的な運用であるということでエラーバジェットがすぐ枯渇して対応に追われてしまうことが無いようにする

という理由から後者の方針を選択しています。

SLOのモニタリング方法

SLOのモニタリングにはNew Relicの「Service Levels」機能を利用しています。

slo_dashboard.png

詳しい設定の仕方については、先述の「SLIとSLOの作成と編集」に詳しく記載されているのでここでは割愛させて頂きますが、SLOの設定を行うだけでエラーバジェットも自動的にカウントされるようになります。
パフォーマンスに問題が無い状態であればオールグリーンで表示されるので視覚的にも安心しますね。

ここまでが現在の試験的な運用についてのお話でした。

本運用を目指す上での課題

本運用に向けた課題は主に2つでした。

  • 現在の指標が「ユーザーがサービスに対して期待していること」を示せているのかが不明瞭
  • SRE以外のシステム開発部メンバーにとって、SLI/SLOは馴染みが薄く意義が浸透していないので、そのまま本運用しても形骸化してしまう恐れがあった

これらの課題を解決してSLI/SLOを効果的に運用していくために、SRE以外のシステム開発部メンバーも含めた一丸で、ユーザ目線に立ってSLI/SLOを定義し直すことにしました。

取り組みを行う際のNew Relicからのご支援

SLI/SLOの再定義を目指す際に、New Relicの担当営業に進め方について相談しました。
その結果、New Relicのソリューションコンサルタントを交えて以下のようなご支援をいただいています。

  • システム開発部メンバー向けにSLI/SLOに関するセミナーを開催
    SLI/SLOがどのようなものであるかの基礎の部分から説明をいただいたおかげで、メンバー全体の足並みを揃えることができました
  • SLI/SLO策定における道筋をご提案いただいた
    効果的なSLI/SLO策定のためには、ユーザージャーニーを作成して利用者の立場で利用者が何を期待するかを明確にすることが重要であると教えていただきました

これらのご支援を元にSLI/SLO再定義に向けた歩みを始めました。

SLI/SLO再定義に向けた歩み

STEP1 ユーザージャーニーの作成

まずはユーザ目線に立ってサービスを見るために、システム開発部メンバー内でユーザージャーニーを作成しました。
完全なものを作り上げるのは大変なので簡略版です。

ユーザーがサービスを利用する際の目的(シナリオ)をあらかじめ数パターン定義しておき、シナリオに沿ったユーザーの立場でサービスをどのように使うかを議論しながらユーザージャーニーを作りました。
ペルソナを設定するのではなく「自分がユーザーとしてサービスを利用するときにどう行動するか」を重視していました。

下記の図は、実際に作成したユーザージャーニーの一例です。

user_journey.png

このようなユーザージャーニーを数パターン作成しています。

STEP2 クリティカルユーザージャーニーの特定

作成したユーザージャーニーの中でも、特に「何らかの阻害を受けた場合に利用目的を達成する前に離脱したくなると思うページ」は何かを検討しました。

それをクリティカルユーザージャーニーとしてピックアップしています。

下記の図は、上記のユーザージャーニーからクリティカルユーザージャーニーをピックアップしたものです。

ciritcal_userjourney.png

STEP3 クリティカルユーザージャーニーに対してユーザーが期待するものは何かを検討

クリティカルユーザージャーニーとしてピックアップしたページにおいて「ユーザーが期待するものは何か」を考えました。

例としては以下のようのものです。

  • 例.商品ページに対してユーザが期待すること
    • ページがストレスを感じない程度の時間内に表示されること
    • エラーになることがなくページが表示されること
    • ユーザが見たいと思った商品が表示されること

STEP4 SLIとの紐づけ

STEP3までで、サービスに対してユーザが特に期待することを挙げることができました。このユーザが特に期待することを言い換えたものがSLIとして設定する指標の候補になると考えています。

例としてあげたユーザが期待することを言い換えると

  • ページがストレスを感じない程度の時間内で表示されること → レイテンシ
  • エラーになることがなくページが表示されること → エラー率
  • ユーザが見たいと思った商品が適切に表示されること → 正確性

このようにステップを踏んで考えることで、SLIとして設定される指標と、サービスにおいてユーザーが期待することを紐づけることができるのでかなり納得しやすいものになったんじゃないかと思います。

ここまでが現在までに実施した内容です。

今後実施すること

SLO再定義の取り組みは引き続き進めていきます。
今後実施することとしては、

SLIの決定

多数のSLI候補から絞り込む

現在までに挙がったSLIの候補は10件以上ありますが、その全てを採用するわけではありません。多くても5個程度を上限に絞り込みを行います。

ベストプラクティスとして「SLIを増やしすぎないこと」があることに加えて、体感的にも多すぎると管理しきれないと思います。

候補のどれも重要であることは変わりないですが、New Relic上でモニタリングが容易にできるものを優先的に選ぶ予定です。

SLOの決定

各SLIに対する適切な目標値を設定

SLOに関しては現状の試験運用における閾値の設定の仕方と同様で、過去1ヶ月間の実績を基準に、少し余裕を持たせた値を設定する予定です。

運用

SLI/SLOは状況に応じて妥当性が変わっていくものなので、定期的にSLIの追加/削除、SLOの閾値の見直しを行なっていくことを前提としています。

終わりに

BookLiveでは、積極的な機能開発によってユーザーに新しい価値を提供し続けることを第一に考えています。同時に、安心して読書を楽しむ環境を守ることも重要な使命だと認識しています。
SLI/SLOの適切な運用を通じて、この両立を実現していきたいと考えています。

参考資料

「SLO サービスレベル目標 ―SLI、SLO、エラーバジェット導入の実践ガイド」
https://www.oreilly.co.jp/books/9784814400348/

「SRE サイトリライアビリティエンジニアリング　―Googleの信頼性を支えるエンジニアリングチーム」
https://www.oreilly.co.jp/books/9784873117911/

「SLIとSLOの作成と編集」
https://docs.newrelic.com/jp/docs/service-level-management/create-slm/

5
2
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
5
2

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?