zeroserve v0.2.11: Caddy互換性とeBPFからネイティブへのJITコンパイル
zeroserve v0.2.11では、Caddyfileを提供することで、サーバーがそれをeBPFにJITコンパイルし、その後x86_64またはARM64のネイティブマシンコードにコンパイルするCaddy互換モードが導入されました。このプロセスにより、サーバーはio_uringイベントループ内で構成ロジックを実行できるようになり、従来の解釈型や高レベルなサーバー構成と比較してパフォーマンスが大幅に向上します。
パフォーマンスベンチマーク
HTTPSリバースプロキシのシナリオにおいて、zeroserveはCaddyに対して大幅なパフォーマンス向上を示しています。AMD Ryzen 7 3700Xの2スレッドを使用したテストでは、zeroserve（clangコンパイラを使用）は約38,948 req/sを達成しましたが、Caddyは12,529 req/sでした。
主なパフォーマンス指標は以下の通りです：
| Protocol | Server | Throughput | p50 Latency | p99 Latency | Peak RSS |
|---|---|---|---|---|---|
| HTTPS | zeroserve-clang | 38,948 req/s | 1.45ms | 3.91ms | 30.9 MiB |
| HTTPS | zeroserve-tcc | 36,653 req/s | 1.67ms | 4.00ms | 34.2 MiB |
| HTTPS | Caddy | 12,529 req/s | 4.74ms | 13.11ms | 67.4 MiB |
| HTTPS | Nginx | 37,424 req/s | 1.57ms | 4.24ms | 25.7 MiB |
これらの結果は、zeroserve-clangがCaddyの約3倍のスループットを提供し、p99レイテンシを70%削減（3.91ms対13.11ms）することを示しています。
eBPFミドルウェアによる拡張性
zeroserveはユーザー空間でチューリング完全なeBPFを実行するため、Caddyfileを介してリクエストパイプラインにカスタムネイティブコードを直接統合することが可能です。ユーザーはeBPFプラグインをロードし、zeroserve_callディレクティブを使用して、それらのプラグイン内の特定のメソッドを呼び出すことができます。
例えば、S3互換バケットに対してAWS SigV4認証を実装する場合、プラグイン（io.su3.aws-sigv4.c）をロードし、ルートブロック内でzeroserve_callディレクティブを利用して、リバースプロキシされる前にリクエストに署名を行います。
技術的実装とコミュニティのフィードバック
アーキテクチャ
zeroserveの核心的な革新は、高レベルな構成（Caddyfile） $\rightarrow$ eBPF $\rightarrow$ ネイティブマシンコードへの変換です。これにより、サーバーは柔軟な構成形式を維持しながら、io_uringの非同期I/Oの効率性を活用できます。
コミュニティの批判
技術的なユーザー間の議論では、zeroserveの採用に関するいくつかの重要なトレードオフと懸念事項が浮き彫りになっています：
- 機能の同等性: 批判的な意見では、「Caddy互換性」は構成構文に限定されており、自動ACME（SSL/TLS証明書管理）や広範なプラグインエコシステムといった、不可欠なCaddyの機能は含まれていないと指摘されています。
- セキュリティ上の懸念:
io_uringの使用とJITコンパイルは、セキュリティ上の警告を引き起こしています。一部のユーザーは、最近のセキュリティアドバイザリによりio_uringを使用してサービスを公開することはリスクがあると主張し、他のユーザーはJITコンパイルによって生み出される攻撃対象領域が「膨大」であると示唆しています。 - 実用的な有用性: 複数のコメント投稿者は、Caddyのパフォーマンスが大多数のユーザーにとってボトルネックになっているのか疑問を視ねており、水平スケーリングの方が、特化したJITコンパイルサーバーへの切り換えるよりも実用的な解決策であると主張しています。
- Nginxとの比較: ベンチマークは、Nginxがスループット（37,424 req/s）においてzeroserve-clangにほぼ匹敵し、安定性とサポートの長期的な実績を維持していることを示しています。