## Memo ## Memo with LLM ### 論文情報 - **論文のタイトル**: eBPF-Based Instrumentation for Generalisable Diagnosis of Performance Degradation - **著者と所属**: - Diogo Landau: PhD candidate at the Department of Information and Computing Sciences, Utrecht University, Netherlands - Jorge Barbosa - Nishant Saurabh - **発表先**: arXiv preprint arXiv:2505.13160 - **発表年**: 2025年 ### 論文概要 本論文は、オンラインデータ集約型アプリケーション（メッセージブローカー、ML推論、データベースなど）における性能劣化の原因診断を目的とした、アプリケーション非依存の細粒度な16のeBPFベースメトリクスを提案している。これらのメトリクスは6つのカーネルサブシステム（スケジューリング、仮想ファイルシステム、ネットワーキング、futex、多重化IO、ブロックIO）にわたり、ロック競合、ディスク競合、CPU競合、サービス依存性の問題を特定することを可能にする。 ### 詳細解説 #### 問題設定 **入力**: オンラインデータ集約型アプリケーション（データベース、メッセージブローカー、ML推論サービスなど） **出力**: 性能劣化の根本原因の特定（ロック競合、ディスク競合、CPU競合、外部依存性など） **必要なデータ**: カーネルレベルのシステムメトリクス、スレッド単位のリソース利用統計、スレッド間通信パターン 従来の手法は、procファイルシステムから取得できる粗粒度なシステムメトリクスに依存しており、性能劣化の詳細な原因（例：特定のロック競合、スレッド単位のリソース待機）を特定できない課題があった。 #### 提案手法 **16のeBPFベースメトリクス**を6つのカーネルサブシステムにわたって実装： 1. **スケジューリング**: runtime（CPU実行時間）、rq_time（ランキュー待機時間）、block_time（割り込み不可スリープ時間）、iowait_time（IOスリープ時間）、sleep_time（割り込み可スリープ時間） 2. **パイプ・ソケット**: pipe_wait_time/count（パイプ待機時間・頻度）、socket_wait_time/count（ソケット待機時間・頻度） 3. **Futex**: futex_wait_time/count（futex待機時間・頻度）、futex_wake_count（futex起床頻度） 4. **多重化IO**: epoll_wait_time/count（epoll待機時間・頻度）、epoll_file_wait（epollファイル待機時間） 5. **ブロックIO**: sector_count（スレッド単位のセクター要求数） **Backing Resource Identifier (BRI)**という概念を導入し、ファイルディスクリプタが指す実際のリソース（パイプ、ソケット、futexなど）を一意に識別する。これにより、複数のスレッドが同一リソースを共有している場合でも正確な追跡が可能。 **選択的スレッド追跡**により、エントリーポイントスレッドから開始して、IPC機構（パイプ、ソケット、futex）を通じて通信するスレッドのみを追跡することで、解析範囲を効率的に絞り込む。 #### 新規性 1. **細粒度性**: 従来研究がプロセスレベルやシステムワイドな統計に留まっていたのに対し、スレッド単位かつリソース単位での詳細な統計を収集 2. **汎用性**: 特定のアプリケーション（NoSQLデータベースのみなど）に限定されず、様々なオンライン データ集約型アプリケーションに適用可能 3. **包括性**: 6つの主要カーネルサブシステムを網羅し、多様な性能劣化シナリオに対応 4. **効率性**: eBPFの安全な実行環境を活用し、カーネルパニックのリスクなしに本番環境での利用が可能 #### 実験設定 **データセット**: 7つの代表的なオンラインデータ集約型アプリケーション - **データベース**: MySQL（リレーショナル）、Apache Cassandra（NoSQL） - **インメモリストア**: Redis - **メッセージブローカー**: Apache Kafka - **検索サービス**: Apache Solr - **マイクロサービス**: TeaStore - **ML推論サービス**: FastAPI + gunicornによる感情分析モデル **負荷生成**: YCSB、TPCC、Cloudsuite、memtier、Locustなどの標準ベンチマークツールを使用 **劣化シナリオ**: - ベンチマークによる負荷増加（飽和点まで） - リソース競合（CPU不足、ディスク競合、ロック競合）の人工的な誘発 **評価指標**: アプリケーション固有のKPI（レスポンス時間のパーセンタイル、スループットなど） **実験環境**: i7-11850H Intel @ 2.50GHz、Ubuntu 22.04 LTS、Linux kernel 6.8.12 #### 実験結果 **[[MySQL]]**: - ディスク競合時：sector_countにより、MySQLのディスク要求シェアが80%から34%に低下することを特定 - ロック競合時：futex_wait_timeの増加（毎秒0msから測定可能なレベルまで）により、特定のfutexリソースでの競合を検出 **[[Apache Kafka]]**: - スループット劣化時：8つのスレッドプールでのblock_timeとfutex_wait_timeの異常な増加を特定 - epoll_file_waitの減少により外部プロデューサー接続の待機時間減少を観測 **Apache [[Cassandra]]**: - CPU競合時：rq_timeの大幅増加とsleep_timeの減少を観測 - ディスク競合時：予想に反してiowait_timeではなくruntimeの増加を観測（CPUキャッシュ競合が原因） **[[Redis]]、Solr、ML推論サービス**: いずれもCPU競合によるrq_timeの増加が性能劣化の主要因として特定 **[[2018__MASCOTS__TeaStore - A Micro-Service Reference Application for Benchmarking, Modeling and Resource Management Research|TeaStore]]**: 外部サービス（persistence service）への依存性によるsocket_wait_timeの増加（0.1秒から1.0秒）を検出 **オーバーヘッド評価**: 計装によるレイテンシ増加は1-4%程度で、Redis・MySQLで最大、Kafka・Cassandraで最小 すべての劣化シナリオにおいて、提案メトリクスの少なくとも1つが性能劣化の原因を正確に特定することに成功。特に、従来手法では困難だったスレッドレベルでの詳細な根本原因分析を実現した。 ## Abstract オンラインデータ集約型アプリケーション（例：メッセージブローカー、ML推論、データベース）は、現代のインターネットの中核コンポーネントであり、接続サービスに重要な機能を提供している。これらが経験する負荷変動と干渉は、一般的にサービス品質（QoS）劣化の主要原因となり、依存アプリケーションに害を与え、エンドユーザー体験の悪化をもたらす。QoS劣化の原因を明らかにするには、アプリケーション活動の詳細な計装が必要である。既存の汎用的なアプローチは、カーネルメトリクスで干渉をエンコードする容易に利用可能なシステムメトリクスを活用するが、残念ながら、これらのアプローチは性能劣化の詳細な原因（例：ロック、ディスク、CPU競合）を特定するのに必要な詳細さを欠いている。これに対して、本論文では、アプリケーション非依存のQoS劣化診断を促進するために、細粒度システムレベルメトリクスの使用を探求する。この目的のため、我々は6つのカーネルサブシステムにわたる16のeBPFベースメトリクスを導入・実装し、アプリケーションの進行を阻害する障害をしばしば強調するカーネルイベントの統計を捕捉する。我々は、代表的なオンラインデータ集約型アプリケーションのセットを含む広範な実験を通じて、我々のeBPFベースメトリクスの使用を実証する。結果は、実装されたメトリクスが、アプリケーションが可変ワークロードパターンや一般的なリソース競合シナリオに直面した際の性能劣化を分解でき、同時にアプリケーションの内部アーキテクチャ制約も明らかにすることを示している。