なんとなくで作っていたFSx for Lustreの複数ファイルシステムを理解する
2025.08.14こんにちは。まるとです。
最近FSx for Lustreに触れる機会があったので、備忘録としてメモします。
FSx for Lustreとは
Amazon FSx for Lustreは、AWSが提供する高性能分散ファイルシステムサービスです。
元々、スーパーコンピューター向けに開発されたLustreファイルシステムをクラウドで手軽に利用できるサービスとなっています。
FSx for Lustreを作るために最低限必要な設定
ここから本題です。
FSx for Lustreの作成には、少なくとも以下の項目を設定する必要があります。
- デプロイとストレージクラス
- ストレージ単位あたりのスループット
- ストレージキャパシティ
- メタデータの設定
- データ圧縮タイプ
- VPC
- VPC セキュリティグループ
- サブネット
- 暗号化キー
この中でも特に「デプロイとストレージクラス」の内容について、あまり理解できていなかったため調べてみました。
デプロイとストレージクラスについて
現状では、以下のストレージクラスが提供されています。
- 永続的ファイルシステム
- Persistent 2 デプロイタイプ
- Persistent 1 デプロイタイプ
- 永続的なインテリジェント階層化
- スクラッチファイルシステム
それでは順番に見ていきます。
永続的ファイルシステム/永続的、SSD
AWS内でデータが同じアベイラビリティゾーン内（インテリジェント階層化の場合は、複数アベイラビリティゾーン）にレプリケーションされる、長期的なデータ保存かつ高可用性を目的としたファイルシステムです。
ハードウェア障害によりファイルシステムに障害が発生してもデータを保持しつつ、自動で正常な状態に置き換えられます。
障害が発生した場合でも自動でリカバリーが効くため、長時間実行されるワークフローや機械学習の継続的な推論、データ損失が許されない計算処理などに向いています。
その他、デプロイタイプとしては以下のものが存在します。
- Persistent 2 デプロイタイプ
- Persistent 1 デプロイタイプ
Persistent 1/2は世代の違いです。
本記事執筆時点では、AWSマネジメントコンソールからファイルシステムを作成した場合は、Persistent 2が使用されます。（Persistent 1を利用した新規作成はCLI、API経由での作成のみ可能）
Persistent 1ではSSDとHDDの2種をサポートしているのに対し、Persistent 2ではSSDのみをサポートするため、多くの場合はPersistent 2を利用することになります。
また、Persistentデプロイタイプではストレージの容量やスループットを事前に決めてファイルシステムを作成します。
永続的ファイルシステム/永続的なインテリジェント階層化
永続的なインテリジェント階層化では、あらかじめスループットキャパシティを定めます。
ストレージ容量は自動で拡張されるため、容量を気にする必要はあまりありません。
また、アクセス頻度によって自動で保存されるストレージが最適化され、料金が抑えられるようになっています。
上記を見ると、永続的なインテリジェント階層化が意識するものが少なく、費用面でも有利に見えますが、リクエスト料金という概念が存在します。
そのため、高頻度でリクエストを行う用途で永続的なインテリジェント階層化を選択した場合、逆にコストが高くなることがあるので注意が必要です。
日本語のページには記載がないのですが、英語版ページを確認すると記載があります。
こちらに関しては大村さんの記事でも紹介しているので、そちらもご確認ください。
スクラッチファイルシステム（スクラッチ、SSD）
こちらのファイルシステムは一時的なデータ向けのファイルシステムで、アベイラビリティゾーン内でデータのレプリケーションが行われません。
そのため、障害が発生した場合でもデータが保持されないものとなっております。
一方で、ストレージ容量あたりのスループットコストは安価に設定されているため、数日単位など短期間だけ使って直ぐにファイルシステムを削除する、という用途であれば費用を抑えて利用できます。
EFA対応について
Elastic Fabric Adapter (EFA)を利用することで、FSx for Lustreとの接続スループットを大幅に上げることができます。（通常100Gbps上限が1,500Gbps上限になる）
この設定を有効化すること自体に追加料金は発生しませんが、ストレージ単位あたりのスループットが最小1000 MB/s/TiBとなるため、FSx for Lustreファイルシステム自体の最小コストが変わるため注意が必要です。
また、EC2側のネットワークアダプタもインターフェイスタイプでENAとEFAを指定する必要があるなど、注意点があります。
終わりに
今回は各ストレージクラスについて調べてみました。
同じ永続的ファイルシステムでもリクエスト数などにより選択肢が変わることがわかりました。
また、スクラッチファイルシステムについてもうまく活用することで、高スループットかつ費用を抑えて利用できることがわかりました。
もし、選択で迷うことがあれば
- そもそも永続的に保存が必要か
- リクエスト数は多いか、少ないか
- ワークロードの時間はどれくらいかかるか
この3点を考えていただくことで良い選択ができると思いました。
この記事が少しでも参考になれば幸いです。
参考文献
![[AWS Technical Support Note]ฉันสามารถใช้ crontab บน Amazon Linux 2023 ได้หรือไม่](https://devio2024-media.developers.io/image/upload/v1753958779/user-gen-eyecatch/vajck46b5z0fsypxdtzj.png)
