SLI(エスエルアイ)

SLI(エスエルアイ)

SLI(エスエルアイ)

英語表記: Service Level Indicator

概要

SLI(Service Level Indicator、サービスレベル指標)とは、システムがユーザーに対して提供しているサービス品質を定量的に測定するための具体的な指標のことです。これは、ハードウェアとソフトウェアが連携して稼働するITシステムにおいて、「信頼性が高い」という主観的な評価を排除し、データに基づいて客観的に議論するために不可欠な要素となります。信頼性工学(SRE)の文脈では、このSLIを基に目標値(SLO)を設定し、システム運用の成否を判断する土台となります。

この指標は、可観測性を高める活動において、膨大な監視データの中から「何を最も重視して見るべきか」を明確にする役割を担っています。

詳細解説

SLIは、私たちがシステムを「ハードウェアとソフトウェアの関係」として捉え、その複雑な動作を「可観測性」という視点から把握し、「信頼性工学」に基づいて改善していくサイクルの中核をなす概念です。単なるサーバーのCPU使用率やメモリ使用量といった内部的なメトリクス(測定値)ではなく、ユーザー体験に直結する指標を選定することが極めて重要です。

SLIの目的と役割

SLIの最大の目的は、システムの信頼性を「気分」や「感覚」ではなく、「数字」で議論できるようにすることです。これにより、運用チームと開発チーム、さらにはビジネス部門が共通の理解を持つことができます。

信頼性工学において、SLIは以下の手順で機能します。

  1. 測定: ユーザーがシステムを利用する際に発生するイベント(例:リクエスト)を測定します。
  2. 指標化: 測定結果を特定の指標(例:成功したリクエストの割合)として集計します。これがSLIです。
  3. 目標設定: このSLIに対して、許容できる最低限の品質目標(SLO:Service Level Objective)を設定します。

例えば、Webサービスにおいて「ページ読み込みの成功率」をSLIとして定義したとします。もしこの成功率が目標値(SLO)を下回れば、それはシステムが信頼性の目標を達成できていないことを示します。

SLIの主要な種類と構成要素

SLIとして一般的に採用される項目は、システムの種類によって異なりますが、信頼性工学の視点から特に重視されるのは以下の4大ゴールデンシグナルです。

  1. レイテンシ(Latency / 遅延時間): リクエストに対する応答にかかる時間です。ユーザーが「遅い」と感じるかどうかを測る決定的な指標ですね。
  2. エラー率(Error Rate): 失敗したリクエストの割合です。成功すべき処理が失敗した場合の頻度を示します。
  3. スループット(Throughput): 単位時間あたりに処理できるリクエスト数やデータ量です。システムの処理能力の限界を探るのに役立ちます。
  4. 可用性(Availability): システムが正常に機能している時間の割合、つまり「利用できる状態であるか」を示す最も基本的な指標です。

これらの指標は、ソフトウェアの動作の結果としてハードウェア上で発生する事象を計測しているため、「ハードウェアとソフトウェアの関係」の健全性を測るバロメーターとなります。そして、これらのデータを継続的に収集し分析することが「可観測性」の実践そのものなのです。

信頼性工学とSLI

信頼性工学(SRE)は、ソフトウェアエンジニアリングの手法を運用業務に適用し、高い信頼性を実現するための体系的なアプローチです。SLIはSREの出発点です。何を測定するかを定義しなければ、目標も設定できず、改善の方向性も定まりません。

SLIの選定には細心の注意が必要です。「可観測性」の観点から見ると、収集できるデータは無限にありますが、その中で真にユーザー体験に影響を与え、かつ測定が容易で、信頼性の目標(SLO)に変換しやすいものを選ぶことが、SRE成功の鍵を握っています。

具体例・活用シーン

SLIを理解するための具体的な例と、初心者にも分かりやすいアナロジーをご紹介します。

1. WebアプリケーションにおけるSLIの定義

ECサイトを例にとりましょう。このECサイトは、ユーザーが「商品を探す」「カートに入れる」「決済する」という一連の動作で成り立っています。

  • 指標(SLI)の定義:
    • 決済完了の成功率: 過去30日間で、決済ボタンが押された全リクエストのうち、エラーにならずに完了したリクエストの割合。
    • 検索応答レイテンシ: 検索リクエストの99パーセンタイル値(全リクエストのうち99%が完了するまでの時間)が1秒以内であること。
  • 活用シーン:
    • 運用チームは、このSLIの値をリアルタイムで監視します。もし決済成功率がわずかでも低下し始めたら、それは「ハードウェアとソフトウェアの関係」のどこかに問題が発生している兆候です。例えば、データベース(ハードウェア)への接続がソフトウェア側で詰まり始めているかもしれません。
    • このSLIの変化を「可観測性」ツールで捉えることで、問題が深刻化する前に対応(ライフサイクル管理)を開始できます。

2. アナロジー:救急車の信頼性管理

