# HPCジョブモニタリング ## 定義 HPCジョブモニタリングとは、HPCクラスタの計算ノード上で収集した性能・資源利用メトリクスを、バッチシステム(多くは[[SLURM]])が管理するジョブの単位に紐づけて可視化・分析する仕組みを指す(Source: [[@2020__CLUSTER__PIKA - Center-Wide and Job-Aware Cluster Monitoring]], [[@2019__CLUSTER__ClusterCockpit - A web application for job-specific performance monitoring]], [[@2023__PEARC__Jobstats - A Slurm-Compatible Job Monitoring Platform for CPU and GPU Clusters]])。ノード単位のシステム全体監視(Ganglia等)と異なり、個々のジョブが「どの資源に律速されたか」を運用者・ユーザーの双方に提示することで、最適化候補の特定とクラスタ全体の効率向上を狙う点が共通する。 2020年前後に独立に発表された[[PIKA]]・[[ClusterCockpit]]・[[Jobstats]]の3システムは、いずれも「ノードローカルな収集は安価・汎用に保ち、ジョブ単位の意味づけは事後にバッチシステムのメタデータと突き合わせて導出する」という設計原則を共有しながら、統合方式・ストレージ選択・タグ付け粒度で異なる選択をしている。 ## アーキテクチャの共通パターン - **収集・保存・分析・可視化の4層(または3層)構成が繰り返し現れる。** - [[PIKA]]は収集(collectdデーモン)・保存(短期/長期InfluxDB + リレーショナルDB)・分析(パフォーマンスフットプリント・タグ)・可視化(Angular+PHP)の明示的4層を提案する(Source: [[@2020__CLUSTER__PIKA - Center-Wide and Job-Aware Cluster Monitoring]] Fig.1)。 - [[ClusterCockpit]]はノードデーモン→中央ストレージコンポーネント(InfluxDB+SQL+Redis)→REST API→Webフロントエンドという3層構成を提案アーキテクチャとして描く(Source: [[@2019__CLUSTER__ClusterCockpit - A web application for job-specific performance monitoring]] Fig.4)。 - 根拠: いずれも「ノードローカル収集」「時系列ストレージ」「ジョブメタデータ用リレーショナル/構造化ストレージ」「Webベースの可視化」という4要素に分解でき、実装言語やコンポーネント選択は違えど機能分割は収束している。 - **時系列データベースにInfluxDBを採用する事例が多いが、統合難度の課題も共有する。** - PIKA・ClusterCockpitはともにInfluxDBを採用する。ClusterCockpitはGrafanaを可視化層として採用しなかった理由に、InfluxDBを含む主要TSDB(OpenTSDB・Prometheus含む)がクエリ単位のアクセス制御を欠き、ジョブ閲覧範囲をユーザーごとに制限できない点を挙げている(Source: [[@2019__CLUSTER__ClusterCockpit - A web application for job-specific performance monitoring]] レッスンズラーンド)。 - 関連: [[時系列データベース]]の一般的な特性(高書き込みスループット・タグベースインデックス)がHPCジョブモニタリングでも土台になっている。 ## SLURMとの統合方式の違い - **ジョブメタデータの取得タイミングと経路が3者3様である。** - PIKAはSLURM内部データベースにプロログ/エピログフェーズで都度クエリし、取得結果を独自のSQLテーブルへコピーする。ノード共有時の詳細な資源割当情報はSLURMコントローラ上にしかなく、追加クエリはコントローラ負荷増とのトレードオフになる(Source: [[@2020__CLUSTER__PIKA - Center-Wide and Job-Aware Cluster Monitoring]] §II-D)。 - Jobstatsはジョブ終了時に性能要約をSLURMの`AdminComment`列へ直接書き込むことで、SLURM本体への追加クエリの繰り返しを避け、要約データをSLURMのジョブレコードそのものに同居させる(Source: [[@2023__PEARC__Jobstats - A Slurm-Compatible Job Monitoring Platform for CPU and GPU Clusters]])。 - ClusterCockpitはマスタ・管理ノードのprologue/epilogueスクリプトからREST API呼び出しでジョブメタデータをClusterCockpitサーバーへ能動的にpushし、独自のリレーショナルDBに格納する(Source: [[@2019__CLUSTER__ClusterCockpit - A web application for job-specific performance monitoring]] 提案アーキテクチャ)。 - 論点: 「SLURM側に要約を埋め込む(Jobstats)」か「監視システム側に独立ストレージを持つ(PIKA・ClusterCockpit)」かは、SLURMコントローラへの追加負荷と、監視システム自体の可用性・スケーラビリティのどちらを優先するかのトレードオフになっている。 ## ジョブ単位ビューの導出方式 - **job-agnostic収集(PIKA)とジョブ起点push(ClusterCockpit)という対照的な設計がある。** - PIKAは収集時点でジョブIDを一切意識しない job-agnostic 収集を採用し、ジョブ単位の時系列はノードリスト・使用コアリスト・開始/終了時刻というメタデータをもとに事後的にTSDBクエリを生成して導出する。これによりオーバーヘッドと、複数ジョブが同一ノードを共有する場合の冗長データ転送を避ける(Source: [[@2020__CLUSTER__PIKA - Center-Wide and Job-Aware Cluster Monitoring]] §II-C)。 - ClusterCockpitはprologue/epilogueスクリプトがジョブ開始・終了のタイミングでREST API経由でジョブメタデータを能動的に送信するプッシュ型で、ジョブという単位がデータフローの起点になっている(Source: [[@2019__CLUSTER__ClusterCockpit - A web application for job-specific performance monitoring]] 提案アーキテクチャ)。 - 留保: job-agnostic方式はシステム全体ビュー(全ノードの状態俯瞰)を同時に得やすい利点があるが、ジョブ単位クエリの生成コストをTSDB側に押し付ける。ジョブ起点push方式はジョブ単位データが最初から整理されている代わりに、ノード共有時のジョブ間の資源競合(cache perturbationなど)をシステム全体ビューとして見るには別途集計が要る。 ## 自動タグ付けによるジョブ分類 - **しきい値ベースのヒューリスティックタグ付けが複数システムで採用されている。** - PIKAはパフォーマンスフットプリント(平均/最小/最大値)に対し、資源ごとの実測値/最大値比にしきい値(memory-bound: 80%、compute-bound: FLOP/s比70%またはIPC比60%、GPU-bound、IO-heavy: 60%、network-heavy: 60%)を適用し、unrestrained を含む6種のタグを自動付与する(Source: [[@2020__CLUSTER__PIKA - Center-Wide and Job-Aware Cluster Monitoring]] Table III)。 - ClusterCockpitは"pathological"(エラー発生)・"low-utilization"(低資源利用率)・"ticket Id"(サポートチケット対応)のようなタグ型による分類を提供し、事前指定カテゴリでの自動タグ付けも要件に含める(Source: [[@2019__CLUSTER__ClusterCockpit - A web application for job-specific performance monitoring]])。 - 反証: PIKAの実運用データでは完了ジョブの91%が unrestrained に分類され、単純なしきい値ベースの分類だけでは大半のジョブ(低並列度・1コアのスループットジョブ)を意味のあるタグへ分離しきれていない(Source: [[@2020__CLUSTER__PIKA - Center-Wide and Job-Aware Cluster Monitoring]] §III-B)。この観察は、しきい値ベースタグ付けの限界がPIKA固有ではなく、同種のアプローチを取る他システムにも共通しうる懸念を示唆する。 ## 未解決の問い - job-agnostic収集(PIKA)とジョブ起点push(ClusterCockpit/Jobstats)のどちらが大規模GPUクラスタ(数百〜数千GPU)でのメトリクス量・カーディナリティ増大に対してよりスケールするかは、直接比較した実験がまだない。 - しきい値ベースのジョブタグ付け(PIKA・ClusterCockpit共通)を、環境間で汎化させる自動しきい値調整・学習ベースの手法へ置き換える試みがあるか。 - SLURMの`AdminComment`への要約埋め込み(Jobstats)方式は、SLURM以外のバッチシステム(PBS, LSF等)にも一般化できるか。PIKA・ClusterCockpitのような独立ストレージ方式との移植性の比較が要る。 ## 未編纂の観察 - 3システムはいずれも[[LIKWID]]または類似のハードウェアカウンタツールをCPU性能メトリクス収集に用いており、HPCジョブモニタリングにおけるハードウェアカウンタアクセスの事実上の標準的手段になっている(Source: [[@2020__CLUSTER__PIKA - Center-Wide and Job-Aware Cluster Monitoring]], [[@2019__CLUSTER__ClusterCockpit - A web application for job-specific performance monitoring]])。 - Jobstats自身の関連研究セクションが、既存ジョブ監視ツールの一つとしてPIKAを名指しし、GPUジョブの詳細サポート不足を課題として挙げている。これは同分野のツール間で相互に弱点が認識・参照されていることを示す(Source: [[@2023__PEARC__Jobstats - A Slurm-Compatible Job Monitoring Platform for CPU and GPU Clusters]] 問題設定)。 - [自動タグ付けによるジョブ分類] **[[TACC Stats]](2014年)は、PIKA(2020年)に先立って「常時・全ノード・全ジョブ・ユーザー操作不要」の完全自動収集と、しきい値ベースの夜間バッチテスト(Imbalance・High CPI・Idle・Catastropheの4種)による異常ジョブ検知を実運用で示していた**。実行1回0.5秒未満・既定間隔でのオーバーヘッド0.1%未満という低コストで、共有メモリアプリの誤ったマルチノード投入やOpenMP `WORKSHARE`のスレッド不均衡といった非効率を、複雑な機械学習的手法を用いずに検知・診断できた(Source: [[@2014__HUST__Comprehensive Resource Use Monitoring for HPC Systems with TACC Stats]])。この「単純な閾値・ステップ関数検知で実用上十分な非効率検知ができる」という知見は、PIKA・ClusterCockpitのしきい値ベースタグ付けの設計判断とも整合する。 - [ジョブ単位ビューの導出方式] **TACC Statsはノードレベル収集(monitor)とジョブレベル変換(pickler、24時間ごとにpickle化)を分離する点で、PIKAのjob-agnostic収集(事後にTSDBクエリでジョブ単位ビューを導出)と設計思想上の系譜が近い**。TACC Statsの収集自体はジョブに依らずノード全体を対象とし、ジョブへの解決は後段のバッチ処理で行われる(Source: [[@2014__HUST__Comprehensive Resource Use Monitoring for HPC Systems with TACC Stats]])。 - [ユーザー提示レイヤーの重心] **多くのジョブ単位性能監視の研究は計測・データ収集層に注力し、ユーザーインターフェースには労力を割かない**という観察がある。ClusterCockpitはこの偏りを問題視し、逆にユーザーインターフェース層へ重心を置く設計を取る(Source: [[@2019__CLUSTER__ClusterCockpit - A web application for job-specific performance monitoring]])。 - [汎用ダッシュボードのセキュリティ制約] **Grafanaのようなviewerロールを持つ汎用時系列ダッシュボードは、ユーザーがInfluxDB等のデータソースへ任意クエリを実行できてしまう権限モデル上の欠陥を抱え、per-query permissionの実装をGrafana開発チームが拒否したため、細粒度アクセス制御を要するジョブ単位性能監視には不向きとされる**(Source: [[@2019__CLUSTER__ClusterCockpit - A web application for job-specific performance monitoring]])。 - [サイト規模と設計判断の対応] **中小規模サイト(運用人員1〜2名、〜2000ノード)向けの監視ツールは、大規模サイト向けソリューション(大規模データ転送・ストレージのスケーラビリティを重視する設計)をそのまま導入すると過剰設計になりやすく、専用の軽量ソリューションが要る**という設計上の対比がある(Source: [[@2019__CLUSTER__ClusterCockpit - A web application for job-specific performance monitoring]])。 ## 未解決の問い(追加) - 「病的ジョブ」(pathological job)をタグ付け・分類する基準は、サイトごとにどこまで共通化・自動化できるか(ClusterCockpit)。 - 収集・転送レイヤーとユーザー提示レイヤーのどちらに研究投資を割くべきかという役割分担は、サイト規模や運用体制でどう変わるか(ClusterCockpit)。 ## 関連 - ソース: [[@2020__CLUSTER__PIKA - Center-Wide and Job-Aware Cluster Monitoring]] / [[@2019__CLUSTER__ClusterCockpit - A web application for job-specific performance monitoring]] / [[@2023__PEARC__Jobstats - A Slurm-Compatible Job Monitoring Platform for CPU and GPU Clusters]] / [[@2014__HUST__Comprehensive Resource Use Monitoring for HPC Systems with TACC Stats]] - エンティティ: [[PIKA]] / [[ClusterCockpit]] / [[Jobstats]] / [[TACC Stats]] / [[SLURM]] / [[LIKWID]] / [[InfluxDB]] / [[Likwid Monitoring Stack (LMS)]] / [[Ganglia]] - 関連概念: [[時系列データベース]] / [[HPCジョブスケジューリング]] ## 出典 - [[@2020__CLUSTER__PIKA - Center-Wide and Job-Aware Cluster Monitoring]] - [[@2019__CLUSTER__ClusterCockpit - A web application for job-specific performance monitoring]] - [[@2023__PEARC__Jobstats - A Slurm-Compatible Job Monitoring Platform for CPU and GPU Clusters]] - [[@2014__HUST__Comprehensive Resource Use Monitoring for HPC Systems with TACC Stats]]