Zilla GatewayがApache KafkaとAIエージェントを単一設定で連携
Apache Kafkaから直接フロントエンドやモバイルクライアントにイベントをプッシュしようとしたことがある人なら、この痛苦は知っているはずです。ブラウザはKafkaのバイナリプロトコルでは動作しません。無限のマイクロサービスアダプタを書いたり、WebSocketブリッジをスピンアップしたり、Server-Sent Eventsでワークアラウンドを組み上げたりすることになってしまいます。MQTTプロトコルを使ったIoTが近くにある場合、さらに状況は複雑になり、ビジネスの要求としてAIエージェントをMCP（Model Context Protocol）経由でこのインフラに接続することも求められます。
Aklivityチームの開発者は、カスタムプロキシサーバーの束の代わりに、Zillaという単一のゲートウェイを提案しました。
Zillaできること
本質的に、Zillaは2つの役割を組み合わせています。最初の役割はおなじみのものです：イベント駆動型ゲートウェイ（Event Gateway）です。HTTP、WebSocket、gRPC、SSE経由で受信リクエストを受け取り、サーバーサイドコードを書かずに直接KafkaトピックやMQTTブローカーに変換します。
2番目の役割はバージョン2.0へのアップデートで появился。Zillaは大規模言語モデルと自律型エージェント向けのMCPゲートウェイとして動作することを学びました。AIアシスタントが異なるソース（内部REST API、Kafkaトピック、外部MCPサーバー）からツールを必要とする場合、Zillaはそれらを単一の管理エンドポイントに集約します。
すべての魔法は単一のファイルを通じて宣言的に設定されます。バインディング、ルーティングルール、スキーマ検証、セキュリティポリシーを記述し、バイナリまたはコンテナを実行するだけです。
プロジェクトの4つの主要機能
Kafkaトピックへの直接RESTとWebSocket転送
HTTP POSTを受け取ってペイロードをトピックに入れるためだけに、GoやJavaでバックエンドを書く必要はもうありません。Zillaはリクエストボディを受け取り、スキーマに対して検証し、Kafkaに書き込みます。
読み取りも同様に動作します：フロントエンドはSSE接続またはWebSocketを開き、ゲートウェイはキャッシュサポート付きでパーティションからのメッセージをクライアントコードに直接ストリーミングします。
AIエージェント向けツール連合
5つの異なるMCPサーバーに別々のキーとフォーマットでLLMを接続する代わりに、エージェントをゲートウェイアドレスに向けます：
Zillaは直感的な名前空間を通じて利用可能なツールキットを自動的にグループ化します：
エージェントは統一された関数のカタログを確認し、ゲートウェイ自体が呼び出しをどこにでも送信するかを決定します：支払いシステムのREST API、GitHub、またはメッセージキューへ。
コンテキスト制御と遅延ツール読み込み
ツールが数十個ある場合、モデルのコンテキストウィンドウはスキーマの説明で急速に埋まっていきます。Zillaはツールを「ホット」（先取り）と「コールド」に分けます。エージェントはまず基本的な機能リストを受け取り、詳細な仕様は実際に必要になったときにのみプルされます。これによりトークンが節約され、レスポンスのレイテンシが削減されます。
組み込みガードとデータ検証
ゲートウェイはJSON Schema、Avro、Protobufスキーマに対して送受信データ構造を検証します。モデルが不正な呼び出しを生成したり、クライアントが不正なJSONを送信したりした場合、リクエストは内部回路に到達する前にゲートウェイレベルでブロックされます。
内部構造
ゲートウェイはJavaで書かれていますが、アーキテクチャはクラシックなエンタープライズアプリケーションとは大きく異なります。開発者はメモリオーバーヘッドとレイテンシを削減することを目指了许多の低レベル最適化を採用しています：
- バイナリバッファをヒープ割り当てなしで操作するための軽量構造（フライウェイト）の生成。
- セッション全体を通じて接続を単一のワーカーにバインドし、コストのかかるスレッド同期を排除。
- バインディング間での共有メモリを介したフレーム交換（バックプレッシャーサポート付き）。
- Kafka用のキャッシュレイヤーでbrokerから一度だけレコードを取得し、何千もの購読者への配布。
これにより、Zillaはストリームをプロキシする際のネットワークレイテンシを実質的に追加しません。
クイックスタート
ゲートウェイを試す最も簡単な方法はDocker Compose経由です。
REST over Kafkaが必要な場合：
起動後、メッセージ送信を確認します：
AIエージェントとMCPプロトコルを実験している場合：
ゲートウェイはポート7114でStreamable HTTPサポートを持つ単一エントリポイントをスピンアップし、ポート7190でメトリクスを公開します。
ニュアンスと制限事項
プロジェクトを初めて使用时、いくつか覚えておくべきことがあります。
Zillaには独自の設定モデルがあります。ファイルは非常に詳細になります：ボールト、バインディング、ルート、パイプラインの概念を詳細に理解する必要があります。シンプルなNginx設定に慣れている場合、ここでの構文は習得に時間がかかります。
2番目の点はライセンスに関することです。ベースバージョンはAklivity Community Licenseで配布されています。任意の内部ワークロードと本番使用に対して無料ですが、Zillaを独立したサービスとして販売することを禁止しています。Redis/Hazelcastに基づく分散状態ストレージや拡張OAuth認証などの高度な機能は、商用版のZilla Plusに移動されています。
試してみる価値はあるか
Zillaは2つの統合の課題を同時に解決します。Kafka関連のボイラープレートコードの記述を排除し、AIエージェント向けのツールの動物園に秩序をもたらします。
このプロジェクトは次のような場合に特に便利です：
- イベント駆動型システムを構築しており、Webプロトコル経由でクライアントにデータを配信したいが、余計なレイヤーなしで。
- AIエージェントを開発しており、散らばったMCPサーバーとAPIキーの管理にうんざりしている。
- インフラにMQTTとKafkaが共存しており、単一のエントリポイントと監視が必要である。
リポジトリにある готовые 例から始めることができます：典型的なタスクのほとんどに明確なシナリオがあります。
関連プロジェクト