コンテンツにスキップ
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.8.x
  • Home icon
  • Kong Gateway
  • Plugin Development
  • カスタムエンティティのキャッシュ
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.8.x
      • 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 以前
    • キーコンセプト
      • サービス
      • ルート
      • コンシューマ
      • アップストリーム
      • プラグイン
      • コンシューマグループ
    • How Kong Works
      • ルーティングトラフィック
      • ロードバランシング
      • ヘルスチェックとサーキットブレーカ
    • 用語集
  • Kong を始めよう
    • Kong をゲットする
    • サービスとルート
    • レート制限
    • プロキシキャッシュ
    • キー認証
    • ロードバランシング
  • コングをインストールする
    • 概要
    • Kubernetes
      • 概要
      • Kong Gatewayをインストール
      • Admin API
      • Kong Manager をインストールする
    • Docker
      • docker run を使用する
      • 独自の Docker イメージをビルドする
    • Linux
      • Amazon Linux
      • Debian
      • Red Hat
      • Ubuntu
    • インストール後
      • データストアを設定
      • エンタープライズライセンスを適用
      • Kong Managerを有効にする
  • Kong in production
    • 展開のトポロジーズ
      • 概要
      • ハイブリッドモード
        • 概要
        • ハイブリッドモードでKong Gatewayをデプロイする
      • DB-lessデプロイ
      • 繁体字版
    • Running Kong
      • non-rootユーザーとしてKongを実行しています
      • 管理者 API の保護
      • systemdの使用
    • アクセスコントロール
      • コングゲートウェイを安全に開始
      • プログラムによる管理者の作成
      • RBAC を有効にする
    • ライセンス
      • 概要
      • ライセンスをダウンロード
      • エンタープライズライセンスのデプロイ
      • ライセンスAPIの使用
      • ライセンス使用状況をモニターする
    • ネットワーク
      • デフォルトのポート
      • DNSに関する考察
      • ネットワークとファイアウォール
      • CP/DP Communication through a Forward Proxy
      • PostgreSQL TLS
        • PostgreSQL TLS の設定
        • PostgreSQL TLS のトラブルシューティング
    • Kongの設定ファイル
    • 環境変数
    • KongからウェブサイトとAPIを提供する
    • モニタリング
      • 概要
      • Prometheus
      • StatsD
      • Datadog
      • ヘルスチェックプローブ
      • AIメトリクスを公開してグラフ
    • トレース
      • 概要
      • カスタム・トレース・エクスポーターの作成
      • トレースAPIリファレンス
    • リソースサイズのガイドライン
    • セキュリティアップデートプロセス
    • ブルー・グリーンの展開
    • カナリアのデプロイ
    • クラスタリングリファレンス
    • パフォーマンス
      • パフォーマンステストのベンチマーク
      • パフォーマンスのベンチマークを作成
      • Brotli圧縮によるパフォーマンスの向上
    • ロギングとデバッグ
      • ログの参照
      • ダイナミックログレベルの更新
      • ゲートウェイログをカスタマイズ
      • デバッグリクエスト
      • AIゲートウェイ分析
    • gRPCサービスの設定
    • 式ルータを使用
    • アップグレードと移行
      • 香港ゲートウェイ3.x.xをアップグレードする
      • バックアップと復元
      • アップグレードの戦略
        • デュアルクラスターのアップグレード
        • インプレイスアップグレード
        • 青緑色のアップグレード
        • ローリングアップグレード
      • 2.8 LTSから3.4 LTSにアップグレード
      • OSSからエンタープライズへ移行
      • 移行ガイドライン Cassandra から PostgreSQL
      • 新しい DNS クライアントに移行
      • 破壊的な変更
  • Kong Gateway Enterprise
    • 概要
    • シークレット管理
      • 概要
      • はじめに
      • ローテーション
      • 高度な使い方
      • バックエンドの設定
        • 概要
        • 環境変数
        • AWS シークレットマネージャー
        • Azure Key Vault
        • Google Cloud Secret Manager
        • HashiCorp Vault
      • How-To
        • AWS シークレットマネージャでデータベースを保護する
      • 参照フォーマット
    • 動的なプラグインの順序
      • 概要
      • 動的なプラグインの順序を始めましょう
    • 監査ログ
    • キーリングとデータ暗号化
    • ワークスペース
    • コンシューマグループ
    • イベントフック
    • データ プレーンレジリエンスの設定
    • 制御機の停止管理について
    • FIPS 140-2
      • 概要
      • FIPS 準拠パッケージをインストール
      • FIPS 140-2 準拠プラグイン
    • AWS IAMでKong Gateway Amazon RDSデータベースを認証する
    • 署名された香港の画像の署名を確認します
    • 署名された香港画像のビルド証明書を確認する
  • Kong AI Gateway
    • 概要
    • AI ゲートウェイを始めよう
    • LLM プロバイダー統合ガイド
      • OpenAI
      • Cohere
      • Azure
      • Anthropic
      • ミストラル
      • Llama2
    • AIプラットフォーム統合ガイド
      • Gemini
      • Amazon Bedrock
    • AIゲートウェイ分析
    • AI指標を公開・グラフ
    • AI Gateway plugins
  • Kong Manager
    • 概要
    • Kong Managerを有効にする
    • Kong Manager を始めましょう
      • サービスとルート
      • レート制限
      • プロキシキャッシュ
      • コンシューマーとの認証
      • 負荷バランス
    • 認証と承認
      • 概要
      • スーパー管理者を作成
      • ワークスペースとチーム
      • パスワードとRBACトークンをリセット
      • ベーシック認証
      • LDAP
        • LDAP の設定
        • LDAP サービス ディレクトリ マッピング
      • OIDC
        • OIDCの設定
        • OIDC 認証済みグループマッピング
        • 以前の設定から移行
      • セッション
      • RBAC
        • 概要
        • RBACを有効にする
        • ロールと権限を追加
        • ユーザーを作成
        • 管理者を作成
    • ネットワーク設定
    • ワークスペース
    • 顧客グループを作成
    • メールを送信中
    • トラブルシューティング
  • カスタムプラグインを開発
    • 概要
    • はじめに
      • はじめに
      • プラグインプロジェクトの設定
      • プラグインテストを追加
      • プラグイン設定を追加
      • 外部サービスを消費する
      • プラグインをデプロイ
    • ファイル構造
    • カスタムロジックの実装
    • プラグインの設定
    • データストアへのアクセス
    • カスタムエンティティの保存
    • カスタムエンティティをキャッシュ中
    • 管理者 API の拡張
    • テストを書く
    • 設置と配布
    • プロキシ-ワズムフィルター
      • プロキシワズムフィルタを作成
      • プロキシ-ワズムフィルタの設定
    • プラグイン開発キット
      • 概要
      • 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.telemetry.log
      • kong.tracing
      • kong.vault
      • kong.websocket.client
      • kong.websocket.upstream
    • 他の言語でのプラグイン
      • 移動
      • Javascript
      • Python
      • コンテナでのプラグインの実行
      • 外部プラグインのパフォーマンス
  • Kong Plugins
    • 概要
    • 認証リファレンス
    • 複数の認証プラグインを許可
    • プラグインのキュー
      • 概要
      • プラグインキューイングリファレンス
  • Admin API
    • 概要
    • 宣言設定
    • Enterprise API
      • 情報ルート
      • 健康ルート
      • タグ
      • デバッグルート
      • サービス
      • ルート
      • コンシューマ
      • プラグイン
      • 証明書
      • CA 証明書
      • SNI
      • アップストリーム
      • ターゲット
      • ヴォールト
      • キー
      • チェーンをフィルター
      • ライセンス
      • ワークスペース
      • RBAC
      • 管理者
      • コンシューマグループ
      • イベントフック
      • キーリングとデータ暗号化
      • 監査ログ
      • Status API
    • オープンソースAPI
  • 参照
    • kong.conf
    • Nginx ディレクティブの注入中
    • CLI
    • キー管理
    • 表現の言語
      • 概要
      • 言語リファレンス
      • パフォーマンスの最適化
    • ライブラリのレート制限
    • WebAssembly
    • FAQ
