【レポート】新たな気象リスクへの挑戦を可能にした HPC on AWS #AWSSummit #ウェザーニュース

ウェザーニューズ様による気象予測のためのHPCをAWSに構築した事例紹介。精度の高い気象予測に対応するために、AWS ParallelClusterを用いて高い性能、費用対効果、可用性を実現。
2020.09.14

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

今回は、2020年9月8日から9月30日の間で開催されている AWS Summit Online のセッションで株式会社ウェザーニューズ様による「新たな気象リスクへの挑戦を可能にした HPC on AWS」を視聴しましたので、レポートをお届けします。

より精度の高い気象予測に対応するために、AWS ParallelClusterを用いて性能、費用対効果、可用を実現したHPC環境をAWS上に構築されていました。

セッション概要

資料

スピーカー

株式会社ウェザーニューズ WNI Forecast Center 飯沼 和久 氏

概要

ウェザーニューズでは、日に日に高まる気象リスクに立ち向かうため、気象予測のパフォーマンス向上に取り組んでいます。本セッションでは、ウェザーニューズにおける HPC (High Performance Computing) の取り組みの一例として、気象予測の数値シミュレーションシステムを AWS ParallelCluster を利用して AWS に移行したプロジェクトを取り上げます。パフォーマンス面での工夫の他に、可用性やコストも意識した長期運用に耐えうる仕組み作りへの取り組みをご紹介します。

HPC on AWS の背景

ウェザーニュースは、倍精度約15TFlops規模のオンプレHPC環境を運営して、気象予測に役立ててきた。

2019年の台風19号、2020年の熊本集中豪雨など、近年は気象災害が激甚化し、気象リスクに対応するために、より高い精度の気象予測が求められている。

より瞬発力・柔軟性に優れた気象予測を行うために

  • パフォーマンス向上
  • 信頼性維持
  • コストを抑える

を目標に、Rapid Update OWN Projectを始動。

2018年からParallelCluster(CfnCluster) を用いて検証開始

運用化に向けて 2020年3月〜5月 に構築

目標値

  • 更新間隔の改善 : 6 時間 → 3時間
  • 予報間隔の改善 : 1時間 → 10分

気象予測用の数値シミュレーションの特性

  • 予測は鮮度が重要。初期値の入電後、いかに早く問題をとくか?
  • EC2 c5.18xlarge(72 vCPU)1インスタンスなら160分〜180分程度かかる計算量
  • 60分以内(フェイルオーバーを考慮すると30分以内)に全過程が終了する必要がある
  • プログラムは MPI / OpenMP による並列計算に対応
  • スケールするには分散メモリー型並列計算クラスターの利用が最も効果的

AWS ParallelClusterの選択背景

  • AWS上でのHPCクラスターの構築にはAWS ParallelClusterを使用
  • アプリケーション側からはオンプレと同じジョブ操作でAWSのリソースを柔軟に利用可能
  • 選択背景
    • 瞬間的に大量のCPUリソースが必要。簡単にスケールするシステムが必要
    • AWS ParallelClusterを利用すると、簡単にこのようなクラスターを構築でき、管理コストを抑えられる

要件や課題

以下では、この3つの軸の詳細について解説します。

ParallelClusterでの並列計算

並列度を1〜64まで変えて、日本エリアを対象に strong scaling で評価

計測結果

  • 1ノード(72 vCPU)だと169分で処理
  • 4ノード(288 vCPU)だと約1/3の49分で処理
  • 64ノード(4608 vCPU)だと約1/19の9分で処理

評価

  • vCPU数の増加に伴い、実行時間は短縮
  • 並列化効率は徐々に下がる
  • 16ノード =1152 vCPU までは高い効率を維持
  • アプリケーションはI/Oを最適化
  • 実行時間は計算律速
  • プロセス数、及び、インスタンス数を増やすことで通信コストが増える
  • 問題サイズが細切れになる(=より多くのノードで処理)と、並列化効率の観点からは不利になる

アプリケーションの実行速度の評価に加えて、EC2の性能を引き出すことも重要

EC2の性能を引き出すには?

  • ネットワークデバイスの変更 → Elastic Fabric Adapter(EFA)の利用
  • ファイルシステムの変更 → Amazon FSx For Lustreの利用(計算律速だが少なからず/Oが発生するため評価)
  • インスタンスタイプの変更

Elastic Fabric Adapter(EFA)の利用

EFAは、HPCや機械学習などのハイパフォーマンスコンピューティング (HPC) と機械学習アプリケーションを高速化するために Amazon EC2 インスタンスにアタッチできるネットワークデバイス

  • vCPU(ノード) 数が少ない場合は、改善率は小さい
  • 4608 vCPU(64ノード)では25%と大きな改善
  • ノードの増加に伴い、通信コストが増加するため、改善率が増えた

インスタンスタイプの変更

3種類のインスタンスタイプを比較

  • c5n.18xlarge : ネットワーク帯域最適化インスタンス
  • z1d.6xlarge : 周波数最適化インスタンス
  • x1.32xlarge : メモリ最適化インスタンス

C5n > X1 > z1d の順に良い結果が得られた。

アプリケーションは

  • 計算律速
  • 内部的にはステンシル計算のようなCPUキャッシュがきく計算が多い

のため、総合的にバランスの良いc5nが向いていたと思われる

最適なインスタンスタイプはアプリケーションの特性に大きく依存

信頼性

  • 停止しないことが大事
  • 現行システムと同等以上の可用性
  • 年に数回処理が失敗する程度

信頼性向上のための方針

  • 正副構成
  • 複数リージョンを利用し、障害時は正系システムから副系システムにフェイルオーバー
  • 正系はバージニア北部リージョン : インスタンス利用費が安く、トータルコストが安くすむため

フェイルオーバーの仕組み

  • 気象データは正副に連携
  • 待機中は正副どちらもヘッドノードのみ起動
  • 新規ジョブに対してParallelClusterが立ち上がり、計算処理を行う
  • ジョブの状態は DynamoDB で管理
  • 予定時間内にジョブが完了しない場合、副系で計算処理を行う

正系

副系

コスト最適化

  • コストを抑える
  • いざというときには動かなければ意味がない
  • 正副構成をふまえた最適化

EC2インスタンスの料金タイプ

  • オンデマンド : 使った分だけ課金
  • Savings Plan : 利用料をコミットすることで割引が受けられる。常時起動に最適
  • スポットインスタンス : 非常に安価に使える。インスタンスが途中で終了するリスクがある

  • 正系は 1日の 1/3 のみ利用
  • Saving Planのコストメリットがあまりでない
  • C案を採用

まとめ

成果物

AIレーダー900

  • 10分間隔で15時間先まで予測

雨雲レーダー

所感

要件・課題を整理した上で

  • 様々なインスタンスタイプ・ノード数を評価
  • 正系・副系に合わせてオンデマンド・スポット・Savings Planを評価
  • マルチリージョンのフェイルオーバーの実装

など、クラウドのメリットを十分活かしながら、堅実かつ模範的な構成で AWS 上に HPC 環境を構築した株式会社ウェザーニューズ様の事例紹介でした。

オンプレの HPC クラスターを AWS に移植するプロジェクトでは、参考になるところがたくさんあるのではないでしょうか。