BT

最新技術を追い求めるデベロッパのための情報コミュニティ

寄稿

Topics

地域を選ぶ

InfoQ ホームページ アーティクル 静かなるプラットフォーム革命 ~ クラウドネイティブ・プラットフォームを根底から変革するeBPF

静かなるプラットフォーム革命 ~ クラウドネイティブ・プラットフォームを根底から変革するeBPF

キーポイント

  • eBPFは、クラウドネイティブ・コンテキストによる強化を実現して、カーネルをクラウドネイティブ・コンピューティングに対応させた。これによってeBPFは、クラウドネイティブ・エコシステムを取り巻く、多くのプロジェクトや製品の水面下ですでに使用されている。
  • eBPFは、すでにあらゆる場所に存在するサイレントインフラ・ムーブメントを生み出し、これまで不可能だった多くの新しい使用例を可能にした。
  • eBPFは、インターネット・スケールで半世紀以上にわたって実稼働しており、世界中の数百万台のサーバーやデバイスで24時間365日稼働していることが証明されている。
  • eBPFはOSレイヤーの新しい抽象化を可能にし、プラットフォームチームはクラウドネイティブネットワーキング、セキュリティ、オブザーバビリティのための高度な機能を得て、ワークロードのニーズに応じてOSを安全にカスタマイズできるようになった。
  • OSカーネルの拡張は、変更が使えるようになるまで何年もかかるような大変で長いプロセスだったが、eBPFでは、開発者と利用者のフィードバックループがほぼ瞬時で終わり、アプリケーションやその構成を再起動したり変更したりしなくても、その場で変更を本番環境に展開できる。
  • インフラストラクチャー・ソフトウェアの次の10年は、eBPFとそれを活用したプロジェクトを利用して、より高度なプラットフォームのための適切な抽象化を実現できるプラットフォーム・エンジニアによって定義されるだろう。eBPFベースのネットワーキング、オブザーバビリティ、セキュリティを実現するCiliumなどのオープンソースプロジェクトは、このインフラの動きを先駆け、Kubernetesとクラウドネイティブにもたらしたのである。

原文リンク(2023-04-06)

Kubernetesとクラウドネイティブが登場してから10年近くが経った。この間、私たちはインフラストラクチャー・ソフトウェアをめぐるプロジェクトやイノベーションがカンブリア紀のように爆発するのを目の当たりにしてきた。また試行錯誤と夜更かしを通じてこれらのシステムを本番環境で大規模に運用する際に、何がうまくいき、何がうまくいかないかを学んできた。このような基本的なプロジェクトと重要な経験により、プラットフォームチームは現在、イノベーションをスタックに押し上げようとしているが、スタックは彼らについていけるのだろうか?

アプリケーション設計がAPI駆動のマイクロサービスに変わり、Kubernetesベースのプラットフォームエンジニアリング、ネットワーキング、セキュリティが台頭する中、Kubernetesは従来のネットワーキングとセキュリティのモデルを置き換えるものなので、チームはその対応に苦労している。クラウドへの移行に伴い、私たちは少なくとも一度は同様のテクノロジーの大変化を経験した。世界でもっとも人気のあるサービスがクラウド上のLinuxボックスで実行されるようになり、データセンターのインフラと開発者のワークフローのルールは完全に書きかわった。今日私たちはクラウド・ネイティブ・インフラストラクチャーをめぐる多くの動きがあり、誰もがその方向性を知っているわけではないという点で、同じような状況に置かれている。 CNCF landscapeを見て欲しい。 Linux カーネル上の分散ネットワークを介して相互に通信するサービスがあるが、多くの機能やサブシステムがそもそもクラウドネイティブ用に設計されていないLinuxカーネルの上で、サービスが分散ネットワーク上で互いに通信しているのである。

インフラストラクチャー・ソフトウェアの次の10年は、このようなインフラストラクチャーの構成要素を利用し、より高度なプラットフォームのための抽象化を具体化できるプラットフォーム・エンジニアによって定義されるだろう。建築家が建材や水、電気を用いて人々が利用できる建築物を建てるように、プラットフォーム・エンジニアはハードウェアとインフラ・ソフトウェアを用いて、開発者が安全かつ確実にソフトウェアを導入できるプラットフォームを構築し、大規模でインパクトのある変更を最小限の労力で予測的かつ高頻度にデプロイできる。クラウドネイティブ時代の次の行動として、プラットフォーム・エンジニアリング・チームは、開発者がビジネスロジックのコーディングに集中できるように、スケーラブルでダイナミック、可用性、高性能な環境のプロビジョニング、接続、監視、およびセキュリティ管理をできなければならない。このようなワークロードをサポートするLinuxカーネルの構成要素の多くは数十年前のものである。クラウドネイティブの世界の需要に対応するためには新しい抽象化された機能が必要だ。幸運なことにこの抽象化はすでに実現されており、何年も前から巨大な規模の現場で実証されている。

