稼働率の予測はやめよう：PrometheusとSlothによるSLO導入の実践ガイド

Table of Contents

午前2時14分のモーニングコール

午前2時14分、ポケベル（ページャー）が鳴り響きました。クリティカルなマイクロサービスが「不健全（unhealthy）」とフラグを立てられたのです。眠い目をこすりながらログインすると、画面は緑一色.CPU負荷は12%でアイドル状態、メモリ使用量は安定しており、すべてのPodは「Running」でした。しかし、サポートチケットは殺到していました。ベルリンのユーザーがチェックアウトを完了できないというのです。これは典型的な罠です。私たちは機械の測定にばかり気を取られ、人間の体験を測定することを忘れていたのです。

5,000リクエスト/秒を処理するプラットフォームにこのSRE戦略を導入した結果、「誤報」率は60%低下しました。幽霊を追いかけるのではなく、サービスレベル目標（SLO）に焦点を当てたのです。ユーザーがバグに遭遇しているのに、ノイズの多いアラートに溺れているのであれば、単純なしきい値監視から脱却する時です。

インフラ監視 vs SREの信頼性

当初、私たちはディスクI/O、ネットワーク割り込み、コンテキストスイッチなど、あらゆるものを追跡していました。私はこれを「ボトムアップ」アプローチと呼んでいます。これはサーバーが遅い理由を説明してくれますが、顧客が実際に困っているかどうかは教えてくれません。データが多すぎて、情報が不足している状態です。

サイト信頼性エンジニアリング（SRE）は、これを「トップダウン」の視点で逆転させます。私たちは**サービスレベル指標（SLI）**、つまりチェックアウトのレイテンシのようにユーザーにとって重要なメトリクスを優先します。そして、そのメトリクスの目標値である**サービスレベル目標（SLO）**を設定します（例：支払いの99.9%が500ミリ秒以内に完了すること）。

特徴	従来の監視	SLOベースの監視
主な焦点	システムリソース (CPU/RAM)	ユーザー体験 (成功率/レイテンシ)
アラートのトリガー	即時のしきい値スパイク	エラー予算の燃焼率（バーンレート）
結果	対症療法的でノイズが多い	データ駆動型で戦略的

手動によるPrometheusルールの現実

PromQLを使用してPrometheusで直接SLOアラートを作成することもできます。私も初期の頃に試しました。しかし、1時間、6時間、3日間といった移動窓に対して同時にエラー率を計算する必要があります。これはメンテナンスの負担が大きく、スケーラビリティに欠けます。

うまくいく点

外部バイナリへの依存がゼロ。
生のPromQLロジックを完全に制御できる。

壊れやすい点

マルチウィンドウのバーンレート計算に苦戦し、ミスが発生しやすい。
各チームが少しずつ異なる、互換性のないバージョンを作成してしまう。
50行のアラートをコピペすることで、不可避な入力ミス（ファットフィンガー）によるバグが生じる。

ここで**Sloth**が状況を一変させます。Slothはジェネレーターです。明確なYAML定義を受け取り、実戦で検証済みの数千行に及ぶPrometheus의 レコーディングルールとアラートルールを自動的に生成します。

推奨される信頼性スタック

プロダクショングレードのKubernetes環境では、以下のツールキットを利用することをお勧めします：

Prometheus: 生のメトリクスを収集・保存するエンジン。
Sloth: 信頼性ルールを定義・生成するアーキテクト。
Grafana: 「エラー予算」（残りの許容ダウンタイム）を可視化するウィンドウ。
Alertmanager: 30日間の目標がリスクにさらされている場合にのみ、クリティカルな通知を送信するルーター。

実装：Slothのセットアップ

理論からターミナルへと移りましょう。リクエスト成功率99.9%を約束する「チェックアウトサービス」のSLOを定義してみます。

1. Slothのインストール

SlothはKubernetesオペレーターとしても動作しますが、CLIを使用するのが最も早く学ぶ方法です。環境に合わせたバイナリをダウンロードしてください：

curl -L -o sloth https://github.com/slok/sloth/releases/download/v0.11.0/sloth-linux-amd64
chmod +x sloth
sudo mv sloth /usr/local/bin/

2. SLO仕様の定義

checkout-slo.yamlを作成します。このファイルは、ビジネスにとって何が「良好」な状態であるかを正確に記述します。

version: "prometheus/v1"
service: "checkout-service"
slos:
  - name: "requests-availability"
    objective: 99.9
    description: "30日間のローリングウィンドウで、チェックアウトレスポンスの99.9%が成功する必要があります。"
    sli:
      events:
        error_query: sum(rate(http_requests_total{service="checkout", code=~"5.."}[{{.window}}]))
        total_query: sum(rate(http_requests_total{service="checkout"}[{{.window}}]))
    alerting:
      name: "CheckoutAvailabilityAlert"
      labels:
        severity: "critical"
        team: "core-commerce"

3. ルールの生成

重労働はSlothに任せましょう。このコマンドは、シンプルなYAMLを複雑なPrometheus設定に変換します：

sloth generate -i checkout-slo.yaml -o prometheus-rules.yaml

prometheus-rules.yamlを開くと、洗練されたレコーディングルールが表示されます。これらにより、30日間の信頼性目標に対して真の脅威がある場合にのみアラートがトリガーされ、軽微な一時的エラーによるアラートの「フラッピング（頻繁なオンオフ）」を防ぐことができます。

4. Prometheusへの接続

メイン設定でPrometheusに新しいルールを指定します：

rule_files:
  - "prometheus-rules.yaml"

リロード後、slo:error_budget:burn_rateのような新しいメトリクスがブラウザに表示されます。これらはサービスヘルスの心拍数となります。

エラー予算の可視化

**エラー予算**は、最も強力なツールです。99.9%のSLOを設定している場合、0.1%の「悪い」イベントが許容されます。サービスが100万回のリクエストを処理する場合、月にちょうど1,000回のエラーまでは許容できるということです。それ以上は許されません。

Grafanaでは、「稼働率」のパーセンテージを見るのをやめましょう。代わりに**残りのエラー予算（Remaining Error Budget）**を追跡してください。もし月の第2週までに予算の80%を使い果たしてしまったら、すべての新機能のデプロイを凍結しましょう。焦点を技術的負債と安定性にシフトするのです。これにより、会話の内容が「誰がビルドを壊したのか？」から「どうすれば信頼性の約束を守れるか？」へと変わります。

これを導入したことで、私たちのチームは場当たり的な消火活動を行う消防士から、プロアクティブなエンジニアへと進化しました。もはや、たった1つの500エラーで起きることはありません。ユーザーへの約束が実際に危機に瀕したときにだけ、呼び出されるようになったのです。