Ansys LS-DYNA のチェックポイント機能でスポットインスタンスのコストを最適化する方法

この投稿はシニアパートナーソリューションアーキテクト (HPC) の Dnyanesh Digraskar とシニアパートナーデベロップメントマネージャの Amit Varde によるものです。

様々な組織がハイパフォーマンスコンピューティング (HPC) のワークロードを、高い可用性、柔軟なキャパシティ、最新のプロセッサやストレージ、ネットワーク——そしてこれらは従量課金で使った分だけの支払いになる——といった利点を理由にオンプレミスのインフラストラクチャから Amazon Web Services (AWS) へと移行しています。これらの便益は有限要素分析 (Finite Element Analysis、FEA) のような、CPU やメモリを多く必要とするワークロードでコストを減少したりより短い時間で結果を得られるようになることで、エンジニアリングチームに利します。

FEA のワークロードを AWS で実行する時、コスト面で支配的な要素は Amazon EC2 インスタンスの利用料です。このような場面で Amazon EC2 スポットインスタンスはコスト効率の高い選択肢になります。スポットインスタンスは Amazon EC2 サービスの未使用のキャパシティを活用し、オンデマンドインスタンスの価格と比べて最大 90% の割引で EC2 インスタンスを使うことができる購入オプションです。

この記事では、Ansys LS-DYNA のチェックポイント機能と自動再開ユーティリティをスポットインスタンスと組み合わせることでフォールトトレラントな FEA ワークロードを構築しつつ、スポットインスタンスによるコスト削減の利益を享受する方法を紹介します。

スポットインスタンスの仕組み

スポットインスタンスは AWS クラウドにある、EC2 サービスの使われていないキャパシティで、オンデマンドインスタンス価格と比較して大幅な割引で提供します。その代わり、中断が発生するという特徴があります。これは、EC2 サービスがキャパシティを必要とするときにスポットインスタンスの使用していたキャパシティを戻す、というルールです。EC2 の空きキャパシティは、24 のリージョンで 77 個のアベイラビリティゾーンに渡って、375 以上のインスタンスタイプを、いついかなるときにも、どのようなリクエストにも応じられるように EC2 サービスが準備しているものです。その結果使われなかった部分があり、これを遊ばせずに提供しよう、というのがスポットインスタンスの考え方です。

ある時点で利用可能な EC2 サービスの空きキャパシティと場所 (リージョンやアベイラビリティーゾン) は動的で、リアルタイムで変化します。これが、スポットユーザーにとって、中断してよいワークロードだけをスポットインスタンスで稼働させるというのが重要である、と言われる理由です。付言すると、スポットインスタンスのワークロードは、余剰キャパシティがある場所へリアルタイムで移動できる (或いは余剰キャパシティが再度発生するまで停止しておく) ような柔軟性があるべきです。スポットインスタンスの仕組みと様々な活用シーンに関する更なる詳細はこちらのホワイトペーパーをご覧下さい。

ソリューション全体

lsdyna-spotless ツールキットとして知られる Ansys LS-DYNA のチェックポイントユーティリティは、次の構成図 (図 1) にあるようにスポットインスタンス上でのシミュレーションジョブを監視するためのメカニズムを使っています。

Figure 1: Architecture for monitoring spot interruptions and restarting jobs.

図 1: ジョブの再開と一時的な割り込み監視の構成

上記の構成図で表わされるフローは、次のような流れになります。

ユーザは単一 (或いは一連の) Ansys LS-DYNA のジョブをクラスタのヘッドノードで投入します
それぞれのジョブはユーザの設定に基づき複数の Message Passing Interface (MPI) タスクに分割されます。
モニタデーモンpollが各計算ノードに送られ、全ての MPI タスクのために EC2 メタデータからの中断シグナルをポーリングします。
中断シグナルを受けとったら、実行中のシミュレーションのチェックポイントを作成し、ヘッドノードと計算ノードの両方からアクセスできる/shared ドライブへ保存します。
ジョブ再開デーモンjob-restarterは要求したキャパシティが再利用可能になった時点でジョブをクラスタのキューへ再投入します。

これでユーティリティとコマンドの動きの概要は掴めました。では次に、ldsyna-spotless ユーリティティを使った Ansys LS-DYNA シミュレーション環境の設定方法の詳細を見ていきましょう。これによってインスタンスコストの概観とその影響を理解できるでしょう。

シミュレーション環境のセットアップ

LS-DYNA の環境をクラスタのヘッドノードにセットアップする方法は次の通りです。