eBPFは、安全でパフォーマンスとスケーラビリティに優れた方法でカーネルを動的にプログラムできるようにすることで、クラウドネイティブの世界に必要な抽象化と新しい構成要素を作成している。カーネル自体をモノリスからクラウドネイティブのコンテキストを強化したよりモジュール的なアーキテクチャに移行することにより、カーネルのソースコードの変更やカーネルモジュールのロードが不要になり、安全かつ効率的にカーネルのクラウドネイティブやその他の機能を拡張できる。この機能がイノベーションを容易にするのである。これらの機能により、Linuxカーネルを安全に抽象化し、このレイヤーで緊密なフィードバックループの中で反復と革新をして、クラウド・ネイティブの世界に対応できるようになる。Linuxカーネルの新しいスーパーパワーにより、プラットフォームチームはクラウドネイティブの第二波に備えることができ、知らず知らずのうちにeBPFを使用したプロジェクトをすでに活用している可能性さえあるのだ。プラットフォームとクラウドネイティブの世界を作り変える静かなeBPF革命が起きているといってもよいだろう。

パケットフィルタの拡張

eBPFは、1992年にBSD Packet Filter(BPF)として誕生した数十年前の技術だ。当時Van Jacobson氏はネットワークの問題をトラブルシュートしたいと考えていたが、既存のネットワークフィルタは遅すぎた。彼の研究室では、libpcap、tcpdump、そして必要な機能を提供するためのバックエンドとして、BPFを設計・作成した。BPFはカーネル内で実行できるように、高速で効率的かつ簡単に検証できるように設計されていたが、その機能はIPアドレスやポート番号などの単純なパケットヘッダーフィールドに基づく、読み取り専用のフィルタリングに限られていたのである。時間とともに進化したネットワーク技術に伴って、クラシックなBPF(cBPF)の限界は明白になった。ステートレスであるため複雑なパケット操作には限界があり、開発者にとっては、拡張が難しいものだったのである。

この制約にもかかわらず、最小限の命令セットを持つことで、プログラムの安全性をカーネルが証明し、カーネル内で実行できるようにするという、レベルの高いcBPFのコンセプトは、未来に起こるイノベーションのためのインスピレーションとプラットフォームを提供していた。2014年、BPF(のちの「eBPF」)命令セットを大幅に拡張し、柔軟で強力なバージョンを作成する新しい技術がLinuxカーネルにマージされた。当初、eBPFは汎用的な概念であり、ネットワーク以外の多くの場所で適用できるため、カーネルのcBPFエンジンのリプレースは目標ではなかった。しかし当時は、この新しい技術をメインラインのカーネルに統合することが、実現可能だったのである。ここで、リーナス・トーバルズ氏の興味深い言葉を紹介しよう。

"私はクレイジーな人たちと一緒に仕事ができる、ぜんぜん問題なく。彼らは、おかしなことを、おかしなことではない論理で、小さく、うまく定義して私に売り込まないといけない。私がキラー機能を求めるときは、彼らが推すものが、大多数の人々の役に立つという、安全でうっとりするお花畑に、私を誘い込んでほしいのである。つまり、新しいクレイジーな機能はすべて、一見して明らかに良さそうなもの、つまり"トロイの木馬"のような素敵な贈り物に隠されているべきなのだ。"

これはつまり、Linuxカーネルの開発モデルの"有機的"な性質を表しており、eBPFがカーネルにマージされた方法と完全に一致する。漸進的な改良をするためには、まずカーネル内のcBPF基盤を置き換えて性能を向上させ、その基盤の上に新しいeBPF技術を公開・改良していくのが自然な流れだった。そこから、eBPFの初期は、ネットワーキングとトレーシングという2つの方向で並行して進化していった。カーネルにマージされたeBPFの新機能はすべて、これらのユースケースに関する具体的な実用上の必要性を解決するものだったのである。bccbpftraceCiliumなどのプロジェクトは、エコシステムが軌道に乗り、主流になるずっと前から、eBPFインフラの中核となるビルディングブロックを形成するのに貢献した。今日、eBPFは、カーネルのような特権的なコンテキストでサンドボックス化されたプログラムを実行できる汎用技術であり、もはや"BSD"、"パケット"、"フィルタ"とはほとんど共通点がない。eBPFは単に、ユーザーのニーズに応じて安全に拡張し調整するオペレーティングシステムカーネルの技術革新を指す疑似略語である。

