Share
Embed
Slide 1
Slide 1 text
eBPFは何が嬉しいのか?
Yutaro Hayakawa
Isovalent
Slide 2
Slide 2 text
Self Introduction
● 早川侑太朗 (@YutaroHayakawa)
● Isovalent (2022 ~)
○ Ciliumの開発 (Datapathチーム)
○ マルチクラスタ (ClusterMesh), BGP, SRv6, etc…
● LINE Corporation (2019 ~ 2021)
○ 内製ロードバランサの開発・運用
○ 大規模LBaaSの成長期に体験した二つの問題
Slide 3
Slide 3 text
No content
Slide 4
Slide 4 text
ユーザが使いたいもの
なぜか話題になるやつ
実装
Slide 5
Slide 5 text
eBPFで作られていることは誰にとってどう重要か？
Slide 6
Slide 6 text
eBPFで作られていることは誰にとってどう重要か？
↓
結局開発者にとってもユーザにとっても重要
*ポジショントーク
Slide 7
Slide 7 text
eBPFとは？
Linuxカーネル拡張を書くためのプログラミングフレームワーク
https://ebpf.io/what-is-ebpf
Slide 8
Slide 8 text
eBPFとは？
Linuxカーネル拡張を書くためのプログラミングフレームワーク
https://ebpf.io/what-is-ebpf
Slide 9
Slide 9 text
eBPFプログラミング
C言語で書く (mainとかはない見慣れないC), ClangにeBPFバイトコードを吐くモードが
ある
Slide 10
Slide 10 text
eBPFプログラミング
ファイルが消えるたびに消されたファイルの名前と消したプロセスのPIDを出力するプロ
グラム
Slide 11
Slide 11 text
eBPFとは？
Linuxカーネル拡張を書くためのプログラミングフレームワーク
https://ebpf.io/what-is-ebpf
Slide 12
Slide 12 text
Load
コンパイラから吐かれた「ELFファイル」をbpfシステムコールに渡せる形にする工程
詳しく知りたい方は => きっと明日から役立つeBPFのしくみ
主要なローダライブラリ => libbpf (C) , cilium/ebpf (Go), libbpf-rs (Rust)
Slide 13
Slide 13 text
eBPFとは？
Linuxカーネル拡張を書くためのプログラミングフレームワーク
https://ebpf.io/what-is-ebpf
Slide 14
Slide 14 text
VerifierとJIT Compiler
bpfシステムコールでロードされたプログラムはVerifierによって「検証」される
=>「安全」でなければ実行できない
検証が通ったらほとんどの場合JITコンパイルされる
=> 実行前に全部ネイティブマシン命令に変換 (JSなどの動的JITとはちょっと違う)
検証が共通化できるのがeBPFバイトコードがアーキテクチャ非依存な理由
Slide 15
Slide 15 text
eBPFとは？
Linuxカーネル拡張を書くためのプログラミングフレームワーク
https://ebpf.io/what-is-ebpf
Slide 16
Slide 16 text
Hook / Event
カーネルの中でeBPFを実行できる場所
何かしらのイベントを契機にeBPFが実行される
代表的なフック
- Socket => socketに対するデータの入出力をフィルタする
- Syscall => システムコールの呼び出しをトレース・フィルタ
- kprobe / ftrace => カーネルの関数呼び出しなどをトレース
- TC / XDP => NIC入ったパケットを書き換え・ドロップ
- TCPの輻輳制御, スケジューラ, etc
Slide 17
Slide 17 text
eBPFとは？
Linuxカーネル拡張を書くためのプログラミングフレームワーク
https://ebpf.io/what-is-ebpf
Slide 18
Slide 18 text
eBPF Map
eBPFプログラムとユーザ空間から読み書きできるデータ構造
=> Hash, Array, Trie, Per-CPU Array, etc…
ユーザ空間とeBPFの情報のやりとりに使える (例えるならRedisのようなもの?)
Slide 19
Slide 19 text
eBPFは何が嬉しいのか？
何か新しいことができるようになったから嬉しい？
そもそも誰にとって嬉しい？
ユーザにとってプロダクトがeBPFで作られているのって重要？
Slide 20
Slide 20 text
eBPFによって何か新しいことができるようになった？
技術的にはなっていない
Linuxには元々「カーネルモジュール」がある
カーネルモジュールもeBPFもカーネル空間で動くプログラム
eBPFで実装できる機能は基本的にカーネルモジュールで作れる機能のサブセット
Ciliumをカーネルモジュールベースで作ることは理論的には可能 => でもやらない
Slide 21
Slide 21 text
eBPFはそもそも誰がなんのために作ったのか？
カーネル開発者にとってカーネルの開発があまりにも辛かったから必要だった
Slide 22
Slide 22 text
eBPFのオリジナルの作者
Alexei Starovoitov
現Meta, 元PRUMgridのエンジニア
IOVisorというプロダクトの一部だった
開発秘話的なプレゼン: The untold story of BPF
Slide 23
Slide 23 text
カーネル (モジュール) 開発の4つのつらみ
プログラミングのつらみ
メンテナンスのつらみ
アップストリームのつらみ
デリバリのつらみ
Slide 24
Slide 24 text
カーネル開発のつらみ - プログラミング -
カーネル空間は色んな意味で「安全」ではない
Cプログラミングそのものの辛み (メモリ管理等)
メモリアクセス違反 => マシンそのものが停止
ハング (デッドロック、無限ループ) => マシンそのものが停止
メモリリーク => 誰もリークしたメモリを回収しない
セキュリティホールを作る => 権限Maxな状態で攻撃に晒される
Slide 25
Slide 25 text
カーネル開発のつらみ - メンテナンス -
Linuxカーネルはカーネルモジュールに対して互換性を一切担保しない
あるバージョンで動いていたモジュールは次のバージョンで動く保証がない
Linuxの開発はかなり早い (9 - 10週ごとにリリース)
Slide 26
Slide 26 text
カーネル開発のつらみ - アップストリーム -
パッチをアップストリームすればバージョンアップで壊れるのは防げる
Linuxの開発者との交渉が必要 + レビューは厳しい
あまりにも特定の会社のビジネスに拠った変更は受け入れられないケースもある
Slide 27
Slide 27 text
カーネル開発のつらみ - デリバリ -
Masterに入った変更がディストリビューションカーネルに降りてくるのはいつ？
ディストリビューションによっては3 - 5年かかるケースもある
Slide 28
Slide 28 text
eBPFはカーネル開発のつらみをどう解決したか？
プログラミング: Verifierによる検証でプログラマのミスを未然に防ぐ
メンテナンス: eBPFのプログラムに対しては後方互換性が担保されるようにした*
アップストリーム: 互換性が担保されるということはアップストリームは不要
デリバリ: アップストリームしなくていいということはデリバリも即座にできる
Slide 29
Slide 29 text
カーネル開発のつらみが解消された結果どうなったか？
一般的な現場でもカーネル開発に手を出せるようになった
一般的な現場でもカーネル拡張の保守が現実的なコストでできるようになった
一般的なエンジニアから見て新しいこと（カーネル開発）ができるようになった
=> これが昨今の盛り上がりの一因？
Slide 30
Slide 30 text
eBPFは何が嬉しいのか？
何か新しいことができるようになったから嬉しい？
=> 技術的にはNoだが、一般的なエンジニアでもカーネル開発ができるようになったという
意味ではYes
そもそも誰にとって嬉しい？
=> カーネル開発者にとっては辛いところが解消されて嬉しい
ユーザにとってプロダクトがeBPFで作られているのって重要？
Slide 31
Slide 31 text
eBPFで作られているのはユーザにとって重要か？
重要だと言える
カーネル開発のつらみと結局は関係している
● プログラミングの難易度が高い => バグや脆弱性が紛れ込みやすい
● 互換性が担保されない => カーネルのアップデートがリスク、メンテされなくなれば
短い期間ですぐ使えなくなってしまう
● デリバリが遅い => 欲しい機能がすぐ手に入らない
Slide 32
Slide 32 text
ケーススタディ - Falco -
FalcoはなぜカーネルモジュールからeBPFベースの
実装に移行しているのか？
● Falcoのイベントコレクタはカーネールモジュー
ルベースだった
● ユーザからのフィードバックとして安定性、セ
キュリティ、互換性への懸念が示された
● Sysdig and Falco now powered by eBPF
Slide 33
Slide 33 text
まとめ
eBPFは何が嬉しいのか？
開発者目線
● 安全なカーネル開発ができるようになる
● カーネル拡張の保守が楽になる
● 開発・デリバリのスピードが上がる
エンドユーザ目線
● カーネル拡張の導入がより「安全」になる
● 互換性やプロダクトの持続性に対する懸念が軽減される
● 欲しい機能が素早く手に入る