youichiro blog 🐈‍⬛
Published on

SLOの定義と導入(GCPのドキュメント)

SLO の定義と導入について、GCP のドキュメントの内容を個人用にまとめたものです

ドキュメント

SLO の定義

  • Software as a Service(SaaS)では、プロダクトの開発速度とオペレーションの安定性との間に自然な緊張関係がある
    • システムを変更すればするほど、システムが破壊される可能性が高くなる
  • SLO を適切に定義すれば、安定性を犠牲にすることなく、開発を加速するデータドリブンのオペレーション決定をチームが行えるようになる
    • これにより、プロダクト開発とシステムの整合性の維持という 2 つの目標の間にある事前な緊張関係を緩和できる

用語

  • サービスレベル

    • 特定のサービスがユーザーに対して期待される作業をどの程度行えているかに関する測定値
    • その測定方法は、サービスの内容、ユーザーが何をサービスに期待しているか、サービスで実現できるとの説明を受けている内容などに基づく
    • 例:「ユーザーは、サービスが利用可能で高速であることを期待している」
  • クリティカル ユーザー ジャーニー(CUJ)

    • ユーザーが 1 つの目的を達成するために行うサービスとの一連のインタラクション
    • 例: 「ユーザーが購入手続きボタンをクリックし、カートが処理されて領収書が返されるレスポンスを待つ」
  • サービスレベル指標(SLI)

    • 定量的に測定可能な、サービスレベルに関するユーザーの満足度の指標
    • サービスレベルを測定するためには、そのサービスレベルに関するユーザーの満足度を表す指標(サービスの可用性など)を測定する必要がある
    • 例: 「直近 10 分間における成功したリクエストの数を、直近 10 分間の有効なリクエストの数で割った値を測定する」
  • サービスレベル目標(SLO)

    • サービスがほとんどの時間帯で達成すると期待されるレベル
    • 例: 「14 日間で測定されたすべての有効なリクエストの 95% でサービスのレスポンスが 400 ミリ秒(ms)より早い必要がある」
    • img
  • サービスレベル契約(SLA)

    • SLO が満足されなかった場合の対応に関する説明
    • 通常、SLA はプロバイダと顧客との間の法的契約であり、補償の条項が含まれる場合もある
    • 例: 「1 暦月の間にサービスによって 99.95% の可用性を実現できなかった場合、サービスプロバイダは、サービス内容についての規定を遵守できなかった時間に対して 1 分単位でお客様に補償する」
  • エラーバジェット

    • SLO 違反となるまでに許容できる時間や好ましくないイベントの数
    • この測定値は、ビジネスでどの程度の数のエラーが想定されるか(許容できるか)を示す
    • 例: 「SLO が 99.9% の可用性の場合、リクエストの 0.1% でインシデント、事故、試験運用のいずれかが原因のエラーが発生することが許容される」

SLO が必要な理由

  • サービスレベルを定義しなければ、顧客がサービスに満足しているかを測定することが困難になる
  • よりよいアプローチは、プロダクト(サービスの集合)に基づいて SLO を開発し、ユーザーがこのプロダクトで行う最も重要なインタラクションに焦点を合わせること
  • そのため、効果的な SLO を開発するために、クリティカル ユーザー ジャーニー(CUJ)と呼ばれる、ユーザーとサービスとのインタラクションを理解することが理想である
    • CUJ ではユーザーの目的と、ユーザーがその目的の達成のためにサービスをどのように使用するかが考慮される
    • CUJ が満たされれば顧客は満足し、顧客の満足度がサービスの成功の重要な尺度になる
  • サービスに対する顧客の満足度の重要な側面は、サービスの信頼性であり、サービスが信頼できるかどうかは、サービスの内容以前の問題である
    • そのため、いかなるサービスにおいても信頼性が最も重要となる
  • 一般的な信頼性の指標に「稼働時間」がある
    • しかし、より有用で正確な指標である「可用性」の使用をおすすめする
    • 今日の分散システムではサービスが部分的に停止することがあり、これは稼働時間の測定ではうまく捉えることができない
  • 可用性は、例えば 99.9% の可用性(スリーナイン)や 99.99% の可用性(フォーナイン)などがある

SLI の選択

  • SLO を満足しているか判断するためには、測定を行う必要がある
  • この測定で得られる指標は、サービスレベル指標(SLI)と呼ばれる

最適な指標の選択

  • SLI の開発の最初の手順は、測定する指標を選択することである
  • これらの指標は、以下の種類のいずれかになることがほとんど
    • カウンター
      • ある測定ポイントまでに発生したエラー数など
      • 増加することはあるが減少することはない
    • 分布
      • 特定の期間に特定の測定セグメントに入ったイベント数など
      • 例: 0〜10ms, 11〜30ms, 31〜100ms かかったリクエスト数をそれぞれ測定する
        • => ([0-10: 50], [11-30: 220], [31-100: 1103])
    • ゲージ
      • キューの長さなど
      • 増加することも減少することもある
  • SLI を 2 つの数値の比較として扱うことを通常はおすすめしている
    • すなわち、良いイベント数をイベントの総数で割る
    • この場合の SLI の範囲は 0~100% になり、直感的に理解できる
  • 良い SLI として使える指標の特徴
    • 指標とユーザーの満足度が直接関係している
      • 一般的に、サービスが期待通り動作しない、動作が遅い場合、ユーザーの満足度は低下する
      • 使用している指標がユーザーの満足度の指標に対応していない場合は、SLI として適した指標ではない可能性がある
    • 指標の悪化とサービスの停止が相関している
      • サービスの停止時に良好な状態であるとして表示される指標は SLI に適した指標ではない
    • 指標のノイズが良好
      • 偽陰性や偽陽性が高頻度で発生する指標は適切な SLI ではない
    • 指標が、顧客の満足度に応じて単調に、ほぼ直線的にスケーリングされる
      • 指標が改善するにつれて、顧客の満足度も向上する
