SLOとエラーバジェットから考える1リクエストの価値

著者：渡部龍一
目次

はじめに

株式会社IVRyというところでSREをやっている渡部龍一です。今日は「SLOとエラーバジェットから考える1リクエストの価値」という普段ぼんやりと考えている内容について言語化した内容を紹介します。

イントロダクション

ECサイトの決済リクエストとSNSのフィード取得リクエスト、どちらが重要でしょうか？システム運用の観点では、1つのリクエストがどのような影響を持つのかを正しく評価し、適切に対応することが求められます。

システム運用において、1リクエストの価値をどのように評価するかは重要なテーマの一つであると考えます。特にSREの観点からは、サービスの信頼性や可用性を考慮しながら、1つのリクエストがどの程度の重要性を持つのかを定量的・定性的に分析することが求められます。それぞれの内容について個人的な視点も交えて説明します。

リクエストの影響を考える

1つのリクエストが持つ影響は、単なる成功・失敗の結果にとどまりません。リクエストの遅延やエラーはユーザー体験の悪化を引き起こし、長期的にはサービスの評価や利用率に影響を及ぼす可能性があります。また、エラーバジェットの観点から見ると、どのリクエストが最も重要で、どこにエラーの許容範囲を設けるべきかを慎重に検討する必要があります。

1. ビジネスインパクト

  • 1リクエストが直接売上やユーザーエンゲージメントにどのような影響を与えるか。
    • 例えばECサイトであれば、1つの注文リクエストは売上に直結し、障害発生時の機会損失は明確になります。
    • B2Bサービスでは、1リクエストが契約ユーザーの業務継続に影響を与える可能性もあります。

2. システムリソースへの影響

  • 1リクエストがどれだけのCPU、メモリ、ネットワーク帯域を消費するのか。
  • 負荷の高いリクエスト（例：重いクエリやバッチ処理）はシステムのボトルネックになりやすいため、適切なキャッシングやスロットリングが必要。

この記事ではビジネスインパクトをベースとしてインパクトが大きい = リクエスト単価が高いと考えて書いていきます。

リクエストの再試行性（リロード可能 vs 不可能）

一部のサービスでは、リクエストが失敗してもユーザー側でリロード（再試行）が可能なため、即時の可用性よりもキャッシュ戦略が重要になります。例えば、ニュースサイトやSNSのフィード取得では、一時的なエラーが発生してもページを再読み込みすることでデータを取得し直せるため、多少の遅延や失敗は大きな問題になりにくいでしょう。

一方で、決済処理やオンライン会議、そして電話サービスのようなリアルタイム性の高いシステムでは、一度リクエストが失敗するとユーザーによる再試行が難しく、業務や取引に直接的な影響を及ぼす可能性があります。例えば、IVRのような電話対応サービスでは、顧客からの着信や音声の転送が適切に処理されなければ、重要な連絡の機会を逃してしまう可能性があります。特に、電話対応の遅延や不達は即座にユーザー体験に影響を与えるため、高い可用性の確保と障害発生時の迅速な復旧が求められます。

  • 再試行可能なリクエスト
    • ニュースサイトやSNSのフィード取得では、一時的なエラーが発生してもページ再読み込みで解決可能
  • 再試行が困難なリクエスト
    • 決済処理やオンライン会議、電話サービスでは、一度の失敗が取引や業務に直結するため、リカバリーが困難

このような特性の違いを正しく理解し、リクエストの重要度に応じた適切なSLOを設計することが、安定したサービス運用において重要なポイントとなります。リアルタイム性が求められるサービスでは、単なるSLOの達成率だけでなく、障害時の影響範囲を最小化するための設計や運用戦略も不可欠です。

ビジネス価値が高く、かつ再試行できない場合の運用戦略

ビジネス価値が高く、なおかつ再試行が難しいリクエストの場合、単なる可用性向上だけではなく、障害発生時の影響を最小限に抑える設計や運用戦略が求められます。特に決済処理・電話対応・オンライン会議のように、一度の失敗が直接的な業務損失につながるケースでは、以下のような対策が重要です。

1. リクエストの確実な処理を保証する仕組み

リクエストの処理が途中で失敗してしまうと、不完全な状態が発生する可能性があるため、確実に処理が完了するように設計する必要があります。特に、決済処理や電話対応サービスのようなリアルタイム性が求められるシステムでは、一部の処理が成功し、別の処理が失敗することで業務に影響を与えるケースが多くあります。そのため、適切なトランザクション管理を行い、エラー時の対応を考慮することが重要です。

2. フォールバックと代替ルートの確保

  • 冗長化とフェイルオーバー
    • 決済処理の場合、複数の決済ゲートウェイを用意する。
    • 電話サービスでは、複数の通信プロバイダと接続。

3. リトライ可能にする

(私は実装したことないですがこういう手段も取れるなと思ったということで書いています)

  • トランザクションIDの導入
    • 転送が発生するたびに一意のトランザクションIDを発行し、関連する情報をログに蓄積
    • 転送が完了した際に、IDを元にまとめてクリア
  • TTL付きのキャッシュ利用 (Redis など)
    • 一時的な情報はTTL付きでキャッシュし、一定時間後に自動クリア
    • 転送完了時点で情報を整理し、必要なものだけを人に伝える
  • 状態マシンを活用
    • 転送前 → 情報収集 → 最終確認 → リセット
    • のような状態遷移を定義し、一定条件で自動リセットされる仕組みを導入

おわりに

1リクエストの価値を適切に評価し、ビジネス、システム、可用性の観点から最適なリソース配分を行うことが、持続可能なサービス運用には必要なのかなと最近ぼんやりと考えています。SLOとエラーバジェットの概念を活用しながら、リクエストの重要性を理解した上でのサービス運用を心がけていきたいと思います。