023-AWS SAP AWS 「理論・実践・一問道場」 Amazon FSx for Lustre

type

status

date

slug

summary

理論

大規模データ処理の効率化

企業がデータ集約型アプリケーションをAWS上で運用している場合、パフォーマンスとコストの最適化は重要な課題です。特に、大規模なデータ処理や月次のバッチジョブを実行するシナリオでは、ストレージと計算リソースのコストをどのように削減しつつ、高速なデータアクセスを維持するかが重要です。この記事では、AWSの各種サービスを活用したコスト削減の方法を解説します。

1. Amazon S3 Intelligent-Tiering: 自動的にコスト最適化

Amazon S3 Intelligent-Tiering は、データのアクセス頻度に基づいて自動的にストレージクラスを変更するストレージサービスです。アクセス頻度が低いデータを最適なストレージに自動的に移行するため、コスト削減が可能です。例えば、月次バッチジョブでデータを使用する場合、ほとんど使用されないデータを低コストのストレージクラスに保存し、アクセス頻度が高いデータを適切なストレージクラスで管理することができます。

コスト削減: 使用していないデータのコストを最適化

柔軟性: アクセス頻度に応じてストレージクラスを自動的に変更

2. Amazon FSx for Lustre: 高パフォーマンスなファイルシステム

データ集約型のアプリケーションや大規模なバッチ処理には、Amazon FSx for Lustre が最適です。これは、高速なデータアクセスが求められるシナリオに最適なファイルシステムです。FSx for Lustreは、Amazon S3 と統合することで、データを高速に読み込み、バッチ処理中に必要なパフォーマンスを提供します。

高速アクセス: データ処理に最適化された高速なファイルシステム

S3統合: S3と連携し、データを効率的に取得・処理

3. バッチロード: 大規模データ移行の効率化

バッチロード は、大量のデータを一度に移行する方法です。ジョブ実行前に必要なデータをまとめて移行し、必要なタイミングで効率的にアクセスできるようにする手法です。このアプローチは、リアルタイム処理が不要なシナリオに有効です。

効率的なデータ移行: 大量のデータを一度に処理

遅延可能: リアルタイム性を必要としない場合に有効

以下は、遅延読み込み（Lazy Loading） と バッチロード の比較表です。

特徴	遅延読み込み（Lazy Loading）	バッチロード
データのロードタイミング	必要なタイミングでデータを逐次的にロード	最初に全てのデータを一度にロード
パフォーマンス	高速、必要なデータのみをロードするため効率的	大量データを一度に処理するため時間がかかる可能性あり
コスト	使用した分だけコストが発生、無駄なロードが発生しない	一度に大量のデータをロードするためコストが高くなる可能性
用途	必要なデータを必要なときに読み込むシナリオに最適	大量のデータをまとめて処理する必要がある場合に適応
データ処理の柔軟性	高い、必要なデータだけを動的に取得できる	低い、最初に全てのデータを準備する必要がある

このように、遅延読み込み（Lazy Loading） は、必要なデータだけを効率的に取得するため、パフォーマンスとコストに優れています。一方、バッチロード は、大量のデータを一度に扱うシナリオに適していますが、パフォーマンスとコスト面での問題が発生することがあります。

4. AWS Storage Gateway: ハイブリッド環境でのデータアクセス

AWS Storage Gateway は、オンプレミスのデータとAWSクラウド間でシームレスにデータを統合するサービスです。ファイルゲートウェイ を使用することで、S3のデータをオンプレミスのアプリケーションから直接アクセス可能にします。これにより、クラウドストレージの利点を享受しつつ、オンプレミス環境と連携できます。

ハイブリッドアーキテクチャ: オンプレミスとAWSのシームレスなデータ連携

コスト: クラウドストレージにアクセスするための追加コストが発生する可能性

最適なソリューションの選択

これらのサービスを組み合わせることで、コスト削減とパフォーマンス最適化を実現できます。具体的なシナリオとしては、データをAmazon S3 Intelligent-Tiering に保存し、月次ジョブ実行時にAmazon FSx for Lustre を利用して必要なデータに迅速にアクセスする方法が挙げられます。これにより、常に高性能なデータアクセスを確保しつつ、ストレージコストを抑えることができます。

