「富岳」の運⽤を⽀えるOSS活⽤事例
PCCC AI/HPC OSS活⽤ワークショップ
2024年2⽉5⽇

理化学研究所 計算科学研究センター
⼭本 啓⼆

OSSの活⽤
l ある機能を実現するときの選択肢
l

独⾃開発

l

既存のソフトウェアを利⽤
lOSS: ⾃由に拡張できるl

プロプライエタリ/SaaS: OSSより機能・サポート⾯で優位な傾向がある

l 「富岳」では多数のOSSを選択し利⽤しているl

同じ機能を実現するOSSにもいくつか選択肢があるため、⽐較検討が必要

2

「富岳」のソフトウェア
l HPCの基本的な環境(ファイルシステム・スケジューラ・並列環境・運⽤管理)は富⼠通製TCS(プロプライエタリ)を利⽤

l TCSのみでは運⽤が難しい部分は独⾃開発するよりも既存のOSSを活⽤l

利⽤者ポータル, ドキュメント, ダッシュボード, 認証システム
ll

デプロイ, 運⽤⼿順, 監視/ログ収集, リポジトリ
ll

Web系
運⽤系

運⽤分析/可視化, ストリーミング処理, データベース
l分析系

3

利⽤者ポータル (ウェブ系)
l 利⽤者向けに運⽤情報やドキュメントを提供
l 「京」のとき
l

独⾃のテンプレートエンジンを利⽤した⼿組みのhtmllPerlでのcgi

l 「富岳」になって
ll

管理コストの低減のためにCMSを導⼊
l

WordPressとDrupalを⽐較し、デフォルトで多⾔語に対応しているDrupalを選択l

たぶんシェアはWordPressの⽅が多い︖

cgi部分はウェブAPIフレームワークを導⼊lPerl, php, python, go => pythonlDjango, Flask, FastAPI => FastAPI

l

フレームワークの学習コストが⼩さく軽量なOSSを選択
4

ドキュメント (ウェブ系)
l 利⽤者向けドキュメントの作成
l 「京」のとき
lWordで書いた利⽤マニュアルをPDF化

l 「富岳」になって
lオンラインマニュアルを主としPDFも残す⽅針l

ドキュメント作成OSS: sphinx, mkdocs, asciidoc
lどれも軽量のマークアップ⾔語でドキュメントを記述するといい感じにレイアウトしてくれるl

デフォルトでPDF化できるのはsphinxのため、「富岳」のドキュメントはsphinxを選択

ll

mkdocsはmarkdownで書けるため、オンラインのみであればmkdocsを選択していたかもGitリポジトリでドキュメント管理をできるようにもなった5

ダッシュボード (ウェブ系)
l 利⽤者向けに運⽤状況を可視化
l 「京」のときl

RRDtoolでジョブ数/利⽤率をグラフ化し利⽤者ポータルに掲載

l 「富岳」になって
llJavascriptのライブラリで⾼度なグラフ⽣成ができるため、静的なグラフ画像⽣成は廃⽌ (plotly,Google chart)
ダッシュボードとしてGrafanaを選択
ll

ダッシュボードを作るなら、これしかない
Gangliaは⽤途が監視から可視化まで含まれており、⾃由にダッシュボードを作りたい場合には向かない
6

認証システム (ウェブ系)
l 利⽤者の認証⽅法
l 「京」のとき
l

認証が必要なのはSSHおよび利⽤者ポータルのみl

利⽤者ポータルは証明書認証

l 「富岳」になって
l

利⽤者ポータルの他にWebAPI, OpenOnDemandなど認証が必要なサービスが増加
ll

特にWebAPIには標準の認証⽅法OpenIDConnectが求められる

セキュリティ的に独⾃実装やライブラリの利⽤よりも、よく利⽤されているOSSのIDPであるkeycloakを選択
l

OSSではkeycloakが最適、ただし運⽤負荷はすこし⾼い- SaaSのAuth0なども最新の認証(Passkey)に追随しているのでよさそう
7

Jupyter/HPCインターフェイス (ウェブ系)
l 利⽤者がインタラクティブな操作が可能なインターフェイスを提供
l 「京」のとき
lなし

l 「富岳」になって
l

OpenOnDemandを導⼊ (独⾃実装を試みた…)
ll

認証にはKeycloakを利⽤

OpenOnDemand内にポータル機能の移植を検討l

たとえば公開鍵の登録画⾯

8

運⽤⼿順 (運⽤)l Infrastructure as Codell

