eBPFは魔法の兵器ですか、それとも観測可能なフィールドでは無味ですか? 真実は実は――

現在、eBPF は間違いなく最も注目されているテクノロジーの 1 つであり、クラウドネイティブ環境におけるネットワーク、セキュリティ、可観測性のソリューションに新しいアイデアを提供します。

eBPF は、アプリケーションコードをハッキングすることなく、オペレーティングシステムカーネルにコードを直接安全に追加する革新的なテクノロジとして、企業がカーネル固有のインジケータデータに依存することなく、カスタムデータを収集し、可観測性インジケータとイベントを生成するコードを直接作成できるようにします。これにより、可観測性がカーネルまで拡張されるだけでなく、安全な操作と制御可能なオーバーヘッドを確保しながら、インストルメンテーションなしでアプリケーションコードの可観測性が可能になります。したがって、多くの人は eBPF が観測可能な分野の将来のスターであると考えています。

ただし、eBPF の役割が誇張されていると感じる人もいます。これは、すべてのプロジェクトやエコシステムにとって万能薬ではありません。Linux とその最新カーネルにのみ適用されます。また、プログラムがアクセスできるオペレーティングシステムの部分を制限することにより、「サンドボックスプログラムも制限され」、機能も制限される可能性があります。したがって、eBPF は、観測可能なシステムをほんの少し補足するものであり、将来の観測可能な分野の主な方向性ではありません。

この点に関して実際の状況はどうなっているのでしょうか？実際には、それは大きな助けとなる可能性が高いでしょうか、それとも足かせになる可能性が高いでしょうか? これに関連して、オープンソースチャイナは、Yunshan Networkの研究開発担当副社長であるXiang Yang氏、Observation Cloudの創設者兼CEOであるJiang Shuomiao氏、『SRE Principles and Practice』の著者であるZhang Guanshi氏、インテリジェント製造業のO&MであるWu Qiuxin氏を招待しました。と SUGA データサイエンスチームリーダーの Jaron Tam が共同ディスカッションを実施します。

eBPF がアーティファクトであると言われるのはなぜですか?

肯定的: 襄陽が話す——

それが人工物であるかどうかは、比較することでわかります。

以前に APM エージェントを使用していたときは、その侵入性と死角が原因で、問題を見つけて範囲を定めることが困難でした。

最初のものは侵入的です:

たとえば、SDK または Java エージェントをアプリケーションに挿入すると、アプリケーションが変更されます。このとき、魂の拷問が現れました。当初は元のプログラムを観察したかったのですが、SDK と Java Agent を挿入した後はそれではなくなりました。では、誰を観察しているのでしょうか? 誰の可観測性を保証するのでしょうか?

パイルを強制的にインストールされた後のアプリケーションは以前と同じアプリケーションですか?

それだけでなく、その後も次のような多くの質問が続きます。

コードの競合: 複数の Java Agent ランタイム間の競合、または SDK に依存するライブラリのバージョンのコンパイル中の競合、どうすればよいですか?
メンテナンスの難しさ: エージェントはどれくらいの頻度でリリースでき、どれくらいのバージョンを維持し、どれくらいの言語を適応させる必要がありますか?
境界があいまい: 予期せぬパフォーマンスの低下と運用上の障害、誰の責任ですか?

結局のところ、APM Agent は商業的な行為ではなく、開発の自律的な行為であり、百花が咲き、開発が何でも選択できる行為です。その結果、金融、エネルギー、電気通信、製造などの一部の非常に中核的な分野では、それらをまったく実装することができません。

また盲点:

クラウドネイティブのシナリオでは、2 つのアプリ間の通信は実際には非常に複雑です。他にもネットワーク伝送、システムコール、データベース、ミドルウェアなど、あらゆるゲートウェイがあなたを待っています。このとき、何か問題が発生し、境界を定義することさえ困難でした。

