【 Kong 】Kong Gateway 3.0 の一般公開について

2022.09.28 KongProduct Releases

はじめに

はじめに
トレースと OpenTelemetry
WebSockets (ベータ版)
Secrets Management (GA)
FIPS 140-2 準拠
プラグインの順序付け
新しいルーティングエンジン
Kong Manager 3.0
非推奨項目と削除項目
その他のハイライト
今すぐ Kong Gateway 3.0 をお試しください

Kong Gateway 3.0は、当社のクラウドネイティブな API プラットフォームに新たな進化をもたらす重要なマイルストーンです。Kong Gateway 3.0 にはエンタープライズエディションとオープンソースエディションがあり、いずれもお好みのディストリビューションチャネルから入手可能です。

Kong Gateway 3.0 には、強力な機能が多数備わっており、次のような大きなメリットが得られます。

セキュリティとガバナンスの強化：
FIPS 140-2 準拠の Kong Gateway ランタイムとセキュアなシークレットストレージ (Gateway の操作とプラグイン全体で使用) により、セキュリティとコンプライアンスの要件を満たします。
柔軟性と拡張性：
プラグインの実行順序の選択、WebSocket トラフィックのネイティブサポートの追加、さらに OpenTelemetry との緊密な統合が活用できます。
容易な API 管理：
Kong Manager UI の新機能により、ユーザーエクスペリエンスが向上します。新たに強力なルーティングエンジンを採用したことで、複雑なルートを最適化すると同時に、ランタイムパフォーマンスも向上します。
パフォーマンスの大幅な向上：
Kong 3.0 では、Kong 2.8.1.4 と比較して、スループットでは 37% 以上向上し、非常に複雑なルーティングシナリオにおいて、99 パーセンタイルで 47% 以上、100 パーセンタイルでは 27% 以上レイテンシーが削減されています。この場合、メモリ消費量も 9% 削減されます。

では、今回のリリースの主なポイントを見てみましょう。

注記: 新機能のタイトル業にあるEnterpriseおよびOSSという単語は、Enterpriseエディション、OSSエディションのいずれか、または両方に搭載されていることを示しています。

トレースと OpenTelemetry

Enterprise / OSS

Kong Gateway の動作を理解しておくことは、どのような展開においても重要です。今回 Kong Gateway のOSSエディションと Enterpriseエディションの両方で、広範なトレースができるようになったことは大変画期的なことです。トレースを始める方法は 2 つあります。まず、すぐに利用できる OpenTelemetry プラグインを使用して、準拠したバックエンド、または OpenTelemetry コレクターに直接 OTel スパンを送信する方法です。私の場合は、Honeycomb を使って Kong Gateway をテストしていますが、うまく動作しています!

以下は、mockbin.org への単一のリクエストをプロキシするトレースです。

次に、Rate Limiting (レート制限) プラグイン (Redis バックエンドを使用) を有効にした後の、同じリクエストが次のようになります。

図 2 : Rate Limiting プラグインを有効にした場合の同じリクエスト

2 つめの方法は、Kong のトレース用 Plugin Development Kit (PDK) を使用して、すべての重要なイベントにフックする方法です。これが OpenTelemetry プラグインの仕組みで、トレース情報の収集方法やサンプリング方法、およびそのデータを他のシステムにエクスポートする方法を完全に制御できます。

どちらのオプションを選択するとしても、Kong Gateway の動作を理解しておくことが重要です。リクエストごとに、時間がかかっている場所を特定することで、パフォーマンスを向上させる最適化が可能となり、結果的にユーザーの満足度は高まります。

WebSockets (ベータ版)

Enterprise

Kong Gateway 3.0 では、独自の WebSocket プラグインを開発できるPlugin Development Kit (PDK) に加えて、2 つの新しい WebSocket プラグインを提供しています。

1 つめの新しいプラグインは、WebSocket フレームを検証し、JSON スキーマを使用して正しくフォーマットされていることを確認します。クライアントから受け取るフレームと、アップストリームからクライアントに送り返されるフレームを検証できます。

# Require a ‘message’ key in the payload that’s a string

curl localhost:8001/routes/ws-validator-route/plugins -d name=websocket-validator -d config.client.text.schema='{"type":"object","properties":{"message":{"type":"string"}},"required":["message"]}' -d config.client.text.type="draft4"

2 つめのプラグインでは、クライアントとアップストリームの両方から受け取るフレームのサイズを制限できます。これで、サイズが大きすぎてアプリケーションがクラッシュする可能性のあるフレームを、API やユーザーが受信するのを防ぐことができます。

# Limit frames to 4kb

curl localhost:8001/routes/ws-framesize-route/plugins -d name=websocket-size-limit -d config.client_max_payload=4096

