信頼性向上のためのSLI/SLO導入vol.1 - 紹介と必要性

はじめに

こんにちは。SRE（site reliability engineering、サイト信頼性エンジニアリング）業務を担当しているEnablement EngineeringチームのDahee Eo、Service ReliabilityチームのKi Cheol Cheonです。

私たちの2つのチームはService Engineering室に所属しており、LINEアプリが提供するサービスの品質向上と可用性の確保を目指して技術活動を行っています。具体的には、メッセージングサービスやメディアプラットフォームなど、LINEアプリサービスのSREを担当しています。この目的を達成するために、サービスリリースやイベントに必要な技術要素を特定し、適切なソリューションを提供します。また、開発組織がより開発・運用に集中できるよう、不安要素を取り除き、反復作業を減らすために技術サポートや自動化を行っています。さらに、需要予測やパフォーマンスの改善、観測可能性（observability）の強化、インシデント対応など、さまざまな分野でサービスの信頼性向上に努めています。

このような経験のもと、私たちは「信頼性（reliability）向上のためのSLI/SLO導入」をテーマにした記事を、3回にわたって連載する予定です。今回はその第1弾として、SLO（service level objective）とSLI（service level indicator）とは何か、そしてそれらがなぜ必要なのかを、初めて聞く方にもわかりやすく解説したいと思います。

SREの役割

SREは、顧客にサービスの「安定性」と「信頼性」を提供するために必要なあらゆるエンジニアリング業務を行います。もう少し具体的に言うと、パフォーマンス改善や自動化のためのコード作成、システム監視、障害対応などを行います。そうすることで、サービスの安定性を保ちながら、できるだけ変化を受け入れ、信頼性の高いサービスを提供することを目指します。

ここでの「信頼性」という言葉はやや抽象的ですが、以下に示すような、信頼に関連するあらゆるポジティブな言葉として解釈できます。

• 迅速なサービスを提供する。
• 安定したサービスを提供する。
• 安全なサービスを提供する。

これは最終的に、ユーザーが信頼して利用できるサービスを提供することを意味します。つまり、信頼性はサービス提供者のモニタリング結果ではなく、ユーザーによって決定されるものです。

そのため、SREはユーザーがサービスをどのように感じているのか、データを基に表現する必要があります。例えば、「サービスが遅い」または「サービスが不安定」といった定性的な表現ではなく、「メッセージ送信APIの応答速度が1秒以上遅くなり、ユーザーが不便を感じている」など、定量的に表現する必要があります。そのためには、基準と評価、ケースごとの計画などが必要です。

ここで登場する概念が、SLIとSLO、SLA（service level agreement）です。LINEアプリも、ユーザーにより信頼性の高いサービスを提供するために、SLIとSLOを導入しました。

信頼性を測定するには？

先に簡単に触れたように、どのようにして信頼性を定量的に測定するのでしょうか？

動画サービスを例に挙げて説明します。動画サービスを利用する際、ユーザーにとって最も重要なのは、再生が開始されるまでの時間が短く、途切れることなく再生されることです。ここで、動画が出力されるまでにかかる時間である待ち時間（latency）がSLI、すなわち指標になります。そして、その指標の目標値がSLOです。また、通常のサブスクリプションサービスの場合、ユーザーと企業との間の契約であるため、このような指標に関する基準を明示し、その基準に違反した場合の補償などを明示しています。これがSLAです。

わかりやすく説明するために、とても簡単で端的な例を挙げましたが、各概念についてもう少し詳しく説明します。

ユーザージャーニー（user journey）

SLIとSLO、SLAを理解するには、まず、ユーザージャーニーという概念を理解する必要があります。ユーザージャーニーとは、ユーザーがサービスを利用するプロセスや流れを定義したものです。前述の動画サービスの例では、「ユーザーがサービス上で動画を再生するために体験する一連のプロセス」をユーザージャーニーと呼びます。メッセージングサービスでは、「ユーザーがメッセージを送信するために体験する流れ」や「友だちを追加する際に体験するプロセス」などがその例になります。