img
  • SLI が適切でない場合のグラフ
    • ユーザーが満足していない期間と、ネガティブなイベント(サービス停止、遅延など)が直接対応していない
    • ユーザーの満足度とは無関係に変動している

適切な数の指標の選択

  • サービスの許容範囲を正確に表現できる、可能な限り少ない数の SLI を使用することが理想的
  • 通常、1 つのサービスには 2 ~ 6 個の SLI が必要
    • SLI が少なすぎる場合、重要なシグナルを見落とす可能性がある
    • SLI が多すぎると、実用性がほとんどない数多くの指標をオンコール チームがトラックしなければならなくなる

SLO の選択

  • SLO は以下の値で構成される

    • SLI
      • 例えば、レスポンスの総数に対する HTTP コード 200 のレスポンスの数の割合など
    • 期間
      • 指標が測定される期間
    • 目標
      • 例えば、特定の期間に達成されることが期待されるイベント全体に対する適切なイベントの目標割合など
  • SLO の期間と目標を定義することが難しい場合がある

    • まずはじめに、SLI を特定し、時間に伴う変化をグラフ化する方法がある
    • SLO をすぐに完璧なものにする必要はない
    • SLO を繰り返し処理し、顧客の満足度と一致させ、ビジネスニーズに合うようにする
    • 1 ヶ月間はツーナイン(99.0%)から始めてみてください

測定データ

  • サービスタイプ別に一般的な SLO に関して考察している
    • リクエスト主導型サービス
    • データ処理サービス
    • スケジュールされた実行サービス
    • 他のシステムの指標の種類
  • ここでは「リクエスト主導型サービス」だけ切り出す

リクエスト主導型サービス

  • リクエスト主導型サービスは、クライアント(別のサービスまたはユーザー)からリクエストを受け取り、なんらかの計算を行い、ネットワーク リクエストをバックエンドに送信し、続いてクライアントにレスポンスを返す
  • リクエスト主導型サービスは、多くの場合、可用性 SLI とレイテンシ SLI によって測定される

SLI としての可用性

  • 可用性の SLI は次のように定義される
    • 「正常に処理された有効なリクエストの割合」
  • 「有効」とは
    • 一般的には HTTP レスポンスコードを使用する
    • 通常、500 エラーは SLO にカウントされるサーバーエラーと判断され、400 エラーはクライアントエラーで SLO にカウントされない

SLI としてのレイテンシ

  • レイテンシの SLI は可用性と同様に定義される
    • 「閾値よりも速く処理された有効なリクエストの割合」
  • 重要なことは、ユーザーによってレイテンシが認識されるかどうか
  • よくある間違いは、レイテンシを正確に測定しすぎること
    • 実際には、更新に 100 ミリ秒(ms)要する場合と 300 ミリ秒要する場合の差異をユーザーは識別できない
  • 代わりに、アクティビティ ベースの指標を開発することをおすすめする
    • 操作
      • 1,000ms
      • ユーザーが要素をクリックした後、結果を待つ時間
    • 書き込み
      • 1,500ms
      • システムには遅いとみなされるが、ユーザーには許容される傾向がある
      • 指標に関しては、書き込みと読み取りを明示的に区別することをおすすめする
    • バックグラウンド
      • 5,000ms
      • データの定期更新やその他の非同期陸絵 s となど
      • ユーザーに表示されないアクション
  • レイテンシは一般的に分布として測定される
    • 過去の分布を調査することで設定された閾値よりも速いイベントを、良好なイベントとみなす
  • 平均または中央値レイテンシのみを SLI に使用することはおすすめしない
    • ユーザーの半数が不満を感じていることを示す
    • 長期的なエラーバジェットに対する現実的な脅威を発見できるまで、数日間にわたってレイテンシ悪化が続く可能性がある
  • 「実用的なレイテンシの目安では、レイテンシの 99 パーセンタイルが中央値のレイテンシの 3 ~ 5 倍を超えてはいけません。サービスのレイテンシの 50 パーセンタイル、95 パーセンタイル、および 99 パーセンタイルは計測する価値があり、それぞれを中心に SLO を設定するのが理想的です。」

SLI としての品質

  • 品質の SLI は次のように定義される
    • 「サービスの中断なしに処理された有効なリクエストの割合」
  • 例えば依存関係が遅い時や使用できないときに、中断することで安全にしっぱうするような設計がされているサービスで役に立つ

目標の設定

  • 目標を設定する最善の方法の 1 つは、SLO とその開発方法を記述した共有ドキュメントを作成すること
  • SLO を実装し、反復作業を重ねるにあたり、チームがドキュメントを繰り返し使用できる
  • ビジネス オーナー、プロダクト オーナー、エグゼクティブが、このドキュメントを確認することをおすすめする
  • 会社にとって最も重要なユーザージャーニー(CUJ)用に、SLO を開発するためのテンプレート
    1. SLI 仕様を選択する
    2. SLI 仕様の実装方法を定義する
    3. 計画に目を通し、CUJ がカバーされていることを確認する
    4. 過去のパフォーマンスまたはビジネスニーズに基づいて SLO を設定する