Petrobras が Amazon EC2 スポットインスタンスを使用して HPC アプリケーションのコストとキャパシティを最適化

このブログは、2025 年 3 月 25 日に Marcelo Baptista、Lucia Maria de A. Drummond、Luan Teylo、Alan L. Nunes、Vinod Rebello、Cristina Boeres によって執筆された内容を日本語化したものです。原文はこちらを参照してください。

大手総合エネルギー企業の一つである Petrobras は、複雑な課題に取り組み、新たな機会を切り拓くために、ハイパフォーマンスコンピューティング（HPC）の変革におけるポテンシャルを信じて、長年取り組んできました。同社は、地震データ処理、貯留層シミュレーション、その他の石油・ガス関連ワークロード向けに設計された強力な HPC インフラストラクチャに多額の投資を行ってきました。

これまで、Petrobras は主にオンプレミスソリューションを使用して HPC アプリケーションを実行していました。従来の HPC の制限を克服するため、フルミネンセ連邦大学（UFF）の Cloud+HPC ラボと共同で、オンプレミスとクラウドリソースを組み合わせたハイブリッドシステムを開発する研究プロジェクトを立ち上げました。AWS ParallelCluster と Amazon EC2 スポットインスタンスを活用することで、Petrobras は事実上無制限のコンピューティングパワーを獲得し、複雑なシミュレーションの効率性を向上させ、可用性と最も重要な生産性を高めることができました。

本日は、これを可能にするために彼らが作成したフレームワーク Sim@Cloud について説明します。Petrobras はこれを使用して、パフォーマンスを最大限に維持しながら、43 % から 90 % のコスト削減を達成しました。Sim@Cloud は待ち時間を最小限に抑え、適切なインスタンスを選択し、インスタンスの稼働を管理します。

AWS の活用による待ち時間の最小化

需要がピークを迎える時期には、Petrobras はジョブ実行の長い待ち時間に直面していました。これはプロビジョニングにおけるよくあるジレンマですが、簡単にまとめると次の通りです。

• オーバープロビジョニング: リソースがピーク需要に合わせてスケーリングされると、需要の低い期間に不必要な費用とエネルギーの無駄が発生します。
• アンダープロビジョニング: リソースが十分にプロビジョニングされておらず、ピーク時の需要を満たせない場合、ジョブ実行の遅延が発生し、会社の意思決定に影響を与え、高度な資格を持つ高給の専門家の時間と生産性を妨げ、非効率による潜在的な財務損失をもたらす可能性があります。

このオーバープロビジョニングとアンダープロビジョニングのトレードオフは難しく、どちらの場合もリソースの無駄につながります。図 1 は、Petrobras の実際のデータを使用してこのシナリオを示しています。データは典型的な 1 週間の経過を示しており、オンプレミスのリソースは需要を満たしているものの、アイドル状態のリソースがあることがわかります。特定の日には、使用率が会社の計算能力の 100 % に達します。この時点（緑色の線で表示）で、ジョブがキューに入り、エンジニアのフラストレーションの原因となります（フラストレーションを抱えたエンジニアを見たことがありますか？私はあります）。

したがって、私たちは自問しなければなりません：これを管理する最も効果的な方法は何でしょうか？

図 1 – Petrobras のオンプレミスインフラにおける 1 週間のジョブ実行状況。100 %（緑色の線）を超える曲線はピーク需要を表し、その結果、ワークロードがクラウドに手動でシフトされます（オレンジ色で表示）。

このような状況において、AWS のネイティブな弾力性が解決策を提供します。日常的なタスクにはオンプレミスリソースを割り当て、ピーク時の要求をクラウドに移行します。これはまさに Petrobras が UFF の Cloud+HPC ラボとのパートナーシップと Sim@Cloud によって実現していることです。

コストの検討

Petrobras のワークロードは通常、完了までに数日から数週間かかり、数百のコンピューティングノードを使用します。クラウドへの移行において彼らの主な懸念はコストでした。これに対処するため、Lúcia Drummond 教授が率いる UFF の Cloud+HPC ラボは、AWS で HPC ワークロードを実行するコストを最適化し削減することに焦点を当てたプロジェクトを立ち上げました。

プロジェクトの最初の 2 年間で、Petrobras はピーク需要期間中に AWS に移行する最初のワークロードとして CMG の貯留層シミュレーションを選択しました。このアプリケーションは、同社のワークロードの大部分を占め、ネイティブで軽量なチェックポイントとリスタート機能を備えていることが特徴です。

チェックポイントとリスタート機能により、エンドユーザーに対する透明性を確保しながら、Amazon EC2 スポットインスタンスを使用してコストを可能な限り低く抑えることができます。ユーザーの視点からは、シミュレーションのバッチを Slurm に送信して結果を待つプロセスは、オンプレミスで実行する場合も AWS Cloud で実行する場合も同じです。

