## Memo
## Memo with LLM
### 論文情報
- **論文のタイトル**: eProbe: eBPF-Enhanced Accurate Container Status Probing in Cloud-Native Systems
- **著者と所属**: Wanqi Yang, Pengfei Chen (Sun Yat-sen University, School of Computer Science and Engineering, Guangzhou, China)
- **カンファレンス/ジャーナル名**: IEEE Transactions on Services Computing (TSC)
- **発表年**: 2025年（Volume 18, Number 4, July/August 2025）
### 論文概要
クラウドネイティブシステムにおいて、既存のKubernetesプローブでは部分的にしか実現できないコンテナ状態の正確な監視を、eBPF（extended Berkeley Packet Filter）ベースの非侵襲的リアルタイムプロービングシステム「eProbe」で実現する。従来のプローブの限界を克服し、より精密で詳細なコンテナ監視により、トラフィックスケジューリングエラーやアプリケーション障害の防止を目指している。
### 詳細解説
#### 問題設定
**入力**: クラウドネイティブシステム内のコンテナ群とその動作状況
- パケット通信情報（送受信パケット数、応答時間等）
- TCP接続情報とHTTP/MySQLリクエストの応答情報
- システムコール情報（tcp_set_state等）
**出力**: コンテナの正確なリアルタイム状態（Ready/Non-ready）
- 詳細な障害原因情報の提供
- Kubernetesプローブの結果制御による正確な状態報告
**必要なデータ**:
- カーネルレベルでのパケット傍受データ
- 応答比率（#send/#recv）、応答時間、接続数（#conn）、エラー率（#error/#total）
#### 提案手法
eProbeは3つの主要モジュールで構成される：
**1. メトリックコレクター**
- eBPFプログラムをContainer Network Interface（CNI）にアタッチし、全コンテナのトラフィックを傍受
- 4つの主要メトリックを収集：
- 応答比率 = #send/#recv
- 応答時間 = trecv - tsend
- 接続数（tcp_set_state フックで監視）
- HTTP/MySQLエラー率 = #error/#total
**2. 状態ジャッジ**
- DDSketchベースの分位数スケッチを用いて応答時間の分布を推定
- 現在の時間窓でのP50が前の時間窓のP90を超える場合に非準備状態と判定
- 判定式：
```
Status(si) = {
NotReady, if Index(P50curr) ≥ Index(P90prev)
NotReady, if #sendi/#recvi ≤ η1 (η1=0.5)
NotReady, if #conni ≥ η2 (η2=500)
NotReady, if #errori/#totali ≥ η3 (η3=0.5)
Ready, else
}
```
**3. 状態エクスポーター**
- XDPプログラムでプローブパケットを傍受・識別
- HTTPプローブ: ステータスコードを200→500に変更
- TCPプローブ: SYNパケットに対するACK応答をドロップ
#### 新規性
**従来研究との差別化**：
1. **カーネル内メトリック収集**: ユーザ空間ではなくカーネル空間での効率的な監視
2. **非侵襲的統合**: 既存のKubernetesプローブシステムを変更せずに機能拡張
3. **リアルタイム精密監視**: パケットレベルでの詳細な状態監視により、従来プローブでは検出困難な障害を発見
4. **分位数スケッチ手法**: eBPFの制約下での効率的な統計計算手法の導入
#### 実験設定
**環境**: 5台のVM構成Kubernetesクラスタ（Ubuntu 18.04、Linux kernel 5.10.85）
- 各VM: 8GB RAM、40GB disk、32-core 2.80GHz Intel Xeon Gold 6242
**評価アプリケーション**:
- [[Sock Shop]]（carts、catalogue、orders、frontend、catalogue-db）
- [[Bookinfo]]（productpage）
- [[Nginx]]
**障害パターン（5種類）**:
1. データベース障害（[[MySQL]]）
2. コンテナ内部障害（HTTP 500エラー）
3. エージング障害（応答時間遅延）
4. 無応答障害（パケットドロップ）
5. 過剰接続障害
**評価指標**: 検出精度、検出時間、リソースオーバーヘッド（CPU、メモリ）、応答時間への影響
#### 実験結果
**検出精度**:
- eProbe: 全障害パターンで100%検出成功
- Kubernetesプローブ: 一部障害のみ検出（特に過剰接続時のみ部分的検出）
**検出時間**:
- eProbe: 3.29秒（過剰接続障害）
- Kubernetesプローブ: 42.8秒以上
**システムオーバーヘッド**:
- CPU使用率増加: 0.22%-0.33%
- メモリ使用率増加: 0.03%-0.26%
- 応答時間増加: 2.48%（最大）
**スケーラビリティ**: 1200並行ユーザまで安定動作、18レプリカまでテスト済み
**閾値影響分析**: η1とη3が検出時間に大きく影響、η2と時間窓は相対的に小さな影響
## Abstract
クラウドネイティブシステムは、コンテナを活用することでスケーラビリティと可用性を向上させます。コンテナの管理とスケジューリングを改善するため、既存のコンテナ管理システム（例：[[Kubernetes]]）は、コンテナの状態を監視するためにレディネスプローブとライブネスプローブを採用しています。しかし、これらのプローブシステムにおける障害は、リアルタイムプローブの問題や実装上のバグにより、トラフィックスケジューリングエラー、アプリケーションの障害、またはクラスターのクラッシュを引き起こす可能性があります。これらの課題を解決するため、私たちは[[eBPF]]（拡張バークレーパケットフィルター）を基盤とした非侵襲的なリアルタイムコンテナ状態プロービングシステム「eProbe」を提案します。eProbeは、既存のコンテナ管理システムに追加のインストルメンテーションや変更を加えることなく、コンテナを通過するパケットをインターセプトし、オペレーティングシステムカーネル内でリアルタイムにコンテナの状態をプローブします。評価結果によると、eProbeはコンテナの状態を正確にプローブできるのに対し、Kubernetesのプローブは部分的にしか実現できません。さらに、eProbeは低オーバーヘッドを実現し、追加メモリ消費は0.03%から0.26%、追加CPU使用率は0.22%から0.33%に抑えられ、クラウドネイティブアプリケーションの応答時間に2.48%の増加を伴います。