「eBPF」の利点とその登場が及ぼすクラウドネイティブへの影響とは? | 東京エレクトロンデバイス

Publickey新野淳一IT羅針盤

「eBPF」の利点とその登場が及ぼすクラウドネイティブへの影響とは?
 クラウドネイティブ最新動向(前編)

クラウドネイティブでいま注目されている技術と言えば「eBPF」と「WebAssembly」が挙げられる。この2つの技術について、クラウドネイティブの視点から、その最新動向を紹介しよう。今回はeBPFの動向と、それがクラウドネイティブへ及ぼす影響について考える。

eBPFはなぜクラウドネイティブとして注目されるのか

このコラム欄で2022年8月に公開した記事「Dockerコンテナと関連技術をやさしく解説 (最終回) Dockerコンテナと関連技術は今後どのように進化していくのか?」で、クラウドネイティブ関連でさらに注目度が高まる技術は「eBPF」と「WebAssembly」であると書きました。今回は、そこでは書き切れなかったeBPFに関する動向を紹介します。

eBPFとは、Linuxカーネルのコードを変更することなく、カーネルの持つさまざまな機能をフックすることで、カーネルに対して動的な機能拡張を実現する技術です。Linuxのカーネルの動的な機能拡張が、なぜクラウドネイティブの文脈で注目されているのか。最大の理由はネットワーク機能の拡張にあります。

一般にクラウドネイティブなアプリケーションと言えば、複数のサービスをネットワーク経由で相互に連携させる分散システムとなります。このとき、サービス間の認証、ネットワーク経路の暗号化、サービスの探索、トラフィックの制御など、ネットワークに対するさまざまな処理が行われます。

これらのネットワーク処理を行う基本的な仕組みは、どのようなサービスにも共通して必要となるため、共通の機能を提供する「サービスメッシュ」という仕組みがクラウドネイティブなアーキテクチャの中で登場してきました。このサービスメッシュを提供する仕組みとは、それぞれのサービスのネットワーク入出力部分に「プロキシ」と呼ばれる機能を組み込むことで実現していました。

