[レポート] HPC ワークロードを AWS を使ってモダンにしようチョークトークに恐る恐る参戦してきました #reinvent #ENU402

AWS re:Invent 2022 で行われた Chalk Talk 「Modernizing HPC workloads using AWS services」のレポートです。

400 - Expert の Chalk Talk 初参戦だったのでどんな感じで進むのかをご紹介します。それではどうぞ。

概要

For decades, industries have been using high-performance computing (HPC) to solve problems that are not solvable on a single machine or to shorten problem-solving run time. Traditionally, HPC workloads are launched and managed on the master node, which represents a single point of failure. Building HPC clusters on AWS allows you to keep the same user experience of launching, monitoring, and managing an HPC workload. In this chalk talk, learn how to launch, monitor, and manage an HPC workload using native AWS services, following a seismic processing problem as an example.

登壇者

• cyril lagrange
  • Solution Architect, AWS
• Kun Jiao, Energy Principal
  • Solutions Architect, AWS

Let's Talk

チョークトークと言うくらいですのでホワイトボードがあります。最大30名程度のお部屋でほぼほぼ席は埋まりました。

前半戦

ホワイトボードを使ったディスカッション前に認識をあわせるために説明がありました。そのアジェンダです。

Seismic processing の簡単な説明からはじまりました。胎児のエコー写真の例や、地震のデータ解析のために地層の確認などで用いられている技術です。

実際に使われた動画ではありませんが、動画の方がわかりやすいので以下のリンクをご確認ください。

エコーで収集するデータは最大100TB、そこからデータ解析処理を行い 3D のデータに起こしたものが最大100GBみておくという条件を説明されていました。

オンプレの HPC 環境は標準的な構成を仮定していました。

データ解析フローの説明です。ポイントは解析処理している箇所をクラウドを利用して実質無制限のスケーラビリティを手に入れられるので考慮したい。

マネージドサービスを活用したり、マイクロサービス化したりしてモダンな構成を考えてみよう！

ここで説明を受けた地震のデータ解析を行うためのオンプレ HPC 環境をクラウドで同様の冗長性や、モニタリングをもたせて実現にするにはどうしたらいいか？が本題で後半戦に進みます。

エキスパートレベルの Chalk Talk になると AWS の話は一切説明がありません。AWS ParallelClusetr だと冗長化が鍵に、AWS Batch ではオンプレスパコンで実現していた処理をコンテナ化できるのか鍵になってきます。今回ですと AWS と HPC 周りの知識は前提として持っている必要がありました。

辛かったのは部屋がそこまで大きくないこともあり、小さめなマイクの音が絶妙に反響して話している内容が聞き取りにくくて困りました。地震データ解析周りは知らない単語も（きっと）多くまったく聞き取れないところもありました。（一応、録音しておいたのですが音質が悪すぎて振り返りには利用できませんでした。)

話振られた前提を理解していない上で話すのは厳しすぎると内心だいぶ焦りました。

後半戦

ディスカッションベースで設計していくのかなと思っていたのですが、登壇者の方が用意した案を紹介しながら質問受けて質問者の疑問を解消していきながら進めるかたちでした。最終的な書き終わったときの構成がこちらです。

AWS ParallelClusetr ベースでも、AWS Batch ベースでもなく、サーバレスアーキテクチャでした。

ホワイトボードに書いた内容は大きなディスプレイで確認できたため、ホワイトボードの真ん前の方以外はディスプレイを見ていたと思います。私の席の位置からでは物理ホワイトボードの文字は読めませんでした。

データ解析ジョブを投げるフロントエンドは Web サイトかなんか用意して、API Gateway -> Lambda -> DynamoDB でジョブを管理する構成です。ジョブスケジューラー（Slurm など）の簡易を自前で実装するかたちでした。

ジョブを受けたらデータ解析処理するをバックエンドは Step Functions で管理し、並列処理可能な部分があるので SQS でキューイングをはさみます。キューをトリガーにオートスケール可能な EC2 か、ECS on EC2 で解析処理を行います。Analisis から Iteration までの処理は同様の構成をとっています。とくに並列処理が求められるデータ解析を行う Shot Prosesing は GPU インスタンスを想定していました。

ワンショットのオーダーは 0.1 - 1時間、大きなサイズの一時ファイルが1TB生成される想定でストレージは FSx for Lustre を選定していました。

EFS ではどうだろうかという質問に対して、EFS も正解、正解だけど HPC ワークロードを考慮し、スループットと IOPS 面で FSx for Lustre が良いだろうと簡単に Lustre の説明をしてくれました。

モニタリングは Grafana を使ってダッシュボードを用意する構成を説明されていました。

実際に構築するときどうしたらよいだろうか？という質問に対しては、AWS CDK を紹介していました。HPC ユーザーには AWS CDK は遠い存在な気もするので、コンストラクタの概念からはじまり厚めに CDK の説明をしてくれました。

構成についてはこれも1つの解答だけど、AWS にはいろいろなサービスがあるからねとしめくくり時間になり終わりました。

おわりに

本当はもっと質問があったのですが、質問者の声はマイクがないため近い人の声しか聞こえずメモれませんでした。後で録音を聞きなおせばよいかと回答もメモらなかったので紹介できずじまいになってしまいました。英語力不足でツヨツヨエンジニアに質問できない & 勇気がないのは機会損失だったのが悔いの残るところです。最後に思うことは知っている分野だから聞き取れたけど初見の分野だとまったくわからないまま終わっていた気がします。