最新の Ansys LS-DYNA をダウンロードしてヘッドノードへインストールします。この記事ではバージョン R12 を利用します。GitHub のリポジトリからツールキットをダウンロードし解凍します。
env-var.sh に幾つかのカスタマイズオプションを設定します。
MPPDYNA 変数に Ansys LS-DYNA の実行ファイルのパスを設定します。

ライセンスサーバと SLURM キューを変数に設定します。

$ export LSTC_LICENSE_SERVER=” IP-address-license-server ”
$ export SQQUEUE=” your-SLURM-queue-name ”

env-vars.sh を source コマンドで取り込み、環境変数を設定します。
```
$ source env-vars.sh
```
パッケージに含まれる全てのツールを手順 2 で設定したパスにコピーします。
```
$ cp * /shared/ansys/bin
```

ジョブの起動

必要な環境設定を終えたので、チェックポイントユーティリティを有効化したフォールトトレラントな Ansys LS-DYNA なジョブをコマンドで投入してみましょう。

それぞれのジョブは、固有の SLURM ジョブスクリプトと一意な名前のディレクトリがあると想定されています。また、主な入力データとして Ansys LS-DYNA では main.k と名付けられたファイルが必要です。もしファイル名が異なる場合は変更するか、あるいはシンボリックリンクを作成して下さい。

ジョブを開始するには次のようなコマンドを使います。

$ start-jobs 2 72 spotq.slurm job-1 job-2 job-3

このコマンドでは 3 つの Ansys LS-DYNA の MPI ジョブを投入しています。それぞれのジョブが 2 ノードでノード毎に 72 のタスクに設定されているので、1 ジョブ当たり 144 タスクになります。

以下の例は SLURM スケジューラ向けの sportq.slurm のジョブスクリプトです。

#!/bin/bash
#SBATCH -J job # Job name
#SBATCH -o job.%j.out # Name of stdout output file

INPUTDECK="main.k"

if ls d3dump* 1>/dev/null 2>&1; then
mode="r=$(ls -t d3dump* | head -1 | cut -c1-8)"
op="restart"
else
mode="i=$INPUTDECK"
op="start"
fi

# create/overwrite checkpoint command file
echo "sw1." >switch

# launch monitor tasks
job_file=$(scontrol show job $SLURM_JOB_ID | awk -F= '/Command=/{print $2}')
srun --overcommit --ntasks=$SLURM_JOB_NUM_NODES --ntasks-per-node=1 $SQDIR/bin/poll "$SLURM_JOB_ID" "$SLURM_SUBMIT_DIR" "$job_file" &>/dev/null &

# Launch MPI-based executable
echo -e "$SLURM_SUBMIT_DIR ${op}ed: $(date) | $(date +%s)" >>$SQDIR/var/timings.log
srun --mpi=pmix_v3 --overcommit $MPPDYNA $mode
echo -e "$SLURM_SUBMIT_DIR stopped: $(date) | $(date +%s)" >>$SQDIR/var/timings.log

実行中のジョブを停止するには次のコマンドを使います。

$ stop-jobs

実行時間とコストへの影響

合計 10 個のジョブを 2 つの c5.18xlarge のスポットインスタンスに投入し、lsdyna-spotless ツールキットを使いジョブ毎に 144 MPI タスクを割り当てました。監視ユーティリティはそれぞれのジョブの状態変化を監視していて、割り込みがあるか無いかを確認しています。ジョブの開始時間と終了時間を分析するために、中断中の時間は除外されるので、実際の実行時間の推測が可能です。また、中断時間を含む合計時間と実行時間を比較することでスポットインスタンスの中断によるオーバーヘッドも見て取れます。時間データを簡単に集計するためのユーティリティ (calc-timing) も用意されていて、今回の 10 ジョブの例であれば以下のような出力が得られます。

$ calc-timing ../var/timings.old
job /shared/lstc/neon finished in 1543 seconds, after interrupt (s).
job /shared/lstc/neon-9 finished in 1308 seconds, uninterrupted.
job /shared/lstc/neon-8 finished in 1333 seconds, uninterrupted.
job /shared/lstc/neon-1 finished in 1478 seconds, after interrupt (s).
job /shared/lstc/neon-3 finished in 1279 seconds, uninterrupted.
job /shared/lstc/neon-2 finished in 1537 seconds, after interrupt (s).
job /shared/lstc/neon-5 finished in 1313 seconds, uninterrupted.
job /shared/lstc/neon-4 finished in 1295 seconds, uninterrupted.
job /shared/lstc/neon-7 finished in 1334 seconds, uninterrupted.
job /shared/lstc/neon-6 finished in 1304 seconds, uninterrupted.
10 jobs finished and they finished in 13724 seconds in CPU time.
Wall clock time: 14669 seconds elapsed.

