eBPFの基本と利用例
ken
皆さん、こんにちは。London Tech TalkのKen Wagatsumaです。
かやさん、今日もよろしくお願いします。
Kazunari Okuda
よろしくお願いします。
ken
今日はですね、久々に技術トピックで、一つの技術を深掘りしていく、
コテコテのソフトウェアエンジニアリング界をやっていこうと思っています。
楽しみです。
それで今日は、eBPF という技術について、包括していこうと思うんですけど、
これ、eBPF について話すためにですね、最高のゲストをお呼びしています。
ケイスケさん、今日はよろしくお願いします。
Keisuke
よろしくお願いします。
ken
ということでケイスケさんは、収録2回目来ていただいているんですけど、
改めて簡単に自己紹介してもらってもいいですか。
Keisuke
はい、ケイスケです。東京で IT エンジニアをしています。
趣味で eBPF 勉強を始めまして、
会社でも使っているので、より興味があって、
その中で、自分でも OSS で eBPF の簡単なツールとか作ってみようと思って、
作ってみて、そんなところも今日は話せればなと思っています。
ken
まずですね、カズさんと僕で、
eBPF まず何それ、おいしいの状態だと思うので、
ケイスケさんに eBPF の簡単に説明をしてもらうと思うんですけど、
現状カズさんが知っていることって何ですか、eBPF。
Kazunari Okuda
ネットで調べた感じだと、Linux 関連で、
Kernel 領域、よりプリビリッジがある、何でもできる、
Kernel の権限で、サンドボックスか何か作って、
そこでプログラムを実行できる、みたいな認識です。
調べてるじゃないですか。
もっと奇想天外の答えを期待しました。
さすがカズさんとしか言いようがない。
でも、それが結局どういう風に使えるのかっていうのは、想像がつかなくて、
サンドボックス、具体的にどういう風なものなんだろうっていうのは、
すごい気になってますね。
ken
そういう意味で、仕事で使ってるっていうのもあるし、
eBPFの安全性と利点
ken
OSSで公開してるっていうのも、けいすけさんにぜひ、
いろいろその魅力を語っていただいて、
カズさんとリスナーの人々にeBPFの良さを売り込む回、
というのが今回の収録の裏目的にしようかな、
なんて思ってたりします。
けいすけさんに振っていいですか。
そもそもeBPFとは何かと聞かれたら。
Keisuke
そうですね。
よく聞くのが、WebブラウザーでJavaScriptを使うと、
ページ上のクリックとか、そういったイベントのコールバックとして、
任意のプログラムをJavaScriptで書いて、
何でもできると思うんですけど、
似たようなことがeBPFでもLinuxのカーネル領域でできるっていう風になので、
ブラウザーにおけるJavaScriptみたいなものがeBPF。
例えばの収録そういう風に言われていて、
Linuxカーネル領域で、
例えばカーネルが外部のネットワークパケットを受け取ったとき、
その受け取る関数にフックして、
任意のプログラムが実行されて、
例えば情報を何か取って、
それが目的としては監視の目的であったり、
セキュリティの目的であったり、
そんなことが簡単に言うとeBPFです。
ken
そのアナロジーを僕も聞いたことがあって、
フロントをやってたりJavaScript好きな人としては、
それを聞くと一気に親近感を湧いてしまうんですが、
その後eBPFのコードを見に行くと、
これ全然わからないみたいな感じになったのが僕なんですけど。
どうですか、今のアナロジー、かずさん、伝わりました?
Kazunari Okuda
そうですね、イベントでなんとなくわかったんですけど、
セキュリティの部分があまりピンとこなくて、
ken
ユースケースですよね。
Kazunari Okuda
そこのフックがあることで、
どうセキュリティに影響するのかなっていうのが想像つかなかったですね。
Keisuke
なるほど、例えば特定のファイルをオープンするっていうことがあったときに、
そのオープンっていうのは結局システムコールが呼ばれて、
パネル領域のファンクションが呼ばれると思うんですが、
そのファンクションにフックしたeBPFのプログラムが、
例えばプロセスのIDとユーザーのIDっていうのを取得して、
このプロセスIDとユーザーIDはこのファイルへのオープンの許可をしていないので、
拒否しますみたいなことができたり、
っていうのでセキュリティの目的で使えるかなっていうふうに言いました。
Kazunari Okuda
なるほどですね、バリレーションじゃないけどそんな感じですかね。
Keisuke
すごい。
いいですよ、どうぞどうぞ。
これは一例でして、例えばネットワークの話だと、
EBPFの応用と実用例
Keisuke
多分特定のIPアドレスから来たリクエストをドロップしたりとか、
そういったこともできるかなと思います。
ken
多分結構厳格なAPIという印象なんですけど、
Linuxでそもそもユーザーが書いたアプリケーションが動く以降、
ユーザーランドっていうところと、
あとカーネルが提供しているシスコールが動くカーネルランドみたいなのがあって、
そこのインターフェースが今まではシステムコールシスコールでやり取りしてたんですけど、
EBPFっていうのは、
普通に例えばレールズアプリケーションとかノードアプリケーションを書いて、
バイトコードにするとユーザースペースで動くんですよね。
だけどEBPFプログラムが実行されるのはカーネルランドのほうということで理解してるんですけど、
Keisuke
それあってますか。
そうだと思うかも認識していて、
そうですね、EBPFのプログラムを書くっていうのは、
プログラムの中身自体は最初Cで書きます。
Cで書いたのをクランっていうコンパイルを使って、
EBPFのバイトコードにしまして、
このバイトコードをカーネルにロードして、
なのでカーネルが領域で動くんですよね、プログラムは。
ken
BPFのバイトコードでまずコンパイルするんですよね、EBPFプログラムを書いてCで。
Keisuke
その書いたEBPFのプログラムと、
ユーザースペースで動くプロセスっていうのを通信させて、
なのでEBPFプログラムが取得した情報をもとにユーザースペースで何かしたいっていうことがあったときに、
そのブリッジになるみたいな部分がEBPFのマップって呼ばれる機能があって、
そこでEBPFのプログラムとユーザースペースのプロセスのやり取りに使われるって感じですね。
ken
明示的にどんなやつをやり取りするか、メッセージやり取りするかってのを書かなきゃいけないから、
例えばフロントエンジニア向けに他のアナロジを紹介する、
例えばサービスワーカー同士でセンドメッセージ、ポストメッセージするとかみたいな感じだったりなのかなと思ってはいるんですけど、
そこでコンパイルされたBPFのバイトコードの中に、
例えばさっきのセキュリティの話で言うと危険なコードとか入っていても、
それが実行される前に多分検証プロセスが入るから、
Keisuke
意図的にLinuxカーネルをぶっ壊すようなコードとかもそこで弾かれるっていうことなのかなと思います。
そうですね。BPFのバイトコードが実行される前に、
ベリファイヤーって呼ばれるものがカーネル領域にいまして、検証ですよね。
バイトコードが何か違反してないかっていうのをチェックしまして、
違反してるようなプログラムであればそもそも実行できない、拒否しちゃうみたいなことがあって、
そのベリファイヤーに通過したものだけが実行されるので、
安全かなと。
よくEBPFでできることで、カーネルモジュール変えちゃえば同じようなことができると思うんですけど、
カーネルモジュールってカーネルにロードして任意のプログラムを実行できるっていう点では、
EBPFと似てるかなと思うんですけども、
カーネルモジュールの中では何でもできちゃうので、
もし何かパニックが起きちゃうと、もうシステム自体ダウンしちゃったりするんですけれど、
EBPFだったらその辺りは、そうですね、より安全かなというふうに思ってます。
Kazunari Okuda
なるほど。何が新しいのかなっていうのが、EBPFの良さ、
似たようなことはLinuxの中でできなかったのかなとちょっと思ってたんですよ。
私は詳しくないのでわかんないんですけど、
でもそこが安全にできるという点がEBPFの良さなのかなと。
Keisuke
注目されてる点に、やっぱり安全な実行環境が用意されていて、
手軽にカーネル領域に対して何かできるっていうところがやっぱり有利でして、
以前だとやっぱり、もうそもそもカーネル自体に変更を加えちゃってやりたいことを実現するのか、
カーネルモジュールを用意してやりたいことを実現するっていうのが大きくあったとしたときに、
カーネルに直接加えるっていうのはかなり長い時間を要してデビュープロセスとか、
あと実際にマージされてもUbuntuとかRELとかそういったディストリビューションに配布されるにはもう何年もかかっちゃうみたいなことがあって、
そういう時間をスキップしてEBPFでとりあえずやりたいことを簡単に実現しようみたいなのは、
今注目されてる理由にあるかなというふうに思ってます。
ken
なるほどね。だからビジネス上、本番展開をしたりとか、ユーザーに早く届けたりとか、
デプロイメントとかマシン展開の用意さみたいなことを考えると、
カーネルモジュールを変えて頑張ってインストールして配布してよりは、
EBPFのバイトコードをコンパイルして動かす方がまだ簡単だよねみたいな。
かつ安全だよねみたいな感じなのかな。
Keisuke
僕もそういうふうに認識してます。
なるほど。
僕がEBPF注目したのもやっぱりその手軽さなんですけれども、
もともとLinuxカーネルのことをもっと勉強したいなって思ったときに、
カーネルにちょっと変更を加えてみたいなって思って、
壊して作って、壊して作ってっていうプロセスで新しいことって勉強できると僕は思ってるんですけど、
カーネルを壊しちゃうと復帰が大変だなと思ってて、
なかなかハードル高いなって僕は思ってたんですけど、
高そう。
EBPFのテクノロジーを使うと手軽にできるなと思って、
まずカーネルのことをもっと深く知る前にEBPFでできることをいろいろやって、
カーネルのことを勉強しようって思ったのが、
僕が勉強を始めたモチベーションです。
ken
カーネル自体、かなり深淵な技術領域ですからね。
僕はもう全然ヒヨコなのでわからないし、
ナックスカーネルだけで一生食ってるようなエンジニアの方もいますからね。
これ流行り始めたのって5,6年前くらいから、
多分技術としてもっと前からあったと思うんですけど、
多分元Netflixのブレンダー・グラックとかが本を書いたりとか、
彼はシステムパフォーマンスみたいな本を書いて、
わりとオピニオンリーダーみたいなところがあるので、
SREとかインフラ領域とかで僕は知ったんですけれども、
そこからその後いろんな人がEBPF使い始めて、
結構サービスとかも出てきたりして、
っていう感じで、
わりとここ2,3年は、
ただEBPFを言うだけじゃなくて、
実際に本番こういうの展開しました?サービスはしました?
みたいなアプリケーションというか応用、
実際の展開みたいなのがニュースに出てくるような印象ではありますけれども、
けいすけさんは何年ぐらいから?
Keisuke
2年前ぐらいですかね。
知ったきっかけが、
カーネルのこと勉強したいなと思っていろいろ調べてたときに、
EBPFって言葉を、その時点では言葉しか知らなかったので、
何も具体的な中身とか知らなかったんですけど、
そんなテクノロジーがあるんだっていうふうに、
ちょっと頭の片隅にあって、
そしたら速報してるうちに、
僕が働いてる会社がEBPFを使った製品を出しまして、
聞いたことあるテクノロジーが使われてると思って、
その出してる製品がやってることっていうのが、
Linuxのホストで動いてる、
そのホスト上で起きてるHTTPの通信とかを監視して、
ネットワークのパフォーマンスを監視するっていうような製品を出していて、
最初僕が使ったときに魔法みたいだなっていうふうに感じまして、
わざわざアプリケーションにセットアップをしなくても、
アプリケーションっていうのを個別に認識していて、
それぞれのAPIのリクエストとかのレイテンシーとか、
そんなのが分かったりして、すごいなと思いまして、
それでどうやって動いてるんだっていうのが気になって、
どんどん仕組みをしていろうと勉強した流れですね。
なので僕自身が知ったのは2年ぐらい前なんですけど、
先ほどちょっと話出たBrendan GreggのBPF Performance Toolsっていう本があって、
eBPFの起源とクラシックBPFとの関係
Keisuke
僕それ読んだんですけど、
2019年の12月に出版されていて、
その本の中でeBPF自体は2013年、14年頃にできた。
もともとBPFっていうネットワークのパケットフィル、
TCPダンプとかそういったもののテクノロジーで使われてたものを、
もっとジェネラルパーパスに展開しようっていうことで、
エクステンデッドBPF、eBPFが2013年、14年頃にできたっていうふうにその本で説明されていて、
なので10年ぐらいの歴史はあるんですかね。
ken
BPF自体がなんだっけ、バークレイパケットフィルターでしたっけ?
そうですね。
パケットフィルターなんですよね、もともと。
BSDパケットフィルターかな、の略なのかな。
それをエクステンドしたから小文字のeがついて、
小文字のeにeBPFっていうのが出たと。
そうですね。
Keisuke
もともとはネットワークの文脈で使われてたものをもっと一般的に広げたっていうのがeBPFですかね。
なのでそのもともとのやつはクラシックBPF、cBPFというふうに本では紹介されてましたね。
ken
ブレナー・グレックが最初2019年に本を出した頃はまだ表記売れがあったような記憶がBPFといったりeBPFといったりしてたような気がしますが、
今はもう小文字のeにBPFが定番なのかなっていう印象ですね。
Keisuke
そうですよね。
リナックスのGitHub見るとドキュメンテーションのところにBPFデザインQAっていうページがあるんですけど、
そこにクラシックBPFのインタプリターまだあるのかっていう質問がノーって書かれてますね。
なのでクラシックBPFはもうeBPFにも合流したっていうか、
今はもうクラシックBPFはないみたいですね。
Kazunari Okuda
なるほど。じゃあもうなんかeBPFがクラシックBPFのように振る舞ってるという感じなんですかね。
Keisuke
そうですね。クラシックBPFの機能も備えてるっていう感じですかね。
Kazunari Okuda
なるほど。じゃあ多分もう今のリナックスっていうのはeBPFが使えるという認識なんですかね。
Keisuke
バージョンで言うと本で書かれてたのは4ぐらい。
メジャーバージョンで言うと4ぐらいですかね。
ken
ちょっと覚えてないですけど。
Keisuke
今は6.9とかが多分最新なので。
Kazunari Okuda
なるほど。リナックスのことは全然すいません。私は分かってないんですけど、
Ubuntuぐらいのは知ってるんですよ。20のバージョンぐらいが出てて。
どのUbuntuが。
ken
LTSがみたいな。
Kazunari Okuda
Windows持ってて、WindowsにUbuntu、LS、SLどっちかで入れてるんですよね。
Keisuke
はいはいはい。
LinuxでのeBPFの利用とバージョンの認識
Kazunari Okuda
リナックス4っていうのがどんぐらいのUbuntuに入ってるものなのかがあんまり分かんないんですけど。
ken
意識しないですよね普通。僕もそんなに意識しないかな。
Keisuke
そうですよね。僕もあんまり意識しないんですけど、
僕が普段使ってるUbuntuのマシンは22.04なんですけど、Kernelのバージョンは6.5ですね。
なので、多分対応表とかは探せばあるんでしょうけど、
そうですよね。Kernelのバージョンって普段あんまり意識しない。
ディストリビューションのバージョンぐらいしか意識しない。
Kazunari Okuda
だいたいある程度最新のもののリナックスバージョンであればEBPFは使えるという認識で、
まあ歴史も長いみたいですからね。
Keisuke
はい。なので多分、
割と対応表とか探せばあると思う。
ちょっと明確にどのバージョンからっていうのは難しいんですけど、
今最新リリースのとかディストリビューション使ってれば確実に使えるかなというふうに思います。
ken
そうですよね。
BPFって僕個人的にすごい思い入れ深い技術なんですよ。
僕挫折した技術なんですよ、これ。
2017年、18年クックパッドの広告時代いた頃なんで、
その時かな、2017後半とかかなに、
よくわかんないけど、0.1%ぐらいで落ちるリクエストっていうのがあって、
当時ダイナモDBバックエンドに行ってエンボイ経由で通信して、
なんかよくわかんないけどエラーになる、それ何でだろうみたいな、
すごい頑張って調べたときに、
既存のオブザーバビリティツールだとわかんなかったんですね。
それの次に行くためにBPFなる技術があり、
それを使ってもうちょっと深いところまでの情報を取れれば何かわかるんじゃないか、
ということがわかったんですよ、当時。
eBPFの実装とツールの利用
ken
僕はLinuxも全然わかんないし、
インストールとかそもそもどうするのみたいな、
ツーリングも全然なかった状況なので、
それで頑張ってやろうとしたんだけど、
なんかよくわかんなくてBPFの本読んでたら、
もう海外地味に遺跡の時間が来ちゃったみたいな、
挫折した技術としてだいぶ思い出深いので、
今こうして話してるのがすごい懐かしいんですけど、
僕は最近のツーリングの発展と全然追ってなくて、
当時ってBPFトレースみたいな、
トレーシングランゲージっていうのを書いて、
実行させるものがあったりとか、
あとはBCCっていう割と初学者向けにも使いやすいような
ツールキットっていうのを提供して、
バイソンとかでもバインディングとか提供して書けるようなものがあった印象なんですけど、
最近のツーリングはどういったものがあるかとかっていうのも
けいさけさんに聞いてみたいなと思っていて、
多分BCC、BPFトレースぐらいだったら僕も聞いたことあるんだけど、
どういったものがあるのかなと思っていて。
Keisuke
なるほど。
最近、僕が作ったOSSで使ってるライブラリっていうのは
シリアムっていうプロジェクトがあって、
そこが出してるEBPF、
Goで書いたんですけれども、そのツール自体は。
シリアムっていうGitHubのレポジトリがありまして、
そこにEBPFっていうレポジトリがあるんですが、
そのライブラリを使って僕はそのツールを開発しました。
これ使うと。
ken
何をしてくれるやつなんですか?
Keisuke
書いたものとしてはCのコードとGoのコードって2つ言語があるんですけれど、
そのCの部分はEBPFのプログラムに該当します。
そのEBPFのプログラムで取得した情報を得て何か、
ユーザースペースで何かしたいっていうその何かしたい部分をGoで実現していて、
そのEBPFのプログラムとGoで書いたプロセスっていうのを、
あんまり中身で何が起きてるかっていうのはあまり意識せずに、
簡単につなげてくれるようなライブラリっていうのが提供されていて、
そこでチュートリアルとか、
Exampleのコードっていうのもレポジトリ内に存在していて、
そのExampleを手元でちょっとビルドして動かしてみて、
っていうみたいなとこから始めましたね。
で、そのExampleのコードの中身をちょっと変えてみてまたビルドして動かして、
壊れたとかうまくいったとか、そんなのを繰り返しながら勉強しました。
ken
なるほど。
だからGoで書いたアプリケーションプログラムは、
その1プロセスとしてユーザーランドで動いており、
Cで書いたものが多分ツーリングがいい感じに途中でBPFプログラムとして、
BPFのバイトコードにコンパイルしてくれて、
それがKernel&動き、
その間がさっき言ったメッセージングAPIでやり取りされてるっていう理解であってますか。
Keisuke
Goで書いたバイナリを実行する前にやることとしては、
Cで書いたプログラムをクランを使ってコンパイルして、
バイトコードにしておいて、
そのバイトコードがあると、
Ciliumのライブラリを使っていると、
そのバイトコードっていうのを使って、
バイナリの実行時、なので起動プロセスぐらいのときに、
Kernelにロードしてみたいな処理をしてくれるんですよね。
なので、
ken
ロードしてくれるんですね。
Keisuke
eBPFのプログラムをコンパイルするタイミングは実行前。
それはCiliumのプロジェクト内に提供されている、
なんて名前でしたっけ。
BPF2GOっていうツールがあるんですけど、
そのツールによって変換して、
プログラムをバイトコードに。
それをしておくと、
実行時に下準備はしてくれるというか。
ken
なるほど。
なんかハマりどころってありました?
それを聞いたら単純な僕はできそうかなって思ってしまったんですけど。
Keisuke
僕もできそうかなって思ってたんですけど、
まず僕はその時点で、
僕の技術レベルとしては、
Kernelも勉強中で全然詳しくないですし、
今でも勉強中ですけど、
そもそもCのコードも読んだことぐらいしかなくて、
ken
ちゃんと書いたことなくて。
Keisuke
なんか5のことは知ってるけど、
Cだとどうやるんだっけみたいな。
あとポインタの操作っていうのを結構しまして、
あとそのeBPFのプログラムで、
例えばですけど、
Kernelのファンクションをフックすることもできるんですけど、
ユーザープロセスのユーザー定義のファンクションに
アタッチすることもできるんですね、
eBPFのプログラムを。
僕はそのuProveっていう名前がついてるんですけどそれは、
Kernel内のファンクションにアタッチするのはkProveっていう名前がついてて、
kがKernelでuがユーザーだと思うんですが、
そのuProveっていうのを使って、
僕はツールを作ってたんですけど、
その時にユーザー定義のファンクションにアタッチして、
そこでeBPFのプログラムが呼ばれて、
その中でアクセスできるものがCPUのレジスタにアクセスできるんですね。
そのファンクションが呼ばれたときのCPUのレジスタにアクセスできて、
そのCPUのレジスタの中に、
もちろん扱ってるデータがインテージャーとかだったら、
レジスタから直接取れるんですけど、
ストリングとかストラクトとかだったら、
メモリのアドレスだけ書いてあって、
そこから飛んで、上から何倍飛め?
オフセットとか使って、
そこのデータを取りたいとかってなると、
そういったポイントの操作が必要になってくるんですが、
そういうの全然意識したことがなかったので、それまで。
確かに。
どうやってやるんだっていうのが全然わかんなくて、
そこはかなり苦労しました。
なんですけど、
僕が見つけた方法としては、
GDPっていうデバッカーがあると思うんですが、
Cとか、
Goにも使えるんですけど、
Cのデバッカーとかで有名だと思うんですが、
そのデバッカーを使って、
アセンブリが見れるので、
アセンブリの行動とかを見て、
このメモリの操作とかしてるのを見て、
ここでプラス何倍としてるから、
ってことはマイナス何倍とすればとか、
そんなのを見て地道にポイントの操作っていうのをやって、
初めてのことだったんで、僕は。
多分それって今ではあんまりお勧めされないっていうか、
アンセーフな作業なので、
Goとかモダンな言語のラストとかだったら、
あんまりできないように何とかしてると思うんですけど、
ken
高級言語だとそうですよね。
Keisuke
でもCだとそういうのができるし、
それは自分にとって新鮮で面白かったですね。
なるほど、なるほど。
なんでそこはハマったっていうか、
初めてだったんで、
Kazunari Okuda
ファードルがかなり高かったです。
ken
技術的に面白そうですけどね。
なかなかそれをデッドラインの限られたファンクション、
フィーチャーのプロダクトアウトに合わせてそれをしてくださいって言われると、
なかなか厳しいものがありそう。
それが本業だったらいいけれどね。
Keisuke
完全に趣味プロジェクトだったんで、
いっぱい時間を使えたんですけど。
Kazunari Okuda
大学時代思い出しました。
CS取ったんですけど、そこでアセンブリで、
ライトをピカピカさせるみたいな、
一緒に学部内でやったんですよ、その時に。
僕の学生時代ってマッチで、
本当にあんまり興味なかったんですよね、
プログラミング正直言って。
ポインターとか本当に理解するの、
今だったら興味があるんですけど、
その時は全然興味なくて、
なんだこれみたいな。
でもできた時は面白かった。
こういう順番でライトをピカピカさせてみたいな、
アセンブリでプログラムを書いてやるんですけど、
EBPFの活用とオブザーバリビリティ関連
Kazunari Okuda
それを思い出しましたね。
コンピューターと話してる感じですよね。
本当に原始的なもの。
ken
めっちゃいい体験じゃないですか。
RubyとかJavaScriptみたいな高級言語を書いてると、
他の人に向けて書いてる感じなんですよね。
数ヶ月後の自分を含めて。
コンピューターと話してる感じはあんまりないというか、
そういうところが求められる、
パフォーマンスが求められるところではその考えになるけど、
高級言語はその感覚がないんでちょっといいですね。
いいですね。
それをツーリングを提供しているCyriumっていうのは、
もうBPF界隈では超有名人みたいな会社かなと認識してる。
これ元々Googleかなんかのスピンオフとかでしたっけ。
Keisuke
これはISOVALENTっていう会社が、
多分メインでやってるオープンソースのプロジェクトで、
このISOVALENTっていう会社自体は、
そのEBPFの本当に初期の、
ちょっと待ってください。
全然違う会社、どこでしたっけ。
GoogleかRed Hatとかどこか忘れちゃいましたけど。
ken
Red Hatもそうですね。
Keisuke
どこかのカンネルにすごい詳しい人が、
EBPFっていうものを作り、
そのコアメンバーの人が作った会社だと思いますと認識してます。
そこの会社がメインでやってるオープンソースのプロジェクトなんで、
割と広く使われてるかなと。
例えばCiliumっていうソフトウェアデファインドネットの、
多分ツールっていうかソフトウェアがあると思うんですけど、
KubernetesのGKEとか、
マネージのKubernetesサービス使ってると、
Ciliumっていうコンテナが動いてるのがあって、
多分もう本当にGKEとかEKSとかKubernetesとか使ってると、
多分意図せず動いてると思います。
そのCiliumが提供した、Ciliumっていうソフトウェアが。
そのCiliumっていうソフトウェアは、
先ほど言ったEBPF5っていうライブラリを使って開発されてると思うので、
多分意識してないですけど、
実は僕たちのインフラストラクチャーを支えてくれてると思います。
ken
オブザーバリビリティ関連を使うときには、
EBPFを使ったほうが圧倒的にコスパもいいし、
パフォーマンスも出るしっていうことなんですよね。
Keisuke
そうですね。パフォーマンス出るっていう面で注目されてますよね。
ゴルーチンの監視ツールの開発
Keisuke
わざわざユーザープロセスまでいかなくていいっていうか、
そっか、それは実装次第ですか。
ken
例えばよくLinuxビギナー本とか読んだりすると、
いろんなコマンドが出てきますよね。
そのコマンドを叩くと、
例えば今動いているプロセス一覧が出てきたり、
ネットワークトレースができたりして、
あれって確かほとんどは、
例えばあくまでユーザーランドで動いているアプリケーションで、
例えば添付ファイルとかファイルシステムとかに書き出したものを読んで、
整形したりとかしてるんですけど、
EBPFだともうカーネルランドで全部必要な情報を取って、
整形して落としてくれるから、
例えばもうそれこそさっき出てきたGoogleとかAzureとか、
クラウドベンダーとかが大規模なマシンにスケールさせる
オブザーバリビリティツールを提供しますってなったら、
圧倒的にコストパフォーマンスのほうが勝つと思うんですよね。
実装の大変さとか保守性とかを加味した上でも。
だから一スタートアップとかのオブザーバリビリティエンジニアが
すごい詳しいかっていうと分からないけれども、
そういった大きい会社にスケールメリットがあるような会社で
オブザーバリビリティに近い仕事をしてる人は
割と最近やってる人が多いのかなと思ったりします。
Keisuke
そうですよ。
なんか使ったことはないんですけど、
多分有名な例としてFacebookが、カトランだっけな。
ロードバランサー?
ロードバランサー、あれもEBPFを使ってたはずで。
ken
そうですね。
Keisuke
それもパフォーマンスを向上させたいっていう目的で
EBPFを使ってたと思います。
ken
あった、カトランですね。L4ロードバランサーですよね。
ネットワーク周りで何かエッジを効果したいみたいなときに
EBPFの技術を知っておくと多分こういうことができるんでしょうね。
なんかそのEBPFのすごいコアコミッターの
アレクセイさんみたいな人も確かFacebookの人ですよね。
そうですね。
ファミリーネーム何て読むのか分かんない。
僕も分かんないです。
ストラボイトフとかかな。
Keisuke
あれは多分今もレビュアーでいて
ちょっと詳しくは見えてないですけど
Linux関連6.9のリリースに含まれている
2つぐらい大きなEBPF関連のリリースがあったんですけど
それのレビューとかに彼の名前があったような気がします。
ken
なるほど。
Keisuke
レビュアーの中か。
Kazunari Okuda
すいません。
そのEBPFのOSS開発されていらっしゃるって聞いたんですけど
例えばNodeとかRubyとかみたいに
EBPFのプログラムをディストリビュートさせるサービスみたいな
こういうのを監視できますよみたいな
ジェムみたいな、Rubyでいうジェムみたいな
そういうプラットフォームとかってあったりするんですか?
それともそういうのってGitHub上で
好みのやつっていうか調べて
ダウンロードしてインストールするみたいな感じなんですかね?
どういう感じなのかな?
Keisuke
あと僕もうまく配布する方法っていうのが分かってなくて
僕のもうプロジェクトは完全趣味の簡単なツールだと思ってるんで
もう手元でビルドしてくださいっていう風に書いてます。
でもどうなんでしょう?
世の中のEBPF使ってるプログラムは
どういう風に確かに作ったものをディストリビュートしてるかっていうのは
ちょっと想像がとんじゃないです。
かなり複雑なことをしてたような印象があります。
あとテストもすごく難しいと思ってまして
Unitテストとか書くのすごく難しい。
ken
確かに。どうしてるんですか?
Keisuke
書けないのかな?多分E2Eとかで担保してるような気がしますけど
なんか自分の会社で聞いたのは
もういろんなバージョンのUbuntuとかDellとか用意して
もうその上で走らしてでE2Eとかやってるって聞きましたね。
なんでもうお金がかかると思います。かなり。
もうマシンを大量に用意してる。
なかなか体力ある会社じゃないとできないですね。
Kazunari Okuda
そうですね。
モバイル機種ごとにいろいろテストするみたいな
わからないですがアプリのテストとか
モバイルのゲームのテストみたいな感じを思い出しましたね。
ken
そうか。かずさんゲーム会社でも働いてたことありましたもんね。
けいすけさんが作ってるOSSの話もまとめて聞いてみたいなと思っていて
どんなものを作っていてどんな機能があって
開発費はとかデバッグの大変さとか
そういうことテストどうしてるのかとか
詳しく聞いてみたいなと思うので
よかったら紹介してもらってもいいですか?
Keisuke
僕が作ってるツールが
Goで書かれてるプログラムのプロセスを監視する
デバッグツールみたいなものを開発していて
Goにはゴルーチンっていうのがありまして
スレッドみたいな形のものなんですけれども
ゴルーチンが作成されたときと終了したときっていうのを
そのイベントその2つのイベントに対して
GPFのプログラムを書いていて
作成と終了っていう2つのイベントから
ゴルーチンのライフタイムみたいなのを計測したり
あとゴルーチンが作成されたときの
そのプログラムのスタックトレースっていうのを取得して
どんなスタックトレースで
そのゴルーチンが作成されたかっていうのを
アウトプットするようなツールを作りました
ken
なるほど
それアウトプットとしては今はどういったものがサポートされてるんですか
コンソールに吐き出すような感じ
メトリックスで取りにいくような感じですか
Keisuke
高純出力に吐くものと
あとオープンメトリックスの形式で
ゴルーチンの作成カウントと終了カウントと
あとそのゴルーチンのアップタイムっていうのを
Kazunari Okuda
3つのメトリックスを出力するようなものを作りました
デバッグの難しさと開発秘話
ken
じゃあプロメテウスとか
サポートしているオブザーバビリティツールであったら
まっすぐダッシュボードに入れたりとかもできそうですね
そうですね
なるほどね
そのなんか開発秘話というかデバッグ
なんかすごい大変だったみたいなのをこの前聞いたんですけど
何かを開発秘話
Keisuke
エピソードみたいなのって何か出せたりしますか
はい
先ほどちょっとポイントの操作とか言ったんですけど
まさにそれとかは
今言ったツールを開発しているときに
勉強しながらやりましたし
あとは
eBPFのいろんなオープンソースのプロダクトを見て
そこで例えばさっき
ゴルチンのクリエーションのスタックトレースを取って
そのスタックトレースの内容っていうのも
ちゃんと人間が読める
ファンクションの名前とかにしたいんですけれど
普通は
ファンクションのアドレスとかしか
多分取れないんですよ
なんですけど
そのアドレスに対応するシンボルっていうのを引いてきて
ちゃんとユーザーが読めるような
このファンクション1がファンクション2を読んで
3を読んで4を読んでみたいな
スタックトレースにするっていうところの実装は
ほぼ真似しただけなんですが
Aqua Securityっていう会社が出している
Tracyっていうツールがありまして
それもGoでeBPを使ったツールなんですけど
そこの実装を真似したりとか
それは結構なんか面白かったですね
勉強しながら
デバッグで辛かったところ
これはちょっと僕の実装ミスみたいなところもあるんですけれど
eBPFのプログラムを
ロードするって先ほど言ったんですけど
ロードしたときにGoのプログラム上で
オブジェクト
ちょっと待ってください
ken
多分見たほうが良くて
Keisuke
CiliumのeBPFのライブラリでいうところの
linkuproveっていうファンクションを読むと
eBPFのプログラムをロードしてくれるんですけれど
そのlinkuproveっていうのが
リンクっていう変数を返してくるんですね
そのオブジェクト
ストラクトとかは
クローズっていうメソッドしか生えてなくて
実装ミスなんですけど
それを僕は握りつぶしてたっていうか
その変数はアンダースコアでつぶしてたんですね
そうすると
Goってgcがあるので
そのgcが勝手に起きて
そのgcが起きたタイミングで
そのオブジェクトがgcされると
ken
eBPFのプログラムも終了っていうか消えてたんです
Keisuke
なるほど
なのでGoのプログラムはずっとeBPFのプログラムからの
データの受け取りを待ってて
でも一向に来ない
エラーも出ないし
サイレントでプログラムが止まってたんですね
止まるっていうか
処理は継続してるんですけど
何のデータも来ない
なんでかなってずっと悩んでて
ken
どうやって解決したかっていうと
Keisuke
どうやって解決したんですか
Goの機能の一つに
エクセキューショントレースみたいな名前だったんですが
Goの標準ライブラリに
そのトレースを取る機能がついてまして
それをいったらどこに仕込んで
僕が作ったコマンドラインの起動時から
プログラムが何も出力しなくなるまで
をトレースして
ken
それ全部読んだ
Keisuke
読みましたね
そうするとメモリのヒープの確保量とかが
グラフ時系列で出てくるんですけど
ある時ガクッと下がってて
これ何だろうって
何で下がってるんだっていうのを見て
特に何かGCされたんじゃないかみたいな
そこをずっと細かく見ていくと
なんかGCされてるってなって
GCされてるものは何かって見たら
さっき言ったリンクでした
ken
最後はどうやって当てるんですか
GCされるタイミングとクローズメソッド
ken
GCされてるものが何かって
Keisuke
それはもう
GCされるタイミングで
ken
付近のコードを見て
参照されてないやつがいてみたいな
Keisuke
先ほどリンク
YouProveが返すものはリンクがあるって言ったじゃないですか
そのリンクにはクローズっていうメソッドが入ってるって
言ったと思うんですけど
そのクローズっていうメソッドが呼ばれてたんですね
勝手に
ken
それでピンときたんだ
Keisuke
これ明示的に読んでないけどどこだってなって
例えばこれ握り潰してるわってなって
それをちゃんとコマンドラインが終了する
例えばコントロールCとかで終了するとき
をフックしてクローズ呼ぶって言ってやれば
ken
問題が直りました
そのデバッグ話めちゃくちゃ熱いですね
デバッグツールの開発とEBPFの将来
ken
なんか聞いてて胸が熱くなりました
楽しそうだけど仕事で来るって辛いやつ
Kazunari Okuda
深淵ですね
僕にとっては深淵です
アプリケーションを書いてるエンジニアにとって
面白そうですね
私もけいすくさんが喋ってる間に
頭の中で考えてたんですよ
どういうことが起きてるのかっていうのが
それが結構ちゃんとっていうか
すごいビジュアライズされて
ペアプロやってるじゃないけど
そこの自分もコンピューターの領域にピューと
降りていってる感じ
ken
降りてった
楽しかったですね
ちっちゃくなって降りてった
デジタル
Keisuke
ポッドキャストでペアプロするっての楽しそう
ken
やってみたいな
なるほどね
いやそれめちゃくちゃ勉強になりますね
なんかすっごいスキルつきそうというか
Keisuke
そうですね
ken
ちなみにこのツールグモンって言うんですかGモン
Keisuke
はいGモンと僕は思ってます
Gモン
ゴルチモリターの略でGモンです
その開発のときに
Goのデファクトのデバッガでデルブってあるんですけど
そのデルブっていうデバッガのコードとかも読んだりして
Linux上でバイナリ作るとLフォーマットになると思うんですけど
そのバイナリに含まれてる情報って何があるのかとか
結構読みまして
でシンボルからファンクションのアドレスとかの対応表とか
多分あるんですけど
SimTabって名前だったかな
なんかそんなあるんだとか
初めてのことばっかりですけど面白かったです
ken
めちゃくちゃいいっすねそれ
なんか本読んでLファイルっていうのがあるんだなとか
Goの本読んでこうやってデバッグするんだと知るけど
実際にやらないと身につかないですよね
かっこいいっすね
このGモンは今後どうなっていくんですか
何か今考えているマイルストーンがあったりとか
Keisuke
アイディアは尽きてまして
今自分が手元で動かしたときにやってたのって
ホスト状態動いてもプロセスの関心しか使ってなくて
コンテナで動いてたときのパターンっていうのをやってないんですよ
コンテナもプロセスになると思うんですけど結局は
Kazunari Okuda
でもコンテナをどうやって識別するかとか
Keisuke
どうやろうかなって
なんとなくアイディアあるんですけど
多分Cグループとかの識別子とかなんかあるんじゃないかなとか
思ったりしながら頭の中にあるんですけど
手は動かせてないです
ken
確かに
EBPFの学習と発展
ken
多分他のEBPF関連スタートアップがやってるから
そこら辺のコードを読めば何かヒントが描けそうなところですよね
Keisuke
楽しそう
ken
僕は全く今わからないけど
いいな
オープンソースの開発と会社での業務でちょっと触ったりとか
自分の自己学習というのは
全ての両輪が綺麗に回って
技術力がガンガン伸びて
すごいEBPFという技術を深掘っていって
すごい効率的な学習をされてるなっていう
これめちゃくちゃいい
こういう個人プロジェクトを持つっていうのは
エンジニアとしてもすごいいいなという一つの良い例でもあったかなと
話を聞いてて思いました
Kazunari Okuda
そうですね
しかも会社でEBPFのプロダクトがあるっておっしゃってたんで
こんなことやってるよみたいな感じで
店に行って
興味ありますよっていうのが店に行って
最終的にそこで働けるようになるっていうか
そういう関連に入れると
なりそうですよね
すげえ
わからないです
それが圭席さんが
仕事でやりたいのか
また個人のあれでやっておきたいのかっていうところもあるかもしれないですけどね
Keisuke
それで言うと仕事で
開発とかで携わればいいなというふうに思ってますけど
ちょっと長期的な目標として今僕は思ってますそれは
ken
これ店に行って
何これ圭席Gモンめっちゃいいじゃん
お前うちのチーム来いよみたいな感じで
なんか言われそうですよね
Keisuke
なったらいいなとは
想像してます
ken
実際に動くものを持っていくっていうのが
ソフトエンジニアとして一番手っ取り早い
力の見せどころなんで
いいですね
EBPFどうですかカズさん
ちょっと聞いてみて
なかなかこう
深淵だということが分かりましたね
Kazunari Okuda
そうですねなんか聞いてる感じだと
もう知ってらっしゃるのを聞いて
こういうふうに動いてるんだっていうのは
なんとなく分かるんですけど
これやっぱり一人でやるってなると
Linuxのカーネルを読むとかっていうところから始まって
いろんな膨大な知識から
ここが自分の欲しい情報だっていうのを見つけていって
膨大な情報からそれを
少なくしていってそれを見つけて
さらにそれを深掘っていくみたいな感じで
大変な作業だろうなと思うし
楽しい作業だな
そこに興味があれば楽しいだろうなと思って
エンジニアの心を揺さぶられる話でした
ken
そうですよね
次やりたいのが
EBPF関連の技術を
いろいろもっとウォークスルーしてみるっていう
なんかもうちょっと
Linuxカーネルとか分からなくても聞けるような
エピソードをやってみたい
例えば今日もいくつか
Aqua SecurityとかCiliumとか
Hubbleとか
Hubble出てないか
いろいろ出てきたけれども
EBPFを使ったらこういうサービスがあって
ここではこういうことができて
例えば他のオブザーバビリティ
プラットフォームではこういうものを使えます
みたいな
EBPFが身近になるようなエピソードを
ウォークしたいなと思っていて
ちょっとけいすけさん一緒にやりません
Keisuke
はい
僕もそのいろんな既存の
有名なオープンソースの
ソースとかちゃんとって
理解したいと思ってるんで
ken
なんかその
EBPFのエヴァンジェリストというか
EBPF広めるみたいなのは
たぶん彼ら自身も頑張っていて
EBPFファンデーションみたいなのもあるし
カンファレンスもあるんですよね確かね
Keisuke
EBPFカンファレンス
結構なんか
ウィークリーで
10分くらいのビデオとか
アイソバレントが出してるかなと思って
たまにそれ見るんですけど
発信は結構積極的
な印象です
ken
なるほど
ウィークリーであるのは知らなかった
ちょっとねそういうのを定期的に
EBPFシリーズというのを
けいすけさんと引き続き
お送りしていきたいなと思います
勝手に宣言させていただきましたが
よろしくお願いします
Kazunari Okuda
私はパッと思いつきですけど
坂尾さんとか
Kubernetes関連の開発されて
ken
確かに
Kazunari Okuda
のことも結構好きだし
たぶん
オブザビリティとか
やってるのかな
やってたら彼も
EBPFに
メンションはしてこなかったんですけど
興味があるよ実はなって
2人が
こういうところで使えるんじゃないみたいな
話せるような感じになると
それめっちゃいいですね
ken
いいなと思いましたね
ゲストとゲストをつなぐ
Kazunari Okuda
ここに坂尾さん呼んで4人で
ken
東京にいらっしゃいますし
坂尾さんに今メッセージを送ります
いいですね
ということで
やっぱりアウトプットすると
情報も人も集まってくるというのもあるので
リスナーの方でEBPF興味ある人
もしくは
これを知ってこのエピソードで知ったという方でもいいので
ぜひ
話したかったら
けいすけさんもまた僕らに声をかけてください
ということで
今日はまずEBPF初回ということで
言い残したことお二人ないですか
けいすけさんかずさん
そろそろクロージングに
入っていこうかなと思いますが
Keisuke
質問にしたら
欲しいです
一回しかできない
ありがとうございます
ken
ロンドテクトークの
ディスコードにもこの後紹介してくださいよ
Keisuke
スターください
ぜひスターくださいって投稿します
ken
ということで
リスナーの皆さんぜひ
Gモン見てみてください
そしてスターをよろしくお願いします
ということで
今日はけいすけさんをお呼びして
かずさんと3人で
EBPFについて話していきました
ぜひ今後のシリーズもお楽しみに
ということでお二人今日はありがとうございました
Kazunari Okuda
ありがとうございました
