クラスタリングリファレンス

Kongクラスタでは、より多くのリクエストを処理するマシンを さらに追加することで、システムを水平方向に拡張できます。これらは同じデータベースを指しているため、 同じ構成となります。 同じデータストア を指しているKongノードは、同じKongクラスターの一部になります。

利用可能なノード全体でトラフィックを分散するには、Kongクラスターの前にロードバランサーが必要です。

Kongクラスターが行うことと行わないこと

Kong クラスタがあるからといって、そのままでクライアントのトラフィックが自動的に Kong ノード間でロードバランシングされるわけではありません。 トラフィックを分散させるためには、Kong ノードの前にロードバランサーを設定する必要があります。Kong クラスタとは、それらのノードが同じ設定を共有することを意味します。

パフォーマンス上の理由から、Kongはリクエストのプロキシ時にデータベース接続を回避し、メモリ内にデータベースの内容をキャッシュします。 キャッシュされたエンティティには、サービス、ルート、コンシューマ、プラグイン、認証情報などが含まれます。 これらの値はメモリ内にあるため、いずれかのノードのAdmin APIから実行された変更は他のノードに伝達される必要があります。

このドキュメントでは、キャッシュされたエンティティが無効になる方法と、パフォーマンスと一貫性の中間辺りに位置するユースケース向けにKongノードを構成する方法を説明しています。

単一ノードのKongクラスタ

データベースに接続された単一のKongノードは、ノードが1つあるKongクラスタを作成します。 このノードのAdmin APIを通して適用された変更は、すぐに有効になります。 以下に例を示します。

1つのKongノードAを検討してみましょう。以前に登録したサービスを削除する場合は、以下のようになります。

curl -X DELETE http://127.0.0.1:8001/services/test-service

その後、A へのリクエストはすべて即座に 404 Not Found を返すようになります。ノードがローカルキャッシュからそれを削除したためです。

curl -i http://127.0.0.1:8000/test-service

複数ノードのKongクラスタ

複数のKongノードのクラスタでは、同じデータベースに接続されている他のノードは、 サービスがノードAによって削除されたことは、すぐには通知されません。サービスが もうデータベースには ない （ノード Aによって削除されました）一方で、 まだ ノードBのメモリにあります。

すべてのノードは定期的なバックグラウンドジョブを実行して、その他のノードによってトリガーされた変更を同期します。このジョブの頻度は、次を介して構成できます。

• db_update_frequency (デフォルト: 5秒)

db_update_frequency秒ごとに、実行中のすべてのKongノードがデータベースの更新をチェックし、必要に応じて関連するエンティティをキャッシュから削除します。

ノード A からサービスを削除した場合、この変更はノード B の次のデータベースポーリングまで、Bノードでは有効になりません。 これは最大 db_update_frequency 秒後（もっと早く起こる可能性はありますが）まで行われます。

これにより、Kongクラスタは 最終的に一貫性のある ものになります。

PostgreSQLでKongクラスターをデプロイするときは、読み取り専用のレプリカを使用してください

Postgres をバックエンドストレージとして使用する場合、オプションで Kongを 有効にして別のデータベースインスタンスからの読み取りクエリを処理することができます。

Kongで読み取り専用の接続サポートを有効にすると、読み取り専用クエリがメインのデータベースインスタンスに送信されなくなるため、当該データベースの負荷が軽減します。

この機能の設定方法の詳細については、 構成リファレンスのデータストアセクション を参照してください。

キャッシュの対象

サービス、ルート、プラグイン、コンシューマ、認証情報などのコアエンティティは、すべてKongによってメモリにキャッシュされ、ポーリングメカニズムを介した無効化に依存して更新されます。

さらに、Kongは データベースのミス もキャッシュします。つまり、 プラグインなしでサービスを構成する場合、Kongはこの情報をキャッシュします。例：

ノード A に、サービスとルートを追加します：

# node A
curl -X POST http://127.0.0.1:8001/services \
  --data "name=example-service" \
  --data "url=http://example.com"

curl -X POST http://127.0.0.1:8001/services/example-service/routes \
  --data "paths[]=/example"

（ショートカットとして /services/example-service/routes を使用していることに注意してください。代わりに /routesエンドポイントを使用することもできますが、その場合は新しいサービスのUUIDとともに、service_idを引数として渡す必要があります。）

