KubeCon China 2024、GPUの故障を検知するOSSを解説するセッションを紹介
KubeCon China 2024から、MicrosoftのAzureのエンジニアとイギリスの自動運転システムのベンダーWayveのエンジニアとが共同で行ったセッションを紹介する。このセッションではGPUノードを使った機械学習ジョブにはアプリケーション、ネットワーク、オーケストレーターそしてハードウェアなど多数のコンポーネントが必要となり、複雑さが増していることを紹介して、多くの時間がかかる学習の段階で起こるエラーに対応するためのツールを解説する内容だ。
前半をWayveのSarah Belghiti氏が行い、後半のプレゼンテーションとデモをAzureでGPU周りのインフラエンジニアであるGaneshkumar Ashokovardhanan氏が行うという分担だ。
●動画:Detecting and Overcoming GPU Failures During ML Training
セッションのタイトルは「Detecting and Overcoming GPU Failures During ML Training」というもので、GPUを長時間使用して処理を行う機械学習ジョブにおいて、関連するさまざまなコンポーネントのヘルスチェックをどうやって行うのか? を解説している。
Belghiti氏は多数のGPUを使って分散処理を行う学習ジョブにはクラウドネイティブなシステムのプラットフォームであるKubernetesが向いているとして、基本的な特性を整理した。ここでは分散処理であること、ジョブをスケジューリングするツールが存在すること、GPUを利用するためのプラグインがNVIDIAから提供されていることなどを要因として挙げた。
その上でGPUのような複雑なハードウェアは、シンプルな構成のプロセッサに比べて故障する確率が高いことを紹介。ここでは具体的な例としてMetaの発表を引用し、2024年7月に発生した障害のうち、58.7%がGPU関連の障害だったとして、多くのGPUユーザーが抱えている問題を浮き彫りにした形となった。
またGPUの価格も高止まりしている現状で、高価なGPUが故障により稼働できないとすると経済的な損失は大きいと説明した。NVIDIAのデベロッパーカンファレンスでもいかに効率よくGPUをスケジューリングするのか? ということは何度も繰り返し語られる内容だが、それはハードウェアが正常に稼働していることが前提だろう。ハードウェア障害だけではなく、ソフトウェアに起因する異常停止や性能劣化、ネットワーク関連のトラブルなど、アプリケーションデベロッパーだけではなくインフラエンジニアにとっても大きな問題である。
デベロッパーにとってもインフラエンジニアにとっても、異常に対応するのであれば最初に必要なのは検知することだ。最終的にはジョブを障害が発生したノードから移動させ、修理もしくは交換などの対応が必要になる。
検知の最初の段階では、NVIDIAが提供するテストツールなどを使って事前にハードウェアやネットワークのヘルスチェックを行う必要があると説明。
ただし事前のチェックで正常と判定されてもジョブの実行中に異常が検出されることもあるとして、バックグラウンドで実行するヘルスチェックとワークロード、つまりジョブの中にヘルスチェックを組み込む方法があると説明。それぞれの長所と欠点を解説した。
ジョブの実行中に以上が発生した場合は、ジョブのチェックポイントファイルを生成して他のノードに移行して続行するという方法を紹介した。チェックポイントファイルが巨大になってしまう場合、いかにそれを移動するのかという問題点に触れていたセッションもあったが、ここでは簡単な説明に留まっていた。
またノードレベルの検知ではヘルスチェックだけではなくメトリクスやログにも注目してエラー処理を行うことが必要だと説明。
ここからはMicrosoftのAshokovardhanan氏に交代してインフラストラクチャーレベルでの対処方法を解説する内容となった。
エラーのレイヤーには4つの段階が存在するとして、スライドで説明。ここではアプリケーションの一つ下のレイヤー、Kubernetesが担うオーケストレーターの部分に特化して解説を行った。
最初に紹介したのはKubernetesの公式の検知ツール、Node Problem Detector(NPD)だ。
このツールは、本来GPUに特化したチェックを行うものではないと説明し、カスタマイズされたヘルスチェックジョブを行うCron JobやLBNL Node Health Checkを紹介。他にもAzureが開発しオープンソースとして公開しているツールも存在することを説明した。ちなみにLBNLはLawrence Berkley National Laboratoryの略で、米国の研究機関由来のオープンソースツールである。Node Health Checkについては以下の公式サイトを参照されたい。
ここでは構成ファイルなどを見せながら紹介を行っているが、Azureのツールはまだ実験段階という但し書きがついている状態だ。
Kubernetesにおいてはエラーを検出するだけではなく、そのエラーの内容に応じて対処を行うRemedy Controllerが実装されていることを紹介。
他にもエラーのシミュレーションを行うツールやKubernetesのノードを実際に立ち上げずにシミュレーションとしてクラスターを起動するKWOKなども紹介され、Kubernetesのエコシステムに数多くのツールが存在していることを紹介した。
KWOKについては以下の公式GitHubページ及びSIGのドキュメントサイトを参照のこと。
●参考:KWOK
●ドキュメント:Manage nodes and pods with kwok
ここからは実際にターミナルを使ってKubernetesのノードの状況を監視するデモなどを行った。
GPUのヘルスチェックについてはまだ多くの課題が残っているとしていくつかを紹介。特にGPUの機種やネットワーク接続の設定などによって必要なテストが変わってしまうこと、ヘルスチェック自体が負担となってしまうこと、そして処置不可能なハードウェア関連のエラーとソフトウェア的に対応可能なエラーの切り分けが難しいことなどを挙げた。
ここで他のツールも紹介し、LinuxからCUDAの処理中にチェックポイントを生成/リストアするツールCRIUやKubernetesのコミュニティにおいても多くの議論が行われていることを紹介した。
CRIUはNVIDIAのデベロッパー向けブログでも紹介されているツールで、x86ベースのLinux環境においてGPUの状態を保存、リストアするツールだ。
●NVIDIAによる解説:Checkpointing CUDA Applications with CRIU
●CRIU公式ページ:https://criu.org/Main_Page
冒頭の障害検知の部分以外はAzureのエンジニアが解説するセッションとなってしまい、WayveのBelghiti氏の出番が少なかったことが惜しまれるが、実際に機械学習を運用する際に高い確率でGPU関連の障害が発生していること、そしてそれに対応するツールも徐々に整備されていることが理解できる内容となった。
Wayveは自動運転システムを搭載した車輛を開発しているのではなく、OEMの形で自動車メーカーに提供するのがビジネスモデルのようだ。KubeEdgeを搭載する車輛そのものを製造するNIOとはビジネスモデルが異なるということだろう。クラウド側はMicrosoftのAzureがバックエンドという関係だろうか。今後の進化が楽しみである。
Wayveについては以下の公式サイトを参照されたい。
●Wayve公式サイト:https://wayve.ai/
連載バックナンバー
Think ITメルマガ会員登録受付中
全文検索エンジンによるおすすめ記事
- KubeCon China 2024、Kubernetes上でMLジョブのフォルトリカバリーを実装したKcoverのセッションを紹介
- CloudNative Days Tokyo 2023から、NVIDIA H100を80基使ったKubernetesベースの機械学習プラットフォームを解説
- 「kwok」でKubernetesクラスターをシュミレーションする
- Microsoft AzureのCTO「人工知能の進化はOSSとクラウドのおかげ」と語る
- KubeCon EU 2022からバッチシステムをKubernetesで実装するVolcanoを紹介
- NutanixのアーキテクトがNutanixの未来を語る
- コンテナは場所を選ばない!「オンプレ or クラウド×コンテナ」(後編)
- ハイパーコンバージドのNutanix、最新のソフトウェアスタックを紹介
- レプリケーション&負荷分散!
- FPGAのXilinxが年次カンファレンスを開催。データセンター、5G、自動運転にフォーカスしたキーノートを紹介