AWS ParallelCluster ヘッドノードのメモリサイジング早見表

はじめに

AWS ParallelCluster 3.13 では、ヘッドノードのメモリサイズに関する新しいバリデーション機能が追加されました。本記事ではこのバリデーション機能の詳細と、各インスタンスタイプで管理できるコンピュートノード数について解説します。

ヘッドノードのメモリサイジング

ヘッドノードは、HPC クラスターの中心的な役割を担います。コンピュートノードの管理、ジョブのスケジューリング、ファイル共有など、多くの重要な機能を提供します。ヘッドノードのメモリが不足すると、これらの機能が正常に動作せず、クラスター全体に影響を与える可能性があります。特にコンピュートノードの数が増えると、ヘッドノードの負荷も増加します。そのため、クラスターの規模に応じた適切なメモリサイズを持つヘッドノードを選択することが重要になってきます。

AWS ParallelCluster 3.13 での新機能

AWS ParallelCluster 3.13 では、ヘッドノードのメモリサイズがコンピュートノードの台数に対して適切かチェックする機能が追加されました。

https://dev.classmethod.jp/articles/aws-parallelcluster-v3130-released/

チェック機能の仕組み

ヘッドノードの必要なメモリサイズを算出するバリデーションが追加されています。

• ヘッドノードの OS が 600MB のメモリを消費すると仮定
• コンピュートノード 1 台ごとに約 250MB のメモリが必要と想定
• チェック対象はメモリサイズが 16GB 未満のインスタンスタイプしたときだけ

バリデーションコードの解説

AWS ParallelCluster 3.13 のバリデーションコードを見ると、HeadNodeMemorySizeValidatorクラスが実装されています。このクラスは、ヘッドノードのインスタンスタイプとコンピュートノードの最大数を入力として受け取り、必要なメモリサイズを計算します。

def _validate(self, head_node_instance_type: str, total_max_compute_nodes: int):
    head_node_memory = (
        AWSApi.instance().ec2.get_instance_type_info(head_node_instance_type).ec2memory_size_in_mib() / 1024
    )
    # Assume OS takes up 0.6GB memory. Only check upto 16GB memory to prevent usage of small instance types.
    required_memory = min(total_max_compute_nodes / 25 + 0.6, 16)
    if head_node_memory < required_memory:
        self._add_failure(
            f"Head node instance type {head_node_instance_type} has {head_node_memory} GB of memory. "
            f"Please choose a head node instance type with at least {required_memory} GB of memory"
            f" to manage {total_max_compute_nodes} compute nodes.",
            FailureLevel.ERROR,
        )

エラーの例

t3.micro などの小さいインスタンスタイプをヘッドノードで使用して、最大 30 台のコンピュートノードが起動可能なクラスターを作成すると以下のエラーが出力されました。この例では 30 台のコンピュートノードを管理するために必要なメモリは約 1.8GB と計算されていますが、t3a.micro は 1GB しかないためエラーが発生しています。

{
  "level": "ERROR",
  "type": "HeadNodeMemorySizeValidator",
  "message": "Head node instance type t3a.micro has 1.0 GB of memory. Please choose a head node instance type with at least 1.7999999999999998 GB of memory to manage 30 compute nodes."
}

インスタンスタイプ別の設定可能なコンピュートノード数早見表

各インスタンスタイプで管理できる最大コンピュートノード数を以下の表にまとめました。

コンピュートノード数の管理だけをみれば、M 系であればメモリサイズが 4GB 以上（.medium〜）のインスタンスタイプを選択しておけば大方耐えられそうです。

開発・検証環境向けインスタンス（T3シリーズ）

本番環境向けインスタンス（M7i-flexシリーズ）

Intel の CPU です。

https://dev.classmethod.jp/articles/ec2-instances-m7i-m7i-flex/

本番環境向けインスタンス（M7aシリーズ）

AMD の CPU の M7a シリーズは vCPU 数 = 物理コア数です。CPU 負荷の高いワークロードであればコンピュートノードで利用するとコストパフォーマンスが高いです。

https://dev.classmethod.jp/articles/amazon-ec2-m7a-ga/

本番環境向けインスタンス（M7gシリーズ）

ARM ベースの Graviton3 は vCPU 数 = 物理コア数です。CPU アーキテクチャが x86-64 ではなく ARM なのでご注意ください。

https://dev.classmethod.jp/articles/m7g-r7g-new-ec2-instances/

まとめ

AWS ParallelCluster 3.13 で導入されたヘッドノードメモリバリデーション機能により、クラスターの規模に適したヘッドノードのインスタンスタイプを選択することが重要になりました。本記事で紹介した各インスタンスタイプの対応可能なコンピュートノード数を参考に、クラスターの規模と用途に応じて適切なインスタンスタイプを選択してください。

おわりに

私の検証環境ですとめったに使わないキューの設定があり、そのコンピュートノード数もカウントされるためヘッドノードのインスタンスタイプを 1 サイズ大きなものへ変更となりました。ですが、明確な基準が設けられたのではじめて ParallelCluster を利用するユーザーにとってはヘッドノードのサイジングがどうしたらいいのか困ると思うので改善ですね。