CNDT 2022、IsovalentのアドボケイトがeBPFを解説

CNDT 2022から、IsovalentのテクニカルコミュニティアドボケイトであるTracy P Holmes氏によるeBPFを解説するセッションを紹介する。

●動画：Cloud Native Superpowers with eBPF

冒頭で日本人として初めてのIsovalentの社員となった早川侑太朗氏が登場し、eBPFが注目されており、日本でもSNSなどで多く言及されていることを紹介。その後、アドボケイトのTracy P Holmes氏に引き継いだ。

日本として初のIsovalentの社員として働き始めた早川氏

Holmes氏のセッションは「Cloud Native Superpowers with eBPF」と題されているが、内容はeBPFの基本的な内容のおさらいとなっている。

セッションを行うTracy P Holmes氏

eBPFはExtended Berkeley Packet Filterの略で、ユーザースペースのプログラムからシステムコールを通じてカーネル内に置かれた仮想マシンでコードを実行するLinuxのカーネルに実装された機能だ。

ユーザープログラムからカーネル空間でコードを実行できる

「eBPFがどうして必要になったのか？」という部分についてはイラストを用いて説明。ここではオブザーバビリティのための機能をカーネルに追加したいと思ったプログラマーは、カーネルデベロッパーに依頼をしてコミュニティの了解を受け、コードを書くという手間のかかるプロセスを経る必要があり、これでは必要な時に間に合わないという例を挙げている。ここで最初に変更をしたいと思ってから5年という時間が掛かるというように描かれているが、カーネルそのものに機能追加するためにはそれぐらいの時間と準備が必要だということを強調している。

カーネルを拡張する変更には時間がかかる

だがeBPFを使えば、数日でその変更を実装できることを解説。

eBPFを使えばカーネルの機能拡張をリブートせずに行うことができる

ここでは最後のコメントに、システムのリブートなどを行わなくても可能になると書かれている点がポイントだろう。

ただしカーネルで実行されるコードであるために安全でなければいけないことを説明し、そのためにVerifierと呼ばれる無限ループしないことなどを検証するプロセスを経て、安全であることを確認する点に言及した。

Verifierで無限ループなどのチェックを実行

eBPFで実行されるコードはシステムコールを使って起動されるため、元々はネットワークのフィルタリングとして使われていたが、ファイルシステムへのアクセスや他のプロセスを立ち上げることなどにも使われると説明。

KubernetesのPodからコールしてさまざまな使われ方が可能に

eBPFは主にオブザーバビリティとして使われることから、例としてIsovalentが開発をリードするオープンソースソフトウェアのHubbleを紹介。

CiliumのサブプロジェクトであるHubbleを紹介

ネットワークに関するさまざまなメトリクスを観測することができる。またNew Relicが買収したPixieについても簡単に紹介し、フレームグラフとしてネットワークトラフィックの可視化が可能になることを説明した。

Pixieの紹介

ネットワークについての解説として従来のLinuxネットワークとCiliumによるeBPFのネットワークの違いを解説し、iptablesベースのネットワークでは多くのオーバーヘッドが発生していることを説明した。

従来のLinuxネットワークの説明。多くのプロセスがiptablesベース

CiliumによるeBPFベースのネットワーク。簡素化されている

ここではiptablesベースのネットワークとeBPFベースのネットワークの性能評価について参照されている。ここで用いられているイラストは、Ciliumのブログからの引用だ。

ベンチマークのブログで紹介されているイラスト

参照元となっているページは以下のリンクを参照されたい。

●参考：Ciliumと従来型のネットワークの違いを解説するブログ：CNI Benchmark: Understanding Cilium Network Performance

左側の従来のLinuxネットワークはiptablesで実装されていることから、多くのオーバーヘッドが発生している。それに比べてCiliumのネットワークは、非常にシンプルになっていることがわかる。

CiliumとCalicoの性能比較

このスライドに使われているグラフのシステムについて、Node-to-NodeはKubernetesも何も実行されていない2つのまったく同じ構成のシステムでのプロセス間通信の数値を、netperfを使って計測しているという。

CiliumとCalicoについてはKubernetesをベースにして計測されている。ここでCalicoが比較対象になっているのは「よく比較されるから」という理由だそうだが、それぞれeBPFをデータプレーンに使ったものとレガシーなKube-proxyを使ったものと比較しているのが興味深い。最新のカーネルを使えない場合にもこのレガシーな構成なら使えるという補助的な意味合いだろう。赤のバーグラフがCiliumのeBPF版、つまり最も性能が出る構成で、ほぼ同じ性能を出しているオレンジのバーグラフはCalicoのeBPF版だ。一方Kube-proxyを使った構成では、CiliumもCalicoも性能が劣化していることがわかる。

最後にeBPFではアプリケーションの書き換えを行わなくても機能追加ができることを紹介して、主な説明を終えた。

アプリのYAMLファイルを書き換えなくても機能追加ができる

その後、eBPFに関する書籍などを紹介してセッションを終えた。

Liz Riceが執筆したWhat is eBPFなどを紹介

ちなみにCiliumは、CNCFにおいてセキュリティオーディットを受けたプロジェクトであることが2023年2月13日のプログ記事で紹介されている。

●参考：“A well-secured project”: Cilium security audits 2022 published

ソースコードのリポジトリからドキュメンテーションまで幅広く監査を受けており、包括的に安全なプロジェクトであることが第3者機関から確認されていることがわかる。eBPFに関するサイトも存在しており、内容の確をお勧めする。

●参考：eBPF公式サイト：https://ebpf.io/