コンテンツにスキップ
Kong Logo | Kong Docs Logo
  • ドキュメント
    • API仕様を確認する
      View all API Specs すべてのAPI仕様を表示 View all API Specs arrow image
    • ドキュメンテーション
      API Specs
      Kong Gateway
      軽量、高速、柔軟なクラウドネイティブAPIゲートウェイ
      Kong Konnect
      SaaSのエンドツーエンド接続のための単一プラットフォーム
      Kong AI Gateway
      GenAI インフラストラクチャ向けマルチ LLM AI Gateway
      Kong Mesh
      Kuma と Envoy をベースにしたエンタープライズサービスメッシュ
      decK
      Kongの構成を宣言型で管理する上で役立ちます
      Kong Ingress Controller
      Kubernetesクラスタ内で動作し、Kongをプロキシトラフィックに設定する
      Kong Gateway Operator
      YAMLマニフェストを使用してKubernetes上のKongデプロイメントを管理する
      Insomnia
      コラボレーティブAPI開発プラットフォーム
  • Plugin Hub
    • Plugin Hubを探索する
      View all plugins すべてのプラグインを表示 View all plugins arrow image
    • 機能性 すべて表示 View all arrow image
      すべてのプラグインを表示
      AI's icon
      AI
      マルチ LLM AI Gatewayプラグインを使用してAIトラフィックを管理、保護、制御する
      認証's icon
      認証
      認証レイヤーでサービスを保護する
      セキュリティ's icon
      セキュリティ
      追加のセキュリティレイヤーでサービスを保護する
      トラフィック制御's icon
      トラフィック制御
      インバウンドおよびアウトバウンドAPIトラフィックの管理、スロットル、制限
      サーバーレス's icon
      サーバーレス
      他のプラグインと組み合わせてサーバーレス関数を呼び出します
      分析と監視's icon
      分析と監視
      APIとマイクロサービストラフィックを視覚化、検査、監視
      変革's icon
      変革
      Kongでリクエストとレスポンスをその場で変換
      ログ記録's icon
      ログ記録
      インフラストラクチャに最適なトランスポートを使用して、リクエストと応答データをログに記録します
  • サポート
  • コミュニティ
  • Kongアカデミー
デモを見る 無料トライアルを開始
Kong Gateway
3.7.x
  • Home icon
  • Kong Gateway
  • Production Deployment
  • クラスタリングリファレンス