⼿順書やパラメータシートを利⽤した⼿動でのプロセスの代わりに、コードを利⽤して構成管理・プロビジョニングを管理
コマンドを羅列したシェルスクリプトでもできるが、専⽤のフレームワークがあるlAnsible (富岳で利⽤), Terraform (クラウドプロビジョニング⽤), Chef, PuppetlAnsibleの設定ファイル(レシピ)は yaml なのでgitでバージョン管理も可能

l 障害対応時や定常的な操作には⼿順書もある
l

LC4RI (Literate Computing for Reproducible Infrastructure)lJupyter notebookを使って⼿順書、実⾏コード、実⾏結果を管理- JupyterからAnsibleを起動など
9

監視システム (運⽤)lll

代表的な監視システム
l

OSS: Nagios, ZABBIX, prometheusl

SaaS: Mackerel, Datadog「京」では運⽤初期にはNagiosを、後期にはZABBIX, Prometheusを導⼊l

多数のアラートの管理が難しい (Nagios)l

設定がウェブUIから (IoCではない)/メトリクスが増えると性能低下 (ZABBIX)「富岳」ではprometheusを導⼊
lOpenMetrics: メトリクスのデータ定義の標準l

計算ノード以外のサーバ全てでnode_exporterを稼働

llluster_exporter, tcs_exporter(富⼠通製スケジューラ⽤のエクスポータ)lGrafanaによる可視化も容易に実現

アラートに対応した⼿順を(基本的には)LC4RIで⽤意ll

300件以上のアラート登録

バックエンドDBはPrometheus, VictriaMetrics, InfluxDB
10

ログ収集 (運⽤)l 管理対象のノード数が増えると、それぞれのノードに⼊ってログを確認する⼿間が増える
l

ログ管理ノードにログを集めて、そこで集中的に管理/監視する
lgrepは⼤変なのでfull-textデータベース化、ストリーミング処理

l 代表的なログ収集ソフトウェア
lOSS: rsyslog, fluentd, logstash (elastic stack)lSaaS: Datadog

l 「京」では運⽤中盤からfluentdを導⼊l

性能⾯および管理⾯でも問題なく稼働

l 「富岳」ではログの全⽂検索としてElasticsearchを導⼊したことで、ログ収集ソフトウェ

アもLogstash, filebeatとelastic stackを利⽤

l

どちらを使うかは好みによる
11

HPC Platform: Log & Metrics collection from Compute nodes
432 compute racks
158,976 nodes(including 9,936 BIO)NFS export

1 compute rack : 384 nodes(including 24 Boot I/O nodes)
Compute node

96 aggregation servers

Message BUS

Compute nodes rack
Compute nodeCompute nodes rack
Compute and Boot I/O node

NFS export

Boot Storage
Compute node

compute nodes
Compute nodes rackCompute and Boot I/O node

Boot Storage

1 logstash aggregate 108 beats Kafka aggregate 96 logstash

1KB/s per Filebeat

1 filebeat aggregate 16 compute node

100KB/s per logstash Total: 10MB/s
1day: 900GB

Delay: ~ 10 sec.

beats, logstash and Elasticsearch are Elastic Stack: https://www.elastic.co/
Boot storage is shared withcompute and I/O node by NFS

Filebeat is a lightweight log shipper written in Go language. Its function is limited to log
forwarding only.

Logs of each node are stored bootstorage

Logstash has data transformation and analysis function in addition forwarding. It runs on
Java and has a large memory footprint.

12運⽤分析/可視化 (分析)l ダッシュボードを⾒ると⼤抵のことが把握できるが、より深掘りしたいときにはダッシュボードの参照先DBを直接⾒たい

l 多数のデータソースと連携して、データ分析・可視化できるBIツールがあるlOSS: Redash, Apache superset, Metabasel

データソース: Excel, CSV, 主要なデータベース

l 「京」ではRedashを利⽤
l100以上の分析クエリを蓄積/共有

l 「富岳」でも引き続きRedashを利⽤
l

ただし、活⽤にはデータが整理されてデータベースに⼊っていることが重要

13

理研で開発中のOSS
l Fugaku WebAPI
l「富岳」の操作(主にジョブ) をウェブAPIから可能としたもの: 実サービス中

l

実装で利⽤したOSS: FastAPI, Keycloakl

WebAPI⾃体もgithubで公開

l現在Webhookの実装を検討中l Lens3
ll

ローカルのファイルシステムをS3として⾒せるソフトウェア
利⽤例: 利⽤者が⾃⾝のホーム/データディレクトリをS3のバケットとして公開できるll

読み書きはユーザ⾃⾝の権限を利⽤

クローズドでサービス中: 来年度には利⽤者に公開
14