eBPF Summit開催 IsovalentのCEOなどによるDay 1のキーノートを紹介

Linuxのカーネル内でセキュアにユーザーコードの実行を可能にするeBPF（Extended Berkeley Packet Filter）のコミュニティが、オンラインカンファレンスeBPF Summit 2021を2021年8月18日、19日に開催した。このカンファレンスから初日のキーノートセッションを紹介する。

公式サイト：https://ebpf.io/summit-2021/

公開されている動画は約4時間と長いが、それぞれセッションやライトニングトークごとにチャプターが区切られているのは親切な設定と言える。

eBPF Summit Day1 Keynote

eBPFがExtended Berkeley Packet Filterの略であることを知れば、実はそのルーツがかなり古いことがわかる。Linux Kernelの登場が1991年、BPFがBerkeley Labで1992年に最初のリリースが行われたことを考えれば、Linuxと同じぐらいには歴史のあるソフトウェアと言える。クラシックなBPFとは互換性はないものの、eBPFは単なるネットワークのためのツールからカーネル内で安全にコードを実行するための仕組みとしてエコシステムを拡げていると言える。

この記事ではカンファレンス初日の最初に行われた、IsovalentのCEOであるThomas Graf氏によるキーノートセッションを紹介する。

「The State and Future of eBPF」というタイトル

このタイトルにあるように、セッションはeBPFの現状と将来について解説した内容となっている。

eBPF Foundationの紹介

最初に紹介したのは、eBPFを管理統制するためにeBPF Foundationが創設されたことだ。eBPF Foundationは、The Linux Foundationのサブ組織として位置付けられている非営利の団体だ。LFの配下になることで、マーケティングやイベントなどのリソースを効果的に利用できることになる。

創設のメンバーとしてIsovalentだけではなくFacebook、Google、Microsoft、Netflixというインターネットジャイアンツが入っていることに注目したい。膨大なトラフィックを捌くインターネットサービスの巨大企業がサポートを行っているというのは、非営利団体としては非常に心強いし、ソフトウェアの素性の良さをユーザーに示すことにもなるだろう。

ガバナンスもLF/CNCFと似ている

また組織自体の管理、統制についてもテクニカルな部分を統制するBSC、組織全体を管理するガバニングボードという2つのグループによって行うという部分はLFやCNCFに良く似ている。

ここからGraf氏は、カーネルに新機能を実装する際に従来の方法では数年かかってしまうが、eBPFなら数日で終わるという違いを、コミックを使って解説した。

カーネルに変更を加えるには多くの時間と労力が必要

eBPFなら安全にカーネル内でコードを実装できる

eBPFの利点としてセキュアなコードの実行というのは、デベロッパー目線としてはよく言われる部分だが、ここではカーネルに新機能を組み込もうとしてもそれを行うには多くの時間と交渉、根回しが必要という部分をアピールしていることは興味深い。デベロッパーでも管理職のレベルに向けてのメッセージを意識しているのかもしれない。

eBPFの構成図。ユーザースペースのコードがJITを通じて実行される

eBPFのSDKだけではなくFacebookが開発するロードバランサーのKatranや、Isovalentが開発をリードするCiliumなども挙げられており、エコシステムの拡がりを強調した形になった。

FacebookやNetflixが開発したプロジェクトも紹介

このスライドではFacebook、Google、Netflix、SysdigがeBPFを使って開発したプロジェクトを紹介している。Microsoftは、eBPF for Windowsの開発プロジェクトを進めていることを2021年5月10日のブログ記事で公開している。

参考：Making eBPF work on Windows

eBPFはもともとLinuxカーネルの機能を使うための仕組みだったが、Windowsにおいても同様のテクノロジーをLinuxのコードをフォークするのではなく自前で作っているという辺りに、Microsoftの本気度が現れていると言っても良いだろう。

そしてここからeBPFのFutureの話ということで、Graf氏の予測という形でこれからeBPFやエコシステムがどのようになっていくのかを解説した。Graf氏が挙げた予測はこんな感じだ。「eBPFによってオブザーバービリティはインテリジェントになる」「eBPFはクラウド、オンプレミス、エッジをつなぐためのSDNとなる」「eBPFはサービスメッシュを実装するテクノロジーになる」「eBPFは根本的により良いセキュリティのためのコンテキストを複数のレイヤーで提供する」「eBPFによってObservabilityは当たり前になる」「eBPFによってネットワーキング、オブザーバービリティ、セキュリティのツールを使う体験が改善される」。

