This documentation is for a release that is no longer maintained
See documentation for the latest supported version 3 or the latest supported version 4.第7章 ルーティングの最適化
7.1. OpenShift Container Platform HAProxy ルーターのスケーリング
7.1.1. ベースラインのパフォーマンス
OpenShift Container Platform ルーター は、宛て先が OpenShift Container Platform サービスの外部トラフィックすべてに対する受信ポイントとなります。
サイズが 4 vCPU/16GB RAM のパブリッククラウドインスタンスで、HAProxy ルーター 1 台で、使用する暗号化、ページサイズ、接続数により、HTTP keep-alive 要求 7000-32000 件を処理できます。たとえば、TLS edge または re-encrypt を使用すると、ページサイズや接続数が大きい状態で中断すると、結果の数値は低くなるはずです。HTTP keep-alive では、HAProxy ルーター 1 台でページサイズが 8kb でも 1 Gbit NIC を飽和状態にすることが可能です。
以下の表では、HAProxy 1 台と、ルート 100 個のパブリッククラウドインスタンスでの HTTP keep-alive のパフォーマンスを示しています。
暗号化 | ページサイズ | 秒ごとの HTTP(s) 要求 |
---|---|---|
なし |
1kB |
15435 |
なし |
4kB |
11947 |
edge |
1kB |
7467 |
edge |
4kB |
7678 |
passthrough |
1kB |
25789 |
passthrough |
4kB |
17876 |
re-encrypt |
1kB |
7611 |
re-encrypt |
4kB |
7395 |
最新のプロセッサーが搭載されたベアメタルで実行する場合は、上記のパブリッククラウドインスタンスのパフォーマンスの約 2 倍のパフォーマンスになることを予想できます。このオーバーヘッドは、パブリッククラウドにある仮想化層により発生し、これは多くの場合、プライベートクラウドベースの仮想化にも適用できます。以下の表は、ルーターの背後で使用するアプリケーション数についてのガイドです。
アプリケーション数 | アプリケーションタイプ |
---|---|
5-10 |
静的なファイル/Web サーバーまたはキャッシュプロキシー |
100-1000 |
動的なコンテンツを生成するアプリケーション |
通常、HAProxy は使用する技術によって異なりますが、約 5-1000 のアプリケーションでルートの負荷分散を行うことができます。静的なコンテンツのみにサービスを提供するアプリケーションの場合は、この数字は通常少なくなります。
アプリケーションに対して、より多くのルートを提供し、ルーティング層の水平スケーリングを図る場合には、ルーターのシャード を使用する必要があります。
7.1.2. パフォーマンスの最適化
7.1.2.1. 最大接続数の設定
HAProxy のスケーラビリティーで最も重要でチューニング可能なパラメーターの 1 つに、maxconn
パラメーターがあります。このパラメーターは、プロセス別の最大同時接続数を特定の値に設定します。このパラメーターを調節するには、OpenShift Container Platform HAProxy ルーターのデプロイメント設定ファイルにある ROUTER_MAX_CONNECTIONS
環境変数を編集してください。
7.1.2.2. CPU および割り込みアフィニティー
OpenShift Container Platform では、HAProxy ルーターは単一のプロセスのとして実行されます。OpenShift Container Platform HAProxy ルーターは通常、周波数が低く、数の多いコアを持つ対称型マルチプロセッシング (SMP) よりも、周波数が高く、数の少ないコアが搭載されたシステムでより優れたパフォーマンスを実現します。
HAProxy プロセスを 1 つの CPU コアに、また別の CPU コアにネットワーク割り込みをピニングすると、ネットワークパフォーマンスが向上する傾向にあります。同じ Non-Uniform Memory Access (NUMA) ノードにプロセスと割り込みを配置すると、共有 L3 キャッシュを確保してメモリーアクセスを回避しやすくなります。ただし、このレベルの制御は、パブリッククラウド環境では一般的に不可能です。ベアメタルホストでは、irqbalance
は、割り込み要求線 (IRQ) があれば、自動的に PCI (peripheral component interconnect) ローカリティーと NUMA アフィニティーを処理します。クラウド環境では、このレベルの情報は一般的にオペレーティングシステムには提供されません。
CPU ピニングは taskset
または HAProxy の cpu-map
パラメーターを使用して実行されます。このディレクティブは、プロセス ID と CPU コア ID の 2 つの引数を取ります。たとえば、HAProxy プロセス 1
を CPU コア 0
にピニングするには、以下の行を HAProxy の設定ファイルの Global セクションに追加します。
cpu-map 1 0
cpu-map 1 0
HAProxy 設定ファイルの変更については、「カスタマイズされた HAProxy ルーターのデプロイ」を参照してください。
7.1.2.3. バッファー増加の影響
OpenShift Container Platform HAProxy ルーター要求のバッファー設定で、アプリケーションからの受信要求や応答のヘッダーサイズを制限します。HAProxy パラメーター tune.bufsize
を増やして、より大きいヘッダーを処理し、多くのパブリッククラウドプロバイダーが提供するロードバランサーで許可されるアプリケーションなど、非常に大きい cookie を使用するアプリケーションを機能させることができます。ただし、これにより、多数の接続が開放されている場合など、合計のメモリー使用率に影響があります。非常に多くの接続が開かれている場合には、メモリー使用率は、このチューニング可能なパラメーターの増加とほぼ比例します。
7.1.2.4. HAProxy 再読み込みの最適化
Websocket 接続などの長時間続く接続が、長いクライアント/サーバー HAProxy タイムアウトと短い HAProxy 再読み込み間隔と組み合わされると、HAProxy プロセスが多数インスタンス化されてしまう可能性があります。これらのプロセスは、HAProxy 設定が再読み込みされる前に開始されていた古い接続を処理する必要があります。これらの数多くのプロセスは、システムに不必要な負荷がかかり、メモリー不足の状態などの問題につながる可能性があるために理想的とは言えません。
この動作に影響を与える ルーターの環境変数 は ROUTER_DEFAULT_TUNNEL_TIMEOUT
、ROUTER_DEFAULT_CLIENT_TIMEOUT
、ROUTER_DEFAULT_SERVER_TIMEOUT
、および特に RELOAD_INTERVAL
です。