クラシックな接続モデルでは、多数のクライアントがバックエンド側で同数のTCPまたはTLS接続に変換されます。新規接続のたびに3ウェイTCPハンドシェイク、TLSハンドシェイク、ソケット管理、切断コストが発生します。トラフィックが増えるにつれ、バックエンドは実際のアプリケーションロジックよりも接続オーバーヘッドに多くの時間を費やします。
短く頻繁なAPIリクエストは問題をより顕著にします。モバイルアプリケーション、B2B呼び出し、マイクロサービス、チェックアウトフローはすべて多くの小さなリクエストを生成します。各リクエストが新規接続になると、CPU、メモリ、ソケット、ネットワークリソースが不必要に消費されます。
フロントエンドでのHTTP/1.1の動作もまた別の制約です。特定の接続上の遅いリクエストは後続のリクエストをブロックする可能性があり、並列ストリーム容量が制限されます。モダンなクライアントトラフィックはHTTP/2とHTTP/3でより効率的に処理でき、バックエンドの接続管理もそれに対応する必要があります。
正しいアプローチは、クライアント接続をバックエンドに1対1でミラーリングすることではありません。接続をプールして再利用し、サービスタイプごとに多重化動作を調整することです。非冪等操作にはより安全な再利用モードが、大量のAPIにはよりアグレッシブなモードが適しています。
TR7接続多重化はこのモデルを提供します：フロントエンドではモダンなストリーム多重化、バックエンドではkeepealiveプール、管理可能なサービスごとの接続再利用ポリシーを実現します。
TR7はバックエンドkeepealiveプール、サービスごとの再利用モード、HTTP/2およびHTTP/3プロトコルサポート、TLSセッション再利用を通じて接続多重化を実装します。
バックエンドへの接続はリクエスト完了時にすぐ閉じられず、再利用のためプールに返されます。これによりバックエンド側のTCPおよびTLSハンドシェイクオーバーヘッドが削減されます。
接続再利用は4つのモードで管理できます：never、safe、aggressive、always。オペレーターはセキュリティ要件、冪等性の制約、スループット目標のバランスを取りながら各サービスに適した動作を選択します。
HTTP/2 ALPNにより、単一接続上で複数の並列ストリームを処理できます。これは特に多数の短いAPIリクエストに効果的で、クライアント側の接続効率を向上させます。
TLSセッション再利用により、リターンクライアントがフルハンドシェイクをスキップできます。TLS負荷の高いサービスではCPU消費と接続セットアップレイテンシが削減されます。
接続多重化はサービスごとの再利用、keepealive、HTTP/2、HTTP/3、タイムアウトプロファイルによりバックエンドの接続オーバーヘッドを削減します。
TR7はプールレベルのアクションとして接続再利用を管理します。neverモードはリクエストごとに新規接続に近い動作をします。safeはより制御された再利用を提供します。aggressiveとalwaysは大量のサービスへのより積極的な接続節約を目指します。オペレーターは各サービスのパフォーマンスと安全性のニーズを反映したモードを選択します。
バックエンド側でkeepealiveが有効になると、リクエスト完了時に接続がプールに返されます。次のリクエストは新規接続を開く代わりに既存の接続を使用します。これにより短いリクエストの接続セットアップコストが大幅に削減され、バックエンドにより安定した予測可能な接続プロファイルをもたらします。
TR7はクライアント側でHTTP/2 ALPNをサポートし、単一接続上で複数のストリームを処理します。これによりブラウザとモバイルクライアントが開く必要がある接続数が減ります。レイテンシとリソース消費がより予測可能になります。HTTP/2サポートはモダンなWebとAPIトラフィックのベースラインパフォーマンス層です。
バックエンド側のHTTP/2はサービスレベルでオプトインです。バックエンドがHTTP/2をサポートする場合、ALPNがh2またはhttp/1.1を自動的にネゴシエートします。HTTP/2をサポートしないサービスは自動的にHTTP/1.1にフォールバックします。これにより、モダンなバックエンドはHTTP/2の利点を得ながらレガシーサービスには影響を与えません。
TR7はフロントエンドでHTTP/3/QUICを介してモダンなクライアントトラフィックを処理します。モバイルと損失の多いネットワークでは接続セットアップとストリームの継続性が向上します。HTTP/2フォールバックにより後方互換性が保たれます。バックエンド側は独自のプロトコル機能に応じて個別に管理されます。
safe再利用モードは危険または非冪等な操作に対してより保守的な動作を適用します。銀行、決済、書き込みが多いAPIでは、パフォーマンスの最適化がデータ整合性を犠牲にしてはなりません。このモードは再利用を安全な境界内に保ちます。オペレーターは高感度サービスにはaggressiveの代わりにsafeを選択できます。
TLSセッション再利用により、同じクライアントがフルハンドシェイクを繰り返さずに再接続できます。TLS 1.2セッションチケットとTLS 1.3 PSKメカニズムの両方がこの動作をサポートします。HTTPS負荷が高い場合、ADC CPU使用量が大幅に削減されます。これは短命の接続が多いモバイルやAPIシナリオで特に価値があります。
HTTPのkeepalive、client-fin、server-fin、tunnel、connect、server、client、queueのタイムアウト値がすべて接続プールの動作を形成します。タイムアウトが短すぎるとプールが枯渇し再利用率が低下します。長すぎるとアイドル接続数とメモリ消費が増加します。TR7はこのバランスをサービスプロファイルごとに管理可能にします。
接続制限はプールレベルとバックエンドレベルで定義できます。これらの制限はバックエンドサービスを突然の接続バーストから保護します。接続容量が小さいまたはライセンスされたアプリケーションに特に重要です。接続多重化とmaxconn制限を組み合わせることでより予測可能な容量動作が得られます。
毎秒の新規接続レートは上限で制限できます。これによりボット波、モバイルの再接続ストーム、突然のトラフィックスパイクによるバックエンドサービスの過負荷を防ぎます。keepealiveプールが再利用を処理する一方で、新規接続レートは個別に管理されます。
クライアントとバックエンドの両側でのTCP keepealiveシグナルにより、中間のネットワーク機器がアイドル接続をサイレントに閉じるのを防ぎます。長期間開いたままの接続はファイアウォールとNATのタイムアウトの影響を受けます。Keepealiveはそれらの接続を維持します。これは長いセッションや低頻度のトラフィックを持つサービスに特に重要です。
設定が変更されると、既存の接続はドレインされながら新規接続は更新された設定で新しいワーカーに受け入れられます。これにより接続プールへの急激な中断が防がれます。オペレーターはタイムアウト値、再利用モード、ALPN設定を変更しながらサービスの継続性を保てます。本番の変更はより低い運用リスクで実行できます。
接続多重化はkeepealiveタイムアウトのバランス、ドレイン動作、TLSキャッシュサイズ設定、ストリーム並列性、プロトコルブリッジング、監視メトリクスとともに運用されます。
keepealiveタイムアウトが短すぎると、接続は再利用される前に閉じてしまいプール利用率が低下します。長すぎるとアイドル接続数が増えメモリ消費が増加します。値はトラフィック密度とバックエンド容量に合わせて調整する必要があります。
ソフトリロード中、旧ワーカーは既存の接続を制御された方法でドレインしながら、新規ワーカーが新しい設定で接続を受け入れます。これは接続多重化を使用するサービスへの無中断の変更に重要です。長命な接続のドレイン期間は別途計画する必要があります。
TLSセッションキャッシュサイズは、重いHTTPSトラフィック下で頻繁に再接続するクライアントにとって重要です。小さすぎるキャッシュは再利用率を低下させます。非常に大きなキャッシュはメモリ計画で考慮する必要があります。
OSレベルのTCP keepealiveは中間層に接続がまだ生きていることを通知します。これによりNATデバイス、ファイアウォール、ステートフルなセキュリティアプライアンスがアイドル接続を早期に閉じる可能性が減ります。この設定は長命な接続に最も価値があります。
単一HTTP/2接続上の並列ストリーム数は上限を設けられます。低すぎる値は多重化の利点を減らし、高すぎる値は単一接続の過負荷リスクをもたらします。トラフィックの種類に応じて適切に調整する必要があります。
クライアント側がHTTP/2を使用しているがバックエンドがHTTP/1.1で動作している場合、バックエンド側のストリーム動作は同じ並列性をミラーリングしません。一部のリクエストはバックエンドの接続モデルに従ってシリアライズされる可能性があります。バックエンドがHTTP/2をサポートする場合、関連するトグルの有効化を検討すべきです。
バックエンドではなくTR7がTLSを終端する場合、バックエンドのTLSハンドシェイク負荷がなくなります。代わりにADCがTLS処理コストを引き受けます。TLSセッション再利用と接続プールがそのコストを相殺するのを助けます。
リクエスト総数、キュー深度、接続数、再利用動作、エラーメトリクスが接続プールの状態を反映します。再利用が低い場合はタイムアウト設定またはバックエンドの動作を見直す必要があります。キューが増えている場合はバックエンドの接続容量またはmaxconn制限の調整が必要かもしれません。
SaaS APIは短く密なリクエスト量を生成します。接続多重化によりバックエンド接続数が削減され、繰り返しのTCP/TLS確立コストがなくなります。
モバイルクライアントは頻繁に接続を開閉します。Keepealive、HTTP/2、TLS再利用によりクライアント側の再接続コストが削減されます。
HTTP/2をサポートするバックエンドでは、ALPNトグルを有効にしてストリーム多重化を評価できます。これにより高頻度のサービス間呼び出しでより効率的な接続使用が実現します。
エッジや高密度なクライアントトラフィックは、新規接続を継続的に開く代わりにオリジンバックエンドへの既存接続プールから利用できます。オリジンのCPUとソケット負荷が削減されます。
非冪等な金融取引では、aggressiveな再利用よりもsafeモードが推奨されます。これによりパフォーマンス向上を追求しながら取引整合性を保護できます。
B2Bサービスでは少量だが価値の高いリクエストが高いTLSコストを発生させることがあります。接続プールとセッション再利用によりセキュアな接続確立のオーバーヘッドが削減されます。
Keepealiveプール、http-reuseモード、HTTP/2、HTTP/3、TLSセッション再利用 — すべての接続最適化を単一のADCポリシーで。お客様のサービスでライブセットアップをご案内します。