AWSのサービスは、それぞれ異なるユースケースに最適化されており、シナリオに合わせた選択をすることで、コスト削減とパフォーマンス向上を両立できます。

実践

参照元：

Amazon FSx for Lustreにファイル読み書きしてLustreの特性を学ぶ | DevelopersIO

AWS HPC Workshopsを下記の項を参考にすすめていきます。 Build a High-Performance File Systemでは、FSx for LustreをParallelClusterにマウントしてファイルのアクセス方法などが解説されています。

https://dev.classmethod.jp/articles/amazon-fsx-for-lustre-learn/

Amazon FSx for LustreとAWS ParallelClusterでHPC環境を学ぶ

1. Lustreファイルシステムの理解

Lustreは、高性能コンピューティング（HPC）向けに特化した分散型ファイルシステムで、並列処理や大量のデータを扱うシステムに最適です。Amazon FSx for Lustreは、このLustreファイルシステムをAWS上でフルマネージドで提供するサービスであり、HPC環境でのストレージニーズに対応します。

2. AWS ParallelClusterの活用

AWS ParallelClusterは、HPCクラスターを簡単に構築、管理できるAWSの公式ツールです。これを使用して、Amazon FSx for Lustreにアクセスし、Lustreファイルシステムの管理方法やデータアクセス方法を学びます。ParallelClusterは、HPCワークロードをクラウド環境でスムーズに運用できるように支援します。

3. AWS HPC Workshopsでの実践

AWS HPC Workshopsでは、HPC技術を学ぶためのハンズオンが提供されています。特に「Build a High-Performance File System」というセクションでは、FSx for LustreをParallelClusterにマウントし、ファイルシステムの操作方法やアクセス方法について解説されています。このセクションを通じて、AWS上での効率的なストレージ管理の仕組みを学ぶことができます。

4. ストライピングと性能検証

ストライピングは、データを複数のストレージに分散して保存し、データ読み書き速度を向上させる技術です。FSx for Lustreを使用して、ストライピングを行い、その性能を検証することが可能です。この検証記録を通じて、どのようにHPC環境でのデータ処理効率を最大化できるかを学びます。

このように、AWS ParallelClusterとAmazon FSx for Lustreを活用して、HPC環境でのストレージとファイルシステム管理を学ぶことができます。また、実際の検証を通じて、ストライピングの性能向上効果も体験できます。

S3にサンプルデータのアップロード

S3に保存したデータをFSx for Lustre経由してアクセスするための準備

20190319 AWS Black Belt Online Seminar Amazon FSx for Lustre

from

Amazon Web Services Japan

S3バケット作成

サンプルファイルをローカルにダウンロード

サンプルファイルをS3バケットにアップロード

ローカルのサンプルファイルを削除

CloudShellで実行

FSx for LustreをマウントしたParallelClusterの構築

以下は、AWS ParallelCluster の設定ファイルで FSx for Lustre を新規作成し、SCRATCH_2 デプロイタイプを指定してマウントする方法を分かりやすく説明した内容です。

1. FSx for Lustreの概要

FSx for Lustre は高性能な分散ファイルシステムで、HPC（高性能計算）などでよく使われます。デプロイタイプは以下の3種類から選べます：

SCRATCH_1（デフォルト）

短期使用向けで安価。

スループットは固定。

データの耐久性は保証されません。

SCRATCH_2（今回使用するタイプ）

第2世代のスクラッチファイルシステム。

短期使用向けでデータ耐久性は保証されないが、データ容量 1 TB あたり最大 1200 MB/s のスループットにバースト可能。

PERSISTENT_1

永続ファイルシステム（データ耐久性を保証）。

高可用性が必要な長期ストレージに適している。

FSx for Lustreのデプロイタイプはスクラッチ2を指定して作成します。

Amazon FSx for Lustre の最新情報: 長期間、高パフォーマンスワークロード用の永続ストレージ | Amazon Web Services

昨年、Amazon FSx for Lustre についての記事を投稿した際、当社のお客様がサブミリ秒の遅延で […]