ユーザージャーニーのコア機能やサービスに関するジャーニーを「クリティカルユーザージャーニー（critical user journey、以下CUJ）」と呼びます。SLIとSLOの導入は、サービスの主要な機能についてCUJを定義し、各ユーザージャーニーで使用するAPIを特定することが出発点となります。

SLI、SLO、SLA

以下はSLIとSLO、SLAの概念をまとめた表です。

区分	SLI（service level indicator）	SLO（service level objective）	SLA（service level agreement）
説明	ユーザーの視点でサービスの安定性を判断できる定量的に測定した値 待ち時間（latency）、可用性（availability）、処理能力（throughput）など	測定されたSLIを通じて、ユーザーの期待に応えるためにサービスが達成すべき目標値または目標範囲	SLOをベースにしたサービス提供者と顧客との間の事業契約（無料サービスでは使用しない）
例	過去1分間の動画再生リクエストのうち、95パーセントタイルの待ち時間が300ms未満 過去1分間の動画リスト閲覧リクエストの可用性が99.9％以上（ステータスコードを基に2XXと3XX）	過去1か月間の動画再生SLIが99.9%を満たしている 過去1か月間の動画リスト閲覧SLIが99.9%を満たしている	動画サービスは、毎月99.8%のアップタイムを維持すること ITサポートチームは、顧客からのメールサポートリクエストを1時間以内に確認・回答すること 動画が再生できないなどの重要な問題は、4時間以内に解決すること

SLI/SLOの例をもう少し詳しく定義すると以下のようになります。文字の色によってEvent（イベント）、Success Criterion（成功基準）、Where and How（APIと測定方法）、Measurement window（測定ウィンドウ）を意味します。CUJを具体化していないため、一般的な例で作成したことをご了承ください。

<例1. 待ち時間ベースのSLI/SLO>

SLIタイプ	待ち時間
SLI仕様	ゲートウェイログ（APIと測定方法）で測定された、/api001（APIと測定方法）に対するHTTP GETリクエスト（イベント）のうち、300ms（成功基準）以内に全ての応答を送信するリクエストの割合 $\frac { HTTP\ GET\ successful\ requests}{ HTTP\ GET\ requests}\ \times 100\%$
SLI実装	HTTPメソッド：GET API：/api001 基準：300ms以内の応答 どこで & どのように：ゲートウェイログ
SLO	過去28日間（測定ウィンドウ）のローリングウィンドウで、api001（イベント）の99.9%（成功基準）が正常（成功基準）に提供されること

<例2. 可用性ベースのSLI/SLO>

SLIタイプ	可用性
SLI仕様	ゲートウェイログ（APIと測定方法）で測定された、/api002（APIと測定方法）に対するHTTP POSTリクエスト（イベント）のうち、ステータスが2XX、3XX、4XX（429を除く）（成功基準）のリクエストの割合 $\frac {\ HTTP\ POST\ successful\ requests}{\ HTTP\ POST\ requests}\ \times 100\%$
SLI実装	HTTPメソッド：POST API：/api002 基準：応答コード。2XX、3XX、4XX（429を除く）ステータス どこで & どのように：ゲートウェイログ
SLO	過去28日間（測定ウィンドウ）のローリングウィンドウで、api002（イベント）の99.9%（成功基準）が正常（成功基準）に提供されること

以下は、SLI/SLOに基づいて信頼性を測定する流れをまとめたものです。

SLI/SLOを定義し、測定する原則は以下のとおりです。

• ユーザーの視点で見ること：重要なのは、どのような値を測定できるかではなく、ユーザーが重要視するものは何かを見つけることです。
• 可能な限りシンプルにすること：SLIを複雑に集計すると、システムのパフォーマンス状況を明確に反映できないため、可能な限りシンプルにする必要があります。
• SLOの設定を最小限に抑えること：システムの特性を正確に把握できる最小限のSLOを選択することが重要です。
• 目標設定：期待値を設定しますが、100%のような過度な目標設定は避けます。
• 継続的な開発と改善：最初から完璧に設定することは不可能なので、継続的な確認と改善が必要です。

エラーバジェット（error budget）

上記のようにSLIを測定し、SLOを定義して目標を立てたら、その目標を達成できなかった場合にどうするか、つまり、リスクとエラーを管理する必要があります。

