高パフォーマンスな SAS Grid Manager クラスターの Amazon FSx for Lustre による AWS 上での実行



SAS® は、エンタープライズや政府系の組織に利用されている、データサイエンスと分析用ソフトウェアのプロバイダーです。SAS Grid は、高い可用性と処理速度を提供する分析プラットフォームであり、集中的な管理機能により、異なるコンピューティングノード間でワークロードをバランスさせます。このアプリケーションスイートには、データ管理、画像分析、ガバナンスとセキュリティ、予測とテキストマイニング、統計的な分析、および環境管理などの機能が備わっています。最近、SAS と AWS では、Amazon FSx for Lustre の共有ファイルシステムにより SAS Grid Manager を AWS 上で使用した場合に、標準的なワークロードがどの程度良好に機能するか確認するためのテストを実施しました。テスト結果の詳細については、ホワイトペーパーの「Accelerating SAS Using High-Performing File Systems on Amazon Web Services (アマゾン ウェブ サービスの高性能ファイルシステムによる SAS の高速化)」をご参照ください。

この記事では、SAS Grid と FSx for Lustre を併用するために AWS の基盤となるインフラストラクチャをデプロイする際のアプローチ手法をご紹介していきます。これは、I/O に対する要求が厳しい他の同様なアプリケーションにも適用が可能です。

システムデザインの概要

高いパフォーマンスのためにスループットへの要求が厳しく、ネットワークのレイテンシーにも敏感なワークロードを実行することは、一般的なアプリケーションでは行わないアプローチを必要とします。通常 AWS では、このようなアプリケーションは複数のアベイラビリティ―ゾーンに展開し、高可用性を達成するように推奨しています。レイテンシーに対する感度を考えたとき、パフォーマンスを最適化するためには、高スループットのアプリケーションのトラフィックはローカルに置く必要があります。スループットの最大化には、次のような手段があります。

• Virtual Private Cloud (VPC) 内で実行し、強化されたネットワーキングが利用可能なインスタンスタイプを使用する
• 各インスタンスは同じアベイラビリティゾーン内で実行する
• プレースメントグループ内でインスタンスを実行する

AWS で SAS Grid と FSx for Lustre を使うアーキテクチャを、次の図に示します。

SAS Grid のアーキテクチャには、中間層ノード、メタデータサーバー、Grid コンピューティングノードが含まれています。中間層ノードでは、プラットフォームウェブサービス (PWS) 、および、ロードシェアリングファシリティ (LSF) のコンポーネントを実行します。これらのコンポーネントは、受け取ったジョブをディスパッチし、各ジョブのステータスを返信します。

中間層ノードにおいて PWS と LSF を効果的に実行するためには、大きなメモリ容量がある Amazon Elastic Compute Cloud (Amazon EC2) インスタンスが必要です。今回のユースケースでは、r5 インスタンスファミリーが、この要件に適合しています。

メタデータサーバーには、すべての SAS Grid マネージャー製品に関するメタデータ定義を保持するメタデータレポジトリが含まれまており、これは同時に、r5 インスタンスファミリーで保持するのに向いています。24 GB の RAM、あるいは各物理コアごとに 8 MB (どちらか大きい方) というメモリ要件と一致する、もしくはそれ以上での使用が推奨されます。メタデータサーバーには、コンピューティング集約型リソースや広帯域の I/O は必要ありません。したがって、r5 インスタンスファミリーを選択することで、コストとパフォーマンスをバランスさせることができます。

SAS Grid ノードには、グリッドが受信したジョブを実行する役割があります。EC2 インスタンスには、これらのジョブをサイズ、複雑さ、グリッドの処理量に見合うボリュームに応じて処理するための機能があります。SAS Grid ワークロードの最小限の要件を満たすためには、コアごとに最低でも 8 GB の物理 RAMと、物理コアごとに 100～125 MB/秒の頑強な I/O スループットを用意することが推奨されます。今回のユースケースでは、m5n と r5n の EC2 インスタンスファミリーが、この RAM とスループットの要件を満たすのに十分です。SASDATA、SASWORK、および UTILLOC ライブラリーは、共有ファイルシステムでホスティングできます。インスタンスストレージに SASWORK を保持させる場合には、i3en インスタンスファミリーが要件に適合します。これらでは、1.2 TB を超えるインスタンスストレージが利用できるためです。次のセクションにおいて、FSx for Lustre を使用する EC2 インスタンスの推奨事項を見極めるため行った、スループットテストの内容を説明していきます。

ストレージの I/O パフォーマンス最大化のための手順

SAS Grid には共有ファイルシステムが必要です。ここでは、さまざまな EC2 インスタンスファミリーに対し共有ファイルシステムとして選ばれた、FSx for Lustre のパフォーマンスをベンチマークすることを目的にしました。各インスタンスファミリーでは、コアごとに 8 GB の物理 RAM、および、物理コアごとに 100～125 MB/秒のスループットという、最低限の要件を満たしています。

