Amazon FSx
Lustre、Windows File Server、NetApp ONTAP、OpenZFS の 4 種類のファイルシステムをフルマネージドで提供し、ワークロードに応じた最適な選択肢を用意している。
概要
Amazon FSx は、業界標準のファイルシステムをフルマネージドで提供するサービスファミリーです。高性能コンピューティング (HPC) や機械学習向けの FSx for Lustre、Windows ベースのアプリケーション向けの FSx for Windows File Server、エンタープライズ NAS 機能を備えた FSx for NetApp ONTAP、汎用的な POSIX 互換ファイルシステムの FSx for OpenZFS の 4 バリアントがあります。いずれもバックアップ、パッチ適用、ハードウェア障害対応を AWS が管理するため、オンプレミスのファイルサーバー運用から解放されます。EFS (Elastic File System) が汎用的な NFS ファイルシステムを提供するのに対し、FSx は特定のプロトコルやワークロードに最適化された選択肢を提供する位置づけです。
4 つのバリアントと選定フローチャート
FSx の選定で最初に確認すべきはプロトコル要件です。Windows アプリケーションが SMB プロトコルや Active Directory 統合を必要とする場合、選択肢は FSx for Windows File Server に絞られます。NTFS のアクセス制御リスト (ACL)、DFS 名前空間、シャドウコピーなど Windows ネイティブの機能がそのまま使えるため、オンプレミスの Windows ファイルサーバーからの移行先として最適です。HPC や機械学習のトレーニングジョブで S3 と連携した高スループットが必要な場合は FSx for Lustre を選びます。Lustre は S3 バケットをデータリポジトリとしてリンクでき、ファイルアクセス時に S3 から自動的にデータをロードする遅延読み込み (Lazy Loading) が可能です。SageMaker のトレーニングジョブで大量のデータセットを高速に読み込む場面で威力を発揮します。マルチプロトコル (NFS、SMB、iSCSI) が必要な場合や、スナップショット・クローン・階層化などのエンタープライズ NAS 機能が求められる場合は FSx for NetApp ONTAP が適しています。特定のプロトコル要件がなく、POSIX 互換の汎用ファイルシステムが必要な場合は FSx for OpenZFS が軽量な選択肢です。
EFS との使い分け - 汎用性か専門性か
AWS のマネージドファイルシステムとして EFS と FSx はよく比較されます。EFS は NFS v4 プロトコルの汎用ファイルシステムで、容量が自動的にスケールし、Lambda や ECS からのマウントも容易です。一方 FSx は特定のワークロードに最適化されており、性能特性が大きく異なります。FSx for Lustre は数百 GB/s のスループットを実現でき、EFS の汎用モードでは到達できない性能領域をカバーします。コスト面では、EFS はアクセス頻度に応じた階層化 (Standard / Infrequent Access) で自動最適化されるのに対し、FSx はプロビジョニング時にストレージ容量とスループットを固定で指定します。ワークロードの I/O パターンが予測可能な場合は FSx の方がコスト効率が良く、アクセスパターンが不規則な場合は EFS の従量課金が有利です。Azure の対応サービスとしては Azure Files (SMB) や Azure NetApp Files (NFS/SMB) がありますが、Lustre 相当の HPC 向けファイルシステムをマネージドで提供するサービスは Azure にはなく、FSx for Lustre は AWS 固有の強みです。ストレージ設計の関連書籍 (Amazon) では、ワークロード特性に応じたファイルシステム選定の考え方が詳しく解説されています。
Lustre と S3 の連携 - データパイプラインの高速化
FSx for Lustre の最大の特徴は S3 との透過的な連携です。S3 バケットをデータリポジトリとしてリンクすると、Lustre ファイルシステム上に S3 オブジェクトのメタデータが自動的にマッピングされます。実際のデータは最初のファイルアクセス時に S3 から Lustre のストレージにロードされる遅延読み込み方式で、事前に全データをコピーする必要がありません。処理結果を S3 に書き戻すには hsm_archive コマンドまたは自動エクスポート機能を使います。デプロイタイプは Scratch と Persistent の 2 種類があります。Scratch は一時的な高速ストレージで、データの冗長化がないためコストが低い反面、ハードウェア障害時にデータが失われます。バッチ処理やトレーニングジョブなど、元データが S3 に保存されていて再実行可能なワークロードに適しています。Persistent はデータが AZ 内で冗長化され、長期間稼働するワークロードや再計算コストが高い中間データの保持に向いています。スループットは 50 - 1,000 MB/s/TiB の範囲で選択でき、ストレージ容量あたりのスループットを上げるほどコストも上がります。実務では最初に低いスループット設定で開始し、CloudWatch の FileServerDiskThroughputBalance メトリクスを監視しながら必要に応じて引き上げるアプローチが合理的です。