枯れた技術の「あがき」：ドメインシャーディングが暴くHTTP/1.1の限界とTCPの深淵
HTTP/2、そしてHTTP/3が普及した現代において、「ドメインシャーディング」という言葉を聞くと、どこか懐かしいレガシーな響きを感じるかもしれない。しかし、インフラの最前線に立つエンジニアであれば知っているはずだ。この手法は、単なる「HTTP/1.1の制限回避」という枠を超え、TCPの輻輳制御、TLSハンドシェイクのオーバーヘッド、そしてブラウザの挙動という、ネットワークスタック全体を最適化するための「ハックの歴史」そのものであることを。
なぜ「同時接続数制限」は必要だったのか
HTTP/1.1の仕様において、ブラウザには「ドメインあたり最大6接続」という暗黙の制約が存在した。これはRFC 2616時代から続く善意の産物だ。無制限にTCPコネクションを張れば、クライアント側だけでなく、サーバー側のリソースも食いつぶし、結果としてネットワーク全体の輻輳を招く。
しかし、Webページが巨大化し、1ページあたりのリクエスト数が数百に達するようになると、この「6接続」はボトルネックへと変貌した。そこで生み出されたのが、`static.example.com`、`assets1.example.com`のようにサブドメインを細分化し、ブラウザを「これらは別のホストである」と誤認させるドメインシャーディングである。
ドメインシャーディングの真実：パケットレベルの代償
ドメインシャーディングは、単にブラウザの制限を回避する魔法ではない。インフラアーキテクトの視点で見れば、これは「TCP接続の乱立」という名のパンドラの箱を開ける行為だ。
1. TLSハンドシェイクの増幅
サブドメインを分けるということは、そのドメインごとに名前解決（DNS）が発生し、そのたびに3-way handshakeに加え、TLSハンドシェイクが必要になる。TLS 1.2以前であれば、RTT（Round Trip Time）の増加は致命的だ。サーバー側で `TCP Fast Open` を有効にし、TLS 1.3の `0-RTT` への移行を検討しなければ、並列化によるメリットをハンドシェイクのオーバーヘッドが完全に相殺してしまう。
2. TCPバッファと輻輳制御の分断
TCPの `Slow Start` アルゴリズムを思い出してほしい。コネクションごとにCWND（Congestion Window）が独立して立ち上がるため、単一のコネクションを維持する場合よりも、帯域利用効率が極端に悪化する。特にモバイル回線のような不安定な環境では、複数のTCPコネクションが互いに帯域を奪い合うことで、パケットロス発生時の再送制御がカオスと化す。
実践的チューニング：シャーディングの呪縛から解き放たれるために
もし現在もドメインシャーディングを駆使した環境を運用・保守しているのであれば、以下のカーネルパラメータチューニングとサーバー設定を再確認すべきだ。
TCPウィンドウサイズの拡大（高レイテンシ環境でのスループット向上）
デフォルトが小さいと、高速な回線でも帯域を使い切れない
sysctl -w net.ipv4.tcp_rmem=”4096 87380 16777216″
sysctl -w net.ipv4.tcp_wmem=”4096 65536 16777216″
TCP Fast Openの有効化（ハンドシェイクのRTTを1つ削減）
サーバー側での設定例
sysctl -w net.ipv4.tcp_fastopen=3
また、Nginx側では `keepalive` を極限までチューニングし、コネクションの再利用を強制する必要がある。
upstream backend_servers {
server 127.0.0.1:8080;
# コネクションをプールし、無駄な再接続を抑制する
keepalive 32;
}
server {
# 接続維持時間を短くしつつ、再接続を減らすバランスを探る
keepalive_timeout 65;
keepalive_requests 1000;
}
現代における「正しい」選択
ドメインシャーディングは、HTTP/1.1の環境下では「苦肉の策」として正当化された。しかし、HTTP/2の登場により、状況は一変した。HTTP/2は単一コネクションでのマルチプレキシング（多重化）を実現し、`HPACK` というヘッダー圧縮アルゴリズムで帯域を節約する。
もしあなたが今、新しいインフラを設計しているなら、ドメインシャーディングを導入してはいけない。 それは、クライアントに余計なDNSルックアップを強要し、HTTP/2の多重化メリットを自ら捨てることに他ならないからだ。
私たちが目指すべきゴール
1. HTTP/2への完全移行: `h2` を基本とし、TLS 1.3によるハンドシェイク高速化を標準とする。
2. CDNの活用: エッジサーバーでのキャッシュ制御により、オリジンへのTCPコネクション数自体を削減する。
3. サーバープッシュの慎重な利用: HTTP/2のプッシュ機能は強力だが、使い所を誤れば帯域を浪費する。キャッシュ状況を考慮した賢明な設計を。
結論
ドメインシャーディングは、プロトコルの限界をハックで乗り越えようとしたエンジニアたちの「執念」の結晶だ。しかし、技術の進化を追う我々は、その「枯れたハック」に依存し続けるのではなく、なぜそのハックが必要だったのかという「ネットワークの本質」を理解しなければならない。
インフラアーキテクトにとっての正解は、常に「現在のプロトコルの制約を理解し、次の時代のスタンダードを先取りすること」にある。HTTP/1.1の呪縛を解き、TCPのフロー制御を理解し、よりクリーンで効率的なアーキテクチャを構築すること。それこそが、パケットを愛する我々の責務ではないだろうか。
コメント