【入門編】 APIの監視におけるゴールデンシグナル(Latency, Traffic, Errors, Saturation) – Web APIアーキテクチャ・データ連携実践ガイド

こんにちは！インフラアーキテクトの私です。普段はルーターやサーバーの向こう側を飛び交うパケットたちと会話する日々を送っていますが、今日は皆さんと一緒に「APIの監視」について、少しおしゃべりしてみたいと思います。

APIを作って公開したはいいものの、「今、ちゃんと動いてるのかな？」「ユーザーに怒られてないかな？」と、夜も眠れなくなることってありませんか？

今回は、GoogleのSRE（サイト信頼性エンジニアリング）のバイブルにも登場する「ゴールデンシグナル（4つの黄金律）」をテーマに、APIの健康状態を正しく把握する方法を、身近な例えを交えながら優しく紐解いていきましょう。難しい専門用語はいったん脇に置いて、一歩ずつ理解していきましょうね！

—

1. なぜAPIの「監視」が必要なの？（郵便配達で考えてみる）

皆さんは、大切な書類を遠くの友人に送るとき、どうしますか？ 郵便局の窓口に出して、あとは「届くのを祈るのみ！」というわけにはいきませんよね。

  • 「今、ちゃんと配達中かな？」
  • 「宛先不明で戻ってきてないかな？」
  • 「郵便局の窓口がめちゃくちゃ混んでて、受け付けてもらえないことはないかな？」

私たちが作るWeb APIもこれと全く同じです。クライアント（スマホアプリやブラウザ）から送られてきたリクエスト（お手紙）が、サーバー（お家）に無事に届き、素早く返事（お返事）ができているか。これを外側から、あるいは内側から見守る仕組みがAPIの監視です。

ここで登場するのが、Google SREが提唱する「ゴールデンシグナル」と呼ばれる4つの指標です。これさえ押さえておけば、APIの体調不良をいち早くキャッチできるようになりますよ！

—

2. ゴールデンシグナルの4つの主役たち

ゴールデンシグナルとは、以下の4つの要素の英語の頭文字をとったものです。

1. Latency（レイテンシー：遅延）
2. Traffic（トラフィック：交通量）
3. Errors（エラー：失敗）
4. Saturation（サチュレーション：飽和度）

それぞれの意味を、身近な例えと一緒に優しく見ていきましょう。

① Latency（レイテンシー）：「お返事が届くまでにかかる時間」

ラーメン屋さんを想像してください。注文してからラーメンが出てくるまでの時間が長すぎると、「まだかな……」とイライラしちゃいますよね。
APIの世界でも同じです。クライアントが GET /api/users のようなリクエストを送ってから、サーバーが処理を終えてレスポンスを返すまでの「時間（ミリ秒など）」がレイテンシーです。ここが急に遅くなったら、データベースが重くなっているなどの悲鳴が隠れているサインです。

② Traffic（トラフィック）：「お店の混雑具合（リクエスト数）」

今、どれくらいのお客さんがお店にやってきているか、その「交通量」を表します。
「1秒間に何件のリクエスト（requests/sec）が来ているか」を測ります。平日の昼間は静かなのに、セールの時間になると一気に交通量が跳ね上がる、といった波を把握することが大切です。

③ Errors（エラー）：「注文と違うものが出てきたり、門前払いされたりした割合」

「ごめんなさい、その商品は売り切れです（404 Not Found）」や、「サーバーがお腹を壊しちゃいました（500 Internal Server Error）」といった、失敗したリクエストの割合です。
全体の交通量のうち、何パーセントがエラーになってしまったのかを監視します。エラーが急増しているときは、プログラムのバグやデータベースのダウンを疑う必要があります。

④ Saturation（Saturation：サチュレーション）：「お店のキャパシティの限界度」

お店の座席数に対して、どれくらいお客さんが埋まっているかを表します。
CPUの使用率が90%に達していたり、メモリの空き容量がギリギリだったり、同時接続数の上限に近づいていたりする状態です。ここが100%（飽和状態）になってしまうと、新しいお客さんを全く受け入れられなくなってしまいます。

—

3. 実践！Python (FastAPI) でゴールデンシグナルを計測・出力する

「なるほど、考え方は分かったけれど、実際にどうやってデータを集めるの？」という疑問が湧いてきますよね。

ここでは、今どきのWeb API開発で大人気のPythonフレームワーク FastAPI を使って、リクエストの「レイテンシー」「トラフィック」「エラー」を簡易的に計測・ログ出力するコードを見てみましょう。