1 人のユーザーのワークロードは、300 を超えるシミュレーションジョブで構成されることがあります。各ジョブは、一度に 100 以上のインスタンスを要求することがあります。適切なインスタンス、適切なタイミング、適切な AWS リージョンを見つけることが、HPC ワークロードを実行し、コストを最適化する鍵となります。

これらの課題を解決するために、プロジェクトは Sim@Cloud を開発しました。これは Slurm や BR-Kalman などの他の Petrobras 内部ツールとネイティブに統合されています。

Sim@Cloud

Sim@Cloud は、シミュレーション実行に適したインスタンスと料金モデル（スポットまたはオンデマンド）の選択をサポートすることで課題に対処します。また、スポットインスタンスの中断を管理できるよう実行を監視します。

Sim@Cloud には、Launcher と Execution Manager という 2 つの主要コンポーネントがあり、それぞれがシミュレーション実行中の特定の管理手順を担当します。フレームワークの動作を説明するために、図 2 はアーキテクチャとステップバイステップの実行例を示しています。

図 2 – Cloud+HPC ラボと Petrobras によって開発された Sim@Cloud フレームワークのアーキテクチャ

まず、ユーザーはクラスタージョブスケジューラ（Slurm）にシミュレーションリクエストを送信します。ユーザーは、コア数、実行用のバッチファイル、出力ディレクトリなど、実行のためのパラメータを定義します。

これらのパラメータを使用して、Slurm はヘッドノードで Launcher を起動します。Launcher は、Slurm の機能のみに基づいてシミュレーションの実行時間を推定する機械学習コンポーネントである ML-Predictor を呼び出します。次に、Launcher は Instance-Selector モジュールを呼び出します。推定時間、アプリケーションの特性、チェックポイントのオーバーヘッドなどの環境要因を考慮して、シミュレーションタスクに最適な Amazon EC2 インスタンスタイプ、購入オプション、およびリージョンが決定されます。この決定により、シミュレーションジョブが Slurm に送信され、選択されたインスタンスが割り当てられ、ジョブが開始されます。

Execution Manager モジュールは、Dynamic-Predictor モジュールを通じてシミュレーションの進行状況を監視します。シミュレータのログに基づいて残りの実行時間を予測します。この情報を使用して、EC2 がスポットインスタンスを中断した場合にシミュレーションを再開するための新しいインスタンスを選択します。

スポットインスタンスで実行する場合、Execution Manager は Checkpoint-Recorder モジュールを使用して定期的にチェックポイントを作成します。必要に応じて、このモジュールは利用可能な最新のチェックポイントからアプリケーションを再起動します。Execution Manager は AWS のインスタンスメタデータからスポットインスタンスの中断通知を受け取ります。中断通知は、スポットインスタンスが中断される 2 分前に送信されます。通知を受け取った後、Checkpoint-Recorder はシミュレーションの現在の進行状況を保存するための最終チェックポイントを開始します。スポットインスタンスが中断された場合、Instance-Selector は Dynamic-Predictor によって予測された残り時間を使用して、シミュレーションを再開するのに最適なインスタンスを決定します。

このプロセスはシミュレーションが完了するまで繰り返されます。Launcher は実行情報を History-Database（実行履歴データベース） に保存し、ユーザーに通知します。データベースには、AWS リージョン、購入オプション、インスタンスタイプ、価格履歴、シミュレーションの実行時間など、シミュレーション実行に関連する情報が保存されます。これにより、実行パフォーマンスとコストのさらなる評価が容易になります。

Sim@Cloud は中断の回数も制限しています。制限に達すると、利用可能なオンデマンドキャパシティを使用してジョブを再開します。

Sim@Cloud は、オンプレミスのクラスターで共有ファイルシステムを使用し、異なる AWS リージョンごとにキャッシュを使用します。Amazon FSx for NetApp ONTAP は、シミュレーションを実行可能な各 AWS リージョンをリンクします。このキャッシュアーキテクチャにより、データは別のリージョンにコピーされ、可用性が向上し、シミュレーションの実行に関連するデータへの迅速なアクセスが可能になります。これは、組織がプライマリデータのホスティング環境としてデータ主権要件を遵守するのにも役立ちます（例えば、ブラジル政府のクラウドサービスのデータ処理とセキュリティに関する規則の遵守など）。

実験結果

スポットインスタンスの中断に対する 2 分前の通知をシミュレートし、Sim@Cloud を使用した場合のコストと総実行時間における効果を調査しました。