ここで登場する概念が「エラーバジェット（error budget）」です。エラーバジェットとは、SLOに基づいて計算された障害やサービスの安定性の低下をどの程度まで許容するかを定義した値です。例えば、1か月間のSLOが99.9%に設定されている場合、0.1%のエラーを許容することを意味します。これを数式で計算すると、40.32分のエラーを許容することになります。

$\frac {\small 99.9\%↑}{\small month} = \frac {\small 0.1\%↓}{\small month} = 0.001 \times \frac {\small 28 day}{\small month} \times \frac {\small 24 hour}{\small day} \times \frac {\small 60 min}{\small hour} = \frac {\small 40.32 min}{\small month}$

下記のようにSLOが高く設定されればされるほど、エラー許容時間は自然と低くなります（下記の計算はすべて１か月を基準としています）。ただし、目標設定は高ければ高いほど良いというわけではありません。Googleでは、99.9%を99.99%に、99.99%を99.999%にするためには、従来比10倍の努力が必要だと説明しています（参考）。したがって、各サービスの特性と状況に応じて適切に設定することが重要です。

• 99.9% = 停止時間（down time）40分 → 人間が異常を検知し、モニタリングを通じてその根本原因を特定・修正
• 99.99% = 停止時間4分 → 人間が異常を検知して解決するには時間が短いため、システムが検知して自己修復できるように設計
• 99.999% = 停止時間24秒 → 人間では検知できず、システムでしか検知できない時間

エラーバジェットを使用した場合のメリットは、開発チームとSREチームが「サービスの信頼性」、つまり、サービスがうまく運用されているかについて「共通言語」で会話できるということです。さらに、エラーバジェットを使用することで、開発チームが自らリスクを管理できます。新規機能の追加とサービスの安定性のうち、どちらに重点を置くべきか、エラーバジェットの状況を見て開発チームで決定できます。もし、現在のエラーバジェットを超過してサービスが安定していない場合は、すべての新規機能の開発やリリースを停止し、安定性に重点を置くべきです。逆にエラーバジェットを超過していない場合は、新規機能の開発に重点を置くことができます。

エラーバジェットで議論されるエラーには、アプリケーションだけでなくネットワークやストレージなどで発生するさまざまなエラーが含まれます。これらのエラーはサービスごとに異なるため、各サービスの特性に応じて定義する必要があります。

SLI/SLOの活用

SLI/SLOの定義と実装が完了したら、ユーザーがサービスに対して感じる信頼性を定量的に評価する準備が整ったことになります。では、SREとしてSLI/SLOを実際の運用業務にどのように活用すれば良いでしょうか。

まず、サービスに関わるさまざまなステークホルダーが「SLI」と「SLO」、「エラーバジェット」を利用して一緒に信頼性を評価できます。定量的な指標をもとに、信頼性について共通言語で会話できるようになります。
次に、定期的なミーティングを通じてSLI/SLOの達成状況を一緒にモニタリングし、レビューや振り返りを通じて信頼性を管理できます。週次や月次ミーティングで指標の変化を共有し、どのような原因や問題で変化したかを確認したうえで、それを改善する方法を定義できます。

また、エラーバジェットを利用してアラートシステムを構築することで、各サービスのオンコール（on-call）またはサービス運用担当者への段階的なアラートを送信し、適切な対応を行うようにします。
最後に、SLOとエラーバジェットの状況による対応およびリソースの利用に関する方針を定義できます。例えば、エラーバジェットに余裕がある場合、新機能のリリースや短いデプロイサイクル戦略を選択し、逆の場合は、信頼性の回復のために安定性向上にリソースを集中させるという選択の判断基準となります。

このように活用できるSLI/SLOは、組織とビジネスの状況に応じて調整する必要があります。そのため、関連するダッシュボードや指標のモニタリングと管理を続ける必要があります。

おわりに

この記事が、SREが果たす役割について興味を持たれていた方や、SLI/SLOの概念が難しいと感じられていた方のお役に立てば幸いです。今後、第2弾と第3弾では、LINEアプリサービスに導入し、測定・実装した事例を紹介する予定です。第2弾ではプラットフォーム、第3弾ではアプリケーションの事例を紹介しますので、引き続きご期待ください。ありがとうございました。