The industry is really excited about the possibilities with this, and there have been projects around observability and traffic management that have proven how powerful this functionality is.

業界はこの可能性に大いに期待しており、観測可能性やトラフィック管理をめぐるプロジェクトは、この機能がいかに強力であるかを証明している。

So let's get into how this technology works.

では、この技術がどのように機能するのかを説明しよう。

So let's draw a server from an operating system perspective.

そこで、OSの観点からサーバーを描いてみよう。

I'm going to break it up into logical layers.

論理的なレイヤーに分けるつもりだ。

And I'm going to start with the kernel layer.

まずはカーネル層から。

So that's this layer in the middle here.

この真ん中のレイヤーがそうだ。

And this is the core of an operating system, and it goes in between the other layers.

そしてこれがオペレーティング・システムの中核であり、他のレイヤーの間に位置する。

Then I'm going to draw a physical layer down here.

次に、この下に物理層を描きます。

And this represents all of the physical aspects of the server.

そしてこれは、サーバーの物理的な側面をすべて表している。

So there could be things like the network, and the storage, and the memory down here.

つまり、ネットワークやストレージ、メモリといったものがここにある可能性がある。

Now the kernel, it knows how to address all of these physical components of the server.

今、カーネルは、サーバーのこれらすべての物理的コンポーネントのアドレスの取り方を知っている。

And then a layer above that is going to be the user layer.

そして、その上のレイヤーがユーザー・レイヤーとなる。

This is the layer where applications are installed and run.

これは、アプリケーションがインストールされ、実行される層である。

And these applications need to have universal ability to talk to the server components to do what they need to do.

そして、これらのアプリケーションは、サーバー・コンポーネントと対話し、必要なことを行うための普遍的な能力を持つ必要がある。

Now an application doesn't want to know how to talk to every single type of network interface card that exists out there.

今、アプリケーションは、世の中に存在するあらゆる種類のネットワーク・インターフェイス・カードと話す方法を知りたいわけではない。

So it just has to worry about talking to the kernel.

だから、カーネルとのやり取りを心配するだけでいい。

And then the kernel can worry about the communications from there.

そして、カーネルはそこから通信の心配をすればいい。

Now this communication happens as events, and eBPF is event-driven.

そしてeBPFはイベントドリブンである。

Inside of the kernel, there are events that can happen when a system call is made in between the kernel and user land. eBPF functions can then be triggered at the time of an event in order to do something.

カーネル内部では、カーネルとユーザー・ランドの間でシステム・コールが行われると、イベントが発生することがある。

Now the kernel is meant to be very stable as a lot of things rely on it, and it needs to be rock solid.

カーネルは非常に安定したものでなければならず、多くのものがカーネルに依存しているからだ。

And so one reason why eBPF is so exciting is that it provides extensibility at a layer where normally it would be quite difficult to implement.

eBPFがエキサイティングな理由のひとつは、通常なら実装がかなり難しいレイヤーで拡張性を提供するからだ。

Normally this would require kernel modules to extend functionality.

通常は、機能を拡張するためにカーネルモジュールが必要になる。

Kernel modules are difficult to maintain because there are changes with each kernel revision that can often break compatibility.

カーネル・モジュールは、カーネルのリビジョンごとに変更があり、互換性が壊れることがよくあるため、メンテナンスが難しい。

And depending on your risk tolerance, you may not even want to do this in production in case there are bugs in the kernel module that you want to install.

また、あなたのリスク許容度によっては、インストールしたいカーネルモジュールにバグがある場合に備えて、本番環境ではこれを行いたくないかもしれない。

With eBPF, you can isolate the risk and extend kernel functionality safely.

eBPFを使えば、リスクを分離し、安全にカーネル機能を拡張できる。

You also don't have to restart the kernel in order to deploy or undeploy eBPF applications.

また、eBPFアプリケーションをデプロイまたはアンデプロイするためにカーネルを再起動する必要もない。

Another reason why this is exciting is because of the performance advantages.

これがエキサイティングなもうひとつの理由は、パフォーマンスの優位性だ。

Because eBPF runs at the logical junction in between the kernel and hardware devices, it's able to make decisions early when receiving inputs from those devices.

eBPFは、カーネルとハードウェア・デバイスの間の論理的な接点で動作するため、これらのデバイスから入力を受けたときに、早期に判断を下すことができる。

This makes it much more performant while observing traffic.

