Upgrade to Pro — share decks privately, control downloads, hide ads and more …

eBPFのこれまでとこれから

Avatar for Yutaro Hayakawa Yutaro Hayakawa
September 14, 2024

 eBPFのこれまでとこれから

情報科学若手の会2024

Avatar for Yutaro Hayakawa

Yutaro Hayakawa

September 14, 2024
Tweet

More Decks by Yutaro Hayakawa

Other Decks in Technology

Transcript

  1. 私と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)
  2. ネットワーク仮想化の実装 • だいたい L2 - L4くらいの話 • スイッチ , ルータ,

    LB, FWなどをソフトウェアで実装する • LinuxではL2-L4はカーネルの領分 • ここで新しいことをするにはカーネルプログラミングが必要 ソフトウェア (ユーザ空間 ) ソフトウェア (カーネル空間 ) 物理 https://www.cloudflare.com/it-it/learning/ddos/glossary/open-systems-interc onnection-model-osi/
  3. カーネルバイパス派 • Intel DPDKに代表されるカーネルをバイパ スしてユーザスペースに全てのネットワーク 機能を実装する派閥 • Pros: カーネル空間の開発と比較して安全 なユーザ空間の開発は早い

    • Cons: Linuxカーネルの枯れたスタックやア プリケーションなどのエコシステムに乗れな い Kernel Driver Network Stack (LB, FW, NAT…) Applications (Routing Protocols) Kernel Driver Network Stack Applications Physical Kernel User NIC
  4. カーネルネイティブ派 • 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…)
  5. カーネルネイティブ派 vs カーネルバイパス派 • 体感的には 2016年くらいまではカーネルバイパス派の優位が続いた ◦ 開発スピードの速さ ◦ コントリビューションのハードルの低さ

    ◦ etc… • Open vSwitchなどは盛り上がったが , 硬直化を打破するほどのプログラマビリティは得られず • その中でカーネル派の中から eBPFが登場 ◦ 「安全なカーネルプログラミング」でカーネル開発の硬直化を打破しようとする技術
  6. Hook カーネルの中で eBPFをアタッチして実行できる場所 何かしらのイベントを契機に eBPFが実行される 代表的なフック - Socket => socketに対するデータの入出力をフィルタする

    - Syscall => システムコールの呼び出しをトレース・フィルタ - kprobe / ftrace => カーネルの関数呼び出しなどをトレース - TC / XDP => NIC入ったパケットを書き換え・ドロップ - TCPの輻輳制御 , スケジューラ , etc
  7. eBPF Core Conceptまとめ • ユーザは任意の eBPFプログラムを書いてカーネルにロードできる • カーネルはプログラムが安全かどうかを実行前にチェックする • eBPFプログラムは最終的にはネイティブコードに

    JITされて実行される • Mapを使ってユーザスペースと eBPFでデータのやりとりができる • Helper Functionを使って外のカーネルの関数を呼べる
  8. eBPFがあるカーネルプログラミング (2/2) • 開発者目線 ◦ 開発のフィードバックサイクルが早い ◦ コードの安全性は自動で検証されるので , よりプロダクトの本質的なところに集中できる

    ◦ 後方互換性があるのでメンテナンスしやすい • ユーザ目線 ◦ 開発が早い => 欲しいものが早く手に入りやすい ◦ カーネルモジュールで書かれた製品より低リスク
  9. カーネルネイティブ派 vs カーネルバイパス派の決着はついた? • カーネルバイパスの代表格である DPDKはISPやテルコなどの現場では健在 ◦ パフォーマンスが特に大事なワークロードではアドバンテージがある ◦ Cisco

    VPPなどネットワークベンダの仮想ルータの実装にも使われている ◦ 比較的ニッチな分野で根強く支持されているという印象 • eBPFを含むカーネルネイティブな技術の方が現在は広く使われている ◦ 特にコンテナネットワーキングの分野では圧倒的に優勢 ◦ カーネルに元々組み込まれている => デフォルトの選択肢ということか?
  10. eBPF for Windows • eBPFをWindowsに移植するプロジェクト ◦ Byte CodeはLinuxコンパチ (コンパイラが流用可能 )

    ◦ プログラムの直接的な互換性はない ▪ Windows固有のフックやカーネルのデータ構造 • Microsoft主導でプロダクションで使えるレベルのものを本気で目指して いる • OSの垣根を超えて移植がされるというのは技術として有用性が認められ た証左
  11. IETFでの標準化 • eBPF for Windowsのメンバが中心となって eBPF ISAなどを標準化 • 違う実装同士の互換性を目指すというよりは ,

    ある程度のコードの共通化が可能になるくらい • 現状実装に関心を示しているのは MSと一部のストレージ系のベンダ
  12. eBPFの未解決問題 - Verifierのスケーラビリティ - • eBPF Verifierの検証には制限がかけられている • 検証に際限なく時間やメモリが使われるのを防ぐため •

    Instruction Limit ◦ プログラム自体の最大インストラクション数 ◦ eBPFができた当初から変わらず 4096 • Complexity Limit ◦ 分岐やループも含めた検証のステップ数 ◦ eBPFができた当初は 4096, カーネル 5.4から1M (100万) • Ciliumのような巨大 eBPFプログラムではたまに上限に引っかかったりする
  13. eBPF FoundationとResearch Fund • eBPF Foundation ◦ eBPFの普及・発展のための基金の運営やイベント・調査などを行う Linux Foundation傘下の組織

    • 今年から Research Fundも開始 ◦ eBPF Verifierのスケーラビリティ改善や新たな応用のアイデアなど ◦ 25k - 50k$くらい (350万円 - 700万円) くらい ◦ 今年は終わったが来年もおそらくやる