[レポート] 「eBPFってなんだ?」というタイトルの New Relic のセッションを聴講しました #devio2022

[レポート] 「eBPFってなんだ?」というタイトルの New Relic のセッションを聴講しました #devio2022

「eBPF...? はじめて聞いたな...」「聞いたことあるけど、何に使えるのか...そもそも New Relic とどんな関係が ?」そんな方にぴったりのセッションが DevelopersIO 2022 っていうイベントで公開されていたのでレポートします!
Clock Icon2022.07.30

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

eBPF ってご存じでしょうか!(挨拶

eBPF はざっくりいうと、アプリケーションを含む Linux OS 内の動作を横から観測できる仕組みで、近年注目されることも多くなった技術です。最近 (?) Windows がサポートを開始したことも、記憶に新しいかたもいらっしゃるかと。

その仕組み上、セキュリティや開発(デバッギング)目的に使われることも多いですが、可観測性 (オブザーバビリティ) 目的としてみても非常に強力なものです。
本セッションはその可観測性プラットフォーム製品である New Relic が eBPF とどう関係しているか、 24 分ほどのスリムなセッションで、デモを交えてがっつり説明して頂けました。

なお、クラスメソッドがお送りする DevelopersIO 2022 イベントの全セッションはこちらから参照可能です:

以下、簡単にレポートします。

動画 (24 分)

YouTube で公開されています。

  • 00:00 オープニング
  • 00:39 アジェンダ
  • 01:33 eBPFとは?
  • 07:36 なぜeBPF?
  • 11:20 eBPFで動くOSSたち
  • 15:28 New RelicとeBPF(デモ有)

よければチャンネル登録 ? ・好評価 ? よろしくお願いします!1

レポート

登壇者は New Relic 株式会社の Yuzuru Ohira さまです。

対象者とゴール

  • 対象者
    • eBPF という言葉をはじめて聞いたひと
    • ちょっと興味があるひと
  • あまり込み入った実装の話はしない
    • どんな技術で、どんなことができるかの話

eBPF とは?

  • Linux カーネルの機能
  • カーネルイベントをフックし、カーネルに手を加えることなく情報の収集ができる
    • ネットワーク
    • セキュリティ
    • オブザーバビリティ
  • ゲームチェンジャと言える強力な技術
  • 最初のアイディアは 1992 年(結構古い)
    • 登壇者が生まれる前!
    • eBPF は最初のアイディア(cBPF)の拡張
  • 最初の実装は 2014 年(Linux Kernel 3.18)
  • コンパイラが 2015 年に開発され利用しやすくなった
  • あらゆるレイヤの分析が可能
    • 様々な言語で書かれたアプリ、MySQL の Raw data、OS のシステムコール、ネットワーク 等々
    • かなり夢のある技術

BCC - Tools for BPF-based Linux IO analysis, networking, monitoring, and moreより引用)

  • eBPF Foundation(団体)が設立されている
    • eBPF Foundation
    • 多くのテック企業が参加し投資する下地がある
  • アーキテクチャ
    • イベントドリブン
    • 何かのシステムコールなどのイベントに対して eBPF のフックを仕込んでおいて情報を収集する
    • ユーザーが書いたコード、ユーザー空間で実行される
    • Verifier がカーネル空間で動作し eBPF プログラムを解析
      • 脆弱性やセキュリティホールなどから保護する
    • 情報の保存 --> eBPF Map

なぜ eBPF? / Why eBPF?

  • 従来の(カーネルに機能を拡張するための)アプローチはハードルが高いところがあった
    • カーネルのネイティブサポート
      • カーネルへのコミット
      • コミュニティ承認が必要でリリースプロセスに数年単位でかかる
    • カーネルモジュール
      • カーネルバージョンに追随する長期メンテナンスが必要
      • 自由度が高すぎる、カーネルクラッシュ
  • eBPF はカーネルの挙動を変えない = コミュニティ対応を待つ必要ない、安全
  • 「eBPF が Linux へ (対して) 行うことは、Javascript が HTML に (対して) 行ったことと同じである。」
    • Brendan Gregg, "BPF Performance Tools"