複雑かつ安全なプログラムを実行できるようになったことで、eBPFは、Linuxカーネルをより上位のスタックからクラウドネイティブのコンテキストで強化し、優れたポリシー決定の実行、効率的なデータ処理、ソースに近い操作、速い反復と革新のための強力なプラットフォームとなった。つまり、カーネルの変更に伴うパッチ適用、再構築、ロールアウトの代わりに、インフラエンジニアとのフィードバックループを減らし、サービスを再起動してデータ処理を中断することなく、eBPFプログラムをその場で更新できるようになった。 eBPFの多機能性は、セキュリティ、オブザーバビリティ、トレーシングといったネットワーク以外の分野でも採用され、システムイベントをリアルタイムで検出・分析するために使用できるようになったのである。

カーネルの実験と進化を加速させる

cBPFからeBPFに移行することで、何が可能か、そして次に何を構築するかは、劇的に変化した。eBPFは、単なるパケットフィルタから汎用サンドボックス型ランタイムに移行することで、ネットワーキング、オブザーバビリティ、セキュリティ、トレース、プロファイリングに関する多くの新しいユースケースを広げたのだ。eBPFは今やLinuxカーネル内の汎用計算エンジンで、Webブラウザのプラグインのようにカーネルで起こっているあらゆることにフックし、観測し、対処できる。いくつかの重要な設計上の特徴により、eBPFはイノベーションを加速させ、クラウドネイティブの世界向けに、より高性能でカスタマイズ可能なシステムを作成できるのだ。

まず、eBPFはカーネルのソースを変更することなく、カーネルの任意の場所をフックして機能を変更し、その動作をカスタマイズできる。ソースコードを変更しないことで、eBPFはユーザーが新機能を必要としてから実装するまでの時間を数年から数日に短縮できるのだ。というのも、Linuxカーネルは何十億ものデバイスに幅広く採用されているため、軽々しく変更はできない。例えば、アプリケーションを観察する必要があり、そのための指標をカーネルから引き出したい。この場合、まずカーネルコミュニティ全体を説得し、それが良いアイデアであり、Linuxを利用しているすべての人にとって良いアイデアであることを理解してもらわないといけない。eBPFを使えば、マシンを再起動することなく、コーディングから観察まで行うことができ、他のユーザーに影響を与えることなく、カーネルを自分の特定のワークロードの要件に合わせて調整できる。"eBPFは非常に有用であり、その真の力は、求められるまで有効化されない特殊なコードを、いかに人々が行えるようにするかということだ"とリーナス・トーバルズは述べている。

 

ebpf-1

ebpf-2

第二に、verifierがプログラムの実行を安全にチェックするため、eBPFの開発者はカーネルのクラッシュやその他の不安定要素を心配することなく、イノベーションを継続できる。これにより、開発者とエンドユーザーは、本番環境で活用できる安定したコードを自信を持ってデリバリできるのだ。また、プラットフォームチームやSREにとっては、本番環境で遭遇した問題を安全にトラブルシューティングするためにeBPFの利用も重要である。

アプリケーションが本番稼動する準備が整えば、ワークロードの中断やノードの再起動なしに、eBPFプログラムを実行できる。これは、プラットフォームを最新の状態に保つために必要な労力を大幅に削減し、ロールアウトの失敗によるワークロードの中断のリスクを低減するため、大規模な作業において大きなメリットとなる。 eBPFプログラムは、ネイティブに近い実行速度でJITコンパイルされており、ユーザー空間からカーネル空間へとコンテキストをシフトすることにより、ユーザーはカーネルの不要な部分や使用しない部分をバイパスまたはスキップし、パフォーマンスを向上できる。しかし、ユーザー空間でカーネルを完全にバイパスするのとは異なり、eBPFは車輪の再発明をすることなく、カーネルのインフラとビルディングブロックをすべて活用できる。eBPFはカーネルの最適な部分を選び、それらをカスタムビジネスロジックと組み合わせて、特定の問題を解決することが可能だ。最後に、実行時にカーネルの動作を変更し、スタックの一部をバイパスできるため、開発者にとって極めて短いフィードバックループが生まれる。これにより、ネットワークの輻輳制御やカーネルのプロセススケジューリングといった分野での実験がようやく可能になったのである。