enterprise-switcher-icon 次に切り替える: OSS
On this pageOn this page
  • モジュール
  • カスタムエンティティのキャッシュ
    • ユーザー定義エンティティを更新または削除する
  • エンティティのキャッシュ無効化
    • 自動キャッシュ無効化
    • 手動によるキャッシュの無効化
  • Admin APIの拡張
旧バージョンのドキュメントを参照しています。 最新のドキュメントはこちらをご参照ください。

カスタムエンティティのキャッシュ

プラグインは、各リクエストや応答に対してカスタムエンティティ(前章で説明)に頻繁にアクセスする必要がある可能性があります。 通常、一度ロードし、メモリに動的にキャッシュするとパフォーマンスは向上しますが、ロード量の増加でデータストアへの負荷が増加しないようにします。

リクエストごとにAPIキーを検証する必要があるAPI Key Authenticationプラグインを考えてみてください。 リクエストのたびに、カスタム認証情報オブジェクトがデータストアからロードされます。 クライアントがリクエストと一緒にAPIキーを提供すると、 通常は、データストアにクエリしてそのキーが存在するかどうかを確認し、それからユーザーを識別するために、 リクエストをブロックするか、コンシューマIDを取得します。これが すべてのリクエストで発生すると、非常に非効率的です。

  • データストアのクエリを実行すると、すべてのリクエストでレイテンシが発生し、リクエストの処理がおそくなります。
  • データストアは読み込み量の増加の影響も受け、クラッシュまたは減速する恐れがあります。その影響はすべてのKongノードに波及します。

