API Gateway Traffic Distribution / Load Balancing Configuration Method
このガイドでは、Kong Gatewayのクラスターとノード間でのトラフィック分配と負荷分散戦略を最適化する方法について説明します。これにより、高可用性と最大スループットが確保されます。リソースのサイズ設定、クラスター構成、メモリ内パフォーマンスチューニング、および以前のガイドラインでカバーされたスケーリングの次元について言及しています。
概念の概要
Kong Gatewayにおけるトラフィック分配 / 負荷分散とは何ですか?
トラフィック分配とは、受信APIリクエストがKong Gatewayクラスターとそのノード間でどのようにルーティングされ、CPU、メモリ、ネットワークの利用を均等に保つかを指します。負荷分散は、単一のノードまたはワーカーがボトルネックにならないようにし、水平スケーラビリティとフォールトトレランスを可能にします。この方法には、以下の設定が含まれます:
- ゲートウェイのスケーリング戦略(垂直/水平)
- ノードレベルのリソースサイズ設定
- メモリ内キャッシングとプラグインキューの最適化
- レイテンシ/スループットに敏感な設定
構成方法
方法1: クラスター負荷に基づくサイズ設定
最適なトラフィック分配を達成するための最初のステップは、ワークロードタイプと予想されるトラフィック量に基づいてゲートウェイを分類することです。以下の表を使用して、初期システムの境界を定義します:
クラスターサイズ | CPU | RAM | クラウドインスタンスの例 | 使用例 |
---|---|---|---|---|
開発 | 1-2 コア | 2-4 GB | AWS: t3.medium / GCP: n1-standard-1 / Azure: A1 | 開発/テスト、低レイテンシ感度 |
小規模 | 1-2 コア | 2-4 GB | AWS: t3.medium / GCP: n1-standard-1 / Azure: A1 | 軽量な本番、グリーンフィールドトラフィック |
中規模 | 2-4 コア | 4-8 GB | AWS: m5.large / GCP: n1-standard-4 / Azure: A1v4 | レイテンシニーズのある重要なワークロード |
大 | 8-16 コア | 16-32 GB | AWS: c5.xlarge / GCP: n1-highcpu-16 / Azure: F8s | エンタープライズグレードの大規模クラスター |
本番環境でスロットルされたインスタンスタイプ(例:AWS t2、t3)の使用は避けてください。CPUスロットリングは、負荷下でKongのパフォーマンスを著しく低下させます。
方法 2: メモリ割り当てとインメモリ最適化
メモリキャッシュの設定:
- mem_cache_sizeをできるだけ大きく設定し、OSや隣接プロセスのためのメモリを確保します。
- 推奨ベースライン: ~500MB/コア
- 4コア、8GBのインスタンスでは、Kongキャッシュに4〜6GBを割り当てます。
- キャッシュされたデータには、ルート、サービス、プラグインなどの設定エンティティが含まれます。
プラグインキューのバッファリング:
- http-logなどのプラグインは、非同期イベントバッファリングのためにqueue.max_entriesを使用します。
- デフォルト値: 10,000
- 高スループットのために、この値を調整してメモリオーバーフローやメッセージのドロップを避けます。
- 各プラグインキューはメモリに依存しており、負荷プロファイルに基づいてスケールする必要があります。
方法 3: レイテンシ/スループット次元によるスケーリング
Kongのパフォーマンスは以下に依存します:
- レイテンシ: リクエストごとの時間(メモリに依存)
- スループット: 秒あたりのリクエスト数(CPUに依存)
最適化戦略:
シナリオ | 最適化の焦点 |
---|---|
レイテンシに敏感 | データベース + プラグインキャッシュのメモリを増やす |
スループットに敏感 | CPUコアを追加; 垂直/水平にスケール |
ハイブリッドスケーリング (HAセットアップ) | 専用の設定処理を使用 |
ハイブリッドモードでdedicated_config_processingを有効にして、ノード間の設定同期などのCPU負荷の高いタスクをオフロードします。
追加の考慮事項
データベースの負荷の影響
- Kongは、ノードが起動するか設定が変更されるときのみDBから読み取ります。
- リソースの必要性は、トラフィック、エンティティ変更の頻度、ノードの数および有効な機能に依存します。
- DBの負荷を軽減するためにインメモリキャッシングを使用します。
- DBが一時的に利用できない場合でも、Kong Gatewayを運用可能にするために、フォールバックを維持しつつ最小限のアクセスを保つ
監視すべきパフォーマンス要因
次の項目を追跡し、調整します:
- ルート、サービス、コンシューマ、プラグインの数
- プラグインのカーディナリティ(多様なプラグインタイプはCPU負荷を増加させる)
- リクエスト/レスポンスサイズ(大きなペイロードはレイテンシを増加させる)
- ワークスペースの数とメタデータ(ワークスペースごとにより多くのメモリが必要)
概要
Kong Gatewayにおけるトラフィックのバランスの取れた分配と最適な負荷処理を確保するために:
- 適切なクラスターサイズの定義から始める
- キャッシュとプラグインキューのニーズに基づいてメモリを割り当てる
- レイテンシとスループットの優先順位に基づいて調整する
- キャッシュを使用してデータベース依存を最小限に抑える
- CPU/メモリの構成とハイブリッド処理オプションを通じてスケーリングを有効にする
これらの構成は、Kongを使用してスケーラブルで生産品質のAPIゲートウェイを構築するための基盤を形成します。