従来のパケットフィルタから脱却し、従来のユースケースから大きく飛躍することで、リソース活用の最適化からカスタマイズされたビジネスロジックの追加まで、カーネルに多くの新しい可能性が生まれた。eBPFによって、カーネルイノベーションのスピードアップ、新しい抽象化、パフォーマンスの飛躍的向上が可能になる。eBPFによって、運用ワークロードへの新機能追加にかかる時間、リスク、オーバーヘッドの削減だけでなく、場合によっては最初の段階でもそれは可能である。

Google、Meta、NetflixにおけるeBPF

「eBPFが現実の世界で実現できるのか」という問いの答えは、多くのメリットがあるため、「イエス」である。MetaとGoogleは世界最大級のデータセンターを持ち、Netflixはインターネットのトラフィックの約15%を占めている。これらの企業はそれぞれ、何年もeBPFを実際に運用しており、その結果はおのずと明らかである。

Metaは、ロードバランサープロジェクトKatranでeBPFを大規模に本番稼働させた最初の企業である。2017年以降、Metaのデータセンターに入るすべてのパケットはeBPFで処理されている。Metaはさらに多くの高度なユースケースにeBPFを使用しており、最近ではスケジューラの効率を向上させ、スループットを15%向上した。これは彼らの規模では大規模なブーストとリソース節約になる。GoogleもデータセンターのトラフィックのほとんどをeBPFで処理し、ランタイムセキュリティとオブザーバビリティのために使用している。また、Google Cloudのユーザーは、ネットワークにeBPFベースのデータプレーンを使用するようにデフォルト設定されている。モバイルデバイスの70%以上を占め、190カ国で25億人以上のアクティブユーザーを抱えるAndroid OSでは、ほぼすべてのネットワークパケットがeBPFを使用している。そうしてNetflixは、自社の性能監視と分析にeBPFを広く利用している。Netflixのエンジニアは、bpftraceなどのeBPFツールのパイオニアとして、本番サーバーのトラブルシューティングの可視性を大きく飛躍させ、On-CPUおよびOff-CPUフレームグラフ用のeBPFベースのコレクターを構築しているのだ。

eBPFは明らかに機能し、インターネットでスケールする企業にとって広範なメリットを示している。そして実は、10年以上前からずっとそうだった。

eBPF (R)evolution: クラウドネイティブのスピードとスケールを可能にする

クラウドネイティブ時代の初期には、GIFEE(Google Infrastructure for Everyone Else)という言葉が流行ったが、誰もがGoogleであったり、Googleのインフラを必要としているわけではないことから、現在はほとんど使われなくなった。そのかわりに、人々は自分の問題を解決するシンプルなソリューションを求めている。クラウドネイティブ環境は、「スケーラブルなアプリケーションを最新のダイナミックな環境で実行する」ことを目的としているのだ。スケーラブルとダイナミックは、どうしてeBPFがクラウドネイティブ革命に必要なカーネルの進化なのかを理解するキーワードなのである。

クラウドネイティブプラットフォームを構築するための基盤として、例によってLinuxカーネルがある。アプリケーションは今、データソースとシンクとしてソケットを使い、通信バスとしてネットワークを使うだけである。しかし、クラウドネイティブには、現在利用可能なLinuxカーネルに新しい抽象化が必要だ。なぜなら、cgroups(CPU、メモリ処理)、名前空間(net、mount、pid)、SELinux、seccomp、netfiler、netlink、AppArmor、auditd、 perfといったこれらの構成要素は、クラウドに名前がつく前から何十年も前から存在しているからだ。また、柔軟性に欠け、グローバルなポリシーしか設定できず、コンテナ単位やサービス単位のポリシーが設定できないものもある。新しいクラウドネイティブの基本要素を活用するかわりに、Podやより高度なサービスの抽象化に対する認識がなく、ネットワークはiptablesに依存しているのだ。

プラットフォームチームとして、クラウドネイティブ環境の開発者ツールを提供したくても、クラウドネイティブ環境が効率的に表現できないこの仕組みから抜け出せないでいるかもしれない。適切なツールがないために、将来的にチームが課題に対応できくなくなる可能性だってあるのだ。eBPFでは、Linuxカーネルの抽象化を一から再構築するツールが登場した。これらの新しい抽象化は、クラウドネイティブ・イノベーションの次の潮流の先駆けとなり、クラウドネイティブ革命の道を切り開くだろう。

