この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
AWS を使った大規模なクラウド HPC の実行環境で Harvard Medical School 様の事例があります。約230万 vCPU を利用した実行例として有名ですが、VirtualFlow を AWS Batch で実行しているとのことで構成に興味があったのでどういった構成なのか調べていました。
創薬分野の基礎知識がないと紹介動画を見ても話されている内容が難しかったので、調べたかった構成とともに VirtualFlow 周辺について勉強した内容をまとめておきます。
最初に抑えておきたい用語
私は創薬分野に疎いので専門用語がサッパリわかりませんでした。先に用語の意味を把握しておくと話の内容が入って来やすくなると思います。
ドッキングシミュレーションとは
バーチャールスクリーニングと呼ばれる効果がありそうな薬の候補（化合物）を見つけるというステップがあり、その手法のひとつにドッキングシミュレーションというものあります。非常に浅い理解ですと薬の標的となるタンパク質（図の立体構造の白い物体）に薬の候補となる数億とある化合物（3次元の分子構造）がいい感じにふっつくか、ふっつかないかをひたすら試していく処理のようです。
画像引用: HCLS Symposium 2021: Harvard Medical School - YouTube
この処理にはマシンパワーが必要になり、立体構造の特定箇所にうまくふっつくものを数億ある候補から探し続ける処理なので計算量が多いのも納得です。そのため、この処理にはいわゆるスパコンが利用されています。
VirtualFlow とは
VirtualFlowはバーチャールスクリーニングのアプリケーションの OSS です。Linux ベースのクラスターシステム上で並列実行できるワークフロープラットフォームです。Slurm などのジョブスケジューラーに対応しています。
ドッキングシミュレーションのイメージと VirtualFlow 開発の経緯も含め以下のリンクで紹介されている動画がわかりやすかったです。（わかった気になれただけです）
VirtualFlow Project | Christoph Gorgulla
以降のセッション動画は Harvard Medical School の Christoph Gorgulla さんが VirtualFlow を AWS 上で動かした話をしてくれています。興味のあった構成に関する部分をメモがてらキャプチャとともに簡単に紹介します。
re:Invent 2021
AWS Batch で約230万vCPU を利用した計算処理を行った Harvard Medical School の事例です。
薬の候補となる化合物を発見するためにドッキングシミュレーションという手法が用いられている。 従来の創薬プロジェクトは平均で10-12年かかり、平均20-30億ドルのコストがかかる。市場に出回る毎年40種類程度。
小さな分子をドッキングする場合、1リカンドあたり平均15秒 × 10億個の化合物でシングルコアのマシンで順番にドッキングすると475年かかることになる。
大学に5,000コアのコンピュタークラスターがあるけど、同じコンピュータークラスターを利用する研究者は多くいるから数週間から数ヶ月かかる。クラウドを利用すると同時に何百万も実行できるので1日程度に短縮できることは大きな違い。
AWS と研究室のコラボでこれまでのクラウドHPCにおける最大規模の実験をし、約230万 vCPU を数時間利用して数百億の分子を調べた。
- AWS Batch を利用
- c5インスタンスファミリーのみのスポットインスタンスを利用
- シングルリージョン指定
数百万 CPU での VirtualFlow 実行にはコードを一部書き直す必要があった。実装に関しては AWS から多くの支援を受けた。
感想
AWS を利用したクラウドHPC環境で同時に約230万 vCPU を利用できたというのは大きな実績です。気になっていた AWS Batch の構成は紹介されていませんでした。あと、オンプレのHPC環境で VirtualFlow の実行環境の移行方法として、いきなりコンテナ化してAWS Batch で動かしたのか、最初からコンテナ化された VirtualFlow だったのか、実行環境移行までの道のり気になりました。
いろいろ動画みていたら次の動画で構成と、移行までの道のりを垣間見ることができましたので紹介します。
Healthcare & Life Sciences Vitual Symposium 2021
re:Invent 2021 前のイベントで登壇されていたときのセッション動画です。このときは約110万 vCPU での同時実行を実現されていました。
当初は AWS ParallelCluster + FSx for Lustre 構成でした。ワークフローの拡大と、コスト削減するためにパートナーの AWS とより良いソリューションを探していました。
ParallelCluster の代わりに AWS Batch をストレージは FSx for Lustre の代わりに S3 の構成になりました。
詳細な構成図。Analysis Instance はワークフロー実行のあと後処理としてデータコピーをしている。
新しい構成で約110万 vCPU を利用した VirtualFlow 実行することができ、前回のベンチマークと比較して完全に線形にスケールすることができた。
感想
構成図はここではじめて確認することができました。思いの外スタンダードな使い方でしたので AWS のインフラ側は一見すると素直に組めそうです。しかし、ここまで大規模になると各サービスのクォータには気をつけないと組めないので、とくにハードリミットに触れるようなものはないか事前に調査・検討が必要ですね。
動画の最後の方で AWS と新しいエキサイティングなプロジェクトに取り組んでいますと発言がありました。 この数カ月後に re:Invent2021 があったようですのでちょうど約230万 vCPU の実行環境に取り組んでいたのでしょう。
re:Invent2021のセッションでも AWS サポートを絶賛していたのですが、こちらのセッションでも絶賛されていましたのが印象的でした。発言から汲み取る分には VirtualFlow の改修部分のサポートも含め手厚かったようにみえました。
VirtualFlow on Google Cloud
VirtualFlow を実行するなら AWS が相性良いのか？という素朴な疑問を調べていました。Google Cloud でも実行することはもちろんできて COVID-19 の研究での利用例の記事がありました。
Case Studies: Harvard Medical School - Google for Education
おわりに
VirtualFlow は OSS で Slurm などののジョブスケジューラーに対応していると書いてあったので、AWS なら ParallelCluster, AWS Batch、Google Cloud ならEasy HPC clusters on GCP with Slurmで動作可能ということがわかりました。
AWS なら何コアを使った計算が可能ですか？と質問を受けたら、230万 vCPU を利用している事例があるので一般的な企業様がご利用される分には十分過ぎる計算リソースではないでしょうかとお答えできるかなと思いました。大規模なクラウド HPC の利用例として大変おもしろかったです。
19
