OTel コンポーネントのパフォーマンスベンチマーク
Blog posts are not updated after publication. This post is more than a year old, so its content may be outdated, and some links may be invalid. Cross-verify any information before relying on it.
ますます多くのユーザーが本番環境で OpenTelemetry の計装を使おうとしている中、重要な検討事項の1つは、OpenTelemetry がアプリケーションのパフォーマンスに与える影響です。 このブログ記事では、パフォーマンスベンチマークに関するツールの最近の改善点についていくつか紹介します。
パフォーマンスオーバーヘッドの測定
計装は無料ではありません。 アプリケーションの操作をインターセプトし、（多くの場合）大量のデータを収集するため、追加の CPU とメモリを消費します。 これはスループットとレスポンスタイムに直接的な影響を与え、アプリケーションのエンドユーザー体験に影響する可能性があります。 また、サービスが実行されるインスタンス数の増加など、運用コストにも影響を与える可能性があります。
パフォーマンスオーバーヘッドに関する一般的なガイダンスを提供することは本質的に困難です。 パフォーマンスに影響を与える要因は多数あります。 アプリケーションのスループット、アプリケーションが実行されるハードウェア、正確に何が計装されているか、OpenTelemetry SDK の設定、サンプリングなどです。 最終的に、パフォーマンスを測定する最善の方法は、特定のアプリケーションのコンテキストにおいて負荷テストを実行することです。
とはいえ、多くの OpenTelemetry コンポーネントにはリグレッションを検出し、パフォーマンス特性をある程度把握するために使用できるパフォーマンステストが含まれています。
OpenTelemetry Collector
OpenTelemetry Collector は、main ブランチへのマージごとにエンドツーエンドの負荷テストを実行しています。 CI ワークフローには最近2つの更新がありました。
- テストはコミュニティ所有のベアメタルマシンで実行されるようになり、テスト結果がより一貫したものになりました。
- テスト結果は自動的に公開されるようになりました。 負荷テスト結果の一部については、Collector Benchmarks を参照してください。 完全なテスト結果も利用可能です。
言語 SDK
多くの OpenTelemetry SDK には、既存のマイクロベンチマークテストがすでに含まれています。 たとえば以下のようなものがあります。
これらのテストは以前はオンデマンドでのみ実行されていました。 最近のツールの改善により、Java と JavaScript のテストは main ブランチへのマージごとに自動的に実行されるようになり、結果は誰でも簡単にアクセスできるように公開されています。 テストはコミュニティ所有のベアメタルマシンでも実行されているため、結果は可能な限り一貫したものとなっています。
Sample benchmark results for Java
Python と Go についても同様の更新を行う作業が進行中です。
まとめ
パフォーマンスの最適化は後付けとしてのみ考えられることが多いですが、そうである必要はありません。 プロジェクトのメンテナーとコミュニティに、開発中に実施できる信頼性の高いパフォーマンステストを提供するために、自動化ツールとドキュメントの改善を進めています。 コミュニティとしての最終的な目標は、エンドユーザーが私たちのコンポーネントを使用する際に、特に OpenTelemetry の計装がアプリケーションのパフォーマンスに与える影響について、安心して使えるようにすることです。