たとえば、従来のネットワーキングでは、パケットはカーネルで処理され、ネットワークスタックのいくつかのレイヤーが各パケットを検査してから目的地に到達する。このため、特に多くのネットワークパケットを処理する大規模なクラウド環境では、オーバーヘッドが大きく、処理時間がかかる。eBPFでは、かわりにカスタムコードをカーネルに挿入し、ネットワークスタックを通過する各パケットに対して実行できるのだ。これにより、効率的で的を絞ったネットワークトラフィック処理が可能となり、オーバーヘッドの削減とパフォーマンスの向上が実現する。Cilium社のベンチマークによると、iptablesからeBPFに切り替えるとスループットが6倍になり、IPVSベースのロードバランシングからeBPFベースに切り替えると、Seznam.czはCPU使用率を72分の1に削減しながらスループットは2倍になった。eBPFは、旧来の機能をわずかに改善するのではなく、飛躍的に向上できるのである。

eBPFは、前身のcBPFのようにネットワークにとどまらず、汎用的なコンピューティング環境であり、カーネルのどこにでもフックできることから、オブザーバビリティやセキュリティなど、さまざまな分野に活用されている。"Cloud Native Computing Foundation "のCTOであるChris Aniszczyk氏は、"eBPF技術は、これまで困難だったカーネルへの可視化を可能にする新しい強力な方法なので、クラウドネイティブセキュリティの未来は、この技術をベースにしていく。アプリケーションとインフラの監視、そしてセキュリティ監視の交差する場所で、チームが問題をより早く検出、軽減、解決するための総合的なアプローチを提供可能だ"と述べている。

eBPFは、クラウドネイティブのスピードとスケールでアプリケーションを接続、観察、保護する方法を提供する。IsovalentのCEO兼共同創業者であるDan Wendlandt氏は、"アプリケーションがクラウドネイティブパラダイムによるAPI駆動型サービスの集合体へと移行するにつれ、すべてのアプリケーションのセキュリティ、信頼性、オブザーバビリティ、パフォーマンスは、eBPFによる新しい接続層に根本的に依存するようになった。新しいクラウドネイティブインフラのスタックにおいて、重要なレイヤーとなるだろう"と発言している。

eBPF革命がクラウドネイティブを変えつつある。そして素晴らしいことに、すでにeBPFは存在しているのだ。

すでにプラットフォームの一部で始まっている静かなるeBPF革命

eBPFの利点は明確だが、Linuxカーネル開発の経験がないプラットフォームチームにとっては、親切なインターフェイスが必要である。これがeBPFの魅力的なところだ。というのも、今日のクラウドネイティブプラットフォームを動かすツールの多くにすでに組み込まれており、知らないうちに活用されている可能性があるからだ。主要なクラウドプロバイダーでKubernetesクラスタをスピンアップすれば、Ciliumを通じてeBPFを利用していることになる。観測可能なPixieや継続的なプロファイリングを行うParcaもeBPFを利用しているのだから。

eBPFは、ソフトウェア業界を変革する強力な力である。マーク・アンドリーセン氏の有名な言葉である「software is eating the world」は、Cloudflareによって 「eBPF is eating the world」と半ば冗談に言いかえられた。しかし、eBPFの成功は、すべての開発者がeBPFを知ることではなく、高速なネットワーク、容易なモニタリングとオブザーバビリティ、使いやすいセキュリティソリューションを求めるようになることにある。eBPFは、Linuxカーネルにコードをアップしたり、Linuxカーネルモジュールを書いたりするときではなく、デベロッパーエクスペリエンスを大幅に向上させるさまざまなプロジェクトや製品が登場したときに、完全に普及したことになる。私たちは、すでにその実現に向けて大きく前進しているのだ。

eBPFは、インフラストラクチャー・プラットフォームの構築方法に革命をもたらし、以前は実装が困難または不可能だった多くの新しいクラウドネイティブのユースケースを可能にした。eBPFにより、プラットフォームエンジニアはLinuxカーネルの機能を安全かつ効率的に拡張できるようになり、迅速なイノベーションが可能になったのだ。これにより、クラウドネイティブの世界の需要に合わせた新しい抽象化と構成要素の作成が可能になり、開発者がソフトウェアをスケールアップして展開することが容易になったのである。

eBPFは最大規模で半世紀以上にわたって運用されており、カーネルを動的にプログラムする安全で性能の高い、スケーラブルな方法であることが証明されている。静かなるeBPF革命は定着し、すでにクラウドネイティブエコシステムを中心としたプロジェクトや製品で使用されているのだ。eBPFにより、プラットフォームチームは、スケーラブル、ダイナミック、可用性、高性能な環境のプロビジョニング、接続、監視、セキュリティの確保が可能になり、開発者はビジネスロジックのコーディングだけに集中できるようになるなど、次のクラウドネイティブ時代の幕開けへの準備が整っている。

作者について

この記事に星をつける

おすすめ度
スタイル

BT