AWS ParallelCluster のクラスターで実行したジョブ実行履歴を保存する場合、ジョブスケジューラーの Slurm と連携したデータベースが必要です。AWS ParallelCluster とデータベースサービスの組合わせで推奨できる構成を検討した結果を共有します。
検討背景
Aurora Serveless v1 の EoL が 2024 年 12 月 31 日とアナウンスがありました。0 ACU まで自動縮退による自動課金停止機能を重宝しており、愛用していました。EoL に備えて 2024 年 1 月時点の最新の AWS ParallelCluster 3.8.0 がサポートしている Slurm version 23.02.7 をベースに構成を考えます。
検討結果まとめ
Aurora Serveless v1 と同じ様にクラスターで計算していないときに DB サーバーを停止する運用を踏襲すると以下の結果になりました。
- RDS for MySQL の db.t4g.micro（2vCPU, 1GB メモリ）を必要なときに起動・停止運用が安価
- 起動・停止運用が手間、または常時計算している環境であれば Reserved Instances の購入を検討
Slurm アカウンテイングとは
Slurm をデータベースと接続することで以下のことが可能になります。
- ジョブの実行履歴保存
- ジョブを実行したユーザー
- ジョブの実行基幹
- 使用したリソース
- QoS などの Slurm の高度な機能
私は主にジョブの実行履歴の保存を目的でヘッドノード（Slurm）を Aurora Servelss v1 MySQL を利用していました。
Slurm 推奨のデータベース構成は？
Slurm のドキュメントを確認すると MySQL か MariaDB が望ましいとあります。
MySQL or MariaDB is the preferred database. Slurm Workload Manager -
Aurora/RDS ともに対応している DB エンジンの MySQL の利用を前提に進めます。
データベースの保存先は内部か外部か？
ヘッドノードに MySQL をインストールすれば Slurm アカウンテイングを利用できます。AWS 利用費だけを見れば最も安価なランニングコストの構成になります。ですが、MySQL へセキュリティパッチあてるためのアップデート作業や、ディスクサイズ、メモリなどのリソース管理が発生します。データベース運用に必要な作業工数を考慮し、マネージドサービスの Aurora/RDS を利用するのが賢明な判断でしょう。
また、ヘッドノードにデータベースを持たせると、必要でなくなったクラスターを削除するときに DB の退避作業が必要になることでしょう。データベースはクラスターと切り離して管理する方がクラスター環境の運用はし易いです。
Slurm アカウンテイングのためのデータベースは Aurora/RDS の MySQL の利用することにしました。
Aurora/RDS の利用費試算
前提条件
月に 10 日間（230 時間）程度、クラスター環境を利用する想定します。Aurora Serveless v1 の運用実績から起動時は 1 〜 2ACU のスペックで問題なかったため、引き続き最低限のスペックを確保します。仮にクラスターの接続数が増えて負荷が増えたときに、インスタンスタイプを変更して調整する運用とします。
Aurora/RDS 料金比較
ディスクサイズや、バックアップ代を除いた純粋な起動料金の比較です。
| 種別 | インスタンスタイプ | 時間単価 | 月額利用費（230時間） | 備考 |
|---|---|---|---|---|
| Aurora Serveless v1 | 1 ACU | 0.1 | $23 | 0 ACUまで縮退可 |
| Aurora Serveless v2 | 0.5 ACU | 0.1 | $23 | 0.5 ACUまで縮退、停止操作可 |
| RDS | db.t4g.micro | 0.025 | $5.75 | |
| RDS | db.t3.micro | 0.026 | $5.98 | |
| Aurora | db.t4g.medium | 0.113 | $25.99 | |
| Aurora | db.t3.small | 0.063 | $14.49 |
※ 執筆時点の東京リージョンの単価です。
DB の実行時間が短い
今回想定したケースですとデータベースの実行時間が短いため、Aurora Serveless v1 よりプロピジョンドタイプの Aurora の方が安く、RDS だと更に安い結果となりました。
Aurora Serveless v1 の 0ACU まで自動縮退機能により自動課金停止を代替えする機能はありません。必要なとき以外は Aurora/RDS の停止をする運用ができて成り立つ費用感です。
Aurora か RDS か
Slurm と連携する MySQL に高度な機能を今のところ要求された試しはありません。RDS でも問題になるようなことが思い当たりません。金銭的な余裕があれば Aurora を使いたいですが RDS の db.t4g.micro (2vCPU, 1GB メモリ)を第一候補にします。
データベースに保存する Slurm のログ容量は微々たるものですので、長く運用していてもディスクサイズに悩まされることは滅多に起きないかと思います。
常時稼働する場合
年間通して常時クラスターが稼働している実行環境の場合は、Reserved Instances（以降 RI）を購入した方がランニングコストを削減できます。RDS の db.t4g.micro の場合は月に 537 時間以上稼働させるなら、RI を前払い一括購入した方が安くあがります。
最低 1 年間インスタンスタイプを変更しないことが前提となるため、db.t4g.micro で問題でないか数ヶ月運用して判断が必要です。
また、RDS の起動・停止運用がめんどくさい場合も、作業の手間をお金で買うという意味で RI 購入を検討してもよろしいかと思います。
まとめ
- Aurora Severless v1 の EoL により、自動的に課金が停止するデータベースサービスはなくなる
- RDS for MySQL の db.t4g.micro（2vCPU, 1GB メモリ）を必要なときに起動・停止運用が安価
- 起動・停止運用が手間、常時計算している環境であれば Reserved Instances の購入を検討
おわりに
Aurora Serveless v2 に 0ACU まで縮退できる機能追加を願っています。クラスターの起動停止に連動して RDS を起動停止する仕組みを自作も検討してみたいと思います。
2