今回のベータ版リリースは、Kong で今後 WebSocket 対応を本格化させる一歩目にすぎませんので、ぜひ、Kong Nation に皆さんのご意見をお寄せください。

Secrets Management (GA)

Enterprise / OSS

当初はベータ版として Kong Gateway 2.8 で Secrets Management をリリースしましたが、今回のリリースで正式に対応となりました。

Secrets Management を使用すると、Kong が実行時にアクセスする外部の保管場所 (OSS、AWS Secrets Manager、および HashiCorp Vault for Enterprise の環境変数) に機密情報を安全に保存できます。機密性の高い値をシークレットとして保存することで、プラットフォーム、kong.conf あるいは宣言型構成ファイル、ログや Kong Manager UI において、プレーンテキストでは表示されないようにすることができます。

さらに、vault secrets を使用すると、開発環境、ステージング環境、および本番環境で固有の値を設定しながら、まったく同じ宣言型構成ファイルを使用して個々の環境を設定できます。

Secrets Management を使用するのは本当に簡単です ! これまでプレーンテキストでパスワードを設定していた場所を、次のようにValutパスに置き換えます。

{vault://hcv/redis/password}

Kong は実行時にこの参照場所を検出し、安全に解決します。

Secrets Management の詳細については、近く公開されるブログをご覧ください。Proxy Cache Advanced プラグインを使用する際に、HashiCorp Vault に Redis パスワードを保存する方法を説明する予定です。

FIPS 140-2 準拠

Enterprise

「FIPS(Federal Information Processing Standards、連邦情報処理標準 )」という言葉に敏感な方 (政府行政機関や金融サービス業界で働いている方のはず) であれば、この機能に興味を持たれることでしょう。Kong Gateway は、BoringSSL ベースのビルドを提供するようになり、コア FIPS 140-2 準拠となりました。

現在、当社のすべてのプラグインが FIPS 準拠となるよう更新作業を進めています。特定のプラグインの詳細については、当社までお問い合わせください。

プラグインの順序付け

Enterprise

プラグインは Kong Gateway の中核をなすものですが、プラグインを適用する順序を決定するのは難しい問題です。レート制限は認証の前に実行すべきでしょうか? レート制限を確認する前に、リクエスト変換を実行できるようにすべきでしょうか?

チームごとにニーズは異なるため、Kong Gateway 3.0 では、プラグインを実行する順序を柔軟に決定できるようになっています。デフォルトは合理的なものが設定されていますが、ブルートフォース攻撃を防ぐために、認証の前にレート制限を実行する場合は、追加の設定を 1 つ行うだけで済みます。

curl -i -X POST http://localhost:8001/plugins \

  --data name=rate-limiting \

  --data config.minute=5 \

  --data config.policy=local \

  --data ordering.before.access=key-auth

プラグインの順序は、前または後に実行するプラグイン名を指定することで、Admin API や decK を使用した宣言型構成ファイルで定義することができます。

新しいルーティングエンジン

Enterprise / OSS

この新機能は技術的な色がやや濃いため、少しご辛抱ください。Kong Gateway 3.0 には、アップストリーム API にリクエストをルーティングする際に使用する、まったく新しい「式」ルーティングエンジンが搭載されています。

GET リクエストと POST リクエストを、HTTP リクエストの場合にのみルーティングするケースを考えてみましょう。JSON を使用してルートを設定する代わりに、次のような式を記述します。

net.protocol == "https" && (http.method == "GET" || http.method == "POST")

これはシンプルな例ですが、特定のホストに一致し、ホスト名が記述されたヘッダーを含むリクエストをルーティングするケースを考えてみましょう。これは想像しにくいと思いますが、次のようになります。

(http.host == "example.com" && http.headers.x_example_version == "v2" ) ||

(http.host == "store.example.com" && http.headers.x_store_version == "v1")

このルートは、ホストが example.com かつ x-example-version ヘッダーが v2 と等しい場合、またはホストが store.example.com かつ x-store-version ヘッダーが v1 と等しい場合にのみ一致します。これは、Kong Gateway 3.0 の新しいルーティングエンジンの柔軟性がわかる良い例です。Kong Gateway 2.x で同じ動作を実現するには、2 つの別々のルートを作成する必要があります。

新しいルーターは表現力が高くなっているだけでなく、パフォーマンスも向上しているのです ! 大規模なルーティング設定では、設定が変更されるたびにルーター全体を再構築するのではなく、差分をリロードできるようになりました。これにより、当社のテストでは、P99 の時間が 1.5 秒から 0.1 秒に短縮されました。

最後に、2.x の JSON ルーターについてですが、もちろん大丈夫です。まだ動作します ! サポートが必要な既存のルーティングルールについては、3.0 でも既存のルーターを利用できます。kong.conf で router_flavor を traditional に設定すれば、2.x シリーズと同様に動作します。

Kong Manager 3.0

Enterprise

3.0 では Kong Manager を刷新し、Service、Route、Consumer、Plugin などの主要な Gateway エンティティがより直感的に設定できるようになりました。エンティティの設定方法は、[View Config] ボタンをクリックして表示させずに、前面の中央に表示され、同じビュー内ですべて編集可能になりました。

Empty状態が更新され、より簡単に始められるようになり、構成オプションを説明するヒントが追加となり、サービスやプラグインが誤って削除されないようになりました。

最後に重要なのは、サービス概要ダッシュボードも刷新されています。より多くの情報が表示されるようになり、使い勝手はさらに向上しています。提供する API サービス数、発行済みリクエスト数、HTTP ステータスの内訳 (エラー率など) がダッシュボードで一目瞭然となります。さらに、ライセンスが期限切れにならないように、新たに「License expiration (ライセンスの有効期限)」ウィジェットが設けられました。

とは言え、これは Kong Manager の序章にしか過ぎません。Kong Gateway 3.1 以降のアップグレードにもぜひご期待ください。

非推奨項目と削除項目

Kong の安定性への取り組みとして、メジャーバージョン内のすべてのリリースで下位互換を維持しています。Kong Gateway 3.0 では、製品の品質を向上させるため、いくつかの機能を非推奨とし、また削除した機能もあります。

非推奨または削除された項目は次のとおりです。

Kong Gateway は、route.path が正規表現パターンかどうかを推測する際に、ヒューリスティックを使用しなくなりました。3.0 以降では、正規表現のパスは必ずプレフィックスに「~」を付ける必要があり、「~」で始まらないパスはすべてプレーンテキストと見なされます。2.x から 3.0 へのアップグレードの際、移行プロセスで正規表現パスは自動的に変換されます。
nginx-opentracing モジュールへの対応は 3.0 では非推奨となり、4.0 では Kong から削除される予定です。その代わりとして、新たなトレース用 PDK および OpenTracing モジュールを使用してください。
Amazon Linux 1 と Debian Jesse オペレーティングシステムは正式対応からはずれました。
/targets エンドポイントの POST リクエストは、既存のエンティティを更新できなくなりました。エンティティの新規作成のみ可能です。POST リクエストを使用して /targets を変更するスクリプトがある場合、Kong Gateway 3.0 にアップデートする前に、適切なエンドポイントに対する PUT リクエストに変更してください。
Prometheus プラグインでは、高カーディナリティメトリクスがデフォルトで無効になりました。このため、Prometheus が統計情報を取得する際のデータベースの負荷が軽減されます。

これらをすべて網羅したリストについては、Kong Gateway のchangelog をご覧ください。

その他のハイライト

長くなってしまいましたが、最後に今回のバージョンに関するその他の機能強化点について簡単に触れたみたいと思います。

プラグインバージョンの整合：
以前は、実行しているプラグインのバージョンを正確に把握することは困難でした。Kong Gateway 3.0 では、プラグインのバージョンをゲートウェイのバージョンに合わせて、実行しているプラグインのバージョンを正確に把握できるようにしています。
Slim/UBI イメージ：
Docker ビルドのベースイメージを debian-slim と rhel-ubi に切り替えました。これでイメージサイズが小さくなり、インストールされるパッケージが少なくなるため、イメージの安全性が向上します。
システム認証局：
Kongは、デフォルトでホストオペレーティングシステムにインストールされている任意の CA 証明書を使用するようになりました。これにより、すべてのソフトウェアの認証局を 1 か所で管理できます。
LDAP 認証：
当社の LDAP 認証プラグインを使用すると、LDAP サーバーに対して認証を行うことでサービスを保護できます。Kong Gateway 3.0 では、グループのメンバーシップに基づいた認証に対応しています。これで、「FinanceDev チームのメンバーのみがこの API にアクセス可能」ということが可能になります。

今すぐ Kong Gateway 3.0 をお試しください

機能、修正箇所、およびアップデートなどをすべて網羅したリストについては、Kong GatewayのCHANGELOG (こちら) と、Kong Gateway OSS (こちら) をご覧ください。
今すぐ Kong Gateway 3.0 をお試しください。エンタープライズエディションとオープンソースエディションの両方が無料でダウンロードしていただけます。すでに Kong Gateway をインストールされている場合は、3.0 へのアップグレードは簡単です。アップグレードガイドをご覧ください。

原文：Announcing General Availability of Kong Gateway 3.0
著者：Michael Heap