SLIを「信頼性工学」の文脈で理解するために、救急車サービスを例に考えてみましょう。救急車サービスのミッションは、人命に関わる緊急事態に迅速に対応し、信頼性の高いサービスを提供することです。

信頼性工学(SRE)の視点:

  • サービス(システム): 救急車による緊急搬送サービス。
  • 信頼性の目標(SLO): 「通報を受けてから現場に到着するまでの時間」が、95%のケースで8分以内であること。

ここで、SLIは以下のようになります。

  • SLI(サービスレベル指標): 「通報から現場到着までの時間」

この「到着時間」こそが、サービス品質を直接的に測定する、具体的で定量的な指標です。

もし、ある月のSLIの平均値が9分だった場合、目標(SLO)である8分を超過しているため、サービスは信頼性を欠いていると判断されます。このデータ(可観測性)に基づいて、運用管理者(SREチーム)は、「なぜ遅延が発生しているのか?」を分析し、ルート最適化ソフトウェアの改善(ソフトウェア)や、車両の配置見直し(ハードウェアとソフトウェアの関係の最適化)といった改善策(ライフサイクル管理)を講じるわけです。

SLIは、この物語における「ストップウォッチ」の役割を果たしている、と言えるでしょう。

資格試験向けチェックポイント

IT系の資格試験、特にITパスポート、基本情報技術者、応用情報技術者試験では、SLI単体で問われることは少ないものの、SREやSLA(Service Level Agreement)の文脈で極めて重要な知識となります。

| 試験レベル | 問われ方と対策 |
| :— | :— |
| ITパスポート | 主に「SLA(サービスレベル合意書)」の構成要素として間接的に出題されます。SLAの品質基準を具体的に定めるのがSLIとSLOの関係であることを理解しておきましょう。「顧客と合意する指標」がSLIである、というレベルの理解で十分です。 |
| 基本情報技術者 | SLI、SLO、SLAの三者の関係性を問う問題が出やすいです。SLI(指標)→ SLO(目標)→ SLA(合意)という流れを確実に暗記してください。特に、SLIは「測定可能な具体的な数値」であり、SLOはその「目標値」であるという定義の違いを明確に区別することが重要です。 |
| 応用情報技術者 | SRE(サイトリライアビリティエンジニアリング)やサービスマネジメントの深い理解が求められます。SLIが「可観測性」によって得られたデータから選定され、「信頼性工学」に基づいて運用の自動化や改善の判断基準となる、という文脈を理解してください。具体的なSLIの例(レイテンシ、エラー率など)を記述式で問われる可能性もあります。 |
| 共通の重要点 | SLIはユーザー体験にフォーカスした指標であり、単なるシステムリソースの監視値ではないことを抑えておきましょう。この視点こそが、旧来の運用管理と信頼性工学の大きな違いです。 |

関連用語

SLIを理解する上で、以下の用語は避けて通れません。これらはSLIと密接に連携し、「ハードウェアとソフトウェアの関係」の信頼性を保証するための重要なフレームワークを構成しています。

  • SLO (Service Level Objective / サービスレベル目標)
    SLIに対して設定される具体的な目標値です。「決済成功率を99.9%以上にする」といった、達成すべき信頼性の水準を定めます。SLIが「何を測るか」であるのに対し、SLOは「どの程度まで許容するか」を定めます。
  • SLA (Service Level Agreement / サービスレベル合意)
    顧客とサービス提供者の間で結ばれる、サービス品質に関する公式な契約です。通常、SLOに基づいて作成されますが、SLAは契約であり、SLOは社内目標であることが多いという違いがあります。
  • エラーバジェット (Error Budget)
    SLOの目標値から逸脱してよい許容範囲、つまり「信頼性を損ねても許される時間や回数」のことです。SLIの測定値がSLOを超えて逸脱すると、エラーバジェットが消費されます。信頼性工学では、このバジェットを使い切るまでは、新機能開発などのリスクを取った行動が許容されます。

関連用語の情報不足について

現在、提供されている文脈では、「関連用語」として上記3つの用語(SLO, SLA, エラーバジェット)を挙げることが最も適切です。しかし、もしこのITグロッサリー全体が、特定のベンダーの製品群や、特定の業界(例:金融、医療)の規制要件に焦点を当てている場合、その具体的な規制用語や、そのベンダー固有の監視ツール名を関連用語として加えるべきでしょう。

例えば、クラウドネイティブな文脈であれば「オブザーバビリティ(可観測性)」や「メトリクス」「トレース」といった用語を追加すべきです。現時点では、これらの具体的な情報が不足しているため、読者が必要とするかもしれないより深い文脈情報を提供できていない可能性があります。


よかったらシェアしてね!
  • URLをコピーしました!
  • URLをコピーしました!

この記事を書いた人

両親の影響を受け、幼少期からロボットやエンジニアリングに親しみ、国公立大学で電気系の修士号を取得。現在はITエンジニアとして、開発から設計まで幅広く活躍している。

目次