eBPFの裏側：プラットフォームの監視とセキュリティのための新しい方法

2022年11月25日 18:41

※本投稿は、上記のElastic BlogをDeepL翻訳したものです。

著者 David Hope
2022年11月10日

この記事では、Elasticのユニバーサルプロファイラとセキュリティソリューションが使用しているeBPFという非常に興味深いテクノロジーの表面に触れ、なぜそれが現代のオブザーバビリティにとって決定的に重要なテクノロジーであるかを説明したいと思います。

eBPFの仕組みと、それを使って強力なモニタリングソリューションを作る方法、そして将来的にeBPFがオブザーバビリティのユースケースに使われる可能性があることについて、少しお話しします。

eBPFとは？

eBPFまたはExtended Berkeley Packer Filterは、かなりユニークな名前ですが、この技術が何をするものかをユーザーが概念化するのに役立つ方法で説明するものではありません。この名前の理由は、この技術の本来の目的がネットワークであり、非常に複雑なファイアウォールルールを動的に適用するために使用されていたからです。

しかし現在では、この技術は他の多くのことに利用することができ、セキュリティやオブザーバビリティが可能な領域にも広く適用することができます。

eBPFは、OSのカーネル空間で、カーネルのソースコードの変更や追加モジュールのコンパイルなしにプログラムを実行することを可能にする技術であり、その中核をなすものである。

観測可能性においてeBPFが重要な理由

私は顧客として、また様々なテクノロジーベンダーで働きながら、長年APMの領域に携わってきましたが、従来から行われてきたインスツルメンテーションの方法はかなり侵襲的なものでした。手動でインスツルメンテーションを追加していない場合、APMはコードに自分自身を挿入し、それは再コンパイルされます。このような導入は、本番環境を停止させるあらゆる種類の問題を引き起こす可能性があります。

私はAPMの強力な支持者であり、問題の可能性はAPMがもたらす価値のはるか下の方にあります。

カーネルで実行するためにBPFコードを書くと、まずClangを使ってBPFの「バイトコード」にコンパイルされ、次にバイトコードが実行しても安全かどうかが検証されます。これらの厳しい検証により、機械コードが意図的または偶然にLinuxカーネルを危険にさらすことはなく、BPFプローブがトリガーされるたびに、決められた数の命令を実行することが保証されます。

従来のインスツルメンテーションのもう一つの問題は、データを取得し、そのデータを処理する必要がある頻度が高いため、一般的にリソースを消費し、大きなオーバーヘッドになる可能性があることです。eBPFはカーネル内で直接実行できるため、データにアグリゲーションを適用し、ユーザレベルにはサマリーのみを渡すことができ、ユーザスペースのソリューションで発生するオーバーヘッドを大幅に削減することができます。

BPF Compiler Collection (BCC)を使ってフードの下を見る

ボンネットの中を見るには、こちらに挙げたBCCツールから始めるのがよいでしょう。これらのツールについて私が気に入っているのは、以下のように、eBPFプログラムをカーネルにブートストラップするために必要なコードの多くを抽象化して、Pythonのコードから簡単にアクセスできるようにしていることです。

手始めに、これを見てみましょう。ここがeBPFのHello worldです。

このプログラムが行うことは、ターミナルから作成されるそれぞれの新しい子プロセスに対して "Hello world!" と表示することです。これは man ページにあるように "sys_clone" のフックを持っているからです。

このコードを Python ファイルに突っ込めば、(BCC ツールを最初にインストールしたと仮定して) 実行できるはずです。そして、別のターミナルでいくつかのコマンドを書き始めれば、プロセスを起動するたびに "Hello World '' が表示されるのを確認できます。本当に簡単なことです。

このプログラムには4つの興味深い点があります。

もう一つの例を見てみましょう。オブザーバビリティの目的にはもう少し便利なもので、httpサーバーの呼び出しをトレースするものです。

