eBPFのこれまでとこれから

情報科学若手の会2024

Transcript

1. eBPFはネットワークソフトウェア開発の何を変えたか Yutaro Hayakawa Isovalent at Cisco
2. eBPFはネットワークソフトウェア開発の何を変えたか eBPFのこれまでとこれから Yutaro Hayakawa Isovalent at Cisco
3. 自己紹介 • 早川侑太朗 (@YutaroHayakawa) • 所属: Isovalent @ Cisco • 肩書: Software Engineering Technical Leader
4. 今日のお話 • eBPFが生まれた歴史的背景 • eBPFとは何か？何が嬉しかったのか？ • eBPFの今後
5. 私とeBPF • 7年ほど大小様々な規模で eBPFを活用したネットワークソフトウェアの開発に従事 • 2017 - 2018: generic-ebpf (eBPF for FreeBSD, GSoC’18) • 2017 - 2021: Prism (学生の頃からやっていた研究プロジェクト , NSDI’21) • 2019 - 2021: LINEの内製クラウドのロードバランサ開発 • 2020 - 現在 : ipftrace2 (個人OSS, トレーシングツール ) • 2022 - 現在 : IsovalentにてCiliumの開発 (2023年からCommitter)
6. Isovalent • 主にKubernetes向けのネットワーク・セキュ リティ・オブザーバビリティのソリューションを 開発する会社 • eBPFを作った人々の一部が創業した会社 • 全てのプロダクトが eBPFを使って作られてい る • 現在は買収によりCiscoの一部
7. eBPFが生まれた歴史的背景
8. 2011年頃: ネットワーク仮想化の隆盛 • 「ネットワーク仮想化」という概念が産学ともに大きなブームを巻き起こした • サーバが仮想化によって数秒 - 数分のオーダで簡単に作って壊せるものになった • ネットワークも仮想化によって同じように簡単に作って壊せるようにしたい • 現在のクラウドネットワーキングやコンテナネットワーキングの基礎になる考え方
9. Any IP Network Niciraのネットワーク仮想化アーキテクチャ • 仮想ネットワークの機能をハイパーバイザ上のソフトウェアスイッチに実装する • LB, FW, NATのようなネットワーク機器もソフトウェア化し APIで集中制御 • プログラムで簡単に作成・削除・制御できるように HV HV HV VM VM VM VM VM VM Distributed Firewall LB vxlan vxlan
10. ネットワーク仮想化の実装 • だいたい L2 - L4くらいの話 • スイッチ , ルータ, LB, FWなどをソフトウェアで実装する • LinuxではL2-L4はカーネルの領分 • ここで新しいことをするにはカーネルプログラミングが必要 ソフトウェア (ユーザ空間 ) ソフトウェア (カーネル空間 ) 物理 https://www.cloudflare.com/it-it/learning/ddos/glossary/open-systems-interc onnection-model-osi/
11. CrowdStrike事件 • 今年の7月19日に世界中の約 850万台 のWindowsマシンが一斉にブルース クリーンになった • 原因は設定ファイルのたった一行の変 更で引き起こされたカーネル拡張のク ラッシュ https://en.wikipedia.org/wiki/2024_CrowdStrike_incident#/media/File:CrowdStrike_BSOD_at_ LGA.jpg
12. CrowdStrike事件から学ぶカーネルプログラミングの難しさ • カーネル拡張を作ることは大きなリスクを伴う ◦ カーネルクラッシュをするとマシンが使用不能になる ◦ カーネルがリークしたメモリは誰も回収できない ◦ 無限ループやデッドロックをしたらマシン全体が使用不能に ◦ さらにLinuxはカーネル拡張に対してインターフェースの後方互換性を担保しない • このようなリスクに対するセーフティネットがほぼ無いのが従来のカーネルプログラミング
13. カーネル開発の硬直化 • カーネル開発はリスクが高いがために保守的にならざるを得ず硬直化していた • ビジネスの都合としては新しいことを押し進めたいのにカーネル開発のスピードが追いつかない • この問題の解決をめぐるアプローチで業界は 2つの派閥に分かれた
14. カーネルバイパス派 • Intel DPDKに代表されるカーネルをバイパ スしてユーザスペースに全てのネットワーク 機能を実装する派閥 • Pros: カーネル空間の開発と比較して安全 なユーザ空間の開発は早い • Cons: Linuxカーネルの枯れたスタックやア プリケーションなどのエコシステムに乗れな い Kernel Driver Network Stack (LB, FW, NAT…) Applications (Routing Protocols) Kernel Driver Network Stack Applications Physical Kernel User NIC
15. カーネルネイティブ派 • Linuxカーネルの中に新たなプログラマビリ ティを持ち込む派閥 . Open vSwitchなどの 開発を通じてプログラマブルなネットワークス タックを目指した . • Pros: 既存のネットワークスタックやアプリ ケーションなど , カーネルの資産を生かすこと ができる • Cons: 硬直化の影響は依然としてある . 開発 スピードは遅い . “Classic” Network Stack (iptables, ipvs …) Applications (Routing Protocols) Physical Kernel User NIC In-kernel Programmable Data Path (OVS, etc…) New CPlane Applications (OpenFlow, etc…)
16. カーネルネイティブ派 vs カーネルバイパス派 • 体感的には 2016年くらいまではカーネルバイパス派の優位が続いた ◦ 開発スピードの速さ ◦ コントリビューションのハードルの低さ ◦ etc… • Open vSwitchなどは盛り上がったが , 硬直化を打破するほどのプログラマビリティは得られず • その中でカーネル派の中から eBPFが登場 ◦ 「安全なカーネルプログラミング」でカーネル開発の硬直化を打破しようとする技術
17. eBPFとは？
18. eBPFとは？ Linuxカーネル拡張を書くためのプログラミングフレームワーク https://ebpf.io/what-is-ebpf
19. eBPFとは？ https://ebpf.io/what-is-ebpf
20. eBPFプログラミング C言語で書く (mainとかはない見慣れない C), ClangにeBPFバイトコードを吐くモードがある
21. eBPFプログラミング NICに入ってきたパケットの数を送信元 IPごとに数えるプログラム NIC Linux Network Stack NIC Device Driver パケットの流れ
22. eBPFとは？ https://ebpf.io/what-is-ebpf
23. Load コンパイラから吐かれた「 ELFファイル」を bpfシステムコールに渡せる形にする工程 詳しく知りたい方は => きっと明日から役立つ eBPFのしくみ
24. eBPFとは？ https://ebpf.io/what-is-ebpf
25. VerifierとJIT Compiler bpfシステムコールでロードされたプログラムは Verifierによって「検証」される =>「安全」でなければ実行できない 検証が通ったらほとんどの場合 JITコンパイルされる => 実行前に全部ネイティブマシン命令に変換 検証が共通化できるのが eBPFバイトコードがアーキテクチャ非依存な理由
26. eBPFとは？ https://ebpf.io/what-is-ebpf
27. Hook カーネルの中で eBPFをアタッチして実行できる場所 何かしらのイベントを契機に eBPFが実行される 代表的なフック - Socket => socketに対するデータの入出力をフィルタする - Syscall => システムコールの呼び出しをトレース・フィルタ - kprobe / ftrace => カーネルの関数呼び出しなどをトレース - TC / XDP => NIC入ったパケットを書き換え・ドロップ - TCPの輻輳制御 , スケジューラ , etc
28. eBPFとは？ https://ebpf.io/what-is-ebpf
29. eBPF Map eBPFプログラムとユーザ空間から読み書きできるデータ構造 => Hash, Array, Trie, Per-CPU Array, etc… ユーザ空間と eBPFの情報のやりとりに使える
30. Helper Functions eBPFプログラムから外のカーネルの関数を呼び出す仕組み システムコールのようなもの (ただし, コンテキストスイッチを伴わないただの関数呼び出し ) あらかじめ決められた関数しか呼べない Mapを読み書きする , タイムスタンプを取る , パケットをリダイレクトする , ルーティングテーブルを検索する , etc…
31. eBPF Core Conceptまとめ • ユーザは任意の eBPFプログラムを書いてカーネルにロードできる • カーネルはプログラムが安全かどうかを実行前にチェックする • eBPFプログラムは最終的にはネイティブコードに JITされて実行される • Mapを使ってユーザスペースと eBPFでデータのやりとりができる • Helper Functionを使って外のカーネルの関数を呼べる
32. eBPFがあるカーネルプログラミング (1/2) • Verifierによるセーフティネット ◦ 危険な可能性のあるメモリアクセスはできない ◦ 取ったロックは全部のコードパスで解放されることが保証されなければならない ◦ ループは実行前に最大ループ数がわかっているケースでしかできない ◦ etc, etc, etc… • (例外はあるが ) 基本的に eBPFプログラムの後方互換性は担保されている
33. eBPFがあるカーネルプログラミング (2/2) • 開発者目線 ◦ 開発のフィードバックサイクルが早い ◦ コードの安全性は自動で検証されるので , よりプロダクトの本質的なところに集中できる ◦ 後方互換性があるのでメンテナンスしやすい • ユーザ目線 ◦ 開発が早い => 欲しいものが早く手に入りやすい ◦ カーネルモジュールで書かれた製品より低リスク
34. カーネルネイティブ派 vs カーネルバイパス派の決着はついた？ • カーネルバイパスの代表格である DPDKはISPやテルコなどの現場では健在 ◦ パフォーマンスが特に大事なワークロードではアドバンテージがある ◦ Cisco VPPなどネットワークベンダの仮想ルータの実装にも使われている ◦ 比較的ニッチな分野で根強く支持されているという印象 • eBPFを含むカーネルネイティブな技術の方が現在は広く使われている ◦ 特にコンテナネットワーキングの分野では圧倒的に優勢 ◦ カーネルに元々組み込まれている => デフォルトの選択肢ということか？
35. eBPFの今後
36. CrowdStrike事件はeBPFがあれば防げた ? • CrowdStrikeもLinuxではeBPFを採用している • WindowsにeBPFがあれば今回のようなインシデント は防げたかもしれない https://en.wikipedia.org/wiki/2024_CrowdStrike_incident#/media/File:CrowdStrik e_BSOD_at_LGA.jpg
37. eBPF for Windows • eBPFをWindowsに移植するプロジェクト ◦ Byte CodeはLinuxコンパチ (コンパイラが流用可能 ) ◦ プログラムの直接的な互換性はない ▪ Windows固有のフックやカーネルのデータ構造 • Microsoft主導でプロダクションで使えるレベルのものを本気で目指して いる • OSの垣根を超えて移植がされるというのは技術として有用性が認められ た証左
38. IETFでの標準化 • eBPF for Windowsのメンバが中心となって eBPF ISAなどを標準化 • 違う実装同士の互換性を目指すというよりは , ある程度のコードの共通化が可能になるくらい • 現状実装に関心を示しているのは MSと一部のストレージ系のベンダ
39. eBPFの未解決問題 - eBPF Verifierのバグ - • 実はCrowdStrikeはLinuxでもeBPFがあるのにもかかわらずカーネルクラッシュのインシデントを起こして いる. 原因はeBPF Verifierのバグ. • eBPFのプログラムの安全性は Verifierによって検証されるが eBPFそのものの安全性は担保されない
40. eBPFの未解決問題 - Verifierのスケーラビリティ - • eBPF Verifierの検証には制限がかけられている • 検証に際限なく時間やメモリが使われるのを防ぐため • Instruction Limit ◦ プログラム自体の最大インストラクション数 ◦ eBPFができた当初から変わらず 4096 • Complexity Limit ◦ 分岐やループも含めた検証のステップ数 ◦ eBPFができた当初は 4096, カーネル 5.4から1M (100万) • Ciliumのような巨大 eBPFプログラムではたまに上限に引っかかったりする
41. eBPF FoundationとResearch Fund • eBPF Foundation ◦ eBPFの普及・発展のための基金の運営やイベント・調査などを行う Linux Foundation傘下の組織 • 今年から Research Fundも開始 ◦ eBPF Verifierのスケーラビリティ改善や新たな応用のアイデアなど ◦ 25k - 50k$くらい (350万円 - 700万円) くらい ◦ 今年は終わったが来年もおそらくやる
42. Q & A