eBPFのコードにベンチマークを組み込むBencherを解説する動画を紹介

2023年5月にシアトルで開催されたOpenSourceSummit North America 2023から、Everett Pompeii氏が行ったBencherの解説セッションを紹介する。この動画は「Run Fast! Catch Performance Regressions in eBPF with Rust」と題されたセッションンの録画だ。当日の最後のセッションとして行われたせいもあり、非常に良い内容にも関わらず参加者が非常に少ないという残念な状況でありながらも、丁寧に解説を行っている良いセッションだ。

OpenSourceSummit NA 2023で行われたセッション

セッションのタイトルには出てこないが、最後に紹介されるBencherはベンチマークテストを本番環境ではなくCIの中に組み込むべきだと言うPompeii氏の理想を形にしたオープンソースソフトウェアで、オンプレミスとクラウドサービスが提供されている。Bencherとは、Pompeii氏が創業した企業の名称でもある。開発から本番に至る途中のプロセスであるContinuous Integrationの中にプログラムのベンチマークを組み込むことをContinuous Benchmarkingと名付けて、本番環境で性能劣化を見つけるのではなく、またデベロッパーがローカル開発環境で開発するプロセスに組み込むのでもなく、ビルドとテストの中に組み込むことが最適だと言うのがPompeii氏のポイントだ。

●Pompeii氏による解説の動画：Run Fast! Catch Performance Regressions in eBPF with Rust

この約30分のセッションでは、Rustで書いたeBPFのプログラムに機能を追加しながらベンチマークを行うまでの解説に25分間を費やしており、eBPFのデベロッパー向けのイントロダクションとも言える内容になっている。そして、Pompeii氏が創業したベンチマークのためのオープンソースソフトウェアであるBencherの解説は、最後の5分程度という比率になっている。eBPFに興味があるデベロッパー向けにはステップバイステップでユーザー空間とカーネル空間で何が行われるのか？ を解説している。データの受け渡しの詳細、eBPFですでに実装されているフィルターの機能などにも触れているので、eBPFを組み込みたいと考えているデベロッパーには良いコンテンツだろう。

eBPFの構造を解説。ユーザー空間とカーネル空間でそれぞれコードが実行される

カーネルで実行されるコードはVerifierによって安全なコードかどうかを判定されるというのが、eBPFが安全であるという特徴のポイントだろう。

性能劣化は本番環境で発見されるのが従来の状況

そしてパフォーマンスリグレッション、つまり性能劣化について解説し、性能に問題があるコードはおおよそ本番環境でその現象が発見され、そこから過去へと辿るように「何がこの劣化の原因なのか？」を探る必要が出てくるという従来の手法に問題があるということを強調した。

Rustで書いたeBPFのコードを使って継続的ベンチマークまで解説

そしてその性能劣化を、実際にコードを見せてeBPFの動きを解説するが、その前にeBPFを実装する際のツールについて解説を行った。

RustでeBPFを記述する際のツールを解説

ここではlibbpf-rs、RedBPF、Ayaという3つのツールを紹介。完全にRustで記述されたeBPFライブラリーであるAyaを使って解説を行うと語った。

デモとして使われているアプリケーションの最初のバージョンはXDPを使ったアプリケーションで、通過するパケットからIPv4のアドレスだけをフィルターするために使われている。ここでIPv4に拘ったのはここからその数値（0から255）を使って処理を追加していくためだ。

ユーザー空間で実行されるRustコード

そしてバージョン3のアプリケーションではその数値が3の倍数ならFizz、5の倍数ならBuzz、3と5の公倍数ならFizzBuzz、フィボナッチ数と同じであればFibonacciと出力するプログラムに機能を追加するところを解説した。

フィボナッチ数を見つけるようにプログラムに機能追加

そしてこのコードを実際に本番環境で実装したところ性能劣化が発生したという想定で、ベンチマークを通じてこのコードを改善するという流れになった。ここからがお楽しみの部分ということで、フィボナッチ数を計算するコードを見せて、実際にこのアルゴリズムで行うよりも255以下の数値であれば、単純にパターンマッチしたほうが実行速度も速いということを示した。

Rustで書いたアルゴリズムよりもパターンマッチしたほうが速い

このスライドではフィボナッチ数を見つけるのに、すでに判明している255までのフィボナッチ数（1から233まで）をマッチさせるリストとして追加を行ってコードを書き直したということを示している。

そしてベンチマークにもミクロなものとマクロなものが存在することを説明し、このプログラムの例に従ってユニットテスト、統合テストの中でベンチマークを行うための設定ファイルやRustのビルドツールであるCargoのコマンドなどを示しながら、ベンチマークの仕方について解説を行った。

ベンチマークにおけるマイクロとマクロの違い

そしてベンチマークは本番環境でも開発環境でもなくCIの中で行うべきだという点を強調した。

ベンチマークはどこで行うべきか？を解説

そして残り5分というところでBencherの説明が始まった。セッションとしてはRustのコードで書いたeBPFの性能劣化をどうやって見つけるのか？ というのがメインであるために、それまでの25分間をeBPFとRustのコードの解説、ツールの解説に費やしたのは仕方がないにしても商売っ気がないエンジニア気質を感じる内容だ。

やっと始まったBencherの解説

Bencherはこれまで解説してきたプログラムのベンチマークを行うためのツールで、オープンソースソフトウェアとして公開されている。オンプレミスでの実装とクラウドサービスが提供されており、Bencherの企業としての収入源は主にそのクラウドサービス側の利用料ということだろう。

Bencherのダッシュボードの例。性能劣化がタイムラインとして可視化

またモダンなCI環境への対応という意味で、GitHub Actionsにも対応していることを訴求した。

GitHub ActionsでもBencherが利用可能に

そしてまとめとして、ベンチマークを本番環境からCIでの実装に早めることで性能劣化を発見するのではなく劣化を防ぐことにシフトできることを訴求した。本番では遅過ぎ、開発環境ではローカルでの実行でしかなく意味がないというのがそれを支える根拠ということになる。

CIにベンチマークを組み込む継続的ベンチマークを提唱

最後にBencherのリポジトリ、公式サイトを紹介して質疑応答に移った。

RustはPompeii氏が愛するプログラミング言語だということでRustに限定した解説だったが、Bencherそのものは多言語に対応し、閾値の設定なども可能などシンプルながらも充分な機能を持っているように見える。ただし性能劣化に対するソリューションはアプリケーションパフォーマンス管理（APM）が存在し、すでにAppDynamicsやNew Relic、Datadogなどプレイヤーが多い領域でもある。コードにベンチマークのコードを組み込むマイクロベンチマークの手法がどれだけデベロッパーに訴求するのかは未知数だろう。eBPFについても、ユーザー企業はまだ応用分野を模索しているという段階で、Bencherがこの先、どのように変化していくのか注目したい。

最後のセッションということで参加者が少ないのが非常に残念だ

●公式サイト：Bencher - Continuous Benchmarking
●リポジトリ：GitHub: https://github.com/bencherdev/bencher