旧バージョンのドキュメントを参照しています。最新のドキュメントはこちらをご参照ください。

リソースサイジングのガイドライン

この文書では、 Kong Gatewayのパフォーマンス特性について説明し、予想されるKong Gateway構成とトラフィックパターンに基づいてリソースを割り当てるためのサイズ設定に関する推奨を提供します。

これらの推奨事項は、あくまでも基本的なガイドです。

パフォーマンスが重要な環境では、特別なチューニングやベンチマーク作業を行う必要があります。

一般的なリソースガイドライン

Kong Gatewayリソース

Kong Gatewayはさまざまなデプロイメント環境で動作するように設計されています。動作に必要な最小システム要件はありません。

リソース要件は、構成によって大きく異なります。以下の大まかなマトリックスでは、全体的な構成とパフォーマンス要件に基づいてシステム要件を決定するためのガイドラインを提供します。

レイテンシとスループットの要件がノードごとに考慮される、次の簡略化された例を検討してみましょう。この表には、大まかな使用要件の見積もりがあります。

サイズ	構成されたエンティティの数	レイテンシ要件	スループット要件	使用パターン
開発	100 未満	< 100ミリ秒	500 RPS まで	開発/テスト環境、レイテンシの影響を受けにくいゲートウェイ
小型	< 1000	< 20ミリ秒	< 2500 RPS	プロダクションクラスタ、グリーンフィールドトラフィックのデプロイメント
中程度	< 10000	< 10ミリ秒	< 10000 RPS	ミッションクリティカルなクラスタ、レガシーおよびグリーンフィールドのトラフィック、セントラルエンタープライズグレードのゲートウェイ
大型	50000以上	< 10ミリ秒	< 10000 RPS	ミッションクリティカルなクラスタ、レガシーおよびグリーンフィールドのトラフィック、セントラルエンタープライズグレードのゲートウェイ

データベースリソース

特定の設定によって異なるため、データベースサイジング（DBサイジング）の具体的な数字は提供していません。サイジングは次の条件で変化します。

トラフィック
ノード数
有効な機能: たとえば、レート制限にデータベースまたはRedisが使用されている場合
構成されたエンティティの変更数と変更率
クラスタ内でのKong Gatewayプロセスの開始および再開速度
Kong Gatewayのメモリ内キャッシュのサイズ

Kong Gatewayは意図的に、可能な限りデータベースにできるだけ依存しないようになっています。構成にアクセスするために、Kong Gatewayはバッキングデータベースへのスパイク状のアクセスパターンを実行します。これは、ノードが最初に起動したとき、または特定のエンティティの構成が変わったときにのみKong Gatewayがデータベースから構成を読み取るという意味です。

データベース内の全ては、頻繁には読み込まれず、メモリにできるだけ長く保持されることを意図しています。したがって、データベースリソースの要件は Kong Gateway を実行しているコンピューティング環境の要件よりも低いです。

クエリパターンは通常は単純で、スキーマインデックスに従います。スパイク状のクエリパターンを処理するために十分なデータベースリソースを割り当てます。

設定を調整して、データベースへのアクセスを最小限に抑えることや（メモリ内キャッシュも参照）、データベースがメンテナンスのためにダウンしている場合にKong Gatewayの稼働を維持することが可能です。ダウンタイム中もデータベースの稼働を維持することを選択した場合、この期間中は、Vitalsデータはデータベースに書き込まれません。

クラスターリソースの割り当て

クラスタで予想される規模と需要に基づいて、以下のリソース配分から始めることをお勧めします。

サイズ	CPU	RAM	一般的なクラウドインスタンスサイズ
小型	1-2コア	2-4GB	AWS ：t3.中型 GCP ：n1-標準-1 Azure ：標準A1 v2
中型	2-4コア	4-8GB	AWS ：m5.大型 GCP ：n1-標準-4 Azure ：標準A1 v4
大型	8-16コア	16-32GB	AWS ：c5.xlarge GCP ：n1-高CPU-16 Azure ：F8s v2

CPU スロットリングはKong Gatewayのパフォーマンスに悪影響を及ぼすため、大規模なクラスターでは、スロットルされたクラウドインスタンスタイプ（ AWS t2またはt3シリーズのマシン）を使用しないことを強く推奨します。また、特定のインスタンスクラスの帯域幅の可用性をテストして検証することも推奨します。 Kong Gatewayの帯域幅要件は、クラスターを流れるトラフィックの形状とボリュームによって異なります。