データストアに対して毎回クエリを実行しないようにするには、ノード上でカスタムエンティティをメモリ内にキャッシュします。そうすることで、頻繁にエンティティを参照しても、初回以外はデータストア クエリを毎回トリガーすることなくメモリ内で実行されます。そして、データストアからクエリを実行するよりもはるかに高速で信頼性が高くなります(特に負荷が高い場合) 。

モジュール

kong.plugins.<plugin_name id="sl-md0000000">.daos

カスタムエンティティのキャッシュ

カスタムエンティティを定義したら、プラグイン開発キットによって提供される kong.cacheをモジュールを使用して メモリ内にキャッシュすることができます。

local cache = kong.cache

キャッシュには次の2つのレベルがあります。

  1. L1: Luaメモリ ャッシュ - Nginxワーカープロセスにローカル。これは、任意のタイプのLua値を保持できます。
  2. L2: 共有メモリキャッシュ(SHM)- Nginx ノードに対してはローカルですが、 そのNginx ノードのすべてのワーカー間で共有されます。これはスカラー値しか保持できないので、Lua テーブルのようなより複雑な型の(逆)シリアル化が必要となります。

データがデータベースから取得されると、両方のキャッシュに保存されます。 同じワーカープロセスが再度データを要求すると、 Lua メモリキャッシュから以前にシリアル化されたデータを取得します。同じ Nginx ノード内の異なるワーカーがそのデータを要求した場合、 SHM でデータを見つけ、逆シリアル化し(そして独自の Lua メモリキャッシュに保存して)、返します。

このモジュールでは、次の機能が公開されています。

関数名 説明
value, err = cache:get(key, opts?, cb, ...) キャッシュから値を取得します。キャッシュに値がない場合(miss)、保護モードでcbを呼び出します。cbは、キャッシュされる1つの値(1つのみ)を返す必要があります。エラーがスローされる 可能性があります が、それらはKongによってキャッチされ、ngx.ERRレベルで適切にログに記録されます。この関数は負の結果(nil)をキャッシュ します 。そのため、エラーをチェックするときは、2番目の引数errに依存する必要があります。
ttl, err, value = cache:probe(key) 値がキャッシュされているかどうかを確認します。キャッシュされている場合は、残りの TTL を返します。キャッシュされていない場合は、nil を返します。キャッシュされる値はネガティブキャッシュになることもあります。3 番目の戻り値は、キャッシュされる値自体です。
cache:invalidate_local(key) ノードのキャッシュから値を削除します。
cache:invalidate(key) ノードのキャッシュから値を削除 し 、そのエビクションイベントをクラスタ内の他のすべてのノードに伝達します。
cache:purge() ノードのキャッシュから すべての 値を削除します。

認証プラグインの例に戻り、特定のAPIキーで認証情報を検索する場合、以下のような記述になります。

-- handler.lua

local CustomHandler = {
  VERSION  = "1.0.0",
  PRIORITY = 10,
}

local kong = kong

local function load_credential(key)
  local credential, err = kong.db.keyauth_credentials:select_by_key(key)
  if not credential then
    return nil, err
  end
  return credential
end


