eBPF - chinng-lab AI実験室

chinng-lab AI実験室

eBPF

A collection of 6 posts

eBPFとは何か——カーネルを再起動せずに拡張する技術が、クラウドの監視・セキュリティ・ネットワーキングを支える仕組み

1. はじめに——なぜカーネル拡張はこれほど難しかったのか eBPF（extended Berkeley Packet Filter）とは、Linuxカーネルを再起動・ソースコード変更なしで安全に拡張する技術です。カーネル空間でサンドボックス化されたプログラムを実行できるため、システムコールやネットワークパケットといったカーネル内のイベントを、高い粒度で計測・制御できるようになります（出典: ebpf.io）。金曜日の16時、担当するKubernetesクラスタで特定サービスのレイテンシだけが急上昇した——そんな経験はありませんか。アプリケーションのログに異常はなく、既存のメトリクスは「遅い」ことしか教えてくれません。本当の原因、つまりどのプロセスがどのファイルを開いたのか、パケットがどのノードで遅れているのかを知るには、すべてのシステムコールとパケットが通過するカーネルの内側から観測するのが理想的です。ところがカーネルはOSの心臓部であり、安易に手を入れればホストごとクラスタを道連れにしかねません。カーネルに機能を足す、従来のつらい2択 OSカーネルは観測と制御に最適な

eBPF入門――Linuxカーネルを安全に拡張する技術がクラウドの監視・セキュリティ・オブザーバビリティをどう変えるのか

はじめに Kubernetes上でマイクロサービスを運用していると、PodのIPアドレスが頻繁に入れ替わる環境では、iptablesベースのネットワーク制御のルール数が増大して更新コストが問題になったり、プロセス単位で動くエージェント型の監視の網羅性に限界が生じたりするケースがあります。「どのコンテナがどのファイルを開いたのか」「どのサービス間でレイテンシが発生しているのか」を、なるべく低いオーバーヘッドで知りたい——そんな課題に対して、いまクラウドインフラの根幹で使われているのが eBPF（extended Berkeley Packet Filter）です。 eBPFとは一言でいえば、Linuxカーネル内で安全にサンドボックス化されたプログラムを実行できる技術です。カーネルのソースコードを変更したりカーネルモジュールをロードしたりすることなく、カーネルそのものを「プログラマブル」にできます（ebpf.io公式）。よく使われる比喩は、「eBPFはLinuxカーネルに対して、JavaScriptがブラウザにもたらしたのと同じ変化をもたらす」というもの。静的な存在だったカーネルが

eBPF入門——カーネルを書き換えずにLinuxの仕組みを変える技術はどう動くのか

はじめに——カーネルを変えるにはなぜ難しいのか？「Linuxの仕組みそのものを変えたい」と思ったら、どうすればいいでしょうか。たとえば、特定のシステムコールを監視したい、カーネルのネットワーク処理に独自の処理を組み込みたい——そんなとき、カーネル内部に新しい処理を追加する代表的な方法は事実上2つでした（ebpf.io）。 1つ目はカーネルソースの変更です。カーネルはシステム全体を制御する特権的な存在であるがゆえに安定性・セキュリティ要件が厳しく、変更はコミュニティの合意を経てメインラインにマージされ、各ディストリビューションへ普及するまで長い時間がかかります。 2つ目はカーネルモジュールの自作です。こちらは即座に反映できますが、セキュリティ境界のない状態でカーネル空間にコードをロードするため、バグひとつでカーネルごとクラッシュする危険を伴い、カーネル更新のたびに破損リスクと隣り合わせになります（ebpf.io）。「待つか、危険を冒すか」。カーネル内部に新しい処理を加える方法としては、この2択に_flock_してきました。そして、第3の選択肢として登場したのが eBPF（ex

eBPF入門——カーネルを再起動なしで拡張する仕組みと、今日から始めるオブザーバビリティ実践ガイド

はじめに結論から言うと、eBPFとはLinuxカーネルを再起動せずに、しかも安全に拡張できる技術です。カーネルのソースコードを改変することも、壊れやすいカーネルモジュールをロードすることもなく、独自のプログラムをカーネル空間で動かせます。かつてパケットフィルタとして生まれたBPF（Berkeley Packet Filter）が進化した「extended BPF」は、今やオブザーバビリティ、セキュリティ、ネットワーキングを支えるLinuxの基盤技術へと成長しています。なぜ今、eBPFなのか eBPFはすでに「研究段階の新技術」ではありません。広く採用が進んでいます。 * クラウドベンダーでの採用: AWSのEKS標準CNIやGuardDutyのランタイム監視、Azureの「Azure CNI Powered by Cilium」、GKEなど、3大クラウドのオブザーバビリティ・ネットワーキング基盤に組み込まれています。 * 商用オブザーバビリティ製品での標準利用: New Relicをはじめ、DatadogやGrafanaといった主要プラットフォームがeBPFベースの機

eBPFが変えるLinuxカーネルの常識——雲の上のコンテナ基盤を支える「プログラマブルカーネル」入門

はじめに——「カーネルを変えずにカーネルを変える」とは？ eBPFという発想 Linuxカーネルに手を入れたい——。システムを深く観測したい、パケット処理を高速化したい、不審なプロセスを即座に止めたい。そんな要求は、クラウドネイティブ基盤を運用するSREやプラットフォームエンジニアなら日常的に直面します。ところが伝統的な解決策はどれも痛みを伴うものでした。カーネルにパッチを当てて再コンパイルする？メンテナの承認を待つのに数年かかることもあります。カーネルモジュールをロードする？完全なカーネル権限で動くため、バグひとつでカーネルパニック＝ホスト全体のダウンにつながります。このジレンマに答えたのがeBPF（extended Berkeley Packet Filter）です。カーネルを再コンパイルせず、危険なカーネルモジュールも使わずに、Verifierで検証された小さなプログラムをカーネル内で実行する——「カーネルを変えずにカーネルを変える」という発想です（Zenn、ebpf.io）。起源は1992年の古典的BPF（cBPF）ですが、2014年にAlexei Starovoit

eBPFが変えるクラウドネイティブインフラ——Cilium・Tetragon・Hubbleで開くゼロトラスト・オブザーバビリティの新世代

はじめに「Kubernetesクラスターの規模が大きくなるにつれて、iptablesルールの更新に数秒かかるようになった」——これは、クラウドネイティブインフラを運用する多くのエンジニアが直面する現実です。マイクロサービスアーキテクチャが普及し、Kubernetesクラスター上で動くサービス数が200、500、ときには1,000を超える規模になると、従来のネットワーキング基盤が限界を迎えます。kube-proxyが依存するiptablesは、サービス数の増加に対して線形（O(n)）にパフォーマンスが劣化します。200サービスを超えたあたりで、ルールの更新に数秒かかるようになり、新しいPodの起動からトラフィックが流れるまでのレイテンシが無視できなくなります。さらに、サービスメッシュの導入による負担も深刻です。Istioなどのサイドカーモデルを採用した場合、各PodにEnvoyプロキシが注入され、Podあたり50〜150MBのメモリを消費します。1,000 Pod規模のクラスターでは、プロキシだけで数百GB〜1TB以上のメモリリソースが圧迫されます。CPUオーバーヘッドも無視