APIの「遅延」はアーキテクチャの敗北か？HTTP/2で手に入れる真のパフォーマンス
ネットワークエンジニアとして現場に立っていると、頻繁に耳にするのが「APIのレスポンスが遅い」という嘆きです。アプリケーションコードを最適化し、データベースのクエリをチューニングしても、なぜか解消しない。そんなとき、多くのエンジニアが盲点とするのが「HTTPというプロトコルそのものの制約」です。
今日は、現代のWeb APIにおける高速化の切り札である「HTTP/2」について、理論と現場の実務を交えて深掘りしていきましょう。
—
1. HTTP/1.1の限界とHTTP/2のパラダイムシフト
HTTP/1.1の時代、ブラウザやクライアントは「ドメインごとの同時接続数」に縛られていました。複数のリソースを取得しようとすると、TCP接続を何度も確立（3-way handshake）しなければならず、さらに「Head-of-Line Blocking（HOLB）」という悪魔が立ちはだかりました。
つまり、前のリクエストのレスポンスが返ってくるまで、次のリクエストがブロックされてしまうのです。これを解決するために、我々は必死にドメインシャーディング（複数のサブドメインにリソースを散らす）を行ってきましたが、これはあくまで対症療法に過ぎません。
ここで登場したのがHTTP/2（RFC 7540）です。
マルチプレキシング：単一TCP接続の魔法
HTTP/2の最大の恩恵は「マルチプレキシング（多重化）」です。一つのTCP接続上で複数のストリームを同時に流すことができます。これにより、接続確立のオーバーヘッドを劇的に削減し、リクエストの順序待ちという呪縛から解放されました。
—
2. HPACK：ヘッダー圧縮という静かなる革命
REST APIを多用する現代では、全ての通信に Authorization や User-Agent といった、冗長なヘッダーが付与されます。これらを毎回フルテキストで送るのは、まさに「帯域の無駄遣い」です。
HTTP/2では「HPACK」と呼ばれるアルゴリズムでヘッダーを圧縮します。
- 静的テーブル: よく使われるヘッダー（
:method: GETなど）をあらかじめ定義。 - 動的テーブル: 通信中に動的に追加されるヘッダーをキャッシュし、2回目以降は「インデックス番号」だけを送る。
これにより、パケットサイズは驚くほど小さくなります。特に、頻繁に小さなAPIコールを繰り返すマイクロサービスアーキテクチャでは、この恩恵は計り知れません。
—
3. 実践：HTTP/2の効果を測定する
理屈だけでは実務になりません。まずは、自分のAPIサーバーがHTTP/2で通信できているか、curlを使って確認する習慣をつけましょう。
# -I オプションでヘッダーのみ取得、--http2 でHTTP/2を指定
curl -I --http2 https://api.example.com
# 出力結果の1行目が重要
# HTTP/2 200 となっていれば成功ですもし、サーバー側（Nginxなど）の設定を確認したい場合は、以下のように設定します。
# Nginxの設定例: HTTP/2の有効化
server {
listen 443 ssl http2; # http2パラメータを追加するだけ
server_name api.example.com;
ssl_certificate /path/to/cert.pem;
ssl_certificate_key /path/to/key.pem;
# HTTP/2はTLS必須です
}—
4. 現場で使えるTips：API設計への落とし込み
HTTP/2が使えるからといって、無制限にリクエストを投げていいわけではありません。以下の点に注意してください。
1. 「細分化しすぎ」に注意
マルチプレキシングは魔法ではありません。クライアントとサーバーの間に数千ものストリームを開くと、フロー制御のオーバーヘッドが発生します。API設計としては、依然として「必要十分な粒度」を保つことが重要です。
2. ストリームの優先順位付け（Dependency & Weight）
HTTP/2にはストリームの重要度を指定する機能があります。クリティカルなレンダリングに必要なリクエストには高い優先度を割り当てる設計が可能ですが、これはインフラ側よりも、むしろgRPCのようなフレームワークを利用する際に意識すべき概念です。
3. デバッグの必須ツール
ネットワークの挙動が怪しいときは、Chromeの「Network」タブを「Protocol」列を表示するように設定してください。h2 と表示されていればHTTP/2、そうでなければ http/1.1 です。
—
最後に：ネットワークスペシャリストからの助言
HTTP/2への移行は、アプリケーションコードを1行も書き換えずにパフォーマンスを改善できる、極めてコストパフォーマンスの高い施策です。
しかし、プロトコルをアップグレードしただけで満足してはいけません。tcpdump を取り、実際にRTT（ラウンドトリップタイム）がどう改善したのか、パケットのシーケンスを見て確認する癖をつけましょう。「なぜ速くなったのか」を論理的に説明できるエンジニアこそが、真のインフラアーキテクトです。
次回のブログでは、HTTP/3（QUIC）がもたらす「コネクションマイグレーション」の脅威と可能性について解説します。ネットワークの深淵はまだまだ奥が深いですよ。それでは、また現場でお会いしましょう。
コメント