AEMM（AWS EC2 Metadata Mock）を使用して、スポットインスタンスの中断をシミュレートする別のツールを開発しました。ポアソン分布を使用してインスタンスの中断時間を計算し、インスタンスのメタデータを更新して終了アラートを含め、スポットインスタンスをシャットダウンします。この離散確率分布は、スポットインスタンスの中断タイミングを含む、特定の期間内でのイベント発生を予測するのに適しています。

1 時間あたりの平均中断回数を表すパラメータ λ を使用してポアソン分布からサンプリングし、結果に 3,600 秒を掛けることで終了時間を決定し、τ をインスタンスの利用可能時間として定義します。このツールはインスタンスの稼働時間を追跡し、秒単位で終了アラートを生成します。

評価では、(λ) – 0.1, 0.5, 0.8, 1.0 の 4 つの中断頻度を考慮しました。λ 値が増加するにつれて、スポットインスタンスが早期に終了する確率も高くなり、λ = 1 の場合は最初の 1 時間以内にスポットインスタンスが中断される確率が高いことを示します。

テストでは、プレソルト（Pre-salt） と呼ばれる半合成貯留層（semisynthetic reservoir）シミュレーションモデルのワークロードを使用しました。これは、Petrobras によって探査されたブラジル沖合の複雑なプレソルト貯留層の代表的なワークロードです。時間と予算を節約するため、50 年ではなく 20 年のシミュレーションを実行するバージョンを作成しました。この記事の残りの部分では、これらのモデルをそれぞれ Pre-Salt および Short-Pre-Salt と呼びます。これらのモデルは、通常、合成貯留層シミュレータ CMG GEM を使用して本番環境でシミュレートされます。これにより、ブラジルのプレソルトの複雑さに対してより良い結果が得られます。しかし、この調査では、テストの目的に合わせて高速化するため、常に 40 スレッドを使用して CMG IMEX ブラックオイルシミュレータを使用してシミュレーションを実行することを選択しました。

Sim@Cloud は、SA-EAST-1 リージョンのベースラインとなるオンデマンドインスタンスと比較して、様々なシナリオでコストを削減し、実行時間を短縮しました。図 3a、3b、3c は、中断頻度（λ）ごとに 3 回実行した Sim@Cloud のインスタンス選択スキームにおける平均メイクスパン（統合プロセス内でメッセージが処理されるまでの所要時間）とコストを表示しています。これを Short-Pre-Salt および Pre-Salt シミュレーションモデルについて示しています。メイクスパンは、統合プロセス内でメッセージが処理されるまでの時間を計算するパフォーマンス指標です。

図 3a – Short-Pre-Salt モデルの初回の実行時のコストとメイクスパン。破線はベースラインの実行を表します（ホーム AWS リージョン SA-EAST-1 で最も安価なオンデマンドインスタンスを使用）。

図 3b – Short-Pre-Salt モデルの 2 回目の実行のコストとメイクスパン。破線はベースラインの実行を表します（ホーム AWS リージョン SA-EAST-1 で最も安価なオンデマンドインスタンスを使用）。

図 3c – 完全な Pre-Salt モデルの実行におけるコストとメイクスパン。破線はベースラインの実行を表します（ホーム AWS リージョン SA-EAST-1 で最も安価なオンデマンドインスタンスを使用）。

最悪のシナリオ（λ = 1）においても、コスト削減は Short-Pre-Salt モデルの 2 回目の実行（図 3b）で最大 43.87 %、Short-Pre-Salt モデルの初回実行（図 3a）で最大 90.39 % に達しました。前者のケースでは、スポットインスタンスを使用する際にチェックポイントが必要なため、処理時間が 9.28 % 増加する代わりにこれを達成しました。対照的に、Short-Pre-Salt モデルの初回実行では、処理時間が平均 10.42 % 短縮されました。スポットインスタンスの中断から回復するプロセスには、代替インスタンスの選択、初期化、シミュレーションの再開など、回収と再起動のためのオーバーヘッドが含まれます。図 3b が示すように、中断頻度（λ）の上昇に伴い、メイクスパンも増加しました。λ = 0.5 および λ = 0.8 の場合、Short-Pre-Salt モデルの 2 回目の実行におけるコスト削減はそれぞれ 81.78 % と 81.46 % で、メイクスパンはそれぞれ 0.70 % と 2.48 % 増加しました。初回実行におけるコスト削減はさらに良好で、それぞれ 90.13 % と 90.07 % となり、メイクスパンは 13.52 % と 18.35 % 短縮されました。

λ = 0.1 のシナリオでも顕著な改善が見られました。コスト削減は初回実行で最大 91.58 %、2 回目の実行で 85.74 % に達し、メイクスパンはそれぞれ 15.97 % と 3.92 % 短縮されました。このシナリオでは、選択ヒューリスティックにより、ベースラインのインスタンスよりも低価格で性能の良いスポットインスタンスが得られました。Short-Pre-Salt の実行時間が短いため、スポットインスタンスの中断は発生せず、シミュレーションを移行するための追加のオーバーヘッドを回避できました。選択ヒューリスティックは、スポットインスタンスの購入においてコスト効率の良いリソースを検索する方法を示しています。

