Kubernetes Meetup Tokyo #55 (https://k8sjp.connpass.com/event/267620/) での発表
発表動画: https://www.youtube.com/watch?v=wlYHa1gKfBI
eBPFは何が嬉しいのか?Yutaro HayakawaIsovalent
View Slide
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 CompilerbpfシステムコールでロードされたプログラムはVerifierによって「検証」される=>「安全」でなければ実行できない検証が通ったらほとんどの場合JITコンパイルされる=> 実行前に全部ネイティブマシン命令に変換 (JSなどの動的JITとはちょっと違う)検証が共通化できるのがeBPFバイトコードがアーキテクチャ非依存な理由
Hook / Eventカーネルの中でeBPFを実行できる場所何かしらのイベントを契機にeBPFが実行される代表的なフック- Socket => socketに対するデータの入出力をフィルタする- Syscall => システムコールの呼び出しをトレース・フィルタ- kprobe / ftrace => カーネルの関数呼び出しなどをトレース- TC / XDP => NIC入ったパケットを書き換え・ドロップ- TCPの輻輳制御, スケジューラ, etc
eBPF MapeBPFプログラムとユーザ空間から読み書きできるデータ構造=> 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は何が嬉しいのか？開発者目線● 安全なカーネル開発ができるようになる● カーネル拡張の保守が楽になる● 開発・デリバリのスピードが上がるエンドユーザ目線● カーネル拡張の導入がより「安全」になる● 互換性やプロダクトの持続性に対する懸念が軽減される● 欲しい機能が素早く手に入る
yutarohayakawa
minorun365
miyayou
yuya4
convto
mot_techtalk
hatahata021
oracle4engineer
okuzawats
takahana
x_ttyszk
hato3isfriend
philhawksworth
lynnandtonic
palkan
chriscoyier
paulrobertlloyd
akosma
jrom
quramy
edds
denniskardys
geeforr