たとえば、ポッドがクラウドサービスへのアクセスに失敗した場合、責任の境界はアプリケーションプロセスですが、作業指示書を送信して境界を定める場合、どの部門が問題の責任を負うのかをどのように判断すればよいでしょうか? ポッドには、ビジネスから Trident、そしてネットワーク送受信用の K8 への非常に複雑なパスがあり、ネットワークサービスの IPVS があり、その後いくつかの転送があり、その後 KVM および任意のプライベートクラウドに至るとします。また、杭を挿入できない場所も多くあります。問題を特定するにはどうすればよいでしょうか?

現時点では、eBPF でこの問題を解決できます。eBPF は、サービス内の動作だけでなく、サービス間の動作も追跡でき、プロセス全体に侵入することなく、コードを変更する必要がなく、同日に実装でき、問題が発生した場合は全体を追跡できます。スタックの境界は 5 分以内に設定できます。

主要産業で APM エージェントを導入できない場合は eBPF で実現でき、クラウドネイティブ環境に盲点がある場合は eBPF で解決できます。

eBPFを使うと可観測性が実現できますが、これは魔法のツールだと思いませんか?

eBPF は単なる一般的なツールです。誇張しないでください。

反対派: 蒋淑妙氏が発言 ——

まず、eBPF を魔法のツールに吹き込むような論調に反対します。

eBPF は単なる手段であり、手段を目的としないでください。

まず、可観測性とデータ収集の利便性を同一視しないでください。

第二に、肯定側が語っているのは、可観測性はトラブルシューティングにのみ使用されるということですが、可観測性の目的はトラブルシューティングだけではなく、トラブルシューティングは非常に小さな段階にすぎません。

第三に、可観測性自体の最大の価値は、システムを理解する完全なプラットフォームを構築することであり、eBPF はシステムを理解するための手段の 1 つにすぎません。

SD-WANをやっているからといって、世界中で釘を探すハンマーにはなれない。可観測性はそれだけではありません。

今日のトピックは、可観測性に対する eBPF の価値です。では、可観測性にとって eBPF はどれくらいの価値があるのでしょうか? 体重をしっかり測りましょう。

まず、eBPFを使用しても観測対象には影響がないのでしょうか？素朴すぎる。

データの観点から見ると、eBPF をバイパスすることでいくつかの情報を見つけることができますが、実際には多くの情報が失われることになります。eBPF を介して実行する場合、アップローブレベルに達すると、実際にコードを挿入することになり、コードの動作に影響を与える可能性があります。まったく影響を与えないことは不可能だとおっしゃいましたが、このリスクは常に存在し、観察者は観察されたに確実に影響を与えます。

カーネルも同様で、eBPFのカーネル技術や仮想マシン技術が影響しないとは考えられず、これも不確実です。ネットワークトラフィックにも影響を与えますネットワークトラフィックはマシンに負担をかけるため、まったく影響を与えないと考えるのは真実ではありません。

第二に、すべての指標が等しいわけではありません。

完全な解決策はこの世に存在せず、何らかの業務処理を行おうとすると、途中で多くのトレードオフが発生し、データが利用できない可能性があります。

例を挙げますと、ネットワークトラフィックからユーザーの有効なアクセスを取得できないため、リチャージインターフェイスが有効かどうか、および運用プロセスと一致しているかどうかを追跡する必要があります。では、ネットワークプロトコル層全体でリチャージ金額とリチャージオブジェクトを暗号化またはマスクした場合でも、eBPF を通じてこの変数を取得できますか? 全然手に入らないですよね。コード呼び出しやネットワークストリームにはそのようなフィールドがないため、どうすれば生成できるでしょうか?

eBPF はその独自性からアーティファクトであると言われています

肯定的: 襄陽が話す——

eBPF が登場する前は、観測を行う方法はたくさんありました。Live エージェントと Java Agent を置き換えましたが、すべて不安を感じながら置き換えられました。時々、カーネルがクラッシュしたり、ファイルに侵入したり、無限ループから抜け出したりすることがありますが、そのような話はそれほど多くないはずです。

