2025.05.20

API監視について解説してみた

keichan

Contents

概要
1. 監視の目的と重要性
2. 主要なメトリクス
3. レイテンシ監視とパーセンタイル
4. 運用上よくある誤解
5. メトリクスの可視化とアラート設計
6. まとめと今後のトピック例

概要

5月に入ると湿度がすごくて大変ですね。蒸し暑いのが苦手でサウナにハマれないkeichanです。

今回はAPIパフォーマンス監視について解説していきます。
APIパフォーマンス監視は、複数コンポーネントで構成されるシステムにおいてUXを維持・向上するために不可欠です。
現代の運用においては、過去から踏襲されてきたインフラ監視だけではユーザー目線での監視は行えず、
これらのパフォーマンス監視を行うことが非常に重要となっています。

特にレイテンシ、スループット、エラー率、SLA/SLOといったメトリクスに着目し、パーセンタイル活用法や平均値依存の誤解を避けるポイント、メトリクス可視化・アラート設計の例を具体的に紹介します。

1. 監視の目的と重要性

APIはシステム内外のコンポーネントをつなぐ重要な接点です。その性能劣化やエラーはユーザー体験に直結し、システム全体に波及します。例えば、APIの1つに遅延が生じるだけでレスポンスが遅くなり、ユーザーの操作感が悪化します。

インフラ監視だけではCPU使用率など内側の状態は分かっても、実際の応答速度や信頼性は測れません。アプリケーションレイヤーの監視に重点を置くと、可用性やエンドユーザー体験の最適化に注力でき、実際の利用状況に即した改善が可能になります。

API監視によりダウンや性能劣化を顧客より先に検知でき、ボトルネックの原因究明やサービス品質の維持が容易になります。監視すべきSLI（Service Level Indicator）としては、レイテンシやエラー率、スループット、可用性などが典型的です。これらはユーザー期待やビジネス優先度と直結する指標であり、SLO/SLA設定やリソース配分にも役立ちます。

2. 主要なメトリクス

API性能を把握するための代表的なメトリクスを以下にまとめます。ユーザーにとっての待ち時間や信頼性を測る指標を優先的に監視します。

メトリクス	説明
レイテンシ（応答時間）	リクエスト送信からレスポンス完了までの時間。低いほどユーザーの待ち時間が短く、体験が向上します。リアルタイム系サービスでは特に重要です。
スループット	単位時間あたりの処理リクエスト数（例：TPS、RPM）。サーバがどれだけ負荷に耐えられるかの目安であり、急激な変化は障害やボット攻撃の兆候になることがあります。
エラー率	全リクエストに対するエラー発生割合。システムの信頼性指標で、許容上限を超えると即時対応が必要です。エラーにも致命度があり、影響の大きいエラーには厳しい閾値設定をします。
可用性（稼働率）	サービスが正常に応答している時間の割合（例：月間99.9%稼働）。一般にSLA/SLOで定義される指標で、99%以上を目標にすることが多いです。

これら指標はシステムの健全性だけでなくユーザー体験を数値化する役割も果たします。
SLAは契約上の保証、SLOは内部目標なので、一般にSLOよりも厳しめに設定し、違反を未然に防ぎます。
例として「99.9%可用性」や「95%のリクエストは200ms以内で応答」などがSLOの一例です。

3. レイテンシ監視とパーセンタイル

レイテンシの分布を把握するため、平均値だけでなくパーセンタイル指標を使うことが重要です。
パーセンタイルとは、ある時間以下で応答したリクエストの割合を表す指標です。

P50（50thパーセンタイル）: リクエストの50%がこの時間以下で完了する値（中央値）。典型的な応答時間を示します。
P90 / P95: それぞれ90% / 95%のリクエストがこの時間以下で完了する値。一般的なユーザーの体感速度を表します。
P99: 99%のリクエストがこの時間以下で完了する値（上位1%の遅いリクエストを含む）。

平均応答時間だけでは一部のリクエストに大きな遅延が起きていても隠れてしまいます。
このような外れ値を見逃さないために、P95やP99を見るのが有効です。
例えば、平均100msのAPIで5分間にわたってP99が閾値を超えた場合にアラートを出せば、潜在的な問題を早期に検知できます。

# 【サンプル: レイテンシパーセンタイルの計算 (Python例)】
import numpy as np

response_times_ms = [120, 80, 200, 95, 110, ...]  # 応答時間（ミリ秒）のリスト
p95 = np.percentile(response_times_ms, 95)
print(f"P95レイテンシ: {p95} ms")  # 全リクエストの95%がこの値以下で応答

4. 運用上よくある誤解

平均値依存
「平均レイテンシが低いから問題ない」と思いがちですが、平均値では一部のユーザーに極端に遅いリクエストが発生していても分かりません。中央値(P50)やP95以上も必ず確認しましょう。
インフラ指標のみ監視
CPUやメモリ使用率が低くても、ネットワークや外部APIの影響で応答が遅くなる場合があります。アプリケーション視点のメトリクスを無視すると本質的な問題を見逃します。
SLOの設定ミス
SLOを100%に設定するとエラーバジェットがなくなり、実務上望ましくありません。一般にはSLA99.95%ならSLOをさらに厳しく（例：99.99%）設定します。
固定閾値アラート
トラフィックの増減を考慮しない静的閾値は誤警報のもとです。通常時や高負荷時の振る舞いを理解し、動的な閾値や異常検知を活用すると誤報を減らせます。

5. メトリクスの可視化とアラート設計

監視データはダッシュボードで可視化し、アラートを設定して自動通知します。例えば、レイテンシのP50/P95/P99を時間経過で重ねたグラフと、同期間のエラー率・スループットを並べて表示します。これにより、遅延が発生したタイミングでエラー率やトラフィック変動を同時に把握できます。

# 【サンプル: アラート閾値チェックの擬似コード】
if error_rate > 0.01:
    send_alert("警告: エラー率が1%を超えました")
if p95_latency_ms > 500:
    send_alert("警告: P95レイテンシが500msを超えました")
if throughput_change < -0.2:
    send_alert("警告: スループットが20%以上低下しました")

また、過去データに基づく動的閾値（ベースラインからの乖離）を使えば、季節性やバーストを学習して偽陽性を抑えることもできます。