@2020__CLUSTER__PIKA - Center-Wide and Job-Aware Cluster Monitoring

# PIKA: Center-Wide and Job-Aware Cluster Monitoring > [!abstract] 概要(abstract の日本語訳) > 今日、性能最適化はハイパフォーマンスコンピューティング(HPC)センターにおいて多かれ少なかれ確立された手順となっている。そのようなシステムの計算効率を持続的に向上させるには、運用者側とユーザー側の双方で効率に対する意識を高める必要がある。そこで我々は、HPCジョブを自動的に特性づけし、最適化の余地がある性能不足の計算ジョブを特定する体系的な手法を提供する、継続的なモニタリングと分析のためのインフラストラクチャを提案する。記録されたメタデータと時系列データは、実行時にライブで、または事後(post-mortem)に可視化でき、最終的には長期分析のために保存される。このモニタリングは計算ノードへの影響が無視できる程度であり、ユーザーアプリケーションに影響も制限も与えない。 ## 論文情報 - **タイトル**: PIKA: Center-Wide and Job-Aware Cluster Monitoring - **著者**: [[Robert Dietrich]], [[Frank Winkler]], [[Andreas Knüpfer]], [[Wolfgang Nagel]]([[TU Dresden]] Center for Information Services and High Performance Computing, ZIH) - **会議**: 2020 IEEE International Conference on Cluster Computing (CLUSTER), pp. 424-432 - **DOI**: 10.1109/CLUSTER49012.2020.00061 - **資金**: Deutsche Forschungsgemeinschaft (DFG) Grant NA711/15-1 (ProPE) - **関連発表スライド**: Frank Winkler, Sebastian Oeste, Andreas Knüpfer et al., "I/O Aspects in the Center-Wide and Job-Aware Cluster Monitoring System PIKA", SC21 Analyzing Parallel I/O BoF(PIKA の I/O 側面を掘り下げた後続発表。本 source ページに統合) ## 概要 PIKA は、TU Dresden の Taurus システム(約1,800ノード・71,000コア)向けに開発された、center-wide(センター全体)かつ job-aware(ジョブ単位を意識した)クラスタモニタリングのソフトウェアスタックである。収集(Collection)・保存(Storage)・分析(Analysis)・可視化(Visualization)の4層構成を取り、オープンソースコンポーネント(collectd・LIKWID・InfluxDB・MariaDB)を組み合わせている。 **Figure 1: モニタリングインフラストラクチャの4層アーキテクチャ** ![[_attachments/PIKA--Center-Wide-and-Job-Aware-Cluster-Monitoring/fig01-monitoring-infrastructure.png]] (Fig. 1. Monitoring Infrastructure. 収集層のノードローカルなデータ収集デーモンが短期時系列データベースへ書き込み、長期時系列データベースへ引き継がれる。分析層はパフォーマンスフットプリント・タグ・マップを生成し、リレーショナルデータベース(ジョブメタデータ・ジョブデータ&フットプリント)と連携する。可視化層はジョブ/システムタイムライン・フットプリントテーブル&プロット・ジョブサマリテーブルを提供する Web フロントエンドである。) ## 問題設定 - HPCジョブはスクリプト言語による逐次実行から高度に並列化されたプログラムまで多様であり、監視はアプリケーションの種類に依存せず動作する必要がある。 - データ取得はプログラムへの計装(instrumentation)のような侵襲的操作を避けなければならない。 - HPCセンターでは1日あたり10,000〜30,000ジョブが投入されるため、性能不足のジョブを手動で発見するのは非現実的であり、自動的な特性づけと分類が必要になる。 - ネットワークや並列ファイルシステムは共有資源であるため、ジョブ単位で見た性能限界(ボトルネック)の要因を切り分ける仕組みが要る。 ## 提案手法 ### データ収集とメトリクス選定 CPU使用率・IPC・FLOPS(単精度換算)・メインメモリ帯域・電力消費・InfiniBand/Ethernet帯域・ローカルディスクおよびLustreのI/O帯域とメタデータ操作数・GPU使用率/メモリ/電力/温度を、ハードウェアスレッド〜ノード単位の粒度でノードローカルに収集する(Table Iに対応)。 | メトリクス | 提案名 | データソース | ハードウェア単位 | |---|---|---|---| | CPU使用率 | cpu_usage | /proc/stat | ハードウェアスレッド | | メインメモリ使用率 | mem_used | /proc/meminfo | ノード | | IPC | ipc | LIKWID | ハードウェアスレッド | | FLOPS(単精度換算) | flops_any | LIKWID | ハードウェアスレッド | | メインメモリ帯域 | mem_bw | LIKWID | CPU/ソケット | | 電力消費 | rapl_power | LIKWID | CPU/ソケット | | InfiniBand帯域 | ib_bw | /sys/class/infiniband/... | InfiniBandデバイス | | Ethernet帯域 | eth_bw | /sys/class/net/eth*/... | Ethernetデバイス | | ローカルディスクI/O | read/write bw & ops | /proc/diskstats | ディスク | | Lustre I/O | read/write bw, open/close/create/seek/fsync/requests | /proc/fs/lustre/llite/*/stats | Lustreインスタンス | | GPU使用率/メモリ/電力/温度 | gpu_used 等 | NVML | GPU | (Table I. Monitored Metrics の転記。要点のみ抜粋) 収集デーモンには[[collectd]](オープンソース・C実装、多言語プラグイン対応)を採用し、8種のreadプラグイン(うち5種は標準提供、InfiniBandとLustreはPython製自作プラグイン)で稼働させる。IPC・FLOPS・メモリ帯域・電力は[[LIKWID]]のC APIをラップした独自プラグインで取得する。InfluxDB書き込みプラグイン(Python 3実装)は値をバッチ化し、NaN/Infを除去し、物理コア単位への集約(ロジカルコア→物理コアの平均・合計)を設定可能にしている。収集デーモンのメモリフットプリントはノード構成に応じて30〜35MBに収まる。収集はジョブ非依存(job-agnostic)アプローチを取る。つまりノードローカルでのメトリクス収集時点ではジョブIDを意識しない。これにより実行時オーバーヘッドを下げ、同一ノードで複数ジョブが共存する場合の冗長なデータ転送を避けられる。ジョブ単位の時系列データは、ノードリスト・使用物理コアリスト・開始/終了時刻などのジョブメタデータをもとに、後から時系列データベースへの一致クエリを生成して導出する。 **Figure 2: 管理者モードのジョブメタデータテーブルビュー** ![[_attachments/PIKA--Center-Wide-and-Job-Aware-Cluster-Monitoring/fig02-table-view.png]] (Fig. 2. Table view of the job metadata with administrator access. 1週間の期間でプロジェクト別にジョブをグループ化し、総コア時間の降順に並べた例。プロジェクトを選択するとユーザー別にジョブがグループ化され、フットプリントへのリンクが提供される。フットプリントは正常終了・タイムアウトのジョブにのみ生成されるため、フットプリント数はジョブ数より少なくなり得る。) ### メタデータとストレージメタデータ(Job ID・ユーザー・プロジェクト・状態・開始/終了時刻・要求ウォールタイム・ノード/コアリスト・メモリ量・GPU数・64ビットのジョブタグなど、Table II)は[[SLURM]]の内部データベースから取得し、単一のSQLテーブル(Job IDを主キー)としてMariaDB/MySQL/PostgreSQLに保存する。SLURMのプロログ/エピログフェーズでジョブ開始・終了時刻を取得できる。ノード共有(1ノードに複数ジョブ)を許す場合、実際の資源割当の詳細はSLURMコントローラ上でしか得られないため、著者らは高速なキー・バリューストアやインメモリDB、RabbitMQのようなメッセージブローカーの併用を提案している。時系列データにはInfluxDBを採用する(代替としてMetricQ・TimescaleDBを検討)。短期・長期の2段構成のInfluxDBインスタンスを持ち、短期DBから長期DBへ引き継がれる。1ノードあたり平均172値/分を生成し、週あたり約10GBのストレージを要する(Taurus実測)。ジョブメタデータは週あたり10,000〜30,000件投入され、MariaDBで週あたり約150MBの容量を要する。 ### パフォーマンスフットプリントとジョブタグ各ジョブについて、性能に関係するランタイムメトリクスの平均・最小・最大値を要約した「パフォーマンスフットプリント」を計算し、専用テーブルに格納する。フットプリントには主メモリ使用率(最大値が重要)や温度など性能指標でないメトリクスも含む。フットプリントを、実測値/理論最大値(または代表期間内の実測最大値)の比にしきい値を適用して自動タグ付けする。 | タグ名 | 式としきい値 | |---|---| | unrestrained | - | | memory-bound | memory bandwidth(実測)/ memory bandwidth(最大) > 80% | | compute-bound | FLOP/s(実測)/ FLOP/s(最大) > 70% または IPC(実測)/ IPC(最適) > 60% | | GPU-bound | GPU使用率 > 70% または GPU使用率 > CPU使用率 | | IO-heavy | IO帯域(実測)/ IO帯域(最大) > 60% | | network-heavy | network帯域(実測)/ network帯域(最大) > 60% | (Table III. Job Tags の転記) **Figure 3: フットプリントのヒストグラム・散布図可視化** ![[_attachments/PIKA--Center-Wide-and-Job-Aware-Cluster-Monitoring/fig03-footprint-histograms.png]] (Fig. 3. Performance footprint visualization of Job States, Job Tags and FLOPS as histograms and IPC / CPU Power as a scatter plot for a period of one year. 記録された全ジョブ(900万件超)の62%超が正常完了(左上)。完了ジョブの91%はタグ付けできず unrestrained に分類された(左下)。残りは主に compute-bound と memory-bound。ほとんどのジョブは2.86 GFlop/s未満(右上)。IPCとCPU電力の相関には IPC=1・CPU電力40Wのホットスポットがある(右下)。) 理論値・測定値のいずれを最大値に使うかは資源の性質に依存する。CPU/GPUのような専有資源は理論最大値または測定ピーク値を使えるが、並列ファイルシステムやインターコネクトのような共有資源では理論ピークが現実的でないため、代表期間内で測定された最大値を「ソフトな最大値」として用い、"bound" ではなく "heavy" という語を採用している。分析の結果、著者らのHPCシステムではほとんどのジョブが unrestrained だった。これはスクリプト言語で書かれ1コアのみを使う多数のスループットジョブによるもので、こうしたジョブはノードローカル資源を他ジョブと共有することが多く、キャッシュの相互干渉などにより準最適な性能になりやすい。スループットジョブの最適化には排他割当ノードでの解析が必要になる。unrestrained だが CPU使用率が低くCPU時間消費が大きいジョブも最適化候補として有望であり、著者らはユーザーへの通知を提案している。ただし本手法は資源使用量の判定に留まり、アルゴリズムや実装の効率自体は判定できないため、より詳細な洞察にはScore-PやVampirのような性能解析ツールが必要になるとしている。 ### インタラクティブ可視化 Web フロントエンドは Angular(フロントエンド)+ PHP(バックエンド)で実装され、管理者モード(パスワード保護・全ジョブアクセス)とユーザービュー(自ジョブのみ、Shibboleth等の既存ログイン認証と統合可能)の2モードを提供する。トップダウン型のテーブルビュー(プロジェクト→ユーザー/ジョブグループ→個別ジョブ)、ヒストグラム・散布図によるフットプリントビュー、タイムラインビューの3種の可視化を持つ。タイムラインは3グループに分類される(Table IV): - **Group I(全測定点・全ハードウェア単位across)**: Peak(全体最大値)、Overall Mean(全体平均値)。基準線として水平線表示。 - **Group II(測定区間ごとに全ハードウェア単位across)**: Max/Mean/Min の時間推移。 - **Group III(時間を通じたベスト/ワーストの平均ハードウェア単位)**: 平均性能が最良・最悪のハードウェア単位(コア等)の時系列。 **Figure 4: 128コアジョブのタイムライン可視化** ![[_attachments/PIKA--Center-Wide-and-Job-Aware-Cluster-Monitoring/fig04-timeline-visualization.png]] (Fig. 4. Timeline visualization of a job with 128 cores, spread over 33 (dual-socket Haswell) nodes that have not been allocated for exclusive use. 左チャートは128コア全体のCPU使用率の最小・平均・最大値(破線は全体平均フットプリント約0.6)を示し、各測定区間で少なくとも1コアが完全使用・1コアがほぼアイドルであり負荷が均等でないことが分かる。右チャートは平均性能が最良・最悪の2コアのタイムラインを示し、最悪平均のコアも一度もアイドルにならず時折平均以上に使用されている、すなわちどのコアも恒常的に低使用ではないことを示す。) ### 発表スライド追補(SC21, I/O側面) 2021年のフォローアップ発表では、収集デーモンの詳細設定(CPUカウンタはLIKWIDで60秒ごと、他メトリクスは30秒ごと、いずれも調整可能)や、Lustreファイルシステムに対するI/O挙動の深掘り可視化(ジョブ間比較・読み書き分布)が示された。 **スライド p.4: 収集デーモンのサンプリング間隔** ![[_attachments/PIKA--Center-Wide-and-Job-Aware-Cluster-Monitoring/slide-daemon-sampling-intervals.png]] (スライド p.4「PIKA Performance Data Collection Daemon」。CPUカウンタはLIKWIDで60秒ごと(ソケット単位/コア単位の区別、イベントグループの多重化あり)、他のメトリクスは30秒ごとに収集し、いずれも調整可能であることを明示している。論文本文には具体的な秒数の記載がなく、スライドが補足する情報である。) **スライド p.10: フットプリントのI/Oパネルと因果関係の指摘** ![[_attachments/PIKA--Center-Wide-and-Job-Aware-Cluster-Monitoring/slide-footprint-io-write-flops.png]] (スライド p.10「PIKA Job Visualization – Footprints」。CPU使用率・主メモリ使用率・Lustre I/O帯域・FLOPS・Lustre I/Oメタデータの6パネルタイムラインを提示し、「Write operations result in lower FLOPS(書き込み操作がFLOPSを低下させる)」という運用上の観察を吹き出しで明示している。論文の Group I〜III タイムライン分類の実例であり、I/Oと計算性能の干渉を可視化から読み取れることを示す。) **スライド p.14: 複数ジョブ間のI/O比較** ![[_attachments/PIKA--Center-Wide-and-Job-Aware-Cluster-Monitoring/slide-compare-jobs-io.png]] (スライド p.14「PIKA Job Visualization – Compare Jobs」。同一コードの異なる実行間でLustre(Scratch2・Highiops)の総読み込み/書き込みサイズを散布図で比較する機能を示す。論文本文では単一ジョブのタイムライン・全ジョブ横断のフットプリント分布までしか説明されておらず、複数ジョブを明示的に比較するUIはスライドで初めて示される追加機能である。) ## 新規性 - **ジョブ非依存(job-agnostic)なノードローカル収集**: ジョブIDを収集時点で意識せず、事後にメタデータと突き合わせてジョブ単位の時系列を導出する設計により、オーバーヘッドと冗長データ転送を最小化しつつシステム全体のビューも同時に得られる。 - **パフォーマンスフットプリントによるジョブの自動タグ付け**: しきい値ベースの単純なヒューリスティックで、大量のジョブ(1日1万件超)から最適化候補を自動的に絞り込む体系的アプローチを提示した。 - **1万ノード超への拡張性の実証**: 単一InfluxDBインスタンスで最大10,800台のシミュレートノードを処理できることをバッチサイズ・送信間隔のパラメータスイープで示した。 ## 実験設定 - **オーバーヘッド測定**: LIKWIDのアセンブリマイクロベンチマーク(peakflops, triad, load, store, stream。AVX版、triad/streamはFMA使用)をデュアルソケットIntel Haswell(24物理コア)ノード上で監視あり/なしで比較。各ベンチマークは全コアで約10分実行。 - **スケーラビリティ測定**: Micron M510 SSD搭載の単一DBサーバ、InfluxDB 1.7.10(インメモリインデックス構成)を使用。Taurus Haswellノード1台につき24コアがそれぞれランダム値のバッチをバッチサイズ200で周期送信する形で、多数ノードをシミュレート。実験開始時点でDBには既に1週間分・約20億エントリが投入済み。HTTPとUDPの両プロトコルで比較。 ## 実験結果 - **オーバーヘッド**: 60秒間隔での実行時間増加はload/streamで約0.3%、triadで約0.2%、peakflops/storeでは検出不能。10秒間隔でも同程度。1秒間隔では最大でloadが1.16%増加。同じ1秒間隔でもLIKWIDメトリクスを使わない場合は最大0.1%(triad)まで低下し、他のベンチマークではオーバーヘッド無し。 - **スケーラビリティ**: HTTPプロトコルで送信間隔2秒・バッチサイズ106のとき、単一Haswellノードで720台の監視ノードをシミュレート可能、この構成は7200台まで拡張可能だった。送信間隔4秒・バッチサイズ212では単一InfluxDBインスタンスが10,800台のシミュレートノードを処理できた。バッチサイズを増やすほど多くのノードを扱えるが、ライブ可視化の遅延も増える。UDPは低プロトコルオーバーヘッドにもかかわらずInfluxDBの書き込み性能を向上させなかった。 - **堅牢性**: Lustre/InfiniBandプラグインは周期的にマウント・デバイス可用性を確認し、読み取りエラー時は該当カウンタを一時無効化する。InfluxDB接続断時はローカルキャッシュ(バッチサイズの倍数)でバッファリングし、DB負荷ピーク・再起動・移行時のデータ損失を回避する。ログファイルを定期的にgrepしerror/failureキーワードで管理者に通知する。 ## 考察 - 本論文はTaurusシステム(約1,800ノード・71,000コア)での実運用経験に基づいており、単なる設計提案ではなく本番稼働データ(1年分・900万件超のジョブ状態、日次1〜3万ジョブ)に基づく評価である点が強い。 - ジョブ非依存収集とジョブ依存分析の分離は、後発の[[Jobstats]](2023, SlurmのAdminCommentフィールドに長期要約を保存する設計)とも設計思想上の親和性がある。両者はいずれも「収集は安価・汎用に、ジョブ単位の意味づけは事後導出」という原則を採る。詳細は [[HPCジョブモニタリング]] を参照。 - ジョブタグのしきい値は初期値として提案されており、環境ごとの調整が前提。実運用ではジョブの91%が unrestrained に分類され、単純なリソース飽和ベースのタグ付けだけでは大半のジョブ(特に低並列度のスループットジョブ)を分類しきれないという限界が観測データから読み取れる。 ## 強み / 弱点・課題 **強み**: - ノードローカル収集がユーザーアプリケーションを計装しない非侵襲設計であり、あらゆる言語・実行形態のジョブに適用できる。 - 実運用(1,800ノード、900万ジョブ超/年)でのオーバーヘッド・スケーラビリティの定量評価があり、他システムとの比較の土台になる。 - オープンソースコンポーネント(collectd, LIKWID, InfluxDB, MariaDB)の組み合わせで実装コストを抑えている。 **弱点・課題**: - ジョブタグのしきい値(memory-bound: 80%、compute-bound: 70%/60%等)は経験的初期値であり、環境間の汎化性が未検証。 - ノード共有時のジョブ単位資源割当の取得はSLURM内部DBに依存し、SLURMコントローラへの追加負荷というトレードオフを抱える。 - 資源使用率の判定はできるがアルゴリズム・実装自体の効率評価はできず、詳細診断には別ツール(Score-P, Vampir)が必要。 - I/Oタグ("IO-heavy")は単純な分類であり、著者ら自身がスライド(Roadmap)で「単純化されすぎている」と認め、長時間ジョブで平均化されて埋もれる短時間の高I/Oフェーズの検出が今後の課題として残っている。 ## 関連研究との比較論文 Section V(既存モニタリングシステム)が比較する主なシステム: - [[Ganglia]]: 階層的アプローチで複数HPCクラスタの状態を監視。ストレージにRRDtoolを使うため、時系列DB(InfluxDB等)と比べてデータ量上限やリサイズ制約という弱点がある。ジョブビューを持たない。 - TACC stats: ジョブのメタデータを収集・解析しジョブレベルビューと性能不足・設定誤りの自動検出を提供。解析は24時間ごと。ノード間タイムスタンプ調整が必要な点でPIKAの同期読み取りより overhead が大きい。時系列はRabbitMQ経由でPostgreSQLへ格納、1サンプル点の全メトリクス収集に約0.5秒を要する。 - PerSyst: 10分間隔の低頻度カウンタ収集をCassandraに格納し、ジョブ単位に提示。基本的な性能問題・資源需要の解析に一部のカウンタを用いる。 - TICK Stack: Go実装、InfluxDB中心。収集エージェントTelegraf、イベント処理・アラートエンジンKapacitorを含むが、UIのChronografはHPC向けでなくジョブビューを持たない。 - Lightweight Distributed Metric Service (LDMS): 監視オーバーヘッド最小化(メタデータと値の分離、収集デーモンのメモリ・実行時フットプリント削減)に焦点。メトリクスはCSV形式で保存されMySQLへバルク挿入される。 - Likwid Monitoring Stack (LMS): オープンソースコンポーネント群をシンプルなインターフェーススクリプトで結合。メトリクスルータがジョブIDをタグ付けしInfluxDBに格納、ジョブビュー生成のためジョブごとのDBへメトリクスを複製する。プリロード可能な軽量アプリケーション監視ライブラリも提供。 ## 出典 - [[.raw/papers/PIKA--Center-Wide-and-Job-Aware-Cluster-Monitoring.pdf]] - [[.raw/papers/PIKA--Center-Wide-and-Job-Aware-Cluster-Monitoring.txt]] - [[.raw/slides/PIKA--Center-Wide-and-Job-Aware-Cluster-Monitoring/PIKA--Center-Wide-and-Job-Aware-Cluster-Monitoring.pdf]](Frank Winkler, Sebastian Oeste, Andreas Knüpfer et al., "I/O Aspects in the Center-Wide and Job-Aware Cluster Monitoring System PIKA", SC21 Analyzing Parallel I/O BoF)