Kong Event Gateway – イベント駆動で始まるAPIプラットフォームの新時代へ
英語によるオリジナルはこちらでご覧いただけます。
EDA（イベント駆動アーキテクチャ）とAPIの世界の融合へ
過去数年間、API管理とイベント管理の融合に関する噂が囁かれてきました。これは単なるベンダー主導の現象を超えた動きであり、ガートナーやフォレスターといった業界アナリストも両分野の融合を指摘しています。そのため、ガートナーは2024 Gartner Magic Quadrant for API Managementレポートでイベントストリーミングとイベント駆動型アーキテクチャに触れており、 また、ForresterのDavid Mooterは2022年に「API戦略を拡張し、イベント駆動型およびリアルタイムメッセージングのユースケースをカバーする必要性」について執筆しています。
アナリスト界ではこの融合について長年議論されてきましたが、市場全体が追いつくには少し時間がかかりました。
しかし、もはやそうではありません。
現在、私が話すほぼすべてのプラットフォームチームリーダーやエンタープライズアーキテクトは、2025年から2026年の内部ロードマップに「統合」（これが彼らがよく使う言葉です）という言葉を掲げていると述べています。
なぜでしょうか？そして、なぜ私たちはここでKongとしてこのテーマについてブログを書いているのでしょうか？
起こりつつある融合 -現状
まず、なぜこれが必要なのかから始めましょう。
EDA側の多くの課題は、API管理によって解決されてきた「伝統的なAPI」側の課題と非常に類似しています（私は「伝統的」という言葉を好んでいません。リアルタイム通信やWebSocketsなどは決して新しい技術ではありませんが、APIの専門家はRESTを「伝統的」と捉えているため、ここではその表現を維持します）。例えば：
- 内部および外部ユーザー向けにイベントストリームを安全に公開する → 伝統的なAPI側では、APIゲートウェイを安全な公開層兼プロキシ層として活用することでこの課題を解決しています。
- イベントストリームをセルフサービス型データ製品としてパッケージ化し、開発者（場合によっては有料顧客）がリアルタイムイベントを容易に発見・利用開始できるようにする → 伝統的なAPI側では、API開発者ポータルをセルフサービス型APIカタログとして活用することでこの課題を解決しています。
したがって、ガートナーとフォレスターが指摘するように、API管理ベンダーとAPI戦略の組織リーダーは、伝統的なAPIプラットフォームの機能をイベント管理まで拡張することを検討すべきです。技術とアプローチは既に存在しています。なぜ市場やエンジニアリングチームに、異なるプロトコルや通信パラダイムをサポートするためだけに、同じソリューションを再構築させる必要があるのでしょうか？
チームトポロジーとAPIに対する誤った認識
では、なぜこの統合がこれまで実現しなかったのか、その理由に焦点を当てましょう。
「なぜイベント管理にAPI管理を使わないのか？」という質問は単純に思えるかもしれませんが、このトレンドは今までに本格的に広がり始めていませんでした。この遅れの主な原因は2つあります。最も大きな要因は、組織の構造とAPIに対するアプローチや態度です。具体的には次のような点です。
チームトポロジー：単一のチームではなくAPIチームとEDAチームという分離
APIとイベントの統合の真の障害は、組織の構造と言語の問題に起因しています。歴史的に、ほとんどの組織では「APIチーム」と「イベントチーム」の間には明確な区分が存在してきました。たとえ行う業務の内容が類似していたとしても（例えば、APIやイベントストリーミングリソースからのデータへのアクセス提供や消費の管理など）、役職名は類似していても、依然として異なるものでした。例えば、私はよくAPIエンタープライズアーキテクトとEDAエンタープライズアーキテクト、APIオーナーとデータオーナーなど、異なる役割を持つ人々との議論を交わしています。
チームの分断と異なる言語がもたらすコミュニケーション障害
APIゲートウェイが「Kafkaをサポートする」ようになった頃でも、Kafka EDAチームは「APIゲートウェイ」や「API管理」について聞く余裕がありませんでした。これは「APIチーム」の領域であり、KafkaチームはEDAチームです。私はよくEDAチームに、EDAにおいてAPI管理を活用する理由を説明しましたが、しばしば無言の反応や、ぼんやりとした目、または「それは何ですか？」という返答を受けました。しかし、ソリューションが提供する実際の機能について説明すると、状況は変わりました。
例えば、次のように説明すると：
- 「ゲートウェイをイベントプロキシとして使用し、HTTPクライアント向けにHTTP経由でイベントを公開したり、Kafkaクライアント向けにネイティブプロトコル経由で公開したりできます」
- 「API開発ポータルを、API製品と — イベントストリーミング用に — データ製品をカタログ化する場所として使用できます」
- 「実際にイベントをAPIとして公開し、クライアントがHTTP経由でKafkaトピックとデータを送受信できるようにできます」
…チームはようやく理解し始め、有意義なディスカッションへと繋がりました。
多くの組織 （ 特に現在） は、イベントの公開と消費に関する問題をようやく認識し始めています。一部は以前から問題に気づき、KafkaをREST APIやWebSocket APIとして公開できるAPIゲートウェイを構築しましたが、その機能を「イベントプロキシ」と呼んでいました。これらの組織は、セルフサービス型の発見問題に取り組むため、独自の「イベントポータル」を構築し始めました。このポータルは、ビジネスクリティカルなサービスの発見や登録のための「真実のソース」として、APIカタログや開発者ポータルとは別に存在することになりました。
これらのカスタムソリューションは、ベンダーソリューションよりも組織に莫大なコストをかけており、エンジニアリングチームがコアビジネスロジックに集中するのを妨げていました。そのため、概念が明確になり、自社の用語で理解できるようになると、これらのチームはAPIゲートウェイのようなものを採用し、それを「イベントゲートウェイ」として活用する可能性に開かれていきました。
「プラットフォームの時代」がもたらす新しい変化
現在、組織と話をすると、APIとイベントの統合の必要性は非常に明確です。説明や翻訳にそれほど時間をかけなくても済みます。多くの場合、APIやイベントについて尋ねなくても済みます。単に「今年と来年に焦点を当てていることは何ですか？」と尋ねると、ほぼすべてのケースで「プラットフォームにおけるAPIとイベントの管理方法を統合したい」という回答が返ってきます。特に大規模な組織との会話ではその傾向が顕著です。
何が変わったのでしょうか？
私が気づいた主なトレンドは、先ほど述べたトポロジーの課題と関連していますが、私はプラットフォームエンジニアやプラットフォームチームと話をしているということです。
これはよく考えてみれば当然のことです。
「APIチーム」の責任が「APIを機能させること」で、EDAチームが「EDAとイベント処理を機能させること」だった場合、APIチーム内でEDAに関する議論の余地はほとんどなく、逆にEDAチーム内でAPIに関する議論の余地はさらに少なかったでしょう。彼らの役割は、本質的に「ビジネスクリティカルなサービスの種類」に沿ってサイロ化されていました。
しかし、プラットフォームチームの責任は異なります。プラットフォームチームはサイロを打破し、サービスを利用するエンジニアがすべてのビジネスクリティカルなサービスにアクセスできるようにし、サービスを提供するエンジニアがすべてのツールやプロセスにアクセスできるようにすることを目的としています。
プラットフォームチームは本質的にサービス固有ではありません。彼らは、開発者プラットフォームに可能な限り多くの異なるサービスを組み込む方法を模索する必要があります。プラットフォームに組み込まれるサービスが増えるほど、エンジニアのイノベーションの可能性も高まるからです。なぜアプリ開発者にREST APIへのアクセスだけに限定するのでしょうか？リアルタイムデータソースへのアクセスも提供すべきではないでしょうか？つまるところ、ごく一部のトップクラスのリアルタイムビジネスは、下位４分の1のリアルタイムビジネスを圧倒することは周知の事実です。
APIとイベントストリーミング/EDAの責任を両方引き受けるプラットフォームチームが増えるにつれ、APIとイベントをビジネスクリティカルなサービスとして、アクセス方法、構築プロセス、DevExなどを統一する方向への自然な動きが生まれています（AIについても同様ですが、ここではその話題は割愛します）。
ニーズは既に存在しており、プラットフォームチームはAPIとイベントのためのプラットフォームを求めている。ただ市場が追いついていない。
しかし、残念ながら、ごく最近まで市場におけるソリューションはかなり脆弱でした。最近になって「イベントをAPIとして利用する」というユースケースに参入した数少ない企業は、EDA（イベントデータアーキテクチャ）とイベント処理のユースケースに対応するAPIゲートウェイの点解決策を提供しています。しかし、これらのソリューションは伝統的なAPIユースケースには対応が不十分で、ベンダーはAPIプラットフォームのコア機能の基盤整備ではなく、これらの専門的なソリューションの開発に時間とリソースを注いできました。具体的には以下の点です：
- APIインフラのセルフサービスプロビジョニングを通じて「ゲートウェイへのアクセスを容易にする」こと。
- プラットフォームチーム向けのより高度な自動化。
- APIOpsサポートAPIとサービスディスカバリー両方の側面を優先し、消費者がAPIとイベントストリーミングサービスを登録・消費するために発見でき、生産者がAPIとイベントストリーミングサービスを内部の在庫管理やガバナンス目的で発見できること。
ここにKong Konnect APIプラットフォームが登場します。
Kong Event Gateway – イベント駆動の為のAPIプラットフォーム
Kong Konnectをプラットフォーム構築者向けのAPIプラットフォームと考えるかもしれません。KonnectをAI向けのAPIプラットフォームと考えるかもしれません。実際、私たちは両方の呼び方をよく使っています。なぜなら、両方とも真実だからです。
現在、私たちはまたEDAとリアルタイムデータ向けのAPIプラットフォームでもあります。
以下がその仕組みです。
プロトコル変換：イベントブローカーをイベントAPIプロダクトのソースとして公開
イベントの生産と消費には多くの異なるユースケースが存在し、その一部はネイティブプロトコル外での作業を必要とします。Event Gatewayのサポートを最初に導入したイベントブローカーはKafka（今後追加予定）です。そのため、ここではKafkaを例に説明します。
現在、Kafka内のリアルタイムデータへのアクセスを共有することは困難です。手動作業、カスタム統合、または複雑な開発作業が必要になることが多くあります。また、リアルタイムデータを外部（潜在的に収益化可能な）消費向けに安全にパッケージ化して製品化することは、非常に困難です。
Kongのソリューション：イベントストリームをセルフサービスAPIデータ製品として提供
開発者はEvent Gatewayを使用して、プロトコル仲介を介してKafkaプロトコル経由で通信しないイベントAPIとしてKafkaを公開できます。
プロトコル仲介のアプローチにより、Kafka内のリアルタイムデータの価値を、Kafkaクライアントとしてアプリケーションを設定する手間を省きたい、またはできない開発者や顧客にも提供できます。Kong Event Gatewayの顧客は、このリアルタイムデータへのアクセスをREST APIやサーバー送信イベントAPIとして公開でき、開発者、パートナー、顧客のニーズに応えることができます。
さらに、単なる仲介機能を超えて、ゲートウェイプラグインを使用してゲートウェイ経由でポリシーを強制適用できます。これは、Kongを伝統的なREST APIケースで使用する場合と同様です。
リアルタイムデータを消費しやすいデータAPI製品として製品化することで、開発者はリアルタイムデータを探索、消費、およびその上に構築するためのシンプルで安全なセルフサービス型のアプローチを提供できます。
注：現在、私たちはKafka（これが私たちの出発点です）について多くの時間を割いていますが、Solaceイベントブローカーのサポートは近日中に追加予定です！Event Gatewayは真のマルチプロトコルおよびマルチブローカー対応を計画しています。
顧客は、支払う価値のあるリアルタイムデータに容易にアクセスできること、または組織が構築する製品やサービスでより良いリアルタイム体験を得られることで恩恵を受けます。
ビジネスは、開発者にAPIへのセルフサービスアクセスを提供することで、アプリケーションを登録し、リアルタイムデータソースを消費し、最終的にリアルタイムな顧客体験を創出するプロセスが加速され、リアルタイム製品の迅速なリリースが可能になることで恩恵を受けます。
ネイティブKafkaサポート：ネイティブKafkaサービスとして公開
プロトコル仲介は、特にデータ製品化シナリオやKafkaの導入初期段階にある組織にとって非常に有用ですが、Kafkaの成熟度が高い組織では、ネイティブKafkaプロキシ（KafkaサービスをネイティブKafkaプロトコルで公開するが、ゲートウェイ経由で提供される）が一般的に選択される方法です。
そのため、私たちはより大規模なEvent Gatewayサービスにネイティブイベントプロキシを組み込みました。
技術的には別々のランタイムですが、Kongネイティブイベントプロキシは、ゲートウェイ経由でKafkaブローカーをネイティブKafkaサービスとして公開し、KafkaクライアントがKafkaブローカーからデータを読み書きできるようにします。これにより、プラットフォームチームとEDAチームは次のようなことが可能になります：
- EDAとAPIの両環境において一貫したセキュリティ基準を適用するため、認証仲介機能を活用し、OIDC、OAuth2、JWTなど、ネイティブKafka露出シナリオに最適な認証プロトコルを利用できま
- Event Gatewayを活用して、ネットワーク内での中央集約型ローカル暗号化を強制し、Kafkaクライアントの負荷を軽減し、暗号化されていないデータがクラウド管理型のイベントブローカー環境に到達しないようにすることで、より多くのEDAワークロードをクラウドに移行できます
- クラスターの仮想化とトピックフィルタリングを活用し、開発ライフサイクルの異なる段階や下位環境での作業において、Kafkaインフラストラクチャを効率的に活用できます
もちろん、これらすべてはKonnect APIプラットフォーム内の統合されたサービスとして提供されるため、開発者はKonnectで従来のAPIインフラストラクチャを構築するのと同じように、Event Gatewayインフラストラクチャを簡単に構築できるようになります。
現在、ネイティブKafkaプロキシはすべてのKonnectユーザーで有効化可能ですが、新しい早期アクセスプロセスを試行中であり、興味のあるチームに対しては手動でアクセスを有効化しています。興味がある方は、こちらからサインアップしてください。
まとめ：イベント駆動から始まる新しいAPIプラットフォームの時代へ
APIは、あなたが重視するあらゆるイノベーションの核心にあります。これにはイベントも含まれます。AIの価値は、安全で管理されたAPIサービスとして提供されることで現実のものとなります。マイクロサービスは、サービス間通信が一貫性がありスケーラブルなAPIによって駆動される際に価値を生み出します。ハイブリッドおよびマルチクラウドアーキテクチャへの移行は、本質的に、エレガントなAPIインフラストラクチャによって接続され、その上に構築されたシステムへの移行です。
イベントとリアルタイムデータは、セルフサービスAPIとしてパッケージ化されることで、真のデータ製品となります。
Kong APIプラットフォームを活用してAPI主導のEDA（イベント駆動アーキテクチャ）とリアルタイムイノベーションを推進したい場合は、デモを予約する、カスタマーサクセスマネージャーに連絡する、またはKongネイティブイベントプロキシの早期アクセスプログラムへの参加を希望する旨をお知らせください。
あなたがどんなものを構築するのか？我々も楽しみにしています。