report-issue問題を報告する
  • Kong Gateway
  • Kong Konnect
  • Kong Mesh
  • Kong AI Gateway
  • Plugin Hub
  • decK
  • Kong Ingress Controller
  • Kong Gateway Operator
  • Insomnia
  • Kuma

  • ドキュメント投稿ガイドライン
  • 3.10.x (latest)
  • 3.9.x
  • 3.8.x
  • 3.7.x
  • 3.6.x
  • 3.5.x
  • 3.4.x (LTS)
  • 3.3.x
  • 2.8.x (LTS)
  • アーカイブ (2.6より前)
  • 導入
    • Kong Gatewayの概要
    • サポート
      • バージョンサポートポリシー
      • サードパーティの依存関係
      • ブラウザサポート
      • 脆弱性パッチ適用プロセス
      • ソフトウェア部品表
    • 安定性
    • リリースノート
    • 互換性のない変更
      • Kong Gateway 3.7.x
      • Kong Gateway 3.6.x
      • Kong Gateway 3.5.x
      • Kong Gateway 3.4.x
      • Kong Gateway 3.3.x
      • Kong Gateway 3.2.x
      • Kong Gateway 3.1.x
      • Kong Gateway 3.0.x
      • Kong Gateway 2.8.x またはそれ以前
    • キーコンセプト
      • サービス
      • ルート
      • コンシューマ
      • アップストリーム
      • プラグイン
      • コンシューマグループ
    • Kongの仕組み
      • トラフィックのルーティング
      • ロードバランシング
      • ヘルスチェックとサーキットブレーカー
    • 用語集
  • Kongを始めましょう
    • Kongを入手
    • サービスとルート
    • Rate Limiting
    • プロキシキャッシュ
    • Key Authentication
    • ロードバランシング
  • Kongのインストール
    • 概要
    • Kubernetes
      • 概要
      • Kong Gatewayのインストール
      • Admin APIを構成する
      • Kong Managerのインストール
    • Docker
      • docker runの使用
      • 独自の Docker イメージをビルドする
    • Linux
      • Amazon Linux
      • Debian
      • Red Hat
      • Ubuntu
    • インストール後
      • データストアの設定
      • エンタープライズライセンスを適用する
      • Kong Managerを有効にする
  • 本番環境のKong
    • デプロイメントトポロジー
      • 概要
      • ハイブリッドモード
        • 概要
        • Kong Gatewayをハイブリッドモードでデプロイする
      • DBレスデプロイメント
      • 伝統的な
    • 実行中のKong
      • 非rootユーザーとしてKongを実行する
      • Admin APIの保護
      • systemdの使用
    • アクセス制御
      • Kong Gatewayを安全に起動する
      • プログラムによる管理者の作成
      • RBACを有効にする
    • ライセンス
      • 概要
      • ライセンスのダウンロード
      • エンタープライズライセンスのデプロイ
      • ライセンス APIの使用
      • ライセンス使用状況の監視
    • ネットワーキング
      • デフォルトポート
      • DNSに関する考慮事項
      • ネットワークとファイアウォール
      • フォワードプロキシ経由のCP/DP通信
      • PostgreSQL TLS
        • PostgreSQL TLSの構成
        • PostgreSQL TLSのトラブルシューティング
    • Kong設定ファイル
    • 環境変数
    • KongからのウェブサイトとAPIの提供
    • モニタリング
      • 概要
      • Prometheus
      • StatsD
      • Datadog
      • ヘルスチェックプローブ
    • トレーシング
      • 概要
      • カスタムトレースエクスポーターの記述
      • トレース APIリファレンス
    • リソースサイジングのガイドライン
    • セキュリティ更新プロセス
    • ブルーグリーンデプロイメント
    • カナリアデプロイメント
    • クラスタリングリファレンス
    • パフォーマンス
      • パフォーマンステストベンチマーク
      • パフォーマンスベンチマークの確立
      • Brotli圧縮によるパフォーマンスの向上
    • ログとデバッグ
      • ログ参照
      • 動的ログレベルの更新
      • ゲートウェイログのカスタマイズ
      • デバッグリクエスト
      • AI Gateway分析
    • gRPCサービスを構成する
    • Expressionsルーターを使用する
    • アップグレードと移行
      • Kong Gateway 3.x.xのアップグレード
      • バックアップと復元
      • アップグレード戦略
        • デュアルクラスターのアップグレード
        • インプレースアップグレード
        • ブルーグリーンアップグレード
        • ローリングアップグレード
      • 2.8 LTS から 3.4 LTS へのアップグレード
      • OSS から Enterprise への移行
      • Cassandra から PostgreSQL への移行ガイドライン
      • 互換性のない変更
  • Kong Gateway Enterprise
    • 概要
    • シークレット管理
      • 概要
      • はじめる
      • シークレットローテーション
      • 高度な使用法
      • バックエンド
        • 概要
        • 環境変数
        • AWS Secrets Manager
        • Azure Key Vault
        • Google Cloud Secret Manager
        • HashiCorp Vault
      • ハウツー
        • AWS Secrets Manager によるデータベースの保護
      • 参照形式
    • 動的なプラグインの順序
      • 概要
      • 動的プラグインの注文を開始する
    • 監査ログ
    • キーリングとデータ暗号化
    • ワークスペース
    • コンシューマグループ
    • イベントフック
    • データプレーン(DP)のレジリエンスの構成
    • コントロールプレーン(CP)の停止管理について
    • FIPS 140-2
      • 概要
      • FIPS 準拠パッケージのインストール
      • FIPS 140-2準拠のプラグイン
    • AWS IAMを使用してKong Gateway Amazon RDSデータベースを認証する
    • 署名付き Kong イメージの署名の検証
    • 署名付き Kong イメージのビルド来歴を確認
  • Kong AI Gateway
    • 概要
    • AI Gatewayを使ってみる
    • LLM プロバイダー統合ガイド
      • OpenAI
      • Cohere
      • Azure
      • Anthropic
      • Mistral
      • Llama2
    • AI Gateway分析
    • AI Gatewayプラグイン
  • Kong Manager
    • 概要
    • Kong Managerを有効にする
    • Kong Managerの使用を開始する
      • サービスとルート
      • Rate Limiting
      • プロキシキャッシュ
      • コンシューマによる認証
      • ロードバランシング
    • 認証と承認
      • 概要
      • スーパー管理者を作成する
      • ワークスペースとチーム
      • パスワードと RBAC トークンのリセット
      • Basic Auth
      • LDAP
        • LDAPの設定
        • LDAP サービスディレクトリマッピング
      • OIDC
        • OIDC を構成する
        • OIDC 認証済みグループマッピング
        • 以前の構成からの移行
      • セッション
      • RBAC
        • 概要
        • RBACを有効にする
        • ロールと権限を追加する
        • ユーザーの作成
        • 管理者の作成
    • ネットワーク構成
    • ワークスペース
    • コンシューマグループを作成する
    • メールの送信
    • トラブルシューティング
  • カスタムプラグインの開発
    • 概要
    • はじめる
      • 導入
      • プラグインプロジェクトの設定
      • プラグインテストを追加
      • プラグイン設定を追加
      • 外部サービスの利用
      • プラグインのデプロイ
    • ファイル構成
    • カスタムロジックの実装
    • プラグインの設定
    • データストアへのアクセス
    • カスタムエンティティの保存
    • カスタムエンティティのキャッシュ
    • Admin APIの拡張
    • テストを書く
    • インストールと配布
    • Proxy-Wasmフィルタ
      • proxy-wasm フィルターの作成
      • proxy-wasm フィルタの設定
    • プラグイン開発キット
      • 概要
      • kong.client
      • kong.client.tls
      • kong.cluster
      • kong.ctx
      • kong.ip
      • kong.jwe
      • kong.log
      • kong.nginx
      • kong.node
      • kong.plugin
      • kong.request
      • kong.response
      • kong.router
      • kong.service
      • kong.service.request
      • kong.service.response
      • kong.table
      • kong.tracing
      • kong.vault
      • kong.websocket.client
      • kong.websocket.upstream
    • 他の言語のプラグイン
      • Go
      • Javascript
      • Python
      • コンテナ内でプラグインを実行する
      • 外部プラグインのパフォーマンス
  • Kong Plugins
    • 概要
    • 認証リファレンス
    • 複数の認証プラグインを許可する
    • プラグインキューイング
      • 概要
      • プラグインキューイングリファレンス
  • Admin API
    • 概要
    • 宣言型構成
    • エンタープライズ API
      • インフォメーションルート
      • ヘルスルート
      • タグ
      • ルートのデバッグ
      • サービス
      • ルート
      • コンシューマ
      • プラグイン
      • 証明書
      • CA 証明書
      • SNI
      • アップストリーム
      • ターゲット
      • 金庫
      • 鍵
      • フィルターチェーン
      • ライセンス
      • ワークスペース
      • RBAC
      • アドミン
      • コンシューマグループ
      • イベントフック
      • キーリングとデータ暗号化
      • 監査ログ
      • ステータスAPI
    • オープンソースAPI
  • リファレンス
    • kong.conf
    • Nginxディレクティブの挿入
    • CLI
    • キー管理
    • 表現言語
      • 概要
      • 言語リファレンス
      • パフォーマンスの最適化
    • Rate Limitingライブラリ
    • Webアセンブリ
    • FAQ