function CustomHandler:access(config)

  -- retrieve the apikey from the request querystring
  local key = kong.request.get_query_arg("apikey")

  local credential_cache_key = kong.db.keyauth_credentials:cache_key(key)

  -- We are using cache.get to first check if the apikey has been already
  -- stored into the in-memory cache. If it's not, then we lookup the datastore
  -- and return the credential object. Internally cache.get will save the value
  -- in-memory, and then return the credential.
  local credential, err = kong.cache:get(credential_cache_key, nil,
                                         load_credential, credential_cache_key)
  if err then
    kong.log.err(err)
    return kong.response.exit(500, {
      message = "Unexpected error"
    })
  end

  if not credential then
    -- no credentials in cache nor datastore
    return kong.response.exit(401, {
      message = "Invalid authentication credentials"
    })
  end

  -- set an upstream header if the credential exists and is valid
  kong.service.request.set_header("X-API-Key", credential.apikey)
end


return CustomHandler

上記の例では、リクエストの処理、モジュールのキャッシュ、または当社のプラグインから応答を生成するために、プラグイン開発キットからさまざまなコンポーネントを使用していることに注意してください。

さて、上記の仕組みを導入すると、コンシューマがAPIキー使ってリクエストを作成すると、 キャッシュはウォーム状態とみなされ、その後のリクエストは データベースクエリの結果になりません。

キャッシュはキー認証プラグインハンドラの複数の場所で使用されます。 公式プラグインでのキャッシュの使用方法については、ファイルをご覧ください。

ユーザー定義エンティティを更新または削除する

Admin API を使用して、キャッシュされたカスタムエンティティがデータストアで更新または削除されるたびに、データストア内のデータと Kong ノードのメモリにキャッシュされたデータの間に不整合が発生します。この不整合を回避するには、キャッシュされたエンティティをメモリ内ストアから削除し、Kong にデータストアのエンティティを再度リクエストさせる必要があります。このプロセスをキャッシュ無効化と呼びます。

エンティティのキャッシュ無効化

キャッシュされたエンティティがTTLに達するのを待つ代わりに、CRUD操作時に無効にするには、次のいくつかのステップに従う必要があります。 このプロセスはほとんどのエンティティで自動化できますが、より複雑な関係を持つ一部のエンティティを無効にするために、一部のCRUDイベントを手動でサブスクライブする必要が生じることがあります。

自動キャッシュ無効化

エンティティのスキーマのcache_keyプロパティを信頼している場合、 キャッシュの無効化は追加設定なしでエンティティに提供されます。たとえば、次のスキーマでは このようになります。

local typedefs = require "kong.db.schema.typedefs"


return {
  -- this plugin only results in one custom DAO, named `keyauth_credentials`:
  keyauth_credentials = {
    name                  = "keyauth_credentials", -- the actual table in the database
    endpoint_key          = "key",
    primary_key           = { "id" },
    cache_key             = { "key" },
    generate_admin_api    = true,
    admin_api_name        = "key-auths",
    admin_api_nested_name = "key-auth",    
    fields = {
      {
        -- a value to be inserted by the DAO itself
        -- (think of serial id and the uniqueness of such required here)
        id = typedefs.uuid,
      },
      {
        -- also interted by the DAO itself
        created_at = typedefs.auto_timestamp_s,
      },
      {
        -- a foreign key to a consumer's id
        consumer = {
          type      = "foreign",
          reference = "consumers",
          default   = ngx.null,
          on_delete = "cascade",
        },
      },
      {
        -- a unique API key
        key = {
          type      = "string",
          required  = false,
          unique    = true,
          auto      = true,
        },
      },
    },
  },
}

このAPIキーエンティティのキャッシュキーをkey属性として宣言していることがわかります。ここでkeyを使用するのは、一意の制約が適用されているためです。したがって、cache_key に追加される属性は、2つのエンティティが同じキャッシュキーを生成することがないようにするため、一意の組み合わせである必要があります。

この値を追加すると、そのエンティティのDAOで次の関数を使用できるようになります。

cache_key = kong.db.<dao id="sl-md0000000">:cache_key(arg1, arg2, arg3, ...)

引数はスキーマの cache_keyプロパティで指定された属性でなければならず、指定された順に表示されます。この関数は 一意であることが保証された文字列値cache_keyを計算します。

たとえば、APIキーのcache_keyを生成する場合は次のようになります。

