コンテンツにスキップ

API のレスポンス時間が適切か？

Type: DeepDive
Category: パフォーマンス・スケーラビリティ
Audience: 設計リーダー / SRE / インフラ設計者 / レビュー担当者

背景・概要

APIはシステムとのインターフェースであり、ユーザー体験や内部システムの信頼性に直結する重要なレイヤーである

特にUIと連携するAPIやバッチ処理のトリガーとなるAPIでは、想定されるレスポンス時間とその変動幅（95パーセンタイルなど）を明示することが望ましい

APIレスポンス遅延の原因はDBだけでなく、バリデーション、認可、外部API呼び出し、シリアライズ処理など多岐にわたるため、全体像の把握が必要

例

  • 一覧系APIの95パーセンタイルが300ms以内で収まることを指標として定義する
  • Google Cloud Trace・AWS X-Ray・Azure Application Insights などのパフォーマンス監視ツールで、レスポンスの85%がDBアクセス由来であると判明し、N+1解消で短縮する
  • 非同期にできる処理（通知送信、ログ保存など）を切り出してレスポンス改善する

よくある失敗例

  • 特定ユーザーだけ遅いがクエリが偏っていてボトルネックに気づけなかった
  • バッチ処理の裏側で大量更新が走っており、通常時と異なるタイミングで急激なレスポンス低下が発生
  • 外部API依存があるにも関わらず、タイムアウトやフォールバック処理が未設計
  • オブジェクトのシリアライズ処理に時間がかかっていたが、観測手段が無く気づけなかった

FAQ

Q. レスポンス時間の目安ってどれくらい？

A. ユーザー向け画面なら300ms〜500ms程度、バッチや内部処理なら用途に応じて秒単位も許容範囲。ただしP95や最大値も併せて考慮すべき

Q. 外部APIが重い時はどうすればいい？

A. タイムアウト設定を明示し、非同期化・リトライ戦略・キャッシュ導入を検討する。可能ならフォールバックの仕組みも用意する

Q. 遅延のボトルネックはどう特定すべき？

A. APMやトレースツール（例: Cloud Trace, Datadog, Splunk）で各処理の内訳を可視化し、シリアライズ・認証・DB・ネットワークと切り分ける

関連観点