enterprise-switcher-icon 次に切り替える: OSS
On this pageOn this page
  • Kongクラスターが行うことと行わないこと
  • 単一ノードのKongクラスタ
  • 複数ノードのKongクラスタ
    • PostgreSQLでKongクラスターをデプロイするときは、読み取り専用のレプリカを使用してください
  • キャッシュの対象
  • データベースキャッシュを構成する方法
    • db_update_frequency(デフォルト: 5秒)
    • db_update_propagation (デフォルト: 0秒)
    • db_cache_ttl (default: 0s)
  • Admin API を使用したキャッシュの操作
  • さらに読む
旧バージョンのドキュメントを参照しています。 最新のドキュメントはこちらをご参照ください。

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

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 を使用したキャッシュの操作

さらに読む

  • db_update_frequency
  • db_update_propagation
  • db_cache_ttl
Thank you for your feedback.
Was this page useful?
情報が多すぎる場合 close cta icon
Kong Konnectを使用すると、より多くの機能とより少ないインフラストラクチャを実現できます。月額1Mリクエストが無料。
無料でお試しください
  • Kong
    APIの世界を動かす

    APIマネジメント、サービスメッシュ、イングレスコントローラーの統合プラットフォームにより、開発者の生産性、セキュリティ、パフォーマンスを大幅に向上します。

    • 製品
      • Kong Konnect
      • Kong Gateway Enterprise
      • Kong Gateway
      • Kong Mesh
      • Kong Ingress Controller
      • Kong Insomnia
      • 製品アップデート
      • 始める
    • ドキュメンテーション
      • Kong Konnectドキュメント
      • Kong Gatewayドキュメント
      • Kong Meshドキュメント
      • Kong Insomniaドキュメント
      • Kong Konnect Plugin Hub
    • オープンソース
      • Kong Gateway
      • Kuma
      • Insomnia
      • Kongコミュニティ
    • 会社概要
      • Kongについて
      • お客様
      • キャリア
      • プレス
      • イベント
      • お問い合わせ
  • 利用規約• プライバシー• 信頼とコンプライアンス
© Kong Inc. 2025