eBPFは何が嬉しいのか？

eBPFは何が嬉しいのか? Yutaro Hayakawa Isovalent

Self Introduction • 早川侑太朗 (@YutaroHayakawa) • Isovalent (2022 ~) ◦
Ciliumの開発 (Datapathチーム) ◦ マルチクラスタ (ClusterMesh), BGP, SRv6, etc… • LINE Corporation (2019 ~ 2021) ◦ 内製ロードバランサの開発・運用 ◦ 大規模LBaaSの成長期に体験した二つの問題

ユーザが使いたいものなぜか話題になるやつ実装

eBPFで作られていることは誰にとってどう重要か？

eBPFで作られていることは誰にとってどう重要か？ ↓ 結局開発者にとってもユーザにとっても重要 *ポジショントーク

eBPFとは？ Linuxカーネル拡張を書くためのプログラミングフレームワーク https://ebpf.io/what-is-ebpf

eBPFプログラミング C言語で書く (mainとかはない見慣れないC), ClangにeBPFバイトコードを吐くモードがある

eBPFプログラミングファイルが消えるたびに消されたファイルの名前と消したプロセスのPIDを出力するプログラム

Load コンパイラから吐かれた「ELFファイル」をbpfシステムコールに渡せる形にする工程詳しく知りたい方は => きっと明日から役立つeBPFのしくみ主要なローダライブラリ => libbpf (C) ,
cilium/ebpf (Go), libbpf-rs (Rust)

VerifierとJIT Compiler bpfシステムコールでロードされたプログラムはVerifierによって「検証」される =>「安全」でなければ実行できない検証が通ったらほとんどの場合JITコンパイルされる => 実行前に全部ネイティブマシン命令に変換 (JSなどの動的JITとはちょっと違う) 検証が共通化できるのがeBPFバイトコードがアーキテクチャ非依存な理由

Hook / Event カーネルの中でeBPFを実行できる場所何かしらのイベントを契機にeBPFが実行される代表的なフック - Socket => socketに対するデータの入出力をフィルタする
- Syscall => システムコールの呼び出しをトレース・フィルタ - kprobe / ftrace => カーネルの関数呼び出しなどをトレース - TC / XDP => NIC入ったパケットを書き換え・ドロップ - TCPの輻輳制御, スケジューラ, etc

eBPF Map eBPFプログラムとユーザ空間から読み書きできるデータ構造 => Hash, Array, Trie, Per-CPU Array, etc…
ユーザ空間とeBPFの情報のやりとりに使える (例えるならRedisのようなもの?)

eBPFは何が嬉しいのか？何か新しいことができるようになったから嬉しい？そもそも誰にとって嬉しい？ユーザにとってプロダクトがeBPFで作られているのって重要？

eBPFによって何か新しいことができるようになった？技術的にはなっていない Linuxには元々「カーネルモジュール」があるカーネルモジュールもeBPFもカーネル空間で動くプログラム eBPFで実装できる機能は基本的にカーネルモジュールで作れる機能のサブセット Ciliumをカーネルモジュールベースで作ることは理論的には可能 => でもやらない

eBPFはそもそも誰がなんのために作ったのか？カーネル開発者にとってカーネルの開発があまりにも辛かったから必要だった

eBPFのオリジナルの作者 Alexei Starovoitov 現Meta, 元PRUMgridのエンジニア IOVisorというプロダクトの一部だった開発秘話的なプレゼン: The untold story
of BPF

カーネル (モジュール) 開発の4つのつらみプログラミングのつらみメンテナンスのつらみアップストリームのつらみデリバリのつらみ

カーネル開発のつらみ - プログラミング - カーネル空間は色んな意味で「安全」ではない Cプログラミングそのものの辛み (メモリ管理等) メモリアクセス違反 => マシンそのものが停止
ハング (デッドロック、無限ループ) => マシンそのものが停止メモリリーク => 誰もリークしたメモリを回収しないセキュリティホールを作る => 権限Maxな状態で攻撃に晒される

カーネル開発のつらみ - メンテナンス - Linuxカーネルはカーネルモジュールに対して互換性を一切担保しないあるバージョンで動いていたモジュールは次のバージョンで動く保証がない Linuxの開発はかなり早い (9 - 10週ごとにリリース)

カーネル開発のつらみ - アップストリーム - パッチをアップストリームすればバージョンアップで壊れるのは防げる Linuxの開発者との交渉が必要 + レビューは厳しいあまりにも特定の会社のビジネスに拠った変更は受け入れられないケースもある

カーネル開発のつらみ - デリバリ - Masterに入った変更がディストリビューションカーネルに降りてくるのはいつ？ディストリビューションによっては3 - 5年かかるケースもある

eBPFはカーネル開発のつらみをどう解決したか？プログラミング: Verifierによる検証でプログラマのミスを未然に防ぐメンテナンス: eBPFのプログラムに対しては後方互換性が担保されるようにした* アップストリーム: 互換性が担保されるということはアップストリームは不要デリバリ: アップストリームしなくていいということはデリバリも即座にできる

カーネル開発のつらみが解消された結果どうなったか？一般的な現場でもカーネル開発に手を出せるようになった一般的な現場でもカーネル拡張の保守が現実的なコストでできるようになった一般的なエンジニアから見て新しいこと（カーネル開発）ができるようになった => これが昨今の盛り上がりの一因？

eBPFは何が嬉しいのか？何か新しいことができるようになったから嬉しい？ => 技術的にはNoだが、一般的なエンジニアでもカーネル開発ができるようになったという意味ではYes そもそも誰にとって嬉しい？ => カーネル開発者にとっては辛いところが解消されて嬉しいユーザにとってプロダクトがeBPFで作られているのって重要？

eBPFで作られているのはユーザにとって重要か？重要だと言えるカーネル開発のつらみと結局は関係している • プログラミングの難易度が高い => バグや脆弱性が紛れ込みやすい • 互換性が担保されない =>
カーネルのアップデートがリスク、メンテされなくなれば短い期間ですぐ使えなくなってしまう • デリバリが遅い => 欲しい機能がすぐ手に入らない

ケーススタディ - Falco - FalcoはなぜカーネルモジュールからeBPFベースの実装に移行しているのか？ • Falcoのイベントコレクタはカーネールモジュールベースだった •
ユーザからのフィードバックとして安定性、セキュリティ、互換性への懸念が示された • Sysdig and Falco now powered by eBPF

まとめ eBPFは何が嬉しいのか？開発者目線 • 安全なカーネル開発ができるようになる • カーネル拡張の保守が楽になる • 開発・デリバリのスピードが上がるエンドユーザ目線
• カーネル拡張の導入がより「安全」になる • 互換性やプロダクトの持続性に対する懸念が軽減される • 欲しい機能が素早く手に入る

eBPFは何が嬉しいのか？

eBPFは何が嬉しいのか？

Yutaro Hayakawa

More Decks by Yutaro Hayakawa

Other Decks in Technology

Featured

Transcript