このような背景から、eBPF は上記の蛾を回避できる非常に強力な機能、つまりサンドボックス内で動作します。また、限られた数のステップ内で、命令セットと数が制限され、実行および終了できること、メモリリークがないこと、そのような異常終了がないことを保証できるベリファイアが備わっています。。これはいわゆるスタブ化とは異なります。インストルメンテーションとは、元のコードを裸で入力することです。あなたも私も関係なく、簡単に失敗してしまいます。そして、eBPF は安全であり、これが他のテクノロジーと区別する核心点です。他のテクノロジーでは実現できないセキュリティとゼロ侵入を実現します。

2つ目はビジネス分野で、金融業界、通信業界、ゲーム業界など、非常に詳しい事例があります。インスツルメンテーションテクノロジと eBPF を通じてデータを取得した後、ビジネスレイヤーの分析を行います。Awesome Plugin メカニズムを通じて、ビジネス指向の属性であろうとユーザーの属性であろうと、すべてが表示されます。これも侵入ゼロであり、Awesome Plugin はサンドボックスメカニズムも提供します。このプラグインは、何セットの命令を実行した後に終了する必要があるとします。止められないなら殺せ。これらはすべて、非常に強力な保証によって裏付けられています。

したがって、これらの外部データから内部状態を判断できます。これは可観測性ではないでしょうか？宇宙船が空を飛んでいて、動かさずに観測することができます。

eBPF は単なるプローブであり、可観測性そのものではありません

反対派: 蒋淑妙氏が発言 ——

私は今でも、eBPF は可観測性を実現するためのエージェントまたは検出手段にすぎないという考えを持っています。これはあくまで手段の一つであり、eBPF当事者やLinuxカーネルの能力を観測可能なものと捉えるのではなく、実情に応じて異なる手段を採用すべきである。実際のところ、あなたは単なるプローブです。プローブがさまざまな方法でデータを取得するだけです。システムに影響を与えるそれぞれの方法には、それぞれ長所と短所があります。

私たちは今日、可観測性を確立したいと考えています。これは本質的に、ユーザーがフロントエンドからバックエンド、端末の右端まで、あらゆる角度からシステムを理解できるように、統合されたデータストレージを確立することです。eBPF が eBPF のために使用され、結果として別の監視システムが他の監視システムと混在し、全員のデータ形式が統一されず、全員のデータ内容が異なり、相互に呼び出すことができない場合、システムをどのように理解すればよいでしょうか?

したがって、可観測性を構築するということは、観測可能なさまざまな信号をリアルタイムに処理できるデータウェアハウスを構築することだと思いますが、このデータウェアハウスにある元の情報を取得するにはさまざまな方法があり、現地の状況に応じてそれらの方法を使い分けています。eBPF は、ネットワークプロトコル層、またはシスコやその他のレベルを通じて関連データを取得する手段の 1 つです。ただし、さまざまなビジネス状況や観察対象に応じて、手段と可観測性を同一視するのではなく、異なる手段を選択し、データプラットフォームと呼ぶことのできない別のデータウェアハウスを作成する必要があります。データ構築全体にとって、これは本末転倒です。

結局のところ、最終的に生成するデータ結果は、観測データ全体のニーズを満たさなければなりません。

要約:

一般に、eBPF は確かに、問題を定義し、特定のシステムやシナリオでカーネルを観察するための強力なツールです。ただし、eBPF には、エンドツーエンド市場などの制限もあります。実際には、eBPF は使用できません。 Windowsも動作しにくいです。しかし、良い包丁には裏があり、その分野で使えれば合格です。

eBPF についてどう思いますか? eBPFを使用したことがある人々に感想を共有してください~

生放送のリプレイは以下の通りです。納得できない場合はQRコードをスキャンしてリプレイをご覧ください↓↓↓