Cloud Service
Amazon File Cache
分散したデータソースへの高速・一元アクセスを実現するフルマネージドな高速キャッシュ。オンプレや S3 など複数の場所のデータを、単一の名前空間から低遅延で読み書きできる。
- 1.S3 やオンプレ NFS など分散したデータを、単一の名前空間に集約して高速アクセスできる高性能キャッシュ。
- 2.Lustre ベースで高スループットと低遅延を提供し、クラウドへ移行したコンピュートからデータへ素早くアクセスできる。
- 3.データは元の場所に残したまま遅延ロードし、変更を元のリポジトリへ書き戻せる。一時的な作業層として使う。
Amazon File Cache は、分散して存在するデータセットへの高速な一元アクセスを提供する、フルマネージドの高性能キャッシュサービスです。オンプレミスや AWS 上の複数のデータソースを単一の名前空間にまとめ、クラウド上のコンピュートから低遅延でアクセスできるようにします。
解決する課題
クラウドへ計算処理を移したものの、元データがオンプレミスのファイルサーバーや複数の Amazon S3 バケットなど別々の場所に散在していると、処理のたびにデータを取りに行く経路がボトルネックになります。データ全体をあらかじめコピーするのは時間と容量のコストがかかり、ハイブリッド構成では距離による遅延も無視できません。
また、ハイパフォーマンスコンピューティングやメディア処理、機械学習の学習・推論のように、多数のクライアントが同じデータセットへ並列に高いスループットでアクセスするワークロードでは、汎用のストレージ経由のアクセスでは性能が頭打ちになりがちです。データの置き場所が複数のシステムに分かれていると、アクセス経路やマウント先がばらつき、アプリケーション側の扱いも煩雑になります。
Amazon File Cache は、これらの分散したデータソースを 1 つの高速なキャッシュ層に束ね、単一の名前空間として提供することでこの課題に応えます。実データは元のリポジトリに残したまま、必要なデータだけをキャッシュへ遅延ロードし、コンピュートからは一貫した高スループットでアクセスできます。
主要概念と用語
- キャッシュ: ファイルデータを一時的に高速保持する本体。Lustre ベースの高性能ファイルシステムとして提供され、クライアントからは単一の名前空間として見える。
- データリポジトリ連携 (DRA): キャッシュ上のパスと、元のデータソース(S3 バケットやオンプレミスの NFS など)を結びつける設定。1 つのキャッシュに複数のリポジトリを紐づけ、別々のサブディレクトリへマッピングできる。
- 遅延ロード: ファイルが初めてアクセスされたときに、元のリポジトリからキャッシュへ実データを読み込む仕組み。全データの事前コピーを避けられる。
- 書き戻し (エクスポート): キャッシュ上で変更したデータを、元のリポジトリへ反映する操作。
- 名前空間: 複数のデータソースを束ねた論理的なディレクトリ構造。クライアントは元データの所在を意識せず、1 つのマウントポイント配下としてアクセスできる。
- スループットキャパシティ: キャッシュが提供できる読み書き性能の指標。プロビジョニングした容量に応じて決まる。
- マウント: Lustre クライアントを用いて、EC2 などのコンピュートからキャッシュをファイルシステムとしてマウントする操作。
仕様・制限・クォータ
Amazon File Cache は Lustre をベースとした高性能ファイルシステムとして動作し、POSIX 互換のインターフェースを提供します。代表的な特性は次のとおりです。
- アクセス方式: Lustre クライアントを通じて POSIX 互換でマウントする。クライアントは VPC 内の EC2 やコンテナから接続する。
- データソース: Amazon S3 と、NFS でアクセスできるオンプレミスや他クラウドのファイルストレージをデータリポジトリとして連携できる。1 つのキャッシュに複数のリポジトリを束ねられる。
- 一時性: キャッシュはデータの永続的な置き場所ではなく作業用の高速層であり、原本は元のリポジトリ側で保持する前提で設計されている。
- 配置: VPC 内のサブネットに作成し、ネットワーク到達範囲はセキュリティグループで制御する。
- クォータ: 1 アカウント・リージョンあたりのキャッシュ数や容量、連携できるリポジトリ数などにサービスクォータが設定される。
具体的な容量の刻みやスループットの単位、上限値はリージョンや時期によって変動するため、設計時には最新の公式ドキュメントとサービスクォータ画面で確認してください。
内部の仕組み
Amazon File Cache は、メタデータを扱うコンポーネントとデータを格納するコンポーネントを内部で分離した Lustre アーキテクチャを採用しています。多数のクライアントからの並列アクセスを、高いスループットと低い遅延でさばけるよう設計されています。
データリポジトリ連携を構成すると、キャッシュ上の特定のパスが S3 バケットやオンプレミスの NFS エクスポートに対応づけられます。クライアントがあるファイルへ初めてアクセスすると、その実データが元のリポジトリから遅延ロードされ、以降のアクセスはキャッシュ上の高速なコピーから処理されます。これにより、データセット全体を事前にコピーしなくても、必要な部分だけを順次取り込めます。
キャッシュ上で変更したデータは、書き戻しの操作によって元のリポジトリへ反映できます。原本はリポジトリ側に残るため、キャッシュ自体は使い終わったら削除でき、必要なときに再作成して再びデータを取り込む使い方が想定されています。
オンプレミスの NFS を連携する構成では、AWS とオンプレミス間のネットワーク経路(専用線や VPN など)を通じてデータが取り込まれます。距離による遅延の影響は初回ロード時に主に現れ、その後はキャッシュ上のコピーへアクセスするため軽減されます。
設計パターン / ベストプラクティス
- 一時的な作業層として使う: 原本は S3 やオンプレミスに置いたまま、処理が必要な期間だけキャッシュを立ち上げ、終わったら削除してコストを抑える。
- 複数ソースの集約: 異なる S3 バケットやオンプレミスの共有を 1 つの名前空間にまとめ、アプリケーションから単一のマウントポイントとして扱えるようにする。
- ハイブリッド移行の橋渡し: オンプレミスのデータをいきなり全面移行せず、File Cache を経由してクラウド上のコンピュートから先に利用し始め、段階的な移行を進める。
- 並列ワークロードへの適用: HPC、機械学習、メディアレンダリングなど、多数のクライアントが高スループットで同じデータへアクセスする処理に向く。
File Cache はあくまで高速な作業層です。永続化が必要なデータは元のリポジトリ側で保持し、キャッシュ上の変更は書き戻しで確実に反映してから削除する運用にすると、コストとデータ保全のバランスを取りやすくなります。
運用・監視
メトリクスは Amazon CloudWatch に発行され、スループット、IOPS、ストレージ使用量、クライアント接続数などを監視できます。性能が頭打ちになっていないか、キャッシュの使用量が逼迫していないかを継続的に確認します。
データリポジトリ連携では、遅延ロードや書き戻しのタスクの進捗・状態を確認できます。大量のファイルを扱う場合は、初回アクセス時のロードに時間がかかることを見込み、必要に応じて事前ロードを計画します。オンプレミス連携では、ネットワーク経路の健全性や帯域も運用対象に含めます。
書き戻しが必要なワークロードでは、キャッシュを削除する前に変更がリポジトリへ反映済みであることを確認する手順を運用に組み込みます。
コスト
料金は主に、プロビジョニングしたキャッシュの容量とそれに対応するスループット性能に基づいて発生します。キャッシュが存在する間は課金が続くため、常時稼働させるよりも、処理が必要な期間だけ立ち上げて使い終わったら削除する使い方がコスト効率に優れます。
オンプレミスや他クラウドからのデータ転送には、ネットワーク経路に応じた転送コストが別途かかる場合があります。原本を S3 などに置き、File Cache を一時的な高速層として割り切ることで、永続ストレージのコストとキャッシュのコストを分離して最適化できます。
キャッシュは一時利用が前提のため、使い終わったら削除しないと容量・性能分の料金が発生し続けます。書き戻しの完了を確認したうえで、不要になったキャッシュは速やかに削除してください。
正確な単価はリージョンや時期によって変動するため、見積もりは公式の料金ページや料金計算ツールで確認してください。
セキュリティ
保存データは AWS KMS の鍵で暗号化され、転送中のデータも暗号化に対応します。キャッシュは VPC 内のサブネットに配置し、セキュリティグループで通信を制御することで、ネットワーク到達範囲を限定できます。
ファイルへのアクセス制御は POSIX のパーミッションに従います。AWS リソースとしてのキャッシュやデータリポジトリ連携の操作権限は IAM で制御し、最小権限の原則に従って付与します。S3 をリポジトリとする場合は、キャッシュが対象バケットへアクセスするための権限を適切に設定します。オンプレミス NFS を連携する構成では、ネットワーク経路自体を専用線や VPN で保護します。
関連サービス・比較
最も近い関連サービスは Amazon FSx for Lustre です。どちらも Lustre ベースの高性能ファイルシステムですが、FSx for Lustre が主に S3 と連携する独立した高性能ファイルシステムであるのに対し、File Cache は S3 とオンプレミス NFS を含む複数のデータソースを単一の名前空間に束ねる「キャッシュ」としての性格が強い点が違いです。
| 観点 | Amazon File Cache | FSx for Lustre |
|---|---|---|
| 主な役割 | 分散データを束ねる一時的な高速キャッシュ | 独立した高性能並列ファイルシステム |
| データソース | 複数のS3とオンプレNFSを単一名前空間に集約 | 主にS3と連携 |
| 想定利用 | 処理期間だけ立ち上げ使い終えたら削除 | 作業層として継続利用も可能 |
| 基盤 | Lustreベースの高性能ファイルシステム | Lustreベースの高性能ファイルシステム |
ハンズオン / CLI例
次の例は、AWS CLI で Amazon File Cache を作成し、一覧を確認するものです。実際の値(サブネット、セキュリティグループ、容量、データリポジトリの設定など)は環境に合わせて置き換えてください。
# File Cache を作成(Lustre ベース)
aws fsx create-file-cache \
--file-cache-type LUSTRE \
--storage-capacity 1200 \
--subnet-ids subnet-xxxxxxxx \
--security-group-ids sg-xxxxxxxx \
--lustre-configuration '{ "DeploymentType": "CACHE_1", "MetadataConfiguration": { "StorageCapacity": 2400 } }' \
--data-repository-associations '[{ "FileCachePath": "/data", "DataRepositoryPath": "s3://my-source-bucket" }]'
# 作成したキャッシュの一覧を確認
aws fsx describe-file-caches
AWS Service
Amazon File Cacheを実務で読む
TL;DRは入口です。実際に選ぶ・使う段階では、何を解決するか、何と比較するか、導入後にどこで詰まるかまで見る必要があります。
解決すること
ストレージ
比較で見る軸
クラウド: AWS / カテゴリ: ストレージ / 難易度: intermediate
導入後に効く点
Lustre ベースで高スループットと低遅延を提供し、クラウドへ移行したコンピュートからデータへ素早くアクセスできる。
先に潰すリスク
サービス単体ではなく、権限、ネットワーク、監視、課金、バックアップを含めて設計する必要がある。
- クラウド
- AWS
- カテゴリ
- ストレージ
- 難易度
- intermediate
- 関連資格
- SAA-C03 / SAP-C02
- 設計柱
- performance / cost / operational
判断チェックリスト
- 自社の用途が「ストレージ / performance」に近いか確認する。
- 強みである「S3 やオンプレ NFS など分散したデータを、単一の名前空間に集約して高速アクセスできる高性能キャッシュ。」が本当に評価軸になるか確認する。
- 注意点の「サービス単体ではなく、権限、ネットワーク、監視、課金、バックアップを含めて設計する必要がある。」を運用で吸収できるか確認する。
- 公開値や仕様値は、対象プラン・対象機種・対象リージョンまで確認する。
- 既存システム、ID、ネットワーク、監視、バックアップとの接続方法を先に洗い出す。
- 小さく試してから、本番移行、権限設計、障害時手順、コスト監視を決める。