API Gateway Traffic Distribution / Load Balancing Configuration Method
このガイドでは、Kong Gatewayのクラスターとノード間でのトラフィック分配と負荷分散戦略を最適化する方法について説明します。これにより、高可用性と最大スループットが確保されます。リソースのサイズ設定、クラスター構成、メモリ内パフォーマンスチューニング、および以前のガイドラインでカバーされたスケーリングの次元について言及します。
概念の概要
Kong Gatewayにおけるトラフィック分配 / 負荷分散とは?
トラフィック分配とは、Kong Gatewayクラスターとそのノード間で、受信APIリクエストがどのようにルーティングされるかを指し、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ゲートウェイを構築するための基盤を形成します。