問題を報告する旧バージョンのドキュメントを参照しています。 最新のドキュメントはこちらをご参照ください。
Kong Gatewayのパフォーマンスベンチマークを確立する
Kong Gatewayはすぐに使用できる状態で最適化されていますが、Kong Gatewayの構成オプションを微調整することによってパフォーマンスが大幅に向上する場合があります。
Kong Gatewayの初期ベンチマークを実行してkong.confを最適化し、さらにいくつかのベンチマークテストを実施することによって、パフォーマンスのベースラインを確立できます。
このガイドでは、次について説明します。
- 初期 Kong Gateway パフォーマンス ベンチマークを確立する方法
- 追加のベンチマークを実行する前にKong Gatewayパフォーマンスを最適化する方法
- ベンチマーク用に
kong.confを構成する方法
前提条件
Kong Gateway3.4.2.0 以降が必要です。
ベンチマークテストを実施する前に、テストベッドが正しく構成されていることを確認する必要があります。以下は、ベンチマークテストを開始する前のいくつかの一般的な推奨事項です。
- 多数の小さなKong Gatewayノードでなく、4つまたは8つのNGINXワーカーを対応するCPUリソース割り当てと併用して、Kong Gatewayのノード数を減らします。
- Kong GatewayをDB-lessまたはハイブリッドモードで実行します。これらのモードでは、Kong Gatewayのプロキシノードはデータベースに接続されておらず、パフォーマンスに影響を及ぼす要素になる可能性があります。
ベースライン Kong Gateway パフォーマンス ベンチマークの実行
前提条件の推奨事項を実装すると、ベンチマーク テストを開始できます。
- Request Terminationプラグインでルートを構成し、Kong Gatewayのパフォーマンスを測定します。この場合、 Kong Gatewayはリクエストに応答し、アップストリームサーバーにトラフィックを送信しません。
- このテストを数回実行して、予期しないボトルネックを見つけます。Kong Gateway、ベンチマーク クライアント（k6 や Apache JMeter など）、またはその他のコンポーネントが予期しないボトルネックになる可能性があります。これらのボトルネックを解決するまでは、Kong Gateway のパフォーマンス向上は期待できません。このベースライン パフォーマンスが許容できる場合にのみ、次の手順に進んでください。
- ベースラインを確立したら、プラグインなしでアップストリームサーバーにトラフィックを送信するルートを設定します。 これは、Kong Gatewayのプロキシとアップストリームサーバーのパフォーマンスを測定します。
- 続行する前に、予期せずボトルネックを引き起こしているコンポーネントがないことを確認してください。
- データの信頼性を高めるために、ベンチマークを複数回実行します。 オブザベーション間の差が高くない（標準偏差が低い）ことを確認します。
- ベンチマークの最初の 1 回または 2 回の反復で収集された統計を破棄します。システムが最適かつ安定したレベルで動作していることを確認するために、これを実行することをお勧めします。
追加の構成で Kong Gateway のベンチマークを実行するには、前の手順を完了する必要があります。追加のベンチマークを実行する前に、次のセクションの最適化に関する推奨事項をよく読み、必要に応じて設定を変更してください。
Kong Gatewayのパフォーマンスを最適化
このセクションのサブセクションでは、追加のベンチマークテストでKong Gatewayパフォーマンスを向上させる 推奨事項について詳しく説明します。 各セクションを注意深く読み、構成ファイルに必要な調整を加えてください。
以下を確認してくださいulimit
アクション： ulimitが16384より小さい場合は、値を大きくします。
説明： Kong Gateway はシステムから得られる出来る限り多くのリソースを使用できますが、
オペレーティングシステム（OS）は Kong Gateway がアップストリーム（または他の）サーバーと開くことができるコネクション数、またはクライアントから受け入れることができるコネクション数を制限します。Kong Gatewayのオープン接続数はデフォルトでulimitに設定されており、上限は16384です。
つまり、 ulimitが無制限であるか、16384より大きい値である場合、Kong Gatewayは16384に制限されます。
Kong GatewayのコンテナまたはVMにシェルでアクセスしてulimit -nを実行すると、システムのulimitを確認できます。
Kong GatewayがVM上のコンテナ内で実行されている場合は、コンテナにシェルでアクセスする必要があります。
ulimitの値が16384より小さければ、それを増加させます。
また、これらのシステムで接続ボトルネックがあるとパフォーマンスが最適でなくなるため、クライアントとアップストリームサーバーで、
適切なulimitを確認して設定します。
接続の再利用を増やす
アクション: upstream_keepalive_max_requests = 100000とnginx_http_keepalive_requests = 100000を構成します。
説明： 10,000RPS以上の高スループットシナリオでは、TCPおよびTLS接続を設定するオーバーヘッドや不十分な接続により、ネットワーク帯域幅またはアップストリームサーバーの使用率が低下する可能性があります。接続の再利用を増やすには、 upstream_keepalive_max_requestsとnginx_http_keepalive_requestsを100000まで増やすか、最大の500000まで増やすことができます。
自動スケーリングの回避
アクション： Kong Gatewayが拡大/縮小（水平）または拡大/縮小（垂直）されていないことを確認します。
説明: ベンチマークの実行中は、Kong Gateway がスケールイン/スケールアウト（水平）またはアップ/ダウン（垂直）になっていないことを確認してください。Kubernetesでは、これは通常、水平または垂直ポッドオートスケーラーを使用して行われます。オートスケーラーはベンチマークの統計に干渉し、不要なノイズを発生させます。
ベンチマーク中に自動スケーリングされないよう、ベンチマークをテストする前にKong Gatewayをスケールアウトしてください。Kong Gateway ノードの数を監視して、ベンチマーク中に新しいノードが生成されることを確認し、 既存のノードは置き換えられません。
複数のコアを効果的に使用する
アクション: ほとんどの VM セットアップでは、 nginx_worker_processesをautoに設定します。Kubernetesではnginx_worker_processesを設定し
ワーカーノードの CPUより1つまたは2つ少なくします。
説明: nginx_worker_processes が正しく構成されていることを確認してください。
-
ほとんどのVMセットアップでは、これを
autoに設定します。これがデフォルト設定です。これにより、NGINXは1つのCPUコアに対して1つのワーカープロセスを生成するようになります。 -
Kubernetes でこれを明示的に設定することをお勧めします。Kong Gateway のための CPU のリクエストと制限が Kong Gateway で設定されたワーカーの数と一致することを確認します。たとえば、
nginx_worker_processes=4と設定すると、 ポッドのスペックでは 4 つの CPU をリクエストする必要があります。Kubernetesワーカーノードとn個のCPUを併用してKong Gatewayポッドを実行する場合、n-2またはn-1を Kong Gatewayに割り当てて、ワーカープロセスカウントをこの数と等しく構成します。 これにより、kubeletなどの設定済みのデーモンとKubernetesプロセスがKong Gatewayを持つリソースと競合しないように徹底できます。
ワーカーが増えるたびにメモリ消費量が増加するため、Kong GatewayによってLinux Out-of-Memory Killerがトリガーされないことを確実にする必要があります。
リソース競合
アクション: クライアント（Apache JMeterやk6など）、 Kong Gateway 、およびアップストリームサーバーが異なる マシン (VM またはベアメタル）を低レイテンシで同じローカルネットワーク上で実行されていることを確認してください。
説明:
- クライアント（Apache JMeterやk6など）、Kong Gateway、アップストリームサーバーが異なるタイプのマシン（VMまたはベアメタル）で実行することを確認します。 これらがすべてKubernetesクラスタで実行されている場合は、これら3つのシステム向けポッドのスケジュールが専用ノードで組まれるようにします。 これらシステム間でリソースが競合（通常はCPUとネットワーク）する場合、どのシステムでも最適なパフォーマンスが得られない可能性があります。
- クライアント、Kong Gateway、およびアップストリームサーバーが同じローカルネットワーク上で低レイテンシーで動作していることを確認してください。クライアントと Kong Gateway 間、または Kong Gateway とアップストリームサーバー間のリクエストがインターネットを通過する場合、結果には不要なノイズが含まれることになります。
アップストリームサーバーの限界
アクション: アップストリームサーバーが負荷の上限に達していないことを確認してください。
説明： アップストリームサーバーのCPUとメモリをチェックすることで、アップストリームサーバーが最大限に達していないことを確認できます。追加のKong Gatewayノードをデプロイしても、スループットまたはエラーレートが変わらない場合は、アップストリームサーバーまたはKong Gateway以外のシステムがボトルネックになっている可能性があります。
アップストリームサーバーが自動スケーリングされないようにする必要があります。
クライアントの限界
アクション： クライアントはkeepalive接続を使用する必要があります。
説明： クライアント（k6やApache JMeterなど）が最大になることがあります。その調整には、クライアントを理解することが必要です。クライアントのCPU、スレッド、接続数を増やすと、 リソースの使用率とスループットが向上します。
また、クライアントはkeepalive接続を使用しなければなりません。たとえば、k6 とApache JMeterのHTTPClient4の実装は、デフォルトでどちらもkeepaliveが有効になります。これがテスト設定で適切に設定されていることを確認します。
カスタムプラグイン
アクション： カスタムプラグインがパフォーマンスを妨げていないことを確実にしてください。
説明： カスタムプラグインはパフォーマンスに問題を引き起こすことがあります。 まず、カスタムプラグインがパフォーマンスの問題の原因であるかどうかを判断する必要があります。これを行うには、次の3つの構成バリエーションを測定します。
- プラグインを有効にせずにKong Gatewayのパフォーマンスを測定します。これにより、 Kong Gatewayのパフォーマンスのベースラインが提供されます。
- 必要なバンドルプラグイン（製品に付属するプラグイン）を有効にしてから、Kong Gatewayのパフォーマンスを測定します。
- 次に、カスタムプラグイン（バンドルされたプラグインに加えて）を有効にして、Kong Gateway のパフォーマンスをもう一度測定します。
Kong Gateway のベースラインパフォーマンスが低い場合は、Kong Gateway の構成のチューニングが必要か、もしくは外部要因が影響している可能性があります。外部要因については、このガイドの他のセクションを参照してください。2 番目と 3 番目の手順のパフォーマンスに大きな差がある場合は、パフォーマンスの問題はカスタムプラグインが原因である可能性があります。
クラウドプロバイダーのパフォーマンスの問題
アクション： バースト可能なインスタンスを使用していないか、帯域幅、単位時間あたりのTCP接続、PPSの制限に達していないことを確認してください。
説明： 以下ではAWSについて言及しますが、同じ推奨事項はほとんどのクラウドプロバイダーに当てはまります。
- AWSで、Tタイプのインスタンスのようなバースト可能なインスタンスを使用していないことを確認してください。 この場合、アプリケーションで使用できる CPU は変動するため、統計にノイズが発生します。 詳細については、バースト可能なパフォーマンスインスタンスのAWSドキュメントを参照してください。
- 帯域幅制限、単位時間あたりのTCP接続数制限、またはパケット毎秒（PPS）制限に達していないことを確認してください。詳細については、Amazon EC2 インスタンスのネットワーク帯域幅に関する AWS ドキュメントを参照してください。
ベンチマークテスト中の構成変更
アクション: ベンチマークテスト中に Kong Gateway 構成を変更しないでください。
説明： テスト中に構成を変更すると、Kong Gatewayのテールレイテンシが急増する可能性があります。 そのため、構成変更後のKong Gatewayのパフォーマンスを測定する目的を除き、テスト中は構成を変更しないでください。
大規模なリクエストと応答本文
アクション： リクエストボディは8KB未満、レスポンス本文は32KB未満にしてください。
説明： ほとんどのベンチマーク設定は、通常、小さなHTTPボディとそれに対応するJSONまたはHTMLのレスポンスボディを含む HTTPリクエストで構成されます。 リクエストボディが 8 KB 未満、レスポンス本文が 32 KB 未満の場合は小さいとみなされます。 リクエストまたはレスポンスボディが大きい場合、Kong Gateway はディスクを使用してリクエストとレスポンスをバッファリングします。 これは Kong Gateway のパフォーマンスに大きな影響を与えます。
サードパーティシステムのボトルネック
説明： 多くの場合、Kong Gateway のボトルネックは、Kong Gatewayが使用しているサードパーティシステムのボトルネックが原因です。次のセクションでは、一般的なサードパーティのボトルネックとその解決方法について説明します。
Redis
アクション： Redisを使用し、いずれかのプラグインが有効になっている場合、CPUがボトルネックになる可能性があります。CPUを追加して、Redisを垂直方向に拡張します。
説明： Redisを使用し、いずれかのプラグインが有効になっている場合は、Redisがボトルネックになっていないことを確認してください。通常、CPUはRedisのボトルネックとなるため、まずCPUの使用状況を確認してください。この場合は、追加のCPUを追加してRedisを垂直方向に拡張します。
DNS TTL
アクション: dns_stale_ttl を 300 または 86400 に増やします。
説明： Kong Gatewayはリクエストの送信先を決定するためにDNSに依存しているため、DNSサーバーがKong Gatewayのボトルネックになる可能性があります。
In the case of Kubernetes, DNS TTLs are 5 seconds long and can cause problems.
dns_stale_ttlを300に、または最大86400をチケットとしてDNSを除外できます。
DNSサーバーが根本原因である場合、CPUでボトルネックを発生させているポッドがcoredns個あることがわかります。
アクセスログのI/Oのブロック
アクション: 高スループットのベンチマークテストに対しては、proxy_access_log 設定パラメータを off に設定してアクセスログを無効にします。
説明: Kong Gatewayと基礎となるNGINXは非ブロッキングネットワーク I/O 用にプログラムされており、ディスク I/O のブロックを可能な限り回避します。ただし、アクセスログはデフォルトで有効になっており、Kong Gatewayノードに電力を供給するディスクが何らかの理由で襲い場合、パフォーマンスの低下につながる可能性があります。proxy_access_log構成パラメータをoffに設定して、高スループットベンチマークテストのアクセスログを無効にします。
Kong Gateway の内部エラー
アクション: Kong Gateway のエラーログにエラーがないことを確認します。
説明: Kong Gateway のエラー ログで内部エラーを確認します。 内部エラーにより、 Kong Gateway 内の問題、またはトラフィックを中継するために Kong Gateway が依存しているサードパーティ システムの問題が明らかになる場合があります。
ベンチマークのための kong.conf の例
次の kong.conf ファイルの例には、前のセクションで推奨されたすべてのパラメータが含まれています。
次の手順
Kong Gatewayのパフォーマンスを最適化したので、追加のベンチマークを実行できます。 常に測定し、変更を加え、再度測定します。行き詰まったときに次のステップを理解したり、別のアプローチに戻ったりできるように、変更の記録を保存しておいてください。
