MPIの新しいセッションモデルにおける障害管理について

最新のメッセージパッシングインターフェース（MPI）のバージョンには、新しいセッションモデルなどの機能が追加されてるけど、効果的な障害管理については触れられてないんだ。前に作られたULFMみたいなツールや拡張機能が障害管理を手助けしてきたけど、これらのツールはMPIの最近の変更には完全には対応してないよ。

この記事では、ULFMの障害管理機能と新しいセッションモデルを組み合わせることに焦点を当ててる。障害を管理しながらコミュニケーターを作成する方法をじっくり見て、発生する課題に対処する方法を提案するよ。実験の結果、提案した解決策はアプリケーションの実行時間に大きな影響を与えず、障害をより良く管理しながらスケーラビリティを維持できることがわかった。

#MPIとその更新の背景

ハイパフォーマンスコンピューティング（HPC）は急速に進化していて、新しいエクサスケールクラスタは開発者やシステム管理者に新しい課題をもたらしてる。HPCの重要なツールの一つがMPIで、これは異なるプロセス間の通信の標準として機能してる。最新のバージョンMPI 4.0では、アプリケーションが通信を処理する方法が変わったよ。

MPIのセッションモデルは、複数の独立した通信インスタンスを許可して、アプリケーションの異なる部分が毎回グローバルなコミュニケーターなしで通信できるようにするんだ。これにより、オーバーヘッドが減り、実行が速くなる可能性がある。

HPCクラスタのノード数が増えるにつれて、障害が発生する可能性も上がってくる。現在のMPI標準は、障害が発生したときにアプリケーションがどう行動すべきかを明確には示していない。そのため、障害管理技術を導入するためのさまざまなツールが作られ、ULFMが最も目立つ存在になってる。ULFMは、障害の影響を受けたコミュニケーターを修復するための機能を追加するんだ。

#MPIセッションモデル

従来のMPI通信方法の課題は、単一の初期化呼び出しに依存していることだ。これが原因で、アプリケーションの複数の部分がMPI Init関数を呼び出そうとすると問題が起こることがある。セッションモデルは、各コンポーネントが独自に通信を管理できるようにして、モジュール性とスケーラビリティを向上させることでこれらの問題に対処してる。

セッションモデルでは、ほとんどの関数がローカルで、通信を必要としない。ただし、MPI Comm create from group関数だけは、関与する全プロセスからの入力が必要なんだ。コミュニケーターが作成されると、アプリケーションは従来のワールドモデルと同様に実行を続けることができるよ。

#ユーザーレベルの障害軽減（ULFM）

MPI標準は、障害が発生した後に何をすればいいかについてのガイダンスを提供していないため、開発者にとって障害管理が複雑になる。ULFMは、1つまたは複数のプロセスが失敗しても実行を続けることを可能にする解決策だけど、すべての障害タイプをカバーしているわけではない。たとえば、静かなデータ破損やタイミングエラーには、ULFMが対応していない特定の解決策が必要なんだ。

ULFMは、プロセスが突然停止することによる障害に焦点を当てている。しかし、MPI Init呼び出しの前や最中に何が起こるかについてのガイダンスは提供していない。これがセッションモデルの課題で、柔軟性があっても、正しく行わないと未定義の動作を引き起こす可能性がある。私たちの仕事は、セッションモデルの初期段階を分析して障害管理を改善することを目的としているよ。

#初期化フローの課題

私たちは、セッションモデルとワールドモデルの両方における初期化プロセスに対する障害の影響を評価してる。ワールドモデルでは、初期化中の障害が発生すると、アプリケーションが参加しないプロセスを無限に待ち続けるデッドロック状態になってしまうことがある。しかし、セッションモデルの構造のおかげで、初期呼び出しのほとんどがローカルで、いくつかのプロセスが失敗しても成功することができる。ただし、MPI Comm create from group呼び出しについては別だよ。

セッションモデルにおけるデッドロックの可能性は大きな懸念で、初期呼び出しが実行中のさまざまなポイントで発生する可能性がある。したがって、アプリケーションのパフォーマンスを維持しつつ、デッドロックのリスクを最小限に抑えることが重要なんだ。

#ホライゾンセットの導入

デッドロックの問題に対処するために、ホライゾンセットの使用を提案するよ。これらのセットは、既存のコミュニケーターを追跡するために設計されていて、少なくとも1つのコミュニケーターが常にLiveness Discovery Algorithm（LDA）が障害を効果的に管理できるように利用可能であることを確保するんだ。

LDAは、通信の作成中に障害を検出し管理する手助けをする。ホライゾンセットを慎重に定義することで、デッドロックの可能性を減らすことができる。新しいコミュニケーターを初期化する前に、コミュニケーターセットを作成するようにすることでこれが実現できる。

単純なアプローチではグローバルなコミュニケーターを作成してしまうけど、これはセッションモデルの柔軟性の目的を無にしてしまう。私たちの方法は、セッションモデルの利点を犠牲にすることなく、コミュニケーターをより効率的に管理する方法を提案しているんだ。

#実験結果

私たちの提案した解決策をテストするために、すでにLDAを実装しているLegioライブラリに統合したよ。実験では、クラスター上の実世界のベンチマークを使用してパフォーマンスとスケーラビリティへの影響を評価した。

ナイーブな解決策、ホライゾンセットサポート、障害管理なしの構成の3つのシナリオを比較するためにさまざまなテストを実施した結果、ナイーブアプローチは常に過剰なオーバーヘッドを招いていて、特にネットワークサイズが大きくなるにつれて顕著だった。対照的に、ホライゾンセットの解決策は、不要なグローバルコミュニケーターの初期化を必要とせずにアプリケーションのスケーラビリティを維持したんだ。

さらに、私たちのアプローチが障害に対してどれだけ耐性があるかを示すために、機能テストも実施したよ。私たちの解決策を利用したアプリケーションは、実行中に障害が発生しても無事に完了することができた。

#結論と今後の課題

私たちの分析と実装を通じて、セッションモデルを使用してMPIアプリケーションにおける障害の影響を効果的に管理することが可能であることを示してきた。ホライゾンセットの導入は、デッドロックリスクを減らし、スケーラビリティを向上させるのに役立つことがわかった。

今後の取り組みでは、私たちのアプローチをBubblesコンセプトのような他のMPI提案と統合したり、新しいベンチマークをテストしてセッションモデルの能力をさまざまなシナリオでさらに調べたりすることが考えられる。これらの継続的な作業は、障害が発生してもアプリケーションが堅牢かつ効率的であり続けることを目指しているよ。