> [!abstract] 概要(ACM abstract の日本語訳) > 現代のコンテナ化された分散システム(ビッグデータストレージ・処理スタックやマイクロサービスベースのアプリケーションなど)の性能における重要な問題は、各コンテナ(またはコンテナポッド)を仮想・物理サーバーに配置することである。アプリケーション間のトラフィックが配置決定の重要な要因であること(コンポーネントの相互作用を直接示すため)は示されているが、アプリケーションに依存しない方法でこれを正確にモニタリングすることは不可能であり、クラウドプラットフォームの手の届かない問題となっている。本論文では、さまざまな目的(適応的配置を含む)で問い合わせ可能な、分散システム内の協調プロセスの重み付き通信グラフを検知・構築する効率的なブラックボックスモニタリング手法を提案する。カスタムアプリケーション計装なしに高い詳細度と低いオーバーヘッドを達成する鍵は、カーネル支援のイベント駆動戦略を用いることにある。マイクロベンチマークでプロトタイプ実装を評価し、分散データストレージ・処理スタック(Cassandra と Spark)のコンテナ配置における有用性を示す。 ## 論文情報 - **タイトル**: Black-box inter-application traffic monitoring for adaptive container placement - **著者**: [[Francisco Neves]]・[[Ricardo Vilaça]]・[[José Pereira]] - **所属**: [[HASLab]] - INESC TEC and [[University of Minho]], Braga, Portugal - **媒体**: SAC '20 — 35th ACM/SIGAPP Symposium on Applied Computing, March 30-April 3, 2020, Brno, Czech Republic - **DOI**: 10.1145/3341105.3374007 - **ページ数**: 8 ページ - **キーワード**: Containers, monitoring, adaptive placement ## 概要 eBPF の kprobe をカーネル内集約(KernelAgg)と組み合わせることで、コンテナ化された分散システムのアプリケーション間トラフィック量を 9% 未満のオーバーヘッドで継続監視し、重み付き通信グラフを構築する手法を提案する。このグラフを Cassandra + Spark スタックのコンテナ配置最適化(自動・手動)に活用し、ネットワーク転送量の大幅な削減と実行時間の短縮を実証した。 ## 問題設定 **課題**: コンテナ配置決定にはアプリケーション間のデータ転送量(通信グラフの辺重み)が必要だが、これを正確に計測する方法が存在しなかった。 | 方法 | オーバーヘッド | 問題 | |------|----------------|------| | アプリ計装(Dapper, OpenTracing) | 低い | ソース変更が必要、クラウド基盤から利用不可 | | 全パケット傍受 | 非常に高い | 本番環境で非現実的 | | Weave Scope(接続開閉のみ) | 約 1% | トラフィック量が取れない | | UserAgg(per-operation イベント) | 約 68% | ベンチマーク性能を著しく低下させる | **入力**: ランニング中のコンテナ群(アプリケーション非依存のブラックボックス) **出力**: プロセスを頂点、接続を辺とする重み付き通信グラフ(辺重み = 交換バイト数) ## 提案手法 ### アーキテクチャ ``` [eBPF プローブ (各ホスト)] ├─ tcp_connect / inet_csk_accept → CONNECT イベント ├─ tcp_set_state (→CLOSED) → CLOSE イベント └─ sock_sendmsg / sock_recvmsg → トラフィック集約(KernelAgg) ↓ (周期的・閾値超過時のみ転送) [Apache Kafka (メッセージキュー)] ↓ [フロントエンドプログラム (ユーザ空間)] 相関処理: ローカル/リモートアドレスペアの突き合わせ ↓ [Neo4j グラフデータベース] ノード = プロセス / 辺 = 接続 + 重み(バイト数) ``` ### カーネル内集約の核となる実装(KernelAgg) トラフィック計測において eBPF プローブはエントリ(kprobe)とリターン(kretprobe)の 2 点に付く。`sock_sendmsg`/`sock_recvmsg` の場合: 1. **kprobe** 時に `<pid, sock>` エントリを eBPF マップに保存 2. **kretprobe** 時に pid からソケットを復元し、転送バイト数を per-connection カウンタに集約 3. 累計バイト数が**経過時間または量の閾値**を超えた時のみユーザ空間へイベント転送 4. 接続クローズ時に最終トラフィック量を送信 これにより、every-operation でのイベント転送(UserAgg: 68% オーバーヘッド)から大幅に削減し、9% 以下を達成する。 ### グラフ構築 - 各ホストのデータは一方のエンドポイントの視点しか持たない - 中央処理で「ローカルアドレス ↔ リモートアドレス」を突き合わせてプロセスペアを確立 - ホスト内通信(intra-host)も捕捉可能(Figure 3 ヒートマップで主対角線として現れる) ## 新規性 1. **接続有無 → トラフィック量**: Weave Scope は接続の開閉のみ追跡。本論文は転送バイト数まで計測。 2. **カーネル内集約**: 「カーネル内で集約してから転送」という設計で UserAgg の 68% → KernelAgg の 9% へ削減。この発想は eBPF の制約(ループ禁止・スタック 512 バイト制限)の中で `<pid, sock>` マップを工夫して実現。 3. **配置最適化への適用**: 収集したグラフを自動(遺伝的アルゴリズム)と手動の両方の配置最適化に接続。 ## 実験設定 - **実環境**: Google Cloud Platform の `n1-standard-2`(スケーラビリティ評価)、`n1-standard-4` × 4(ケーススタディ) - **ベンチマーク**: iperf(最悪ケース負荷 — I/O 集約・高 syscall 率)、メッセージサイズ 128KB(損失率 0%) - **ケーススタディ**: Cassandra 4 レプリカ + Spark master 1 / worker 4、Kubernetes(kubeadm + Flannel) - **データ**: Cassandra に 200 万行(各行 ≈ 2 KiB)、SQL クエリ Q1(スキャン多) / Q2(シャッフル多) - **監視**: dstat で CPU を秒単位収集 ## 実験結果 ### オーバーヘッド評価(Figure 2) | 方式 | throughput 低下 | 主な CPU 使用 | |------|----------------|---------------| | Baseline | 0% | — | | Conn. (接続のみ) | 約 1% | 無視できる | | Traffic UserAgg | 約 68% | user mode (イベント処理) | | **Traffic KernelAgg** | **約 9%** | **sys mode (カーネル集約)** | ### ネットワーク転送量(Table 2: 自動配置) | クエリ | Baseline | Scan Opt. | Shuffle Opt. | |--------|----------|-----------|--------------| | Q1 | 2.46 GB | **1.76 GB (−28%)** | 1.96 GB | | Q2 | 355.28 MB | 270.42 MB | **214.64 MB (−40%)** | ### ネットワーク転送量 + 実行時間(Table 3: 手動配置) | | Baseline | Scan Opt. | Shuffle Opt. | |--|----------|-----------|--------------| | Q1 実行時間 | 34.33 s | **30.19 s (−12%)** | 31.87 s | | Q2 実行時間 | 52.96 s | 51.95 s | **37.30 s (−29%)** | | Q1 ネットワーク | 2.46 GB | **17.12 MB (−99.3%)** | 2.67 GB | | Q2 ネットワーク | 355.28 MB | 279.56 MB | **95 MB (−73%)** | ## 考察 - **通信グラフのプロジェクション**: 物理ホスト単位(Figure 3, 6)、プロセスタイプ単位(Figure 4, 7)、プロセス個体単位(Figure 5, 8)の 3 レベルで可視化でき、それぞれ異なる洞察を与える。プロセスタイプ単位の集約が「Q1=スキャン、Q2=シャッフル」の区別を明確に示す。 - **手動配置が自動配置を大幅に上回る**: Q1 の Scan Opt. で転送量が 17.12 MB(自動は 1.76 GB)になるのは、Kubernetes マニフェストで Spark worker と Cassandra サーバーを同一ポッドに配置し同一 IP にすることで Cassandra のトポロジー検出がローカルとして認識するため。これはアプリケーション固有の設定が必要で、クラウド基盤だけでは自動化が難しい。 - **ブラックボックス監視の価値と限界**: 本手法はアプリケーション知識なしに「どこで通信が多いか」を特定できるが、配置の改善アクションはアプリケーション固有の設定変更を要する部分が残る。 ## 強み / 弱点・課題 **強み**: - アプリケーション非依存で 9% 未満のオーバーヘッド — 本番導入が現実的 - intra-host 通信も捕捉(CPU・RAM・ネットワークの三次元で資源利用を可視化) - 通信グラフのクエリ柔軟性(ホスト単位/プロセスタイプ単位/プロセス個体単位の集約) **弱点・課題**: - eBPF の制約(ループ禁止、スタック 512 バイト、繰り返しコピーが困難)により実装が非自明 - 遺伝的アルゴリズムの配置最適化はクエリ実行時間を 9〜14% 悪化させる(CPU・RAM を詰め込んでもネットワークは削減できる) - Q2 の Shuffle Opt. が自動配置よりも大幅に優れる(95 MB vs 214.64 MB)理由は、Spark ワーカー数の削減・リソース割り当て変更という「アプリケーション固有の設定」が必要で、汎用クラウド基盤が自動化するには Kubernetes コントローラとの連携が課題として残る - 実験はシングルリージョン/ゾーンの同質構成で、異質ハードウェアやマルチリージョンへの一般化は未検討