local cache_key = kong.db.keyauth_credentials:cache_key("abcd")

これによりAPIキー"abcd"のcache_keyが生成され(クエリの引数の1つから取得)、キャッシュからキーを取得するのに使用できます(またはキャッチがミスの場合はデータベースから取得)。

local key       = kong.request.get_query_arg("apikey")
local cache_key = kong.db.keyauth_credentials:cache_key(key)

local credential, err = kong.cache:get(cache_key, nil, load_entity_key, apikey)
if err then
  kong.log.err(err)
  return kong.response.exit(500, { message = "Unexpected error" })
end

if not credential then
  return kong.response.exit(401, { message = "Invalid authentication credentials" })
end


-- do something with the credential

cache_keyがこのように生成され、エンティティのスキーマで指定されている場合、 キャッシュの無効化は自動プロセスになります。 このAPIキーに影響を与えるすべてのCRUD操作は、影響を与えるcache_keyをKongに生成させ、クラスタ上の他のすべてのノードにそれをブロードキャストすることで、特定の値をキャッシュから退避させたうえで、次のリクエストでデータストアから新しい値を取得できるようにします。

親エンティティが CRUD 操作を受けているとき(例えば、スキーマの consumer_id 属性に従い、この API キーを所有するコンシューマ)、Kong は 親エンティティと子エンティティの両方に対してキャッシュを無効化するメカニズムを適用します。

注 : Kongが提供するネガティブキャッシュに注意してください。上記の例では、特定のキーのデータストアにAPIキーがない場合、キャッシュモジュールはヒットしたかのようにミスを保存します。つまり、「Create」イベント(この特定のキーを使用してAPIキーを作成するイベント)はKongによっても伝播されるため、ミスを保存したすべてのノードがミスを削除し、新しく作成されたAPIキーをデータストアから適切に取得できます。

Clustering Guideを参照して、このような無効化イベントに対してクラスタが適切に構成されていることを確認してください。

手動によるキャッシュの無効化

場合によっては、エンティティスキーマのcache_keyプロパティは十分に柔軟でない場合があり、手動でそのキャッシュを無効にする必要があります。これは、プラグインが従来のforeign = "parent_entity:parent_attribute"構文を介して別のエンティティとの関係を定義していないか、DAOのcache_keyメソッドを使用していないか、何らかの形でキャッシングメカニズムを悪用しているのが原因です。

そのような場合は、Kongがリッスンしているものと同じ 無効化チャンネルに自分のサブスクライバーを手動でセットアップし、独自のカスタム無効化作業を行うことができます。

Kong内の無効化チャンネルでリッスンするには、プラグインのinit_workerハンドラーで 以下を実装してください。

function MyCustomHandler:init_worker()
  -- listen to all CRUD operations made on Consumers
  kong.worker_events.register(function(data)

  end, "crud", "consumers")

  -- or, listen to a specific CRUD operation only
  kong.worker_events.register(function(data)
    kong.log.inspect(data.operation)  -- "update"
    kong.log.inspect(data.old_entity) -- old entity table (only for "update")
    kong.log.inspect(data.entity)     -- new entity table
    kong.log.inspect(data.schema)     -- entity's schema
  end, "crud", "consumers:update")
end

上記のリスナーが目的のエンティティに配置されたら、 プラグインがキャッシュしたエンティティを手動で無効化できます。 例:

kong.worker_events.register(function(data)
  if data.operation == "delete" then
    local cache_key = data.entity.id
    kong.cache:invalidate("prefix:" .. cache_key)
  end
end, "crud", "consumers")

多くの場合、プラグインを使用してconfigureを実装し、イベントを使用せずに問題/ニーズが解決するかどうかを確認するとよいでしょう。たとえば、Kongノードの役割(従来型、DBレス、データプレーン)によってイベントの動作が異なる場合があります。

Admin APIの拡張

すでにご存知かも知れませんが、Admin APIはKongユーザーがAPIやプラグインを設定するためにKongと通信する場所です。これらはプラグイン用に実装したカスタムエンティティにも対応できる必要があります(たとえば、APIキーの作成および削除)。これは、Admin APIを拡張して実行します。次の章「Admin APIの拡張」で詳細をご紹介します。


前へ カスタムエンティティの保存
次へ Admin APIの拡張
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