これにより、トラフィックを観測する際のパフォーマンスが格段に向上した。

You can implement hooks into almost any device the kernel is managing, such as memory and networking and storage.

メモリやネットワーク、ストレージなど、カーネルが管理しているほとんどすべてのデバイスにフックを実装できる。

And all of these hook points will be able to have links back to programs running in user space if needed.

そして、これらのフックポイントはすべて、必要に応じてユーザー空間で実行されているプログラムへのリンクを持つことができる。

So let's talk about the use cases we're seeing with this technology.

では、この技術で見られる使用例について話そう。

Some of the main use cases the industry is excited about is network filtering, observability, and security policies.

業界が期待している主なユースケースは、ネットワーク・フィルタリング、観測可能性、セキュリティ・ポリシーである。

Network Filtering eBPF can enforce simple to complex rules very early in the receive path.

ネットワーク・フィルタリング eBPFは、受信パスの非常に早い段階で、単純なルールから複雑なルールまで適用できる。

This is done very efficiently and tailored to specific processes, network namespaces, or application types.

これは非常に効率的に行われ、特定のプロセス、ネットワーク・ネームスペース、またはアプリケーション・タイプに合わせて調整される。

And this filter can also do egress filtering for the use cases of loss prevention or content filtering.

また、このフィルターは、紛失防止やコンテンツ・フィルタリングのユースケースのために、イグレス・フィルタリングもできる。

Observability So I'm just going to draw a couple of magnifying glasses here.

観察可能性ということで、ここに虫眼鏡をいくつか描いてみる。

And I'm also going to draw this, which is a representation of a process tree.

そして、プロセス・ツリーの表現であるこれも描いておこう。

And so eBPF can see traffic from any device on the server and the behavior of any process in the process tree.

そしてeBPFは、サーバー上のどのデバイスからのトラフィックも、プロセスツリー内のどのプロセスの動作も見ることができる。

And so as applications get broken down into microservices, I'm going to represent those with these boxes here.

アプリケーションはマイクロサービスに分解されるので、このボックスでそれを表現する。

It's increasingly difficult to bolt on observability in the user land.

ユーザーの土地で観測可能性をボルトで固定するのはますます難しくなっている。

And using eBPF, it allows for user space processes such as system monitors, process visualizers, and tracing tools to have a kernel space point of view.

また、eBPFを使用することで、システムモニター、プロセスビジュアライザー、トレースツールなどのユーザー空間のプロセスが、カーネル空間の視点を持つことができる。

This is an alternative to service meshes, which implement distributed tracing using sidecar proxies, which each add some performance burden.

これは、サイドカー・プロキシを使って分散トレースを実装するサービス・メッシュの代替手段であり、それぞれ性能上の負担が増える。

Instead, performing this at the kernel level has already proven to be advantageous for performance.

その代わりに、カーネルレベルでこれを実行することが、パフォーマンス上有利であることがすでに証明されている。

Another use case comes around security.

もうひとつの使用例は、セキュリティーに関するものだ。

So now that you have all this information, you've identified devices and process flows and you have observability to detect anomalous behavior, you can combine that to trigger policies and you can use eBPF to enforce those policies by asking the kernel to kill processes or you can restrict certain behaviors directly, or you can filter network traffic to and from the device itself. eBPF opens up a number of possibilities that were previously difficult to scale at the same pace of application modernization.

eBPFを使用すれば、カーネルにプロセスの強制終了を要求することでポリシーを適用したり、特定の動作を直接制限したり、デバイス自体との間でネットワーク・トラフィックをフィルタリングしたりすることができます。eBPFは、これまでアプリケーションの近代化と同じペースで拡張することが難しかった多くの可能性を開きます。

Solutions that take advantage of eBPF will be able to provide a high degree of functionality without the challenges of performance degradation and kernel stability.

eBPFを活用するソリューションは、パフォーマンスの低下やカーネルの安定性という課題を抱えることなく、高度な機能を提供できるようになる。

So thanks for checking out this Brightboard lesson.

このブライトボードのレッスンをチェックしてくれてありがとう。

Hit like if you enjoyed this content, leave a comment down below if you have any questions.

このコンテンツを楽しんでいただけたなら、「いいね！」を押してください。質問があれば、下にコメントを残してください。

Hit subscribe if you want to see more of these and I will see you on the next one.

もっと見たい人は購読してください。