特別な高価なツールを使わなくても、まずはこうして仕組みの基本を知ることが大切です。

import time
import logging
from fastapi import FastAPI, Request, HTTPException
from starlette.responses import Response

# ログの出力設定（コンソールに綺麗に表示させます）
logging.basicConfig(level=logging.INFO, format="%(asctime)s [%(levelname)s] %(message)s")
logger = logging.getLogger(__name__)

app = FastAPI()

# 【ミドルウェア】すべてのリクエストの出入りを見守る「番人」のような仕組みです
@app.middleware("http")
async def monitor_api_signals(request: Request, call_next):
    # 1. Traffic（トラフィック）の計測開始：どのパスにリクエストが来たか
    path = request.url.path
    method = request.method
    
    # 2. Latency（レイテンシー）の計測開始：時計をスタート！
    start_time = time.time()
    
    try:
        # 実際にAPIの処理を実行する
        response: Response = await call_next(request)
        status_code = response.status_code
    except Exception as e:
        # 予期せぬ例外（クラッシュなど）はすべてエラー（500系）として扱う
        status_code = 500
        logger.error(f"予期せぬエラーが発生しました: {e}")
        raise e
    finally:
        # 3. Latencyの計測終了：経過時間を計算（ミリ秒に変換）
        process_time = (time.time() - start_time) * 1000
        
        # 4. Errors（エラー）の判定：ステータスコードが400以上なら要注意！
        log_level = logging.WARNING if status_code >= 400 else logging.INFO
        
        # ログとして記録（実務ではここにPrometheusやDatadogなどの監視メトリクスを流し込みます）
        logger.log(
            log_level,
            f"METHOD={method} PATH={path} STATUS={status_code} LATENCY={process_time:.2f}ms"
        )
        
    return response

# テスト用のAPIエンドポイント
@app.get("/api/greet")
def say_hello():
    # わざと少し待つ処理（レイテンシーの雰囲気を体験するため）
    time.sleep(0.05) 
    return {"message": "こんにちは、インフラの世界へようこそ！"}

@app.get("/api/error-test")
def trigger_error():
    # わざとエラーを返すエンドポイント
    raise HTTPException(status_code=400, detail="不正なリクエストです")

このコードを動かすと、サーバーにリクエストが届くたびに、コンソール画面に次のようなログが出力されます。

202X-XX-XX 12:34:56,789 [INFO] METHOD=GET PATH=/api/greet STATUS=200 LATENCY=52.14ms
202X-XX-XX 12:35:10,123 [WARNING] METHOD=GET PATH=/api/error-test STATUS=400 LATENCY=2.05ms

「どのパスに」「どんなステータスコードで」「何ミリ秒かかったか」が綺麗に記録されていますよね。これが監視の第一歩です！

—

4. 現場で役立つ！監視設計の3つの心得

最後に、実際の現場でゴールデンシグナルを使って監視を組み立てるときの、ちょっとしたコツをお伝えします。

1. すべてを一度にやろうとしない
最初から高価な監視ツールや複雑なダッシュボードを導入する必要はありません。まずは先ほどのコードのように、サーバーのログ出力から「エラーが増えていないか」「遅くなっていないか」を確認する習慣をつけることが大切です。
2. 「しきい値（アラートの基準）」を正しく決める
「レイテンシーが1秒を超えたら夜中にスマホを鳴らす！」と設定してしまうと、ちょっとした混雑で何度も起こされてエンジニアが倒れてしまいます。「通常の99%のリクエストが200ミリ秒以内に返っているか（P99レイテンシー）」というように、ユーザー目線に立った現実的なラインを引きましょう。
3. 飽和度（Saturation）のボトルネックを見つける
CPUが一杯なのか、データベースへのコネクションが枯渇しているのか。サチュレーションの指標は、インフラのどこが弱いかを教えてくれる宝の地図のようなものです。

—

おわりに

今回は、APIの監視におけるゴールデンシグナル（Latency, Traffic, Errors, Saturation）について、郵便配達やラーメン屋さんの例えを交えて解説しました。

難解に思えるインフラの指標も、「お客さんの満足度や、お店の健康状態を守るためのもの」だと分グッと身近に感じられたのではないでしょうか。

あなたの作るAPIが、今日も明日も、世界中のユーザーへスムーズにお手紙を届けられますように。それではまた、次のパケットの旅でお会いしましょう！

スポンサーリンク

コメント

タイトルとURLをコピーしました