見てわかるように、これにはあまり多くのことはありませんが、非常に強力です。Node JS の httpリクエストをインターセプトして、リクエストメソッドに渡される特定のパラメータを見ることができるのです。

このリポジトリにある他のBCCツール（以下に示す）をチェックして、あなたが経験する厄介な問題、特に従来のツールではまだ解決できなかった問題に役立つ方法をすべて見てみる価値があります。私は、近い将来、これらのツールが私たちのお気に入りのオブザーバビリティのソリューションに統合されることを信じています。

以下は、私たちElasticがBCCツールを使ってeBPFで取り組むことができたことのリストです。

・ディスクIOレイテンシのデバッグ
・遅いXFSファイル操作のトレース
・XFS操作のレイテンシをまとめる
・カーネル関数コールをトレースしてmd_flush_requestの問題を発見し、ディスク書き込みのスローダウンを軽減する。

eBPFの技術はどこに向かっているのか？

ご覧のように、私たちは簡単にカーネルにフックを入れ、ネットワークや低レベルのサブシステムから上で実行されているアプリケーションまで、システムで起こっていることを調べ始めることができます。

さて、eBPFにはいくつかの制限がある。eBPFのコードを実行する仮想マシンは、コード内の変数に読み取り専用でアクセスすることができます。eBPFではAPMのようにコードにタグやトレースIDを動的に追加することは現実的にはできません。技術的には可能ですが、メモリにパッチを当てることになり、安全ではありませんし、潜在的に高いオーバーヘッドを持つことになります。したがって、トレース情報、ログ、メトリックデータをコードに追加する必要があることを考えると、それらの問題が解決されるまでは、APMエージェントとOpenTelemetryは現在も存在することになります。

ここで起こるかもしれないと思うのは、従来のAPMの責任の一部、特に収集の部分がeBPFベースのエージェントに移っていくことです。トレース ID やメトリックを読み込んでコンテキストを生成し、すべてのデータを結びつける作業は、パフォーマンスの利点や要約のスピード、そしてより多くの基礎システムにアクセスできることから、eBPF ベースのエージェントに移行する可能性があります。

同時に、eBPF はより深く、より興味深い情報、ネットワークデータ、セキュリティデータ、kubernetes に関するデータ、その他従来 APM の手の届かなかったシステムサービスを収集するために使われるかもしれません。

eBPFについては、今後、さらに多くの情報を得ることができると期待しています。Elasticのようなオブザーバビリティのソリューションの大部分は、ますますこの技術の多くを隠れて使うようになるでしょう。もしかしたら、eBPFのプログラムに機械学習モデルを組み込んで、最も重要なデータや問題を特定し、これまでよりもずっと早く問題を知らせてくれるようになるかもしれません。 eBPFは、現代のオブザーバビリティと、今後数年間で出現するユースケースにおいて重要な未来を持っています。

Elastic Observabilityについて（日本語）

オブザーバビリティに関するお客様事例（日本語）

12/14開催予定のウェビナー： ElasticAPMのログ活用法

＜概要＞
システムの動作のトラブルシューティングとデバッグを行う場合、ログにはストーリーの一部しか示されません。

アプリケーションパフォーマンスモニタリング（APM）と分散トレースは、ログに必要なコンテキストとタイミング情報を提供し、複数のコンポーネントの動作をリンクし、ログに記録されたイベントを可観測性の高いコンテキストとして配置します。このウェビナーでは、Elastic Stackが、メタデータでログを充実させ、ログをメトリックとトレースにリンクすることで、視覚化と異常検出にどのように役立つかを学びます。

このウェビナーでは、次のことを学びます:

サーバーとコンテナに関するデータでログを充実させる方法
ログをメトリック、トレース、および稼働時間データと関連付ける方法
ログやメトリックなどのイベントデータを格納するための共通のフィールドセットであるElasticCommonSchemaに関すること全般
Elastic機械学習機能を使用してログを拡張する方法

この記事が気に入ったらサポートをしてみませんか？