上記の例で発生した中断は Amazon EC2 メタデータモックツールでユーザが手動で発生させたものであり、スポットインスタンスの実際のパフォーマンスと可用性を表わしているわけではありません。

10 個のジョブの内 3 つのジョブで中断が発生しています。中断の影響を受けた 3 つのジョブの実行時間は平均して 11% 増加しています。しかしながら図 2 の通り 11% の実行時間の増加で、オンデマンドインスタンスと比べて約 60%、コストを削減できています。図の中では実行時間が青い棒グラフで、総インスタンスコストが赤い三角形で表わされています。

Figure 2: Comparison of turnaround times and cost for running a set of 10 Ansys LS-DYNA jobs on Amazon EC2 On-Demand and Spot Instances.

図 2: Ansys LS-DYNA のジョブで Amazon EC2 オンデマンドインスタンスとスポットインスタンスを使った際の実行時間とコスト比較

クラスタ設定と AWS サービス

今回の記事のテストのために AWS 上に構築した HPC クラスタの構成は以下の図 3 にあります。今回のケースでは Amazon EC2 のコンピュート最適化の C5 スポットインスタンスを使いました。Amazon EC2 C5.18xlarge インスタンスは 3.4GHz の Intel Skylake-SP の CPU を 36 コア搭載しています。Amazon Elastic File System (EFS) ドライブがヘッドノードにアタッチされていて、アプリケーションのファイルを格納し計算ノードと共有するのに役立ちました。各計算ノードから収集されたシミュレーションのチェックポイント情報も Amazon EFS ドライブに保存されています。

以下が構成図です。

Figure 3: Architecture for deploying LS-DYNA on AWS using AWS ParallelCluster.

図3: ParallelCluster を使い AWS 上で LS-DYNA を実行するための構成

AWS ParallelCluster は AWS によってサポートされているオープンソースのクラスタ管理ツールで、HPC クラスタのデプロイと管理に利用できます。Ansys LS-DYNA のチェックポイントユーティリティを動かす前提として SLURM のジョブスケジューラを AWS ParallelCluster で利用しています。Amazon Elastic File System (Amazon EFS) はユーザ自身でストレージを管理する必要無しにファイル共有に使える柔軟なファイルシステムです。Amazon EFS ドライブを共有することは、全ての計算ノードからシームレスにアクセスできるという意味でアプリケーションのチェックポイントデータを格納するには最適です。

更にスポットインスタンスを活用するために

ここまでで詳述してきた Ansys LS-DYNA のチェックポイントユーティリティを利用してスポットインスタンスの中断を監視し再投入する構成は、シミュレーション環境に更なるフォールトトレラントな運用を可能します。

そのような方法の一つは、インスタンスタイプを多様化する、つまり複数のインスタンスタイプを指定して Ansys LS-DYNA のシミュレーションを実行することです。これは AWS ParallelCluster のマルチキューとマルチインスタンスの機能を使えば実現できます。詳細は「Using multiple queues and instance types in AWS ParallelCluster 2.9」のブログ記事を参照下さい。EC2 のキャパシティと複数のインスタンスタイプを使うことで HPC クラスタは潜在的な中断可能性を低減し柔軟にジョブの投入が可能になります。

おわりに

エンジニアリングにより Amazon EC2 スポットインスタンスを活用したフォールトレラントな Ansys LS-DYNA シミュレーションが効果的に実行可能になりました。またこれによりオンデマンドインスタンス価格に比べて最大 60%のコスト削減も達成可能です。

この記事では、Ansys LS-DYNA の新しいチェックポイントユーティリティによって、スポットインスタンスの中断を考慮しつつ FEA のワークロードを実行できることを示しました。またこのユーティリティではインスタンスキャパシティが戻った時に HPC クラスタのキューにジョブを自動的に再投入することも可能です。

もし FEA や他の HPC ワークロードを Amazon EC2 スポットインスタンスと Ansys LS-DYNA を使って動かすことに興味があるならば、更なる情報は Ansys LS-DYNA solution のページにあります。

この記事は2021 年 9 月 27 日に投稿された「Cost-optimization on Spot Instances using checkpoing for Ansys LS-DYNA」をソリューションアーキテクトの小野が翻訳したものです。

Amazon Web Services ブログ