クラウド規模での Western Digital HDD シミュレーション – HPC タスク 250 万件、EC2 スポットインスタンス 4 万個

今月の初めに、同僚の Bala Thekkedath がエクストリームスケール HPC についての記事を公開し、AWS のお客様である Western Digital が AWS でクラウド規模の HPC クラスターを構築し、それを使用して次世代ハードディスクドライブ (HDD) のための将来のヘッドにおける極めて重要な要素をシミュレートした方法について語りました。

この記事で説明されているシミュレーションには 250 万強のタスクが含まれており、その実施は vCPU 100 万個の Amazon EC2 クラスター上でわずか 8 時間で完了しました。Bala がその記事で述べたように、Western Digital でのシミュレーション作業のほとんどが、HDD を包含するテクノロジーとソリューションの異なる組み合わせを評価する必要性を中心に展開されています。エンジニアはその過程において、ますます多くのデータを同じ領域に詰め込むこと、ストレージ容量を改善すること、そして転送速度を向上させることに焦点を当てます。材料、エネルギーレベル、および回転速度の何百万もの組み合わせのシミュレートすることは、Western Digital が最も高い密度と最も速い読み取り/書き込み時間を追求することを可能にし、結果をより迅速に得ることは、より良い判断を行うことを可能にすると共に、新しい製品を以前より速く市場に出すことができるようにします。

以下は、Western Digital のエネルギーによる記録処理が行われる様子を可視化したものです。上の横棒は磁気、中央の横棒は付加されたエネルギー (熱)、そして下の横棒は磁気と熱の組み合わせによって媒体に書き込まれた実際のデータを表しています。

先日、私は記録を塗り替えるこのシミュレーションを実現するために共に取り組んだ私の同僚、Western Digital のチーム、そして Univa に話を聞きました。私の目的は、このシミュレーションのための準備方法についての詳細を解明し、彼らが学んだ事柄を理解して、独自の大規模ジョブを実行する準備が整っている皆さんとそれらを分かち合うことでした。

規模の拡大
約 2 年前、Western Digital チームは、可能な限りコスト効率を良くするために、EC2 スポットインスタンスによって作動する、vCPU 8 万個もの大きさのクラスターを実行していました。クラスターは、8,000 個、1 万 6,000 個、および 3 万 2,000 個の vCPU でのシミュレーションを繰り返し実施し、成功を収めた後で vCPU 8 万個のレベルに拡大されました。当初の成功を収めた後、彼らは思い切ってその限界を押し上げ、100 万個の vCPU でのシミュレーションに向けて取り組むことにしました。これが既存のツールを圧迫し、重い負担をかけることはわかっていたため、彼らは把握/修正/もう少し拡大、という手段を取ることにしました。

Univa の Grid Engine はバッチスケジューラです。これが、利用可能なコンピューティングリソース (EC2 インスタンス) を追跡し、可能な限り迅速かつ効率的に作業をインスタンスにディスパッチする責任を担います。目的は、ジョブを最短時間内に最小コストで完了させることです。Univa の Navops Launch はコンテナベースのコンピューティングをサポートし、Grid Engine と AWS Batch への同じコンテナの使用を可能にすることによって、このシミュレーションの実施における重要な役割を果たしました。

興味深いスケーリング課題のひとつは、5 万個のホストが Grid Engine スケジューラに対して同時接続を作成したときに発生しました。実行されると、スケジューラは毎秒最大 3000 件のタスクをディスパッチできます。インスタンスが予期せず終了する場合 (比較的まれなケース) には追加のバーストがあり、64 件以上のタスクを可能な限り迅速に再スケジュールする必要を伝えます。チームは、IP アドレスでワーカーインスタンスを参照することによって、Elastic Network Interface ごとの DNS　ルックアップの数に対する内部 (AWS) レート制限の一部を回避できることも発見しました。

利便性のため、シミュレーションの全体がひとつの Docker コンテナに格納されました。新たに起動されたインスタンスがオンラインになると、これらはそれぞれの仕様 (インスタンスタイプ、IP アドレス、vCPU 数、メモリなど) を ElastiCache for Redis クラスターに登録します。Grid Engine は、インスタンスの検索と管理にこのデータを使います。これは、継続的に DescribeInstances を呼び出すことよりも効率的でスケーラブルです。

