Kong についてよく寄せられる質問です。
Kong の仕組みとは？
Kong のセットアップには、次のふたつのコンポーネントがあります:
NGINX 上にビルドされた Kong サーバーは、API リクエストを実際に処理し、設定されたプラグインを実行して、リクエストをアップストリームへプロキシする前に、基礎となる API に追加機能を提供します。
Admin API は、Kong の構成、新規ユーザーの作成、プラグインの有効化または無効化、ならびにその他の多くの機能を提供します。RESTful API を使用して Kong を運用するため、Kong を既存のシステムと簡単に統合できます。
Kong は、登録された API、コンシューマーやプラグインなどの構成を、外部のデータストアに格納します。プラグイン自体には、永続化する必要があるレート制限のデータやコンシューマー クレデンシャルなどの情報を格納できます。
Kong は、このデータのキャッシュを保持するため、リクエストをプロキシ中にデータべースを往復することなく、パフォーマンスに致命的な影響を与える心配がありません。このキャッシュは、Admin API への呼び出しが行われた際に、ノード間の通信によって無効化されます。そのため、ノードのキャッシュが正しく無効化されないことから、Kong のデータストアの直接操作は推奨されません。
このアーキテクチャにより、同じデータストアに接続し、独自のキャッシュを保持する新しいノードを追加するだけで、Kong を水平方向にスケールできます。
どのデータストアがサポートされていますか？
PostgreSQL は、最も確立された SQL データベースで、チームで既に使用されている、または使用経験がある可能性があります。
設定が分散型でない場合、または自身で PostgreSQL の拡張が可能な場合に適切な候補です。Amazon RDS など、多くのクラウド プロバイダーは、PostgreSQL インスタンスをホストおよび拡張を提供します。
また、Kong はキャッシュを保持するため、ほとんどのユースケースにおいてパフォーマンスに心配はなく、PostgreSQL は Kong クラスターにとっても適切な候補です。
Kong をスケールするには、Kong サーバーをスケールし、サーバーのデータストアがインフラにおいて単一障害点ではないことを保証する必要があります。
Kong サーバーをスケールアップまたはスケールダウンすることは、比較的簡単です。各サーバーはステートレスなため、同じデータストアに対して、負荷分散装置の元で任意の数のノードを追加または削除できます。
ノードを終了すると、サーバーで進行中の HTTP リクエストを中断する可能性があるため、ノードを終了する前に、すべての HTTP リクエストが処理されたことを確認する必要があります。
前述のとおり、Kong はキャッシュを保持するため、データベースのスケーリングは最も懸念される点ではないので、データストアのトラフィックは比較的静かです。
しかし、インフラに単一障害点 (SPOF) が含まれていないことを保証することは、常に良い実践になります。そのため、データストアを詳細に監視し、データの複製を確保します。
Cassandra を使用する場合の主な利点の 1 つは、分散型で使用しやすい複製機能です。FAQ の Cassandra 部分で紹介されているドキュメントをご覧ください。
プラグインは、Kong にとって最も重要な機能の 1 つです。Kong API ゲートウェイの多くの機能は、プラグインによって提供されています。認証、レート制限、変換、ログ機能など、すべてプラグインとして独立して実装されます。プラグインは、Kong と並行して実行される Admin API を通してインストールおよび設定できます。
ほとんどのプラグインはカスタム可能で、特定のプロキシされたサービスをターゲットするだけでなく、特定のコンシューマーをターゲットします。
技術的な観点では、プラグインはプロキシされたリクエストとレスポンスのライフサイクル中に実行される Lua コードです。プラグインを通して、Kong をあらゆる顧客のニーズや統合へのチャレンジに合わせて拡張することができます。例えば、API のユーザー認証をサードパーティのエンタープライズのセキュリティ システムと統合する場合、その API をターゲットとするすべてのリクエストで実行される専用のプラグインで実装されます。
デプロイ可能なプラグインの幅広いセットは、Kong プラグイン ページからご確認ください。プラグインの構成とともに、プラグインを有効化する方法を参照してください。
追加の無償版開発者向けのプラグインは、Github 上で入手できます。そして、プラグインの開発ガイドを参照して、Kong プラットフォームの機能を拡張する新規のプラグインを作成しましょう。
Kong のマイクロサービス および API ゲートウェイは、基本的に異なるアーキテクチャを採用しており、コミュニケーションの待機時間を短縮し、取り幅広いサービスを提供するため、API 管理とは大きく異なっています。
API 管理ソリューションは、アプリケーション開発の初期の時代に生まれ、「いかにして確立されたモノリシックなアプリケーションにサード パーティがアクセスするための外部使用可能な API を提供するか」というその当時における非常に重要な問題にソリューションを提供しました。初期のモバイルアプリケーション アドオンや、パートナー アクセスの可能な API による、ミッションクリティカルなアプリケーションへの読み取りアクセスを思い出してみてください。当時のアプリケーションは、モノリシックなデザインのものが主要であったため、機能間の内部通信は、外部 API ではなく、内部の関数呼び出しによって処理されていました。
API 管理ソリューションの発明以降、アプリケーション開発と導入パターンは劇的な変化を遂げました。最新のアプリケーション開発では、RESTful API やマイクロサービス、コンテナー、クラウド、および分散システムなどの革新は一般的なものとなりました。このような技術革新を採用するには、低レイテンシで内部通信だけでなく、外部通信も動かす方法が必要となります。このニーズにより、現在のマイクロサービス/API ゲートウェイおよび Kong が誕生する結果となりました。
API ゲートウェイは、大容量で低レイテンシの内部および外部通信を可能にする最新のアプリケーション開発において必要不可欠なコンポーネントとして浮上してきました。さらに、ゲートウェイは、内部および外部のコンシューマー両方に対して認証やレート制限、キャッシング、ロギングなどの追加のサービスを提供します。ゲートウェイでこれらのサービスを有効にすることにより、開発者は各マイクロサービスごとにコーディングを繰り返す必要がなくなり、最終的にチームの生産性が向上します。
API 管理システムは、外部の API 通信にも役立ちます。Kong のような API ゲートウェイは、、API の管理機能とともにサブミリセカンドのレイテンシを提供するため、開発者は単一のテクノロジを使って内部、外部両方の API 処理を実現できるようになります。
API ゲートウェイは、クライアントとアプリケーション間、およびアプリケーション内のマイクロサービス間における API 通信を容易にします。レイヤー 7 (L7/HTTP) で動作する API ゲートウェイは、認証、レート制限、変換、ロギングなどの付加価値サービスとともに、内部および外部通信の両方を提供します。
サービス メッシュというのは、内部通信のルーティングに焦点をあてた、新しいテクノロジです。サービス メッシュは主にレイヤー ４ (L4/TCP) で動作し、ヘルス チェックやサーキット ブレーカーなどのサービスとともに内部通信を提供します。
API ゲートウェイとサービス メッシュはネットワーク スタックの異なるレイヤーで動作するため、それぞれに長所を持っています。
Kong では、API ゲートウェイとサービス メッシュの両方のソリューションに注力しています。開発者には、あらゆる内部、外部通信や付加価値サービスに対応できる、統合された信頼できるインターフェイスが必要です。しかし、今日では、API ゲートウェイとサービス メッシュは、異なるアーキテクチャや実装の選択を必要とする、異なったソリューションであるかのように見えます。近い将来、それは変わっていくものと思われます。
Kong は、ブラウザーやモバイル、IoT クライアントからアクセスする Web や SaaS アプリケーションに最もよく導入されている API 標準の REST API をフルサポートしています。
REST とは、"Representational State Transfer" の略で、HTTP や HTTPS などのステートレスのクライアント/サーバー、キャッシュ可能な通信プロトコルに依存しています。
RESTful な API では、 「コンシューマー」は /product/vase/ などのリンク (リソース) や、GET、DELETE などの特定の HTTP 操作 (メソッド) を選択してアプリケーションを実行し、結果として次のリソース (アプリケーションの次のステート) が転送されます。“Learn REST” は、REST API について学ぶために非常に役立つチュートリアルの 1 つです。
さらに、管理者は、RESTful な Kong Admin API を使って Kong をデプロイして管理したり、API を追加したり、コンシューマーの設定をしたりできます。
マイクロサービスや API は無制限に追加することができ、また Kong を使ってそのすべてを処理できます。Kong は現在、HTTP または HTTPS を介する RESTful なサービスをサポートしています。Kong に 新しいサービスを追加する方法は、こちらをご参照ください。
多数のリクエストを処理している場合には、Kong のサーバーをクラスターに追加することにより、Kong を水平にスケーリングできます。
サービスの上に認証レイヤーを追加するには、Plugins Hub で利用可能な Basic Authentication (基本認証)、Key Authentication (鍵認証)、OAuth 2.0、OpenID Connect などのプラグインを選択します。
はい、Kong はクラウド、オンプレミスで、シングルベンダー、マルチベンダー、分散型のセットアップをサポートしています。
Kong は、完全にプラットフォーム非依存の、類まれな API ゲートウェイの 1 つです。つまり、プライベートのデータセンターとパブリック クラウドの間で簡単にアプリケーションを移動できます。1 つのパブリック クラウドから別のパブリック クラウドに移動することも、任意の数のデータセンターやクラウド環境でグローバルなハイブリッド環境を構成することもできます。
Kong の利用により、クラウド ベンダーのロックインから解放され、独自のコンピューティング環境を管理できます。
すでに既存の API ゲートウェイを利用中で、Kong への移行を検討している場合には、次の 2 つのステップを考慮する必要があります。
Kong Enterprise のユーザーは、移行のサポートを受けることができます。
おそらく互換性があると思われます。Kong および Kong のプラグインは HTTP や JSON などの業界標準に準拠しています。Kong は、NGINX の Web およびプロキシ サーバー。PostgreSQL および Cassandra データストア、Linux やコンテナーの動作環境、ならびにマイクロサービスのデザイン パターンに基づく API など広範囲にわたってテストされています。Kong はアプリケーション レベルで動作し、業界標準に準拠しているため、あらゆる主要な Web テクノロジやオーケストレーション、ログ管理、マイクロサービス開発ツールなどと幅広い互換性があります。
この FAQ 以上より詳細な技術情報は、Kong 社のドキュメントを参照してください。
また、ミートアップに参加して直接お問い合わせいただくことも可能です。
高度な機能を備え、Kong のカスタマー サクセス チームによるサポート付きの商用バージョンである Kong Enterprise をご希望の場合は、こちらでお問い合わせください。
Kong Enterprise サブスクリプションには、 Kong のカスタマー サクセス チームへのアクセスが含まれ、Kong API ゲートウェイのスペシャリストからのサポートが得られます。
製品の詳細、ライセンス体系、デモの依頼など、お気軽にお問い合わせください。