メモリ内キャッシュ

mem_cache_size構成はできるだけ大きく定義するとともに、オペレーティングシステムとKong Gatewayに隣接して実行されるその他のプロセスに適切なリソースを提供することを推奨します。この構成により、 Kong Gatewayはメモリ内キャッシュを最大限に活用することができ、データベースへの交通量を減らすことができます。

各Kong Gatewayワーカープロセスは独自のメモリ割り当てを維持するため、メモリのプロビジョニング時には計算に入れる必要があります。デフォルトでは1つのワーカープロセスは利用可能なCPUコア数に応じて実行します。 Kongでは、約 500MB メモリをワーカープロセスごとに割り当てることをお勧めしています。

たとえば、 4 つの CPU コアと 8 GB の RAM を備えたマシンでは、 Kong Gatewayと並行して実行されている他のプロセスに応じて、 mem_cache_sizeディレクティブを使用して 4～6 GB をキャッシュに割り当てることをお勧めします。

プラグインキュー

Kong Gateway と一緒に配布されているいくつかのプラグインは、内部のメモリ内キューを使用して、アップストリームサーバーへの送信データの生成を切り離します。これらのキューは、高負荷条件下でアップストリームサーバーに対して同時に行われるリクエスト数を減らし、一時的なネットワークとアップストリーム停止中のバッファリングを行います。Kong Gateway の内部キューイングシステムの詳細については、「プラグインキューについて」を参照してください。

キューはメインメモリを使用してキューに入っているエントリを保存するので、システムにいくつのキューがあるのか、そして容量構成の面でどれだけのエントリを持ちこたえることができるのか理解しておくことが重要です。

ほとんどのプラグインは、そのインスタンスごとに1つのキューを使用します。例外的にHTTP Logプラグインは、ログサーバーのアップストリーム構成ごとに1つのキューを使用します。

queue.max_entries 構成パラメータは、特定のキューで送信を待つことができるエントリの数を決定することができます。制限に達したあとは、新しいエントリがあると、最も古いエントリが削除されます。特定のプラグインおよび特定の構成で、1つのキューエントリーが占有するメモリの量を正確に予測することはできませんが、アップストリームサーバーに送信される実際のデータの量に基づいて推定することができます。

大規模な構成では、試行錯誤しながらキューのメモリ要件を決定することをお勧めします。そのためには、テスト環境でKong Gatewayを実行し、メモリ消費量を観察する一方で、プラグインのアップストリームサーバーを利用できない場合は、設定されている上限にキューが強制的に達するようにします。

queue.max_entriesのデフォルト値である10,000エントリは多数のインストールで十分なバッファリングを提供し、キューの最大メモリ使用量を妥当なレベルに保つ必要があります。

ディメンションの拡張

Kong Gatewayは、大量のリクエストトラフィックを処理し、最小限の遅延でリクエストを中継するよう設計されています。さまざまな構成シナリオがリクエストトラフィックにどのように影響するのか、そして Kong Gateway クラスタ自体を理解することは、 Kong Gateway のデプロイを成功に導くために欠かせないステップです。

Kong Gatewayは以下のディメンションでパフォーマンスを測定します。

レイテンシ とは、ダウンストリームのクライアントによるリクエストの送信と応答の受信の間の遅延を意味します。Kong Gatewayはリクエストで発生する遅延をマイクロ秒またはミリ秒で測定します。Kong Gatewayクラスタのルート数とプラグイン数が増加すると、各リクエストに追加された遅延の数も増加します。
スループット とは、 Kong Gateway が一定の期間内に処理できるリクエストの数を指し、通常は秒または分単位で測定されます。

これらのディメンションは、他のすべての要因が同じであれば、反比例関係にあります。各リクエストで発生するレイテンシが減少すると各リクエストの処理に費やされるCPU時間が短縮され、トラフィック全体の処理に費やされるCPUが増えるため、Kong Gateway の最大スループットが向上します。Kong Gateway は水平方向に拡張できるように設計されており、特定のスループット要件を満たす必要があるものの、リクエストに大幅なレイテンシを追加する構成に対して、全体的なコンピューティング能力を追加できます。