FSx for Lustre は、高速ストレージを必要とするアプリケーション向けに設計された、完全マネージド型のファイルストレージサービスです。FSx for Lustre は POSIX 互換のファイルシステムなので、一切の変更は必要とせずに、現行の Linux ベースアプリケーションで使用できます。FSx for Lustre では、スクラッチと永続的、両方のファイルシステムが利用可能ですが、SAS Grid の FSx for Lustre に関しては永続的な ファイルシステムの使用が推奨されます。SASWORK、SASDATA、および UTILLOC のデータとライブラリの保存は長期間になり、高い可用性とデータの耐障害性が必要だからです。I/O スループットについては、要求される 100～125 MB/秒の範囲のスループットを達成するため、ストレージユニットごとに適切なストレージ容量を選択します。

ファイルシステムのセットアップが完了した後の FSx for Lustre のマウンティングには、flock マウントオプションを選択する方が良いでしょう。次のサンプル例に、マウンティング用のコマンドと、FSx for Lustre のマウントオプションを示します。

$ sudo mount -t lustre -o noatime,flock fs-0123456789abcd.fsx.us-west- 2.amazonaws.com@tcp:/za3atbmv /fsx
$ mount -t lustre
172.31.41.37@tcp:/za3atbmv on /fsx type lustre

(rw,noatime,seclabel,flock,lazystatfs)

スループットテストとその結果

FSx for Lustre で SAS Grid を実行する際の、EC2 インスタンスの最良な選択を見極めるために、100.8 TiB の永続的ファイルシステムを使用する個別の EC2 インスタンスについて、並列性が高いネットワークスループットに関する一連のテストを実施しました。ファイルシステムの全スループット容量は、19.688 GB/秒になります。このテストは、複数のリージョンにおいて、複数の EC2 インスタンスファミリー (c5、c5n、i3、i3en、m5、m5a、m5ad、m5n、m5dn、r5、r5a、r5ad、r5n、r5dn) を用いながら実施しました。各インスタンスでのテストは、それぞれ 3 時間行われ、ファイルシステムの DataWriteBytes メトリクスを 1 分間ごとに記録しました。1 度にファイルシステムにアクセスするインスタンスは 1 個のみにし、p99.9 の結果をキャプチャしています。得られたメトリクスには、4 つのリージョンすべてで一貫性が見られます。

最小限のネットワークパフォーマンスとメモリの推奨事項を満たしたか、それを超えたのは、i3en、m5n、m5dn、r5n、r5dn の EC2 インスタンスファミリーです。このパフォーマンス結果の詳細については、ホワイトペーパーの「Accelerating SAS Using High-Performing File Systems on Amazon Web Services (アマゾン ウェブ サービスの高性能ファイルシステムによる SAS の高速化)」をご参照ください。i3 インスタンスファミリーでは、最小限のネットワークパフォーマンスに対して、わずかながら不足が見られました。SASWORK と UTILLOC ライブラリ用のインスタンスストレージが必要な場合は、i3en インスタンスが適しているでしょう。

M5n と r5n ではコストとパフォーマンスのバランスが良く、SAS Grid ノード向けとしては、m5n のインスタンスファミリーが推奨されます。ただし、メモリに対する縛りが強いワークロードを実行する場合は、r5n インスタンスが向いています。m5n インスタンスと比較すると、こちらでは、追加料金により物理コアごとに大きなメモリーがで利用可能になります。

今回は、rhel_iotest.sh も実行しました。これは、SAS のテクニカルサポートによるサンプルツールレポジトリ (SASTSST) から入手可能です。FSx for Lustre には、前出と同様な設定を使用しています。次の表に、m5n および r5n ファミリーにおけるさまざまなインスタンスサイズでの、読み出しおよび書き込みのパフォーマンス結果を物理コアごとに示します。

クラウドでの伸縮性やスケーラビリティ、そして柔軟性を活用するためには、SAS Grid やコンピューティングワークロードを、少数の大きなインスタンスではなく多数の小さなインスタンスで展開することを推奨します。SAS Grid アーキテクチャにおいては、中間層で最低 2 つのインスタンスを、また、メタデータサーバーには、最低でも 3 つのインスタンスを使用します。

まとめ

FSx for Lustre の登場以前、SASWORK や SASDATA そして UTILLOC のライブラリを使用する、もしくはデータを保存する際には、Amazon Elastic File System (Amazon EFS) を使用するか、サードパーティ製のファイルシステムを AWS Marketplace や Amazon Elastic Block Store (Amazon EBS) から入手して使用する必要がありました。これらの各ストレージには、固有の設定と制限があり、それがパフォーマンスを損なう原因となっていました。FSx for Lustre では、すべてのSAS Grid のストレージ要件に対する単一的なソリューションを提供します。これによりお客様は、ファイルシステムの管理ではなく、本来のビジネスに注力できるようになります。SAS の管理者には、FSx for Lustre ファイルシステムをアクセスする SAS Grid のコンピューティングノード向けとして、m5n および r5n インスタンスを使用してのデプロイを推奨します。

ご質問またはご提案などについては、以下からコメントをお寄せください。