Pre-Salt モデルについては、図 3c に示す結果は Short-Pre-Salt モデルの結果と類似しています。このシナリオでは、コストとメイクスパンの両方で削減が達成されました。

実行時間は、ジョブ送信時のリージョンにおけるスポットインスタンスの可用性によっても影響されることに注意してください。スポットインスタンスの価格は実行中に変動する可能性がありますが、λ = 1.0 の両方のシナリオでコストが増加した主な原因は、許可されたスポットインスタンスの中断制限を超えた後に、Sim@Cloud がシミュレーションを完了させるためにオンデマンドインスタンスを選択したことでした。

ベネフィット

この調査は有益であり、HPC ワークロードの管理方法に新たな可能性をもたらし、Amazon EC2 スポットインスタンスがコスト最適化の鍵となることを示しました。スポットインスタンスを使用することで、オンデマンド料金と比較して EC2 コストを大幅に削減できます。

FlexCache を搭載した Amazon FSx for NetApp ONTAP を使用して効率的なキャッシュを実現したことで、ストレージ費用を削減し、優れたパフォーマンス指標でクラウド内でのデータアクセスを容易にする重要な変化をもたらしました。Sim@Cloud のようなソリューションは、スポットインスタンスの中断という固有の性質があっても、ワークロードの整合性を損なうことなく大幅なコスト削減を実現できることを示しています。

クラウドベースのソリューションは、エンドユーザーに透明性を提供し、技術的な障壁を減らし、ユーザー（科学者やエンジニア）にピーク需要時に必要となる追加のキャパシティを提供することで、HPC アプリケーションのアクセシビリティを向上させます。

結論

このプロジェクトとその良好な成果は、UFF、Petrobras、AWS の三者による緊密な連携とサポートによって実現されました。結果から分かるように、Sim@Cloud はシミュレーションの実行時間に関係なく、全体的なコストの削減に効果的です。中断頻度（λ）が高くても、より長いシミュレーションモデルは低コストで短いメイクスパンを達成できます。

これらの結果は、AWS が HPC ワークロードの処理において成熟していることを示しています。Petrobras のような大企業は、この結果と AWS の規模とキャパシティの恩恵を受けることで、典型的なプロビジョニングの問題だけでなく、特殊なプロビジョニングの問題も解決できます。

AWS は Petrobras と UFF と緊密に連携しました。この緊密な関係は、環境を理解するだけに使われるはずの時間を節約し、研究やソリューションに取り組むことができるため有益でした。これはプロジェクトの成功と Sim@Cloud の開発に不可欠であり、潜在的なバグを回避し、プロジェクトを最良の決断へと導きました。

謝辞

この研究は多くのエンジニアとアナリストによって実施されました。彼らに深く感謝いたします： Alan L. Nunes (UFF), Cristina Boeres (UFF), Daniel B. Sodré (UFF), Felipe A. Portella (Petrobras), José Viterbo (UFF), Luan Teylo (INRIA/Bordeaux), Lúcia M. A. Drummond (UFF), Maicon Dal Moro (Petrobras), Marcelo Baptista (AWS), Paulo F. R. Pereira (Petrobras), Paulo J. B. Estrela (Petrobras), Renzo Q. Malini (Petrobras), Vinod E. F. Rebello (UFF).

出版物

このプロジェクトについて詳しく知りたい場合は、以下の論文リストをご参照ください。

• Sim@Cloud – ​Experimental Evaluation
• MScheduler: Leveraging Spot Instances for High-Performance Reservoir Simulation in the Cloud, IEEE CloudCom 2023: 99-106
• Prediction of Reservoir Simulation Jobs Times Using a Real-World Slurm Log, XXIV Simpósio em Sistemas Computacionais de Alto Desempenho 2023: 49-60
• A. L. Nunes et al., “A Framework for Executing Long Simulation Jobs Cheaply in the Cloud,” 2024 IEEE International Conference on Cloud Engineering (IC2E), Paphos, Cyprus, 2024, pp. 233-244, doi: 10.1109/IC2E61754.2024.00033.
  • High Performance Computing in Clouds: Moving HPC Applications to a Scalable and Cost-Effective Environments, Springer, 2023 https://www.amazon.com/High-Performance-Computing-Clouds-Cost-Effective-ebook/dp/B0BYN665C2/

翻訳はネットアップ合同会社の方様、監修はソリューションアーキテクトの宮城が担当しました。