Mission Control 2.5、Run:aiのKubernetes作業に復旧機能を拡張

NVIDIA は十月二十六日の記事で、Mission Control 2.5 の自動復旧エンジンを NVIDIA Run:ai が管理する Kubernetes の作業にも広げたと説明した。従来の対象は Slurm を使う高性能計算の作業だった。本稿の掲載日は十月二十八日で、製品記事の発表日とは異なる。記事が示すのは機能の範囲と故障時の設計であり、平均修理時間、稼働率、費用の改善を測った比較ではない。「自動復旧」という名称だけから、あらゆる学習作業が無損失ですぐ再開できると推論してはいけない。

仕組みには三つの責任がある。Kubernetes のスケジューラーは利用可能な機器へ作業を配置する。自動ジョブ復旧サービスは失敗時の文脈を記録し、再試行、再配置、担当者への引き継ぎを判断する。自動ハードウエア復旧サービスは問題のある機器を隔離して診断する。作業を健康な機器で動かし直すことと、故障機器を調べることを並行させれば、完全な原因分析を待たずに計算を戻せる可能性がある。どの地点から再開できるかは、作業側のチェックポイントや設定にも左右され、記事は普遍的な再開保証を示さない。

一つ目の例は学習中の GPU 障害だ。訂正不能なメモリーエラー、作業プロセスの停止、通信の時間切れなどが手掛かりになる。ジョブ復旧側は失敗の情報と疑わしい機器を確認し、スケジューラーを介して健康な場所で再起動または再配置を進める。同時にハードウエア復旧側は対象ノードを割り当て不能にし、理由を記録し、診断を始める。古いノードが次の作業に使われるのを防ぐ意図があるが、記事の図は想定した処理の流れを示すもので、実際に起きた事故数や成功率を表すものではない。

二つ目は一時的なソフトウエアの失敗である。作業プロセスが終了したり短時間の通信問題が起きたりしても、機器そのものは健康かもしれない。その場合は方針に従って作業をやり直し、無用にノードを隔離しない。繰り返す失敗や再試行できない障害は、自動処理を抜けて調査に回す。三つ目は故障前に兆候を捉える場合だ。健康警告や接続問題が続くノードを新しい作業の候補から外し、先に診断する。三つの例は、すべての失敗を機器故障として扱うことも、すべてを単なるソフトウエアの揺らぎとして扱うことも避ける設計を説明する。

運用チームが採用を判断するには、自分たちの学習手順で障害を注入し、作業の完了率、失ったチェックポイント以降の計算、隔離による空き容量、復旧時間を測る必要がある。誤った隔離は健康な計算機を使えなくし、誤った再試行は同じ機器で障害を繰り返す。記事は Mission Control 2.5 の文書とリリースノートも案内するが、そこへのリンクが本記事に欠ける定量比較を補うわけではない。確認できる新事実は Run:ai 管理の Kubernetes 作業への対応拡大と、ジョブ、機器、配置を分けた制御の説明である。

本媒体が十月二十六日に掲載した Minerva の監視や GPU 利用率の議論を、この復旧機能の成果として流用してはならない。その記事が参照した NVIDIA の原文は十月二十二日に公開された。監視の信号と復旧の判断は関係するが、原文はそれぞれ別の仕組みを説明している。とくに図の中の作業手順の数は、現場で起きた事故の件数を表していない。機能の説明と実測の改善を分けることが、今後の比較に必要な基準になる。