「eBPF is the technology to win service mesh」と予測

このスライドではサービスメッシュにおいてeBPFがコアのテクノロジーとなると予測しているのが興味深い。サービスメッシュはマイクロサービス化の流れの中で注目されているが、分散されたプロセスの粒度が細かくなればなるほどサービス間の通信は増加し、観測するのが難しくなる。その結果、サービスメッシュ自体を構成、運用することも難しくなるという傾向にある。

クラウドネイティブの代表的なプラットフォームとして挙げられているKubernetesは、自前のDNSやProxyを使って通信を行い、サービスメッシュにはEnvoyやLinkerdを使うというのが今の状況だ。サービスメッシュの実装にはコンテナの中にProxyエージェントをサイドカーとして配置して通信を代替、通信制御やサービスディスカバリーは別のコントロール専門のプロセスが行うというスタイルになる。このスタイルがeBPFによってどう変わるのか？ についてはGraf氏のキーノートではなくこの後に行われたセッションに興味深いスライドがあるのでそれも紹介しょう。

「Container Level Network Observability with eBPF」というセッション

これはKentikというベンチャーのIan Pye氏が行ったセッションで、「コンテナレベルのネットワークオブザーバービリティをeBPFで行うとどうなるのか？」というものだ。

ここでPye氏は、コンテナベースのネットワークをどうして意識しなければならないのか？ を解説した。

コンテナベースベースのネットワークを監視する必要性を解説

ここで何か問題が起きた時にそれがネットワーク問題なのか、アプリケーションの問題なのかを切り分ける必要がある、どのプロセスと通信をしているのかを知っている必要があるなどを挙げた。最後の「どうして自宅の冷蔵庫が北朝鮮に通信を行っているんだ？」という文は、スマート家電であったとしても通信を観測する必要性があるということを強調するためだろう。

そしてコンテナのネットワークが多層的になっていることを次のスライドで説明した。

一般的なコンテナ通信の概要を説明

コンテナが内部で持っているIPアドレスと外部に通信するためのアダプターのIPアドレスが異なっているのは当たり前だとしても、その間には複数のレイヤーが存在しており、「どのレイヤーで観測を行うのか？」という問題が持ち上がってしまう。

パケットキャプチャー、サービスメッシュ、eBPFを比較

このスライドではパケットキャプチャー、サービスメッシュ、eBPFを比較して解説し、パケットキャプチャーはCPUに対する負荷が高く、ダイナミックに構成されるネットワークには適していない、サービスメッシュは構成が複雑、通信の向きを制御する必要があるというマイナス点を指摘している。それに対してeBPFは、CPUの負荷が低いこと、そして通信ではなくKernelを通過するという部分に注目して観測を行えと解説した。つまりはコンテナにサイドカーで別のプロセスを足すのではなく、eBPFによってKernelにイベントを追加して、そこで観測を行うことを推奨した。

実際にKubernetesのエコシステムの中で、eBPFがどのようにサービスメッシュを実装していくのか？ については、コミュニティの力の見せ所だろう。すでにIstioやLinkerdで実装されているサービスメッシュも多く、どのように実装するのか、移行のためのツールはあるのか、など多くの質問に答えていく必要があるだろう。またパブリッククラウド、オンプレミス、エッジのブリッジとしてeBPFがSDNとなるという点についてはCiliumが念頭にあると思われるが、ここについてもパブリッククラウドベンダー2社が支援しているのは強力だとしても、トップのAWSを巻き込んで流れを作れるのか、注意深くウォッチしていきたい。

ちなみにIan Pye氏が共同創業者であるKentikは、ネットワーク可視化のためのサービスとソフトウェアを提供するベンチャーで、CEOは元Akamaiのネットワークインフラの責任者、Pye氏は元Cloudflareのエンジニアであることからもわかるように、キャリアグレードのネットワークに精通している企業と言える。日本では2017年にKDDIのユースケースが公表されている。

Kentik公式サイト：https://www.kentik.com/

KDDIに関するリリース：Top Japanese Telecom Operator KDDI Corporation Selects Kentik for Network Traffic Intelligence