eBPF で動く OSS たち / eBPF Projects

  • cilium
    • eBPF ベースの CNI
    • GKE や EKS Anywhere のデータプレーンで利用
    • Pod 感の通信パフォーマンス向上を実現
    • Service Mesh などへの利用も進んでいる(現在は beta)
  • Hubble
    • cilium 上に構築
    • Hubble UI という Service Map が特長
      • サービス間の依存関係を可視化可能
    • アプリケーションレベルのネットワーク通信問題の特定
      • レイテンシなど
    • ネットワークセキュリティ分野でも
  • Tetragon
    • cilium 関連プロジェクト、セキュリティ特化
    • k8s のセキュリティイベントを検出
    • OPA(Open Policy Agent)定義
  • つまり
    • eBPF は未来の技術ではなく、いま使えるもの

New Relic と eBPF の関わり

Auto-telemetry with Pixie for instant Kubernetes observability | New Relic Documentation

  • Pixie by New Relic
    • k8s の観測ツール
    • eBPF を利用しクラスタ内の情報を収集
      • 導入不要(No Instrumentation)
      • HTTP, JVM, MySQL etc...
    • リアルタイムに現状を表示(Live UI)
  • 従来からもっていた k8s 観測機能との違い
    • Pixie : 開発・検証・デバッグ向き
      • 追加設定・コード修正不要
      • アラートなし、データ保持期間 24h
    • New Relic : 運用監視向き
      • 詳細な連携、k8s events / logs
      • アラート機能、ふるまい検知、データの長期保存(最大 13 ヶ月)
    • 両者を掛け合わせることで、開発から運用まで依りよい k8s の可観測性を実現出来る

  • 組み込み方法
    • Helm
    • AWS CDK(新規構築のみ)

DEMO

※実際に Pixie を動作させてのデモとなります。是非動画でご覧ください!

  • クラスタ全体
    • サービスの依存関係、Pod の状態など一覧

  • TCP ドロップ
    • クラスタ内で検索・可視化
    • どこからどこまで(テーブル形式)

  • MySQL のデータ
    • レイテンシやクエリ
    • 開発中のパフォーマンスチューニングなどに

  • それぞれの Pod の状態
    • Profiling

  • New Relic へのデータ転送も可能
    • OpenTelemetry 形式
    • サービスの依存関係、トランザクション、ログなどを中長期的に観測
    • 従来の New Relic と変わらない使い勝手

まとめ

  • eBPF は Linux カーネルの挙動を変えずに情報を取得出来る技術
  • ネットワークや可観測性、セキュリティなど広い分野で使用される
  • 今後は重要なサービスの裏側で当たり前のように動くものになるのでは
    • そうなることを祈っている
  • [PR]
    • New Relic は無料枠もあるので使ってみて!
    • We are hiring!

所感とまとめ

可観測性界隈やセキュリティ界隈をウォッチしていて、最近よく聞くようになった「eBPF」。その実態から応用まで網羅的に知識が得られるセッションでした。Pixie の実際に動いているところをデモで見られたのもうれしいです。

OSS の例をみていると k8s や CNCF 界隈で積極的に応用が進んでいるようなので、これらを使われている方々は要チェックですね。確かに登壇者の Ohira さんの発言の通り、ゆくゆくは特に意識する必要のない(でも裏で支えてくれる)基幹要素技術になるとぼくも思いますが、しばらくは注目しておくと面白いキーワードなのかなと思ってます!

ちなみにセッションとは関係無いんですが、eBPF のサイトをみていて「eBPF は何かの略称ではない (which is no longer an acronym for anything)」という知見が得られました2。まじか。。。

なお弊ブログでも eBPF に関連した記事がいくつか掲載されているので、もし興味があればそちらもご参照下さい!

脚注


  1. 一度いってみたかっただけなので他意はありません 
  2. WikipediaによるとeBPFがBPF(Berkeley Packet Filter)のextendedバージョンとして開発されたのは確かみたいなんですが、どこかのタイミングでそうされたようです。なんとなくQUICを思い出す事象ですが、このケースはおそらくeBPFがもはやパケットフィルタのためだけではないからなのかなと思いました 

Share this article

facebook logohatena logotwitter logo

© Classmethod, Inc. All rights reserved.