要約

  • 9月2日に研究者が紹介したBeelineは、アプリケーションのコードを変更せず、一部のアプリケーション層ポリシーをeBPFで処理する。
  • 論文ではHTTP/2のルーティングに全Podでのヘッダーキャッシュ無効化を求めている。Huffman符号化は引き続き利用できる。

導入費用をコードの変更量だけで測ると、設定をそろえる仕事が見えなくなる。9月2日のAPNIC Blogへの寄稿は、Beelineがアプリケーションのコードを変更せずに一部のポリシー処理をeBPFへ移せると説明する。一方、HTTP/2について論文を読むと、全Podに及ぶ設定条件がある。これは研究者による成果紹介であり、独立した本番導入評価ではない。

条件の理由は、通信の履歴にある。HTTP/2のHPACKでは、以前に保存したヘッダーフィールドを動的テーブルの参照で表せる。そのテーブルは特定の符号化・復号化コンテキストに属し、別の受信先が同じ履歴を持つとは限らない。ただし、あらかじめ定義された静的テーブルや文字列のHuffman符号化とは別の仕組みだ。RFC 7541はこれらを区別している。

論文第4版のIV-C節では、その履歴に依存する参照を別の受信先向けに解決する必要をなくすため、すべてのPodでヘッダーキャッシュを無効にする設計を採る。Huffman符号化には対応しているため、「HPACKの圧縮をすべて止める」と読むのは誤りである。

評価時の扱いにも範囲がある。gRPCとHTTP/2を使うHotel Reservationでは、Beelineのキャッシュを無効にし、比較対象のシステムでは有効にした。研究者は両設定を試し、自分たちの環境で差はごく小さかったと報告している。繰り返し現れるヘッダーの分布が違う業務でも費用が変わらない、という証明ではない。物理ノードとノード単位のEnvoyによる評価を、あらゆる商用サービスメッシュの実績と見なすこともできない。

8月27日のコミットに固定したREADMEには、評価に用いたカーネル6.16や暗号処理用の補助モジュールも記されている。研究実装の環境を確認するための情報であり、本番ホストを今すぐ変更せよという意味ではない。

問うべきは、次のアプリケーション更新でも同じHTTP/2条件が保たれるかどうかだ。資料は本番障害や独立監査済みの展開、移行の総費用を示していない。Lu Hengが説く、主張よりも現実を扱う姿勢に照らせば、必要なのは研究を礼賛したり否定したりすることではなく、設定の責任範囲を正確に記すことである。