GCP Cloud CDNの深淵：Brotli圧縮とTLS最適化がもたらす「エッジの静寂」
ネットワークエンジニアにとって、ユーザーの「体感速度」とは、実は非常に冷徹な数値の集積に過ぎません。RTT（Round Trip Time）の削減、TCPスロースタートの克服、そして何より、限られた帯域をいかに効率的に使い切るか。これらは現代のWebインフラにおいて、避けては通れない「物理層の呪縛」です。
今日は、Google Cloud CDNが提供するエッジでのオンザフライ圧縮（Brotli / Gzip）と、その裏側に隠されたトランスポート最適化の深層にメスを入れます。
BrotliとGzip：バイト単位のせめぎ合い
Cloud CDNにおける動的/静的コンテンツの圧縮は、単なる「計算リソースの節約」ではありません。それは、クライアントの Accept-Encoding ヘッダーをトリガーとした、エッジサーバー上のプロトコル変換プロセスです。
Googleが強力にプッシュする Brotli は、Gzip（DEFLATE）に比べ、テキストベースのコンテンツにおいて圧縮率で約15〜25%の優位性を誇ります。これは、単に計算量の問題ではなく、辞書圧縮アルゴリズムの最適化の賜物です。
なぜエッジで圧縮すべきなのか？
もしオリジンサーバー（GKE上のPodやCompute Engineなど）で全ての圧縮を行えば、オリジンのCPU負荷が増大し、その結果としてアプリケーションの応答時間がスパイクします。Cloud CDNにこれを任せることで、オリジンは「未圧縮の生データ」を送ることに集中でき、エッジの強力な計算リソースで最適化されたペイロードをユーザーに届けるという、理想的な役割分担が完成します。
TLSハンドシェイクとTCP最適化：RTTを削り出す
圧縮だけではレイテンシは解消されません。重要なのは、クライアントとエッジ間の「握手」です。
Cloud CDNは、Googleのグローバルネットワークの末端で TLS 1.3 を強制的に最適化します。TLS 1.3 では、ハンドシェイクの往復回数が削減され（1-RTT）、かつ 0-RTT（Early Data）の可能性も秘めています。
トランスポート層のチューニング
我々SREが注目すべきは、TCPの initcwnd（Initial Congestion Window）です。Googleのインフラでは、この初期ウィンドウサイズがデフォルトで最適化されており、大きなHTMLやCSSを送り出す際、最初のパケット群でTCPスロースタートの制限を可能な限り回避します。
以下の設定は、バックエンド（オリジン）側で最低限守るべき最適化指針です。
# オリジン側のNginx設定例
# Cloud CDNからのリクエストを効率よく処理するためのチューニング
http {
# 接続の持続性を確保し、再接続のオーバーヘッドを排除
keepalive_timeout 65;
keepalive_requests 1000;
# TCPの送信バッファを最適化（カーネルレベルと連動）
tcp_nopush on;
tcp_nodelay on;
# クライアントのAccept-Encodingに応じた分岐はCDNに任せ、
# オリジンは「素のデータ」を渡すことに特化する
gzip off;
}セキュリティの「穴」を塞ぐ：Varyヘッダーの正しい扱い
圧縮機能を利用する際、最も陥りやすい罠が Vary ヘッダーの不適切な管理です。
CDNエッジが Accept-Encoding: br を見てBrotli圧縮データをキャッシュした場合、適切に Vary: Accept-Encoding ヘッダーをレスポンスに含めなければ、別のブラウザ（例えば br を解釈できない古いクライアント）に圧縮されたゴミデータが配信される事故が起きます。
Cloud CDNは自動的に Vary ヘッダーを適切に処理しますが、もしカスタムオリジンを構築しているなら、以下の点に注意してください。
- キャッシュキーの正規化:
Accept-Encodingをキャッシュキーの一部に含める設定を怠らないこと。 - セキュリティヘッダーの注入: エッジで圧縮を行う場合、
Content-Lengthが変化します。Transfer-Encoding: chunkedが適切に付与されているかを確認してください。
究極のパフォーマンスを求めて
我々が現場で目撃する「遅いCDN」の正体は、多くの場合、Cloud CDN側の問題ではなく、オリジンサーバーまでの TCP Keep-Alive が適切に設定されていないことに起因します。
実践的なアーキテクチャ・チェックリスト
1. プロトコル最適化: オリジンとCloud CDNの間でも HTTP/2 または HTTP/3 を使用し、多重化によるヘッド・オブ・ライン・ブロッキングを排除すること。
2. 証明書の管理: GFE（Google Front End）の証明書と、オリジン側のTLS証明書の整合性を保ち、SNI（Server Name Indication）が正しく機能するようにすること。
3. ヘッダーのクリーンアップ: X-Forwarded-For や X-Cloud-Trace-Context が適切に引き継がれ、デバッグが可能な状態を維持すること。
結びに代えて
Cloud CDNの圧縮機能は、単なる機能ではありません。それは、巨大なGoogleのネットワークを、あなたのアプリケーションの「拡張されたNIC（ネットワークインターフェース）」として利用するための強力なツールです。
ネットワークのレイテンシは、物理的な距離という絶対的な制約と、ソフトウェアによる最適化という知的な挑戦の境界線にあります。パケットが光速で駆け巡る際、そこに「圧縮」という名の知的な間引きが加わることで、ユーザーは「一瞬」を体験するのです。
皆さんのインフラが、今日も軽快なパケットの往来に満たされていることを願っています。
コメント