## 概要 [[Cory Lueninghoener]]（[[Los Alamos National Laboratory]]、HPC 設計グループリーダー）が SREcon Europe 2016（2016-07-12、Dublin）で発表したスライド。HPC 環境における月次クラスタメンテナンスの計画管理に、SRE のエラーバジェット概念を適応させた「ダウンタイム予算（Downtime Budget）」の取り組みを報告する。37 ページ、YouTube 動画・自動字幕トランスクリプトあり。 ## 主要メッセージ - **エラーバジェットの直接移植は不可**: Web SRE では SLA 99.99% の 0.01% = 1,000 万リクエスト中 1,000 件の失敗許容（意味がある）。HPC では 0.01% of 1,000 ジョブ = 1/10 ジョブ（意味をなさない）。しかし「ダウンタイムを追跡し意思決定に使う」という原則は移植できる。 - **ダウンタイム予算の定義**: 各クラスタに月 1 回 10 時間の DST（Dedicated System Time）が割り当てられる。四半期 = 3 回 × 10 時間 = **30 時間**（クラスタ利用可能時間の約 **1.4%**）。 - **バーンダウンチャート**: Y 軸を「残り時間（0–30 時間）」、X 軸を日付とした折れ線グラフ。計画消費ラインは 30 から 0 への直線。実クラスタは階段状に消費。 - **失敗事例が可視化される**: Wolf クラスタ（Q2 2015）は高速ネットワーク障害で一晩停止、**予算をほぼ使い果たしてマイナス域に落ちた**。従来は「何時間損失したか」が不明確だったが、グラフで即座に見えるようになった。 - **予算の 5 用途**: ①計画維持報告、②施設工事計画（電源工事など）、③落雷対策バッファ、④ユーザー専用時間リクエスト管理、⑤技術的負債解消のための管理者時間。 - **SRE 普及の挑戦**: 「これは改宗・伝道の課題ではなく、コミュニティ形成の課題だ」——自分の環境に SRE 原則を適応させる方法を他者に教え、コミュニティを育てることが本質である。 ## 視覚的に重要な図表 **p.6 典型的な HPC クラスタ設計** ![[_attachments/2016__SREcon16Europe__Downtime-Budgets/page-006.png]] コンピュートノード・IO ノード・ログインノード・管理ノードが高速ネットワーク（InfiniBand 等）と管理ネットワークで接続。NFS と Lustre の 2 層ファイルシステム。この高速ネットワークの停止がクラスタ全体停止を招くため、メンテナンスはクラスタ単位になる設計上のトレードオフ。 **p.12 クラスタ利用率グラフ（LANL HPC 7 日間）** ![[_attachments/2016__SREcon16Europe__Downtime-Budgets/page-012.png]] cielito 25%・conejo 79%・moonlight 79%・mustang 85%・pinto 76%・wolf 84%・woodchuck 0% の 7 クラスタ。HPC では 80% が「良い」利用率の目安——大規模ジョブのスケジューリング待ちが必ず発生するため 100% は非現実的。 **p.23 バーンダウンチャート（計画消費ライン）** ![[_attachments/2016__SREcon16Europe__Downtime-Budgets/page-023.png]] Open DST Budget Q2 2015。Y 軸: 残り時間（0–30h）、X 軸: 2015-04-05〜2015-06-28。計画消費ラインは 30h から 0h への直線。実際の予算消費はこの直線との乖離で判断する。 **p.25 Wolf クラスタのバジェット超過（Q2 2015）** ![[_attachments/2016__SREcon16Europe__Downtime-Budgets/page-025.png]] Planned Budget（青線）に Moonlight（橙線）と Wolf（緑線）を重ねた 3 線グラフ。Wolf は 2015-05-03 に急落し **−12h 程度まで落下**。高速ネットワーク障害で一晩停止した影響。口頭説明では「翌月は追加メンテナンスができなかった」と補足（Source: transcript）。 **p.26 Q2 2015 全クラスタ（7 系統）** ![[_attachments/2016__SREcon16Europe__Downtime-Budgets/page-026.png]] Cielito・Conejo・Mapache・Moonlight・Mustang・Pinto・Wolf の 7 クラスタ＋計画ライン。全体としては計画ライン近辺で推移しているが、Wolf だけがマイナス域に落ちている。Pinto は四半期を通じて約 3 時間しか使わず、大量の余剰時間が生じた。 **p.27 Q3 2015 全クラスタ（悪い四半期）** ![[_attachments/2016__SREcon16Europe__Downtime-Budgets/page-027.png]] 2015-09-06 前後に施設停電（計画済み電源工事）で全クラスタが一斉にドロップ。大半がマイナス域（最大 −30h 近く）に達した。1 系統のみ軽微な落下に留まった。口頭では「施設チームと四半期ごとに調整して予算を確保する必要性」として言及（Source: transcript）。 ## 口頭説明・補足（transcript） - **9 to 5 ショップの問題**: LANL の HPC クラスタは 9–17 時運用。夜間に停止が続いた場合「帰宅して翌朝来るか、残業で復旧するか」の判断が曖昧だった。バーンダウンチャートで「一晩停止 = 四半期予算の大半を消費」が可視化されたことで、意思決定が変わった。 - **Wolf の事例の詳細**: 高速ネットワーク停止後、翌日の復旧まで誰もジョブを実行できない状態が続き、予算を"止まったまま"消費した。その結果、同四半期中に追加メンテナンスが実施不能になった。 - **施設停電（Q3 2015）**: ラスアラモスでは夏季に落雷が頻発（年 1–2 回は機械室停止）。水冷設備の敷設工事では機械室の電源を 1–2 時間停止する必要がある。これらを四半期計画に組み込む必要がある。 - **技術的負債の「消火ヘリ」比喩**: 森林火災を消す消防ヘリを比喩として使い、「四半期末に 3 時間余れば、積み残していたスイッチ再起動等のメンテナンスをする」という用法を説明。 - **Q&A「報告の抽象度」**: 資金提供元（DOE）への報告は管理層が上がるにつれ抽象化が必要。ただし「80% が良い利用率」という説明は常に要る——なぜ 100% にならないかを説明しないと理解されない。 - **Q&A「ユーザー専用時間の事例」**: 四半期の残余予算を見て「あと 3 時間ある、ユーザーの専用時間リクエストを承諾できる」と判断できるようになった。 ## Q&A - **Q: DOE への予算報告をどう抽象化するか？** → 管理層ごとに抽象度を上げる。科学時間（Science/hr）タコメーターが核心指標。 - **Q: 9–17 時ショップでの夜間超過はどう扱うか？** → バーンダウンチャートが可視化することで「一晩停止のコスト」が定量化され意思決定基準になった。 - **Q: クラスタのアーキテクチャ構成は？** → 全クラスタが均質構成（同時購入・同時リタイア）。InfiniBand 等の高速ネットワークのみ特殊。x86_64 中心。GPU 搭載クラスタも一部。 ## 概念・実体への接続 - [[エラーバジェット]] — 本スライドはエラーバジェットを HPC 環境に適応した実践例。単位を「リクエスト失敗率」でなく「計画外停止時間」に変換することで移植を実現。 - [[並列ファイルシステム]] — Lustre が主要 HFS として登場。クラスタ全停止の理由の一つ（FS 変更は全停止が安全）。 - [[HPCワークロード特性化]] — LANL のジョブ特性（64–64,000 コア、1–24 時間、6,000 ジョブ/日）は HPC ワークロード特性化の実例。 - [[Cory Lueninghoener]] — 本スライドの著者。 - [[Los Alamos National Laboratory]] — 発表者の所属。米国 DOE の国家安全保障研究所。 ## 限界・不確実点 - transcript は YouTube 自動字幕（機械精度）。固有名詞（Cielito → "ciolito"、Lueninghoener → "leaninghaver"）に誤りあり。数値はスライド画像を正とする。 - 各グラフの個別クラスタ名（Wolf は判読可）と実際の停止時刻は、スライドから読み取れる範囲のみ。 - 実装状況は「まだ概念実証段階（proof of concept）」と明示（p.22）。本番導入の詳細不明。