それぞれのサービスにプロキシをくっつけることを、オートバイの本体の横にサイドカーをつけることに例えて「サイドカー・パターン」(もしくは「サイドカー・アーキテクチャ」)などと呼びます。サービスメッシュの代表的な実装の1つがオープンソースのIstio (https://istio.io/) であり、Istioはまさにこのサイドカー・パターンを採用しています。

しかし、サイドカー・パターンは例えば1つの物理サーバー上で30個のサービスを稼働させているとすれば、そのサービスにくっついている30個のプロキシも一緒に稼働していることになります。プロキシはどれも同じものなので、言い換えれば30個のプロキシが重複して1つの物理サーバー上で稼働していることになります。

サービスメッシュを実現するためにすべてのサービスにプロキシを組み込むサイドカー・パターンは、わかりやすい仕組みではありますが、重複が発生するぶん、コンピューティングリソースを効率的に使えていないという面がありました。

Introducing Istio Ambient Meshー東京エレクトロンデバイス
Introducing Istio Ambient Mesh - Solo.io (https://www.solo.io/blog/istio-ambient-mesh-evolution-service-mesh/)

ピンチアウトで拡大

サイドカーを不要にしたeBPFのメリット

eBPFの登場は、このサイドカー・パターンにおけるプロキシを不要にしました。というのも、サービス間の通信は常にホストOSであるLinuxカーネルのTCP/IPスタックを通ります。そこで、このTCP/IPスタックの部分をeBPFによって拡張し、サービス間通信に必要な機能をすべて組み込むことにしたのです。

これによって、2つの大きなメリットが得られました。1つは各サービスにプロキシを配置する必要がなくなったため、アーキテクチャがシンプルになると同時に、デプロイもいちいちプロキシに合わせてデプロイする必要がなくなりました。そして、プロキシが消費していたコンピューティングリソースも不要になるため、効率的になりました。

もう1つのメリットは、サービス間の通信をLinuxカーネルで集約して管理するため、通信のオーバーヘッドが小さく、管理も容易になり、可観測性が向上したことです。

これらのメリットが得られることにより、クラウドネイティブにおけるeBPFの注目度が急速に高まっているわけです。

eBPFの代表的な実装「Cilium」

eBPFを用いた代表的な実装が、Isovalent社の「Cilium」(https://cilium.io/) です。CiliumはKubernetesの開発などをホストし、クラウドネイティブなコンピューティングを推進する独立団体「Cloud Native Computing Foundation」傘下のオープンソースプロジェクトとして開発が進められており、開発元のIsovalent社が商用ソフトウェアとしても提供しています。

eBPFを用いることで、Kubernetes上で分散稼働している種々のサービス間の接続、認証や暗号化、ロードバランシング、メトリクスの取得など、サービスメッシュが提供するさまざまな機能を実現できます。

今後のクラウドネイティブにおけるサービスメッシュの実装は、Ciliumが主流となる可能性が高まり、現在のeBPFとCiliumに対する注目度も極めて高いものがあります。さらに、その勢いはeBPFの領域を超えて広がろうとしています。

その例を2つ紹介しましょう。

クラウドネイティブの外側へ進出するCilium

1つは、このCiliumによるサービスメッシュの機能をKubernetes上のサービスだけではなく、パブリッククラウドおよびオンプレミスのインスタンスや仮想マシンにまで拡大する「Cilium Mesh」をIsovalent社が2023年4月に発表したことです。

これによって、クラウドネイティブの世界とパブリッククラウドやオンプレミスで稼働している従来システムの世界をシームレスに接続し、サービスメッシュが提供するサービス間の認証、通信の暗号化、ロードバランシングといったセキュリティ機能、そしてシステム全体で統一されたメトリクスの取得による可観測性などが実現されます。

いわゆる「ゼロトラストセキュリティ」のような高度なセキュリティも、システム全体で実現することが可能になります。

このようにIsovalent社とCiliumは、eBPFの勢いに乗ってクラウドネイティブの外側の世界へも進出しようとしています。

Cilium Mesh – One Mesh to Connect Them Allー東京エレクトロンデバイス
Cilium Mesh – One Mesh to Connect Them All (https://isovalent.com/blog/post/introducing-cilium-mesh/)

ピンチアウトで拡大

Istioも“サイドカー・レス・パターン”に進化

サービスメッシュのパイオニアとしてサイドカー・パターンを採用してきたIstioも、eBPFの影響を受けて、その仕組みを“サイドカー・レス・パターン”へと進化させています。

これまでサービスごとにサイドカーとして配置していたプロキシを廃止し、その代わりにサービスをホストしているOS上にプロキシを配置。このプロキシによって、すべてのサービスからの通信を処理する仕組みに変更したのです。Istioはこれを「Ambient Mesh」(暗黙的なメッシュ)と呼んでいます。

これによって、従来のサイドカー・パターンの弱点が克服され、デプロイや管理が容易になり、コンピューティングリソースも効率良く利用できることなどが期待できます。

Istioは2023年4月、このAmbient Meshを正式な実装としてメインブランチに取り込みました。つまり、今後はこのAmbient MeshがIstioの基本的な機能として使われていくことになります。

このようにeBPFの登場は、クラウドネイティブにおける新たなアーキテクチャ・パターンをつくり出しただけではなく、クラウドネイティブの外側にも大きな影響を及ぼそうとしています。

クラウドネイティブの分野では今後も、さらに新しい変化が起きていくことでしょう。次回の「後編」では、その新しい変化を起こしている、もう1つの大きな要素「WebAssembly」について解説します。

Introducing Istio Ambient Mesh - Solo.ioー東京エレクトロンデバイス
Introducing Istio Ambient Mesh - Solo.io (https://www.solo.io/blog/istio-ambient-mesh-evolution-service-mesh/)

ピンチアウトで拡大

IT羅針盤

※このコラムは不定期連載です。
※会社名および商標名は、それぞれの会社の商標あるいは登録商標です。

新野淳一

新野淳一Junichi Niino

ブログメディア「Publickey」( http://www.publickey1.jp/ )運営者。IT系の雑誌編集者、オンラインメディア発行人を経て独立。新しいオンラインメディアの可能性を追求。