Kong Gatewayの最大スループットはCPUに依存し、最小レイテンシはメモリに依存します。

レイテンシの影響を受けやすいワークロード ：データベースキャッシュに使用できるメモリを増やすことは、クラスタに計算能力を追加するよりも有益です。
スループットの影響を受けるワークロード ：これらのワークロードは十分なメモリとCPUリソースの両方に依存しますが、Kong Gatewayを垂直方向または水平方向にスケーリングしてコンピューティング能力を追加するほうが、ほぼ無制限のスループット容量を得られるため、より良い選択です。このシナリオでは、キャッシュメモリを追加しても最大スループットはあまり増加しません。

パフォーマンスのベンチマークと最適化は全体として複雑な作業です。

Kong Gatewayの外部要因を含め、さまざまな要因を考慮する必要があります。たとえばアップストリームサービスの挙動や Kong Gatewayが動作している基盤となるハードウェアの状態などです。

パフォーマンス特性

Kong Gateway のパフォーマンスに影響を与える要因は以下のように数多くあります。

構成されたルート数とサービス数 ：クラスタのルートとサービスの数を増やす場合、リクエストを評価するためにより多くのCPUが必要になります。ただし、 Kong Gatewayのリクエストルーターは大規模で処理することができます。リクエストルートの評価の結果として、Kong Gatewayノードのクラスターが遅延の影響を最小限に抑えて何万ものルートにサービスを提供するのが確認されています。
構成されたコンシューマと認証情報の数 : コンシューマと認証情報データは Kong Gateway のデータストアに保存されます。Kong Gateway は、このデータをメモリにキャッシュしてデータベースの負荷とリクエスト処理中のレイテンシを軽減します。コンシューマや認証情報の数が増加すると、キャッシュ内のデータを Kong Gateway に保存するには、より多くの利用可能なメモリが必要です。リクエストされたすべてのデータベースエンティティをキャッシュするのに十分なメモリがない場合、Kong Gateway がリクエストを満たすためにデータベースをより頻繁にクエリすることからリクエストレイテンシは増加します。
構成済みのプラグインの数 ：クラスタのプラグイン数を増やす場合、リクエストの処理中にプラグインを介して反復処理されるため、より多くのCPUが必要になります。プラグインの実行には、プラグインの性質によってさまざまな代償が伴います。たとえば、key-authのような軽量の認証プラグインの場合、利用可能なリソースは、HTTPリクエストまたは応答の複雑な変換を実行するプラグインよりも少なくて済みます。
構成済みプラグインのカーディナリティ ： カーディナリティ とは、クラスタで構成された独特なプラグインタイプの数を意味します。例えば、ip-restriction、key-auth、bot-detection、rate-limiting、http-logのプラグインをそれぞれ1つずつ持つクラスタには、ルートレベルで適用されるrate-limitingプラグインが1000個あるクラスタよりもプラグインカーディナリティが高くなります。クラスタにそれぞれの追加のプラグインタイプが追加されると、Kong Gatewayは特定のリクエストに対して特定のプラグインを実行するかどうかを評価するために多くの時間を費やします。構成済みプラグインのカーディナリティを増加する場合、プラグイン評価の処理はCPU制約のタスクであるため、より多くのCPUが必要になります。
リクエストとレスポンスのサイズ ：リクエストまたはレスポンス内の HTTP本文が大きいリクエストは、Kong Gatewayがリクエストをプロキシする前に、ディスクにバッファリングしなければならないので、処理に時間がかかります。これにより

Kong Gatewayはメモリ不足にならずに大量のトラフィックを処理できます。ですが、バッファリングされたリクエストの性質上、レイテンシが増加する可能性があります。

構成されたワークスペースの数 ：クラスタ上のワークスペースの数が増加すると、各リクエストを評価するためのより多くのCPUと、ワークスペースの構成とメタデータを保存するキャッシュに使用するためのより多くのメモリが必要となります。このワークスペースの数を増やすことがクラスタに与える影響も、クラスタに設定されているプラグインのカーディナリティによって影響を受けます。プラグインのカーディナリティとワークスペースの数が増えるにつれて、クラスタ内でのリクエストスループット容量への指数関数的影響が生じます。