シミュレーションタスクは Amazon Simple Storage Service (S3) に対してデータの読み書きを行い、大量のデータを保存して、考えられるあらゆるリクエストレートを処理する S3 の能力を活用します。

シミュレーションタスクの内側
可能性のあるヘッドデザインのそれぞれがパラメーターの一群によって記述され、全体的なシミュレーションの実施はこのパラメーター空間の探求で構成されます。シミュレーションの結果は、設計者が構築可能で信頼性があり、製造可能なデザインを見つけるために役立ちます。この特定のシミュレーションの実施は、書き込み操作のモデル化に焦点を当てていました。

各シミュレーションタスクは、EC2 インスタンスタイプに応じて 2～3 時間実行されました。スポットインスタンスが終了寸前であるという場合に作業を失ってしまわないように、ジョブが終了シグナルの後、ただし実際のシャットダウン前に終了する重要なケースを保護するための小さな追加ロジックによって、タスクは 15 分ごとに S3 に対して独自のチェックポイントを作成します。

シミュレーションの実施
たった 6 週間の計画と準備の後 (入力ファイルを生成するための複数の大規模な AWS Batch の実行を含む)、Western Digital / Univa / AWS の共同チームは、本格的なシミュレーションを実施する準備を整えました。Grid Engine の開始とクラスターの起動には AWS CloudFormation テンプレートが使用されました。前に説明した Redis ベースの追跡によって、タスクはインスタンスが利用可能になった時点でディスパッチすることができました。クラスターは 1 時間 32 分で 100 万個の vCPU に成長し、6 時間フル稼働しました。

ディスパッチされていないタスクがなくなったとき、Grid Engine はインスタンスのシャットダウンを開始し、約 1 時間でインスタンスがゼロの状態に到達しました。実施中、Grid Engine はインスタンスに作業が十分に供給されている状態をほぼ完全に (99% 以上) 維持することができました。このシミュレーションの実施には、C3、C4、M4、R3、R4、および M5 のインスタンスの組み合わせが使用されました。以下は、シミュレーションの実施過程における全体的な内訳です。

ジョブは米国東部 (バージニア北部) リージョン内の 6 つのアベイラビリティーゾーンにスパンされました。スポット入札はオンデマンド価格で行われました。実施過程の全体において、フリート内の約 1.5% のインスタンスが終了され、自動的に置き換えられましたが、この間、インスタンスの大多数が実行状態を維持しました。

というわけで…
このジョブは 8 時間実行され、コストは 137,307 UDS (1 時間あたり 17,164 USD) でした。私が話を聞いた人たちは、これが社内のクラスター (このサイズのものがあれば、の話ですが) での実施コストの約半分だと推定しています。

このシミュレーション実施の成功を評価して、スティーブ・フィルポット氏 (Western Digital 最高情報責任者) はこのように話しました。

「ストレージ技術は驚くほど複雑で、私たちは次世代の性能と技術的なイノベーションを実現するべく、常に物理的特性とエンジニアリングの限界に挑戦しています。成功を収めたこの　AWS とのコラボレーションは、クラウドベースの HPC の極限的なスケール、力、そして俊敏性を示しており、私たちが未来のストレージアーキテクチャの分析と材料科学の探求のための複雑なシミュレーションを実施するために役立ちます。AWS を使用してシミュレーション時間を 20 日から 8 時間に簡単に短縮したことにより、Western Digital R&D チームは、ほんの少し前には想像もできなかったペースで新たなデザインとイノベーションを探求することができました。」

このシミュレーションを後押しした Western Digital チームは R&D エンジニアリングテクノロジスト、およびその他職種の人材を募集しています!

独自のシミュレーションの実施
10 万個から 100 万個レベルのコア (またはそれ以上) での実施をご希望の場合は、AWS の HPC チームに加えて、Univa の仲間がいつでもお手伝いします。開始するには、HPC セールス担当者までご連絡ください!

— Jeff;