A と B の両方のプロキシポートにリクエストすると、このサービスはキャッシュされますが、実際にはプラグインは何も構成されません。

# node A
curl http://127.0.0.1:8000/example

応答:

HTTP 200 OK
...

# node B
curl http://127.0.0.2:8000/example

応答:

HTTP 200 OK
...

さて、ノード AのAdmin APIを介してこのサービスにプラグインを追加するとします。

# node A
curl -X POST http://127.0.0.1:8001/services/example-service/plugins \
  --data "name=example-plugin"

このリクエストはノードAのAdmin APIを介して発行されたため、ノードAはローカルでキャッシュを無効にし、それ以降のリクエストでは、このAPIにプラグインが設定されていることを検出します。

しかし、ノードBはまだデータベースポーリングを実行しておらず、これをまだキャッシュしています APIには実行するプラグインがありません。ノードBがデータベースポーリングジョブを実行するまで、 この状態が続きます。

結論 : すべてのCRUD操作はキャッシュの無効化を引き起こします。作成 （POST、PUT）はキャッシュされたデータベースのミスを無効にし、更新/削除 （PATCH、DELETE）はキャッシュされたデータベースヒットを無効にします。

データベースキャッシュを構成する方法

Kong設定ファイルでは3つのプロパティを設定できます。最も 重要なのはdb_update_frequencyで、これがパフォーマンスと一貫性のトレードオフに基づいて、Kong ノードの位置を決定します。

Kong には、一貫性を保つために調整されたデフォルト値が用意されているので、予期せぬ事態を避けながら、クラスタリングの機能を試すことができます。本番環境のセットアップを準備する際には、パフォーマンスに関する制約が守られるように、これらの値を調整することを検討する必要があります。

db_update_frequency（デフォルト: 5秒）

この値は、Kongノードがデータベースに対して無効化イベントをポーリングする頻度を決定します。値を低くすると、ポーリングジョブの実行頻度が高くなりますが、Kongノードが適用した変更に追従することを意味します。値を高くすると、Kongノードはポーリングジョブの実行時間を減らし、トラフィックのプロキシ処理に専念します。

注 ：行われた変更は、最大db_update_frequency秒でクラスタ全体に伝達されます。

構成リファレンスドキュメントの db_update_frequency エントリを参照してください。

db_update_propagation (デフォルト: 0秒)

このパラメータを設定することで、変更がデータベースノード全体で伝播する時間ができます。これが設定されると、ポーリングジョブから無効化ジョブを受信するKongノードは、キャッシュの消去をdb_update_propagation秒先延ばしにします。

最終的に一貫性のあるデータベースに接続されたKongのノードにイベント処理で 遅延が発生していない場合、キャッシュを消去しますが、結局は更新されていない値を 再度キャッシュします（変更がまだデータベースに伝達されていないからです）。

この値を、変更の伝達にデータベースクラスタが費やすと推定される 時間に設定する必要があります。

注 ：この値を設定すると、変更はクラスタ全体に 最大 db_update_frequency + db_update_propagation 秒で伝達されます。

構成リファレンスドキュメントの db_update_propagation エントリを参照してください。

db_cache_ttl (default: 0s)

Kongがデータベースエンティティ（ヒットとミスの両方）をキャッシュする時間（秒）。このTime-To-Live値は、Kongノードが無効化イベントを見逃した場合に、古いデータで長時間実行されないようにするための保護手段として機能します。TTLに達すると、値はキャッシュから消去され、次のデータベースの結果が再度キャッシュされます。

デフォルトでは、この TTL に基づいて無効化されるデータはありません（デフォルト値は0です）。通常はこれで問題ありません。KongノードはDBベースストアレベルで処理される無効化イベントに依存します。もし、Kongノードが何らかの理由で無効化イベントを見逃す可能性がある場合は、TTLを設定する必要があります。そうしない場合、キャッシュが手動で削除されるか、ノードが再起動されるまで、ノードはキャッシュ内の古い値で未定義の時間実行される可能性があります。

構成リファレンスドキュメントの db_cache_ttl エントリを参照してください。

Admin API を使用したキャッシュの操作

何らかの理由でキャッシュされた値を調査したい場合、または手動で Kong によってキャッシュされた値 (キャッシュされたヒットまたはミス) を無効にしたい場合は、 Admin API /cache エンドポイントから行うことができます。

さらに読む

• db_update_frequency
• db_update_propagation
• db_cache_ttl