HTTP/2動演習：HPACK動的テーブルの深層と、メモリを喰い潰す悪夢のトレードオフ
こんにちは。インフラとプロトコルの泥臭いトラブルシューティングにまみれて早幾年、技術メディアで筆を執っているシニアネットワークアーキテクトの私です。
Web APIのパフォーマンスチューニングやインフラの負荷分散設計をしていると、「なぜかリバースプロキシやAPIゲートウェイのメモリ使用量がじわじわと増加し、最終的にOOM Killerに討ち取られる」という不可解な現象に直面したことはありませんか？
「コネクション数はそんなに多くないはずなのに……」と首を傾げるあなた。その犯人は、もしかするとHTTP/2の心臓部であるHPACK（HTTP Header Compression）の「動的テーブル管理」の不適切なチューニングかもしれません。
今回は、RFC 7540およびRFC 7541の仕様の裏側にある「パケットの挙動」と「メモリの現実」を紐解きながら、現場で生きる実践的なデバッグと設定のノウハウを伝授しましょう。
—
1. なぜHTTP/2ヘッダー圧縮（HPACK）が必要だったのか
HTTP/1.1の時代、リクエストのたびに送信される `User-Agent`、`Cookie`、`Authorization` などの冗長なヘッダー文字列は、帯域の大きな無駄でした。これを解決するため、HTTP/2では「HPACK」という専用の圧縮スキームが導入されました。
HTTP/1.1のテキストベースのヘッダーとは異なり、HPACKは以下の2つのテーブルを使ってヘッダーを軽量なインデックス番号に置き換えます。
1. 静的テーブル（Static Table）: RFC 7541で予め定義された61個の静的なエントリ（例: `:method: GET` は `2`、`:path: /` は `4` など）。
2. 動的テーブル（Dynamic Table）: 通信の過程で、動的に追加・更新されるエントリのリスト。
問題はこの「動的テーブル」です。通信相手（クライアントとサーバー）が互いに「これまでどんなヘッダーが送られてきたか」を記憶し続ける必要があるため、ここにメモリのトレードオフが発生します。
—
2. 動的テーブルの仕組みと `SETTINGS_HEADER_TABLE_SIZE`
動的テーブルは、接続（Connection）が確立された時点では空っぽです。しかし、リクエストやレスポンスに新しいヘッダー（あるいは既存の静的テーブルにないカスタムヘッダー）が含まれている場合、送信側はそれを動的テーブルに追加し、受信側も同じタイミングで同じエントリを自分の動的テーブルに追加します。
ここで重要になるのが、HTTP/2の接続設定フェーズでやり取りされるパラメータ、`SETTINGS_HEADER_TABLE_SIZE` です。
パラメータの意味とデフォルト値
- デフォルト値: `4096` バイト（4KB）
- 意味: 動的テーブルとして許容する最大メモリサイズを指定します。
受信側（例えばNginxなどのリバースプロキシ）は、自分自身が動的テーブル用に確保できるメモリの上限を、`SETTINGS_HEADER_TABLE_SIZE`（デフォルト4KB）としてクライアントに通知します。クライアントはこのサイズを超えて動的テーブルを肥大化させることはできません。
しかし、もしサーバー側が「うちのゲートウェイはメモリに余裕があるから、もっと大きなテーブルサイズを許容しよう」と設定を変更した場合、あるいはクライアント側が意図的に大きな値を要求・設定した場合、どうなるでしょうか？
—
3. 現場で直面する「メモリ消費と圧縮率」の残酷なトレードオフ
動的テーブルのサイズを大きくすれば、長大でユニークなカスタムヘッダーや、頻繁に送信されるAuthorizationトークンなどがテーブルに残り続けるため、ヘッダーの圧縮率は飛躍的に向上します。帯域幅の節約という観点では理想的です。
しかし、シニアエンジニアとして声を大にして言いたいのは、「圧縮率の追求は、サーバー側のメモリ枯渇リスクとトレードオフである」という事実です。
HTTP/2コネクションとメモリの数式
HTTP/2は単一のTCPコネクション上で複数の「ストリーム」を多重化（マルチプレクシング）します。ここで忘れてならないのは、動的テーブルは「コネクション単位」ではなく、厳密には「デコーダー/エンコーダーのコンテキスト単位（基本はコネクション単位）」で独立してメモリ上に保持されるという点です。
もし、1つのサーバープロセス（例: Node.jsやGoのHTTP/2サーバー、あるいはNginx）が、同時に 10,000件のクライアントコネクション を維持していたとしましょう。
- 動的テーブルサイズがデフォルトの 4 KB の場合：
$10,000 \times 4\text{ KB} = \mathbf{40\text{ MB}}$ （ヘッダー管理用メモリ）
- もしこれを設定ミスや高スループットチューニングで 64 KB に拡大していた場合：
$10,000 \times 64\text{ KB} = \mathbf{640\text{ MB}}$
これに加えて、各ストリームのバッファやTLSのセッション状態のメモリが乗っかってきます。「たった数百MB」と思われるかもしれませんが、Kubernetes上のコンテナなどでメモリリミットをシビアに設定している環境では、この動的テーブルの肥大化が原因で突如としてOOM Killerが発動する引き金になります。
—
4. 実務での設定・デバッグ手法（Nginx & Python / curl）
では、実務においてこのHPACK動的テーブルはどのようにコントロールし、どのようにトラブルシューティングすればよいのでしょうか。具体的なコードと設定を見ていきましょう。
① NginxにおけるHTTP/2バッファ・テーブル設定
Nginxをリバースプロキシとして運用する場合、HTTP/2関連のバッファサイズは非常に重要です。
http {
# HTTP/2接続におけるワーカーあたりの接続バッファサイズ
# 動的テーブルやリクエストヘッダーの受信用メモリプールの初期サイズを調整
http2_max_field_size 4k;
http2_max_header_size 32k;
# 注: Nginxのコア実装では、HPACKの動的テーブルサイズは
# RFC 7541に則り最大4096バイトをベースに最適化されていますが、
# クライアントからの過剰なリクエストヘッダーを受け止めるバッファは別途チューニングが必要です。
}
② Python (Hyper-hpack) を使った動的テーブル挙動のシミュレーション
Pythonの `hpack` ライブラリ（HTTP/2実装で広く使われているモジュール）を使い、動的テーブルのサイズ制限がどのように働くかをコードで確認してみましょう。
from hpack import Encoder, Decoder
エンコーダーとデコーダーの初期化
encoder = Encoder()
decoder = Decoder()
動的テーブルの最大サイズを変更する（例: 4096バイトから2048バイトへ縮小）
これにより、メモリ消費を抑えつつ、古いエントリが自動的にパージされる
encoder.header_table_size = 2048
decoder.header_table_size = 2048
サンプルヘッダーの定義
headers = [
(‘:method’, ‘GET’),
(‘:path’, ‘/api/v1/resource’),
(‘x-custom-tracking-id’, ‘a9b8c7d6-e5f4-3210-9876-543210fedcba’)
]
ヘッダーをHPACKでエンコード（圧縮）
この時点で動的テーブルにカスタムヘッダーが書き込まれる
encoded_data = encoder.encode(headers)
print(f”Encoded bytes length: {len(encoded_data)} bytes”)
デコード側の処理
decoded_headers = decoder.decode(encoded_data)
print(f”Decoded headers: {decoded_headers}”)
現在の動的テーブルのサイズを確認
print(f”Encoder dynamic table size: {encoder.current_table_size} bytes”)
③ curlを用いたデバッグ（パケットとフレームの観察）
クライアント側からHTTP/2の通信やSETTINGSフレームを確認するには、`curl` の詳細出力（`-v` や `–http2`）を利用します。
HTTP/2での通信を強制し、TLSハンドシェイクやSETTINGSフレームのやり取りを詳細に出力
curl -v –http2 https://api.example.com/healthz 2>&1 | grep -E “(<|>|HTTP/2)”
より低レイヤーでHTTP/2のバイナリフレーム（SETTINGSフレーム内の `SETTINGS_HEADER_TABLE_SIZE` の値など）を解析したい場合は、Wiresharkを用いるか、Go言語製の軽量プロキシ `h2load` や `nghttp2` コマンドを使用するのがプロの定石です。
nghttp2パッケージに含まれるnghttpd/nghttpコマンドで詳細なフレームログを追う
nghttp -v https://http2.golang.org/
出力結果の中に `Settings: HEADER_TABLE_SIZE=4096` といったログが現れます。ここを監視することで、サーバーとクライアントがどのような動的テーブルサイズで合意しているかが手に取るようにわかります。
—
5. まとめ：現場のアーキテクトが伝えるベストプラクティス
HPACKの動的テーブル管理は、「設定をいじればパフォーマンスが上がる魔法の杖」ではありません。最後に、実務で気をつけるべき指針をまとめます。
1. 基本はデフォルト（4KB）を信頼する: 特殊な組み込み機器や、極端に長大なヘッダーをやり取りするレガシーなマイクロサービス群でない限り、`SETTINGS_HEADER_TABLE_SIZE` を無理に大きくする必要はありません。
2. メモリの天井を常に意識する: 大規模トラフィックを扱うAPIゲートウェイやロードバランサーでは、「コネクション数 × 動的テーブルサイズ」がメモリを圧迫する隐れたボトルネックになることを忘れないでください。
3. オブザーバビリティ（可観測性）の確保: プロキシ層のメモリ使用率（RSS）がトラフィックに比例して右肩上がりになる場合は、HTTP/2のコネクション維持数とHPACKのバッファ割り当てを疑い、メトリクスを収集しましょう。
プロトコルの仕様を深く理解し、コードや設定の背後にある「メモリとCPUの物理的な挙動」を想像できるようになれば、あなたのインフラはどんな高負荷の荒波をも乗り越える堅牢な要塞となります。
それでは、次のトラブルシューティングの現場でお会いしましょう。
コメント