https://aws.amazon.com/jp/blogs/news/amazon-fsx-for-lustre-persistent-storage/?sc_channel=sm&sc_campaign=AWS_Blog,launch_&sc_publisher=FACEBOOK&sc_country=Japan&sc_geo=JAPAN&sc_outcome=awareness&trk=amazon-fsx-for-lustre-persistent-storage_FACEBOOK&sc_content=amazon-fsx-for-lustre-persistent-storage&sc_category=FSx+for+Lustre&linkId=83748590

Amazon FSx for Lustre の最新情報: 長期間、高パフォーマンスワークロード用の永続ストレージ | Amazon Web Services

AWS ParallelClusterの設定ファイル

6行追加するだけでクラスター構築と同時にFSx for Lustreも新規作成・マウントしてくれます。

What is AWS ParallelCluster - AWS ParallelCluster

AWS ParallelCluster is an AWS supported open source cluster management tool that helps you to deploy and manage high performance computing (HPC) clusters in the AWS Cloud. It automatically sets up the required compute resources, scheduler, and shared filesystem. You can use AWS ParallelCluster with AWS Batch and

https://docs.aws.amazon.com/parallelcluster/latest/ug/fsx-section.html

操作手順

1. 設定ファイルを作成する

設定ファイルの準備

テキストエディタを使って設定ファイルを作成します。ファイル名は config.ini とします。

設定内容の記述

次の設定をファイルに記述してください。

2. クラスターの作成

コマンドを実行する

設定ファイルを指定してクラスターを作成します。

クラスターの進行状況を確認する

クラスターの作成には数分かかります。以下のコマンドでステータスを確認できます。

ステータスが CREATE_COMPLETE になれば成功です。

3. クラスターに接続して確認する

クラスターに SSH 接続する

作成したクラスターのマスターインスタンスに接続します。

FSx for Lustre のマウント確認

接続後に次のコマンドを実行し、FSx for Lustre が正しくマウントされているか確認します。

出力に /lustre が表示されていれば成功です。

4. 必要に応じた操作

FSx のパフォーマンス確認:

必要に応じて Lustre ファイルシステムにデータを読み書きし、パフォーマンスを確認します。

クラスターの削除:

クラスターが不要になったら、次のコマンドで削除します。

注意点

リソース料金に注意

クラスターを起動している間、AWS リソース（EC2、FSx など）の使用料金が発生します。不要な場合は速やかに削除してください。

インスタンスとストレージの選定

ワークロードに応じて適切なインスタンスタイプやストレージサイズを選択してください。

トラブル時の対応

クラスターの作成や接続がうまくいかない場合、設定ファイルや IAM ポリシーを見直してください。

これで、AWS ParallelCluster を使って FSx for Lustre を組み込んだクラスターを簡単に構築できます！

MDT（Meta Data Target）とOST（Object Storage Target）の概要

MDT (Meta Data Target)

ファイルシステムのメタデータを保持するストレージです。
MDS（Meta Data Server）にマウントされたストレージ領域です。

OST (Object Storage Target)

ファイルシステムの実データを保存するストレージです。
OSS（Object Storage Server）にマウントされたストレージ領域です。

Amazon FSx for Lustreはマネージドサービスで、MDSやOSSのサーバー管理が不要です。FSx for Lustreのデプロイ時に、ストレージサイズを1.2TB単位で指定します。この指定されたサイズはOSTのストレージサイズです。

Lustreのストレージアクセスとパフォーマンス

アクセステスト

初回アクセス

455MBのファイル（SEG_C3NA_Velocity.sgy）をFSx for Lustreにマウントされたディレクトリにアクセス。初回アクセス時は、HPCクラスターがUS-East-1にあり、S3バケットがAP-Northeast-1にあるため、16秒のアクセス時間となった。

キャッシュ後の再アクセス

データがインスタンスにキャッシュされた後の再アクセスでは、0.24秒と大幅に速くなった。さらに、キャッシュ削除後でもアクセス時間は0.8秒となり、最初のアクセスに比べて格段に速くなった。

