# コンテナ配置最適化 ## 定義 コンテナ配置最適化(Adaptive Container Placement)は、Kubernetes などのコンテナオーケストレーターが管理するコンテナ群を物理・仮想サーバーに割り当てる際、ネットワーク転送量・CPU・RAM の資源利用効率を最大化するようにスケジューリングを最適化する手法の総称である。コンポーネント間のデータ転送量はアプリケーションの性能を直接左右するため、通信パターンを配置決定に組み込むことが重要とされる。([[@2020__SAC__Black-box inter-application traffic monitoring for adaptive container placement]]) Kubernetes の標準スケジューラは CPU/RAM の均衡を考慮するが、アプリケーション間の**通信量**は考慮しない。これを補う手法として、(1) アプリケーション固有の監視ツール(Spark の内部メトリクス等)を利用する方法と、(2) **ブラックボックス監視**によりアプリケーション非依存で通信グラフを構築する方法がある。 ## 横断的知見 - **eBPF カーネル内集約(KernelAgg)がブラックボックスとしての配置最適化に必要な精度とオーバーヘッドの両立を実現した**: Neves ら(SAC 2020)は eBPF kprobe を `sock_sendmsg`/`sock_recvmsg` に付けてバイト数を per-connection カウンタに集約し、周期的に転送することで 9% 未満のオーバーヘッドを実現した。ユーザ空間集約(per-operation イベント)では 68% のオーバーヘッドとなり、接続開閉のみ追跡(Weave Scope 方式)はオーバーヘッド 1% だがトラフィック量が計測不能であった。「ブラックボックスで通信量を計測可能」というこれ以前の方法の空白を埋める。(Source: [[@2020__SAC__Black-box inter-application traffic monitoring for adaptive container placement]]) - **自動配置(遺伝的アルゴリズム)より手動配置が大幅に優れる場合があり、「アプリケーション固有設定のブラックボックス的特定」が鍵になる**: Cassandra + Spark のスキャンワークロード(Q1)で、自動配置は 2.46 GB → 1.76 GB(−28%)に対し、手動配置は Spark worker と Cassandra を同一ポッドに入れることで 17.12 MB(−99.3%)まで削減できた。この差はアプリケーション固有の設定(Cassandra のデータローカリティ認識)にあるが、**そもそもその設定変更が必要だとブラックボックス監視によって気づける**点が本手法の価値。アプリケーション知識は「最適化の実行」に必要だが、「どこを最適化すべきかの特定」はブラックボックス監視で賄える。(Source: [[@2020__SAC__Black-box inter-application traffic monitoring for adaptive container placement]]) - **コンテナ配置研究は 2017 年 SMS 時点で SLA-Infra ステークホルダーの二極化として認識されていた**: Pahl ら(IEEE TCC 2019)は 46 件 SMS で品質関心を SLA Parameter(performance・compliance・security・reliability; count=36)と Infrastructure Parameter(workload・resource utilisation・startup・memory use・size/volume; count=33)に二分し、System/Management Parameter(elasticity; count=10)を中間に置いた。SLA は consumer 側、Infra は provider 側の関心であり、コンテナ配置最適化はこの両者を同時最適化することが要件となる。Neves ら(SAC 2020)が provider 側の「ネットワーク転送量」(Infrastructure Parameter)を主目的とするのは、この二極化のうち Infra 側の継続深掘りに位置付けられる。(Source: [[@2019__TCC__Cloud Container Technologies - A State-of-the-Art Review]], [[@2020__SAC__Black-box inter-application traffic monitoring for adaptive container placement]]) ## 未解決の問い - ブラックボックス通信グラフで「どこを最適化すべきか」を特定できるとして、Kubernetes コントローラとのどのような統合インタフェースが汎用化に必要か。論文は Pyevolve(遺伝的アルゴリズム)と Kubernetes マニフェスト書き換えを手動で繋いでいる。 - 本論文の評価は Cassandra + Spark の同質構成(同一リージョン/ゾーン)に限る。異質ハードウェア・マルチリージョン・サービスメッシュ環境でブラックボックス通信グラフの精度と有用性はどう変わるか。 - マイクロサービス数が多い場合、通信グラフのエッジ数は O(N²) となりうる。大規模環境での集計・クエリの計算量はどう抑えるか(論文は 4 サーバー・約 10 プロセスの小規模評価のみ)。 - 論文は 2020 年発表。eBPF エコシステム(CO-RE・BTF、libbpf)・Kubernetes スケジューラ拡張機能(Scheduler Extender、Scheduling Framework)の成熟を受け、同様のアプローチがプロダクション採用された事例はあるか。 ## 関連 - ソース: [[@2020__SAC__Black-box inter-application traffic monitoring for adaptive container placement]] / [[@2019__TCC__Cloud Container Technologies - A State-of-the-Art Review]] - 概念: [[eBPF]] / [[分散トレーシング]] / [[テレメトリ]] / [[オブザーバビリティ]] / [[マイクロサービスアーキテクチャ]] / [[コンテナオーケストレーション]] - エンティティ: [[Francisco Neves]] / [[Ricardo Vilaça]] / [[José Pereira]] / [[HASLab]] / [[University of Minho]] / [[Docker]] / [[Kubernetes]] ## 出典 - [[@2020__SAC__Black-box inter-application traffic monitoring for adaptive container placement]](DOI:10.1145/3341105.3374007; SAC 2020; Cassandra+Spark 4ノード実験; KernelAgg 9% オーバーヘッド; Q1 手動配置で −99.3% 転送量削減) - [[@2019__TCC__Cloud Container Technologies - A State-of-the-Art Review]](§5.2.3 Quality Management 品質パラメータ二極化、§5.2.5 Tools/Platforms/Technology)