ファイルの状態確認

lfs hsm_state コマンドでファイルの状態を確認すると、最初は「released」で、ファイルがLustreのストレージにロードされていないことがわかる。キャッシュ後、状態は「exists archived」となり、ファイルがLustreにロードされたことが確認できた。

ファイル解放

lfs hsm_release コマンドでファイルを解放し、再度状態を確認すると、ファイルが「released」に戻った。

FSx for Lustreのストレージ容量と使用状況

MDTの容量とOSTの容量

lfs df コマンドを使ってFSx for Lustreのストレージ容量を確認した結果、MDTは約35GB、OSTの使用可能容量は1.1TBであることがわかる。

ファイル保存後の使用容量確認

455MBのサンプルファイルをLustreに保存した後、OSTの使用容量が459MBに増加した。ファイルを解放した後、再び使用容量は4.5MBに戻った。

FSx for Lustreのストライピング

ストライピングの設定

Amazon FSx for Lustreは、デフォルトでストライピングが有効でない設定です。lfs getstripe コマンドを確認したところ、stripe_countが1となっており、実際にはストライピングされていないことが確認されました。

複数のOSTとストライピング

FSx for Lustreを新たに作成し、複数のOSTを使用する設定（4つのOST、各1.1TB）にした場合でも、ストライピング設定が有効でないことが確認されました。

実際のファイル操作によるパフォーマンス

ファイル書き込みテスト

約10GBのファイルをLustreに書き込むテストを行った結果、2分10秒かかりました。書き込み速度は80.3MB/sとなりました。

このように、FSx for Lustreでは、ストレージの管理、データのキャッシュ、ストライピングの有無に関する設定やパフォーマンスが重要な要素となり、利用状況に応じて最適な管理と運用が求められます。

一問道場

ある企業が、データ集約型のアプリケーションをAWSで運用しています。このアプリケーションは、月に1回実行され、200 TBのデータを扱う共有ファイルシステムでデータを読み書きしてレポートを生成します。計算インスタンスはオートスケーリンググループでスケールしますが、共有ファイルシステムをホストするインスタンスは常時稼働しています。

要件:

月に1回のジョブが72時間で実行される。

必要なデータに高パフォーマンスアクセスが必要。

共有ファイルシステムを置き換えてコストを削減。

選択肢の整理:

手順:

既存の共有ファイルシステムからデータをAmazon S3に移行。

S3 Intelligent-Tieringストレージクラスを使用。

ジョブ実行前に、Amazon FSx for Lustreを使用して、S3から新しいファイルシステムを作成し、遅延読み込みでデータをロード。

ジョブ終了後にFSx for Lustreファイルシステムを削除。

手順:

既存の共有ファイルシステムからデータをAmazon EBSに移行。

Multi-Attachを有効にして、EBSボリュームを複数のインスタンスにアタッチ。

Auto Scalingグループのユーザーデータスクリプトで、EBSボリュームをインスタンスに接続。

ジョブ終了後にEBSボリュームをデタッチ。

手順:

既存の共有ファイルシステムからデータをAmazon S3に移行。

S3 Standardストレージクラスを使用。

ジョブ実行前に、Amazon FSx for Lustreを使用して、S3から新しいファイルシステムを作成し、バッチロードでデータをロード。

ジョブ終了後にFSx for Lustreファイルシステムを削除。

手順:

既存の共有ファイルシステムからデータをAmazon S3に移行。

AWS Storage Gatewayを使用して、S3からファイルゲートウェイを作成。

ジョブ終了後にファイルゲートウェイを削除。

特徴:

S3からファイルゲートウェイを使ってデータを直接アクセスできる。
Storage Gatewayを使うことで、オンプレミスとAWSのデータ統合が可能。

結論:

最もコスト削減を実現できる選択肢は A です。

理由:

S3 Intelligent-Tieringを使用することで、データのアクセス頻度に応じたコスト管理が可能になり、FSx for Lustreで必要なデータを効率よく処理できるからです。
バッチ処理によるデータの遅延読み込みで、不要なコストを抑えつつ、72時間のジョブを高パフォーマンスで実行できます。