KNFSD ファイルキャッシュのご紹介: NFS ストレージをクラウドに拡張

本記事は 2026 年 7 月 20 日に公開された「Introducing KNFSD File Cache: Extending your NFS storage into the clouds」を翻訳したものです

長年にわたり、Amazon Web Services (AWS) はコンピューティングインフラをスケールアップ、スケールアウト、そして広域展開する手段を提供してきました。一方、ストレージ面、特に Network File System (NFS) を基盤とし、オンプレミスやハイブリッド環境にデータを持つ組織にとっては、同じペースで進化が進んでいませんでした。コンピューティング負荷の高いワークロードでより高いスループットが必要な場合、並列ジョブ向けに高速な共有アクセスが必要な場合、あるいはデータを複製せずに別の AWS リージョンやアベイラビリティーゾーンにコンピューティングを配置したい場合でも、課題は共通しています。移行やクライアント側の変更なしに、弾力的なコンピューティングに見合ったデータアクセスのスケールを実現することは、依然として難しい問題でした。

KNFSD File Cache (KNFSD) はその課題を解決します。Amazon Elastic Compute Cloud (Amazon EC2) 上で動作するオープンソースの NFS キャッシングプロキシソリューションで、既存の NFS サーバーを透過的に AWS へ拡張します。クラウドインスタンスのすぐ近くに高性能なキャッシュ層を配置することで、ワークロードの実行場所を問わず、共有データへの高速アクセスを実現します。

本記事では、KNFSD の仕組みと、オンプレミスのファイラー、サードパーティ製品、Amazon FSx などの AWS サービスを含む NFS 準拠のストレージとの組み合わせ方を説明します。また、単一の Terraform モジュールで本番環境向けのオートスケーリングクラスターをデプロイする方法と、100 Gb/秒の合計スループットを 1 時間あたり 6 ドル未満で実現する方法についても解説します。

「AWS との共同作業で行った初期の KNFSD プロトタイプにより、極めて長距離でも高性能なキャッシングがクラウドレンダリングで実用的であることが証明されました。KNFSD File Cache 向けの新しい AWS Solution Guidance の採用を楽しみにしています。これは、私たちが手作業で構築しなければならなかった機能をまさに製品化したものです。」

– Kimball Thurston、CTO、Wētā FX

対象となるユーザー

KNFSD は、クラウド上の NFS データへの高性能かつ読み取り中心のアクセスと、ソースへの書き戻しが必要なあらゆる組織を対象に設計されています。ユースケースには以下が含まれますが、これらに限りません。

読み取り I/O が多いコンピューティング集約型の業界: 既存の NFS インフラに保存された大規模データセットへの高速な共有アクセスを必要とするワークロード全般。メディア & エンターテインメント (レンダーファーム)、ハイパフォーマンスコンピューティング、金融サービス、ヘルスケア & ライフサイエンス、エネルギー、気象 & 気候科学などが含まれます。
ハイブリッドクラウドおよびマルチクラウド: オンプレミスのファイラーや他のクラウドプロバイダーから、データの移行や複製なしに既存の NFS インフラを AWS へ拡張したい組織。
マルチリージョンおよびマルチ AZ : AWS リージョンまたはアベイラビリティーゾーンをまたいでコンピューティングを分散させるスタジオや研究チーム。KNFSD がデータをローカルにキャッシュすることで、中央の NFS ソースへのレイテンシーを解消します。

「KNFSD キャッシングソリューションは期待を上回る結果をもたらしました。開発中に AWS と協力し、本番環境でのスケール運用に必要な重要な内部メトリクスが確実に公開されるようにしたことで、独自ツールの構築が不要になりました。この取り組みのおかげで、不確実な状態から脱却し、複数のプロジェクトにわたって本番環境でこのソリューションを効果的に運用できるという確信を持てるようになりました。」

– Greg Newman、シニアマネージャー、プロダクションエンジニアリング & デジタルリソース、Industrial Light & Magic (ILM)

KNFSD File Cache とは

KNFSD は、ハイブリッドおよびバーストコンピューティングのユースケース向けに設計された高性能 NFS キャッシングプロキシを提供する、オープンソースの AWS Solution Guidance です。既存のオープンソースプロジェクトをフォークし、AWS との統合機能を加えて拡張しています。AWS 上での動作最適化 (AWS Graviton を含む)、開発環境および本番環境向けのコンテナサポート、OpenTelemetry と Amazon CloudWatch を活用した包括的なメトリクスダッシュボード、そして Common Vulnerabilities and Exposure (CVE) 対策による強化されたセキュリティを備えています。

KNFSD File Cache は、実績ある Linux カーネル技術を基盤としています。

nfs-kernel-server – NFS マウントの再エクスポートをサポートする Linux カーネルネイティブの NFS サーバーです。プロキシがソースの NFS エクスポートをマウントし、まるで元のファイラーであるかのように下流のクライアントへ提供します。
cachefilesd (FS-Cache) – ネットワークファイルシステムのデータをローカルディスクに永続的にキャッシュする Linux カーネルモジュールです。同じファイルへの再リクエスト時は、ソースから取得するのではなく、キャッシュから直接提供されます。

KNFSD は kernel NFS daemon の略で、ソリューションを支えるカーネル空間コンポーネントへの敬意を込めた名称です。独自エージェント、ベンダー固有のプロトコル、特定のストレージソリューションへの依存は一切ありません。既存のファイラーに対して NFSv3 または NFSv4 で通信できる NFS クライアントであれば、変更なしに KNFSD と連携できます。

2 段階のキャッシュ

KNFSD は、各プロキシインスタンスに 2 層のキャッシュ階層を提供します。

レイヤー	技術	媒体	特性
L1	Linux ブロックキャッシュ	RAM	超低レイテンシー、インスタンスメモリ量に依存
L2	FS-Cache (cachefilesd)	ローカル NVMe	高スループット、再起動後もデータが保持され、テラバイト級の容量

クライアントがファイルをリクエストすると、プロキシはまず L1 (RAM) を確認します。RAM からデータが退避されている場合は、L2 (NVMe ディスク) がローカルストレージの速度で提供します。完全なキャッシュミスが発生した場合のみ、プロキシはソースファイラーからデータを取得します。ファイルの取得後、そのプロキシに接続しているクライアントからの後続の読み取りはキャッシュから提供されます。

“EngineLab では、Barnstorm VFX などのスタジオ向けクラウドバーストレンダリングアーキテクチャの中核として KNFSD を導入しています。オンプレミスのコンピューティングリソースが枯渇した瞬間に AWS 上でレンダリング容量をスケールでき、KNFSD が限られた帯域幅接続でテクスチャなどの共通アセットを効率的にキャッシュします。レンダリング中はコンピューティングの料金のみを支払い、不要な時はゼロにスケールダウンできます。私たちが目指しているのはまさにこれです。インフラの制約を取り除くことで、お客様がクリエイティブな作業に集中し、より野心的なプロジェクトに挑戦でき、レンダーファームの規模によって締め切りが左右されることのない環境を実現することです。”

– Sam Reid、CEO/Co-Founder、EngineLab

仕組み

アーキテクチャはシンプルです。次の図は、コンピューティングが低レイテンシー・高帯域幅で NFS データにアクセスできるよう、KNFSD を使って再エクスポートされた NFS データへのローカルアクセスを提供するデプロイ構成を示しています。

図 1: KNFSD アーキテクチャ図

この構成には以下の機能が含まれています。

ソースマウント – 各プロキシインスタンスは、オンプレミスのファイラー、NFS 対応の Amazon FSx サービス、別のアベイラビリティーゾーンやリージョン、または他のクラウドプロバイダーなど、ソース NFS デバイスのエクスポートをマウントします。
接続 – KNFSD は、AWS Site-to-Site VPN、AWS Direct Connect、AWS Interconnect (マルチクラウド) など、他の AWS インフラと同じ接続方式をサポートし、オンプレミスストレージへの安全で低レイテンシーなアクセスを提供します。
負荷分散 – Amazon EC2 Auto Scaling グループが複数の KNFSD インスタンスを管理します。クライアントトラフィックは DNS ラウンドロビンまたは Elastic Load Balancing (Network Load Balancer) で分散されます。
クライアントへの透過性 – NFS クライアントは、通常の NFS 共有と同じ方法で KNFSD のエクスポートをマウントできます。特別なドライバー、エージェント、設定は不要です。
利用 – Amazon EC2 インスタンスはワークロードの処理に合わせてスケールし、変更なしに KNFSD 経由でソースデータにアクセスし、必要に応じて結果を書き戻します。また、スループット要件の増加に応じて KNFSD インスタンスのスケールアップを促すシグナルを提供します。

“NFS キャッシュは、長年にわたってお客様から繰り返しご要望いただいてきた機能です。自信を持ってお客様に提案できる AWS サポート付きのソリューションが登場したことを嬉しく思います。”

– Paul Judkins、VP Cloud Services、Integrated Media Technologies (IMT) Global

KNFSD File Cache の位置づけ

AWS は幅広いストレージサービスを提供しています。耐久性の高いオブジェクトストレージと分析向けの Amazon Simple Storage Service (Amazon S3)、フルマネージドの高性能ファイルシステム向けの Amazon FSx、そして弾力的なサーバーレス NFS 向けの Amazon Elastic File System (Amazon EFS) などがあります。これらはいずれも、対象ワークロードのプライマリストアとして設計されています。

データを移行したりクライアントのマウントパスを変更したりすることなく、既存の NFS ソースからバーストスケールのスループットを必要とするワークロードには、透過的なアクセラレーションレイヤーが必要です。Amazon File Cache や Amazon FSx for NetApp ONTAP FlexCache などのマネージドオプションはこれらのシナリオの一部に対応していますが、Amazon EC2 上で動作するシンプルで低コストなオープンソースのキャッシュレイヤーが最適なケースも多くあります。特に、チューニングの完全な制御、透過的な NFS 再エクスポートのセマンティクス、そして柔軟なスケールアップ・スケールアウトが必要な場合に適しています。

KNFSD が埋めるのはこのニッチです。リポジトリには、強化された AMI、ルート Terraform モジュール (複数の子モジュールと独立したデータベース・メトリクスモジュールを含む)、組み込みのオブザーバビリティ、ヘルスチェック、オートスケーリング、ファンアウトトポロジーが含まれています。

キャッシュは KNFSD 層に保持されるため、ダウンストリームのコンピューティングインスタンスを Amazon EC2 スポットインスタンス (AWS が短い通知で回収できる、大幅に割引された中断可能なキャパシティ) として実行しても、データ損失や再取得のリスクはありません。スポットインスタンスが回収されて新しいインスタンスに置き換えられた場合も、新しいインスタンスはすぐにウォームキャッシュの恩恵を受けられます。

“『Avatar: The Way of Water』では、オンプレミス設備の 250% の規模のクラウドレンダーファームを運用し、AWS と共同開発した NFS キャッシュがショーのデータへのアクセスをスケールさせる上で不可欠な役割を果たしました。Avatar 後に改善点として挙げていた領域 (弾力的なスケーリング、ロードバランシング、階層型キャッシング) は、まさに AWS が KNFSD File Cache に組み込んだ機能です。ハイブリッドレンダーパイプライン全体への導入と、オープンソースプロジェクトへの貢献を楽しみにしています。”

– Andy Wright、Head of Pipeline、Wētā FX

主な機能

KNFSD は、迅速なデプロイ、シンプルな運用、初日からのオブザーバビリティを実現するよう設計されています。このセクションでは、本番環境で特に重要な機能を説明します。

事前構築済み AMI

リポジトリには Packer ビルドスクリプトが含まれており、Ubuntu ベースの最適化された Amazon Machine Images (AMI) を生成します。従来の x86 Intel・AMD プロセッサと、AWS Graviton Processors (ARM64) などの ARM ベースプロセッサの両アーキテクチャに対応しています。

Packer ビルドで作成されるイメージには以下が含まれます。

NFS 再エクスポートと FS-Cache を有効化したチューニング済み Linux カーネル
CloudWatch と OpenTelemetry を使用したオブザーバビリティ向けの KNFSD メトリクスエージェント
ヘルスチェックとステータス確認用の KNFSD HTTP エージェント
ビルド検証用のスモークテスト

AWS はストレージ最適化された Amazon EC2 インスタンス (L2 層向けのローカル NVMe 搭載) を幅広く提供しており、各パイプラインステージのアクセスパターンに合わせて KNFSD インスタンスを選択できます。数百万件の小さなファイル読み取りが中心のワークロードには、最新の i7ie および i8g ファミリーの低レイテンシー NVMe が適しており、大きなシーケンシャル読み取りには im4gn および i3en ファミリーの高スループットと大容量キャッシュが有利です。

AWS Graviton の優位性は特に注目に値します。NFS 再エクスポートとディスクキャッシングは、高いシングルスレッド性能を必要とせず複数コアに並列化しやすいため、AWS Graviton のアーキテクチャと自然に適合します。im4gn.16xlarge は i3en.24xlarge と同等の毎秒 10〜12 GB のスループットを、オンデマンドの時間単価でおよそ半分のコストで実現します。次の表は比較のための Amazon EC2 インスタンスタイプの一例です。最新のインスタンスタイプとリージョン別料金については、Amazon EC2 インスタンスタイプのドキュメントをご参照ください。

インスタンス	アーキテクチャ	ネットワーク	ローカルNVMe	$/時間 **	用途
im4gn.16xlarge	ARM	100 Gbps	30 TB	$5.82	高スループット、GB/sあたりのコスト効率が最適
i8g.16xlarge	ARM	50 Gbps	15 TB	$5.49	最新世代NVMe、小規模ファイルのIOPSワークロード
i3en.24xlarge	x86	100 Gbps	60 TB	$10.85	大容量キャッシュ、KNFSDの主力インスタンス
i7ie.48xlarge	x86	100 Gbps	120 TB	$24.95	NVMeレイテンシが65%改善、レイテンシに敏感な読み取り処理

** 執筆時点の US-East-1 (バージニア北部) の料金

ファンアウトアーキテクチャ

多数のクライアントが同じ大規模データセットを読み取るワークロードに対して、KNFSD はオプションの 2 層ファンアウトデプロイをサポートしています。単一の高メモリプロキシ (Tier 1) がソースファイラーとの通信をすべて処理することで、各ファイルが広域ネットワーク (WAN) を通過するのを 1 回のみに抑え、高レイテンシー・低帯域幅の環境にも対応します。2 つ目の小規模プロキシクラスター (Tier 2) がファンアウトして数百のクライアントを提供します。これにより、キャッシュソリューションは実質的に 2 つの役割に分かれます。プライマリの Tier 1 KNFSD インスタンスによる初回の長距離転送と NFS 再エクスポート、そしてクライアントに直接 NFS を提供するセカンダリ Tier 2 KNFSD インスタンスの仕様と最適化です。この構成により、セカンダリ KNFSD インスタンスはクラウド側のキャッシュ充填を維持しながらスケールアップ・ダウンおよびスケールイン・アウトが可能となり、初回の長距離転送の繰り返しを防ぎ、インフラ変更後も迅速に再キャッシュできます。次の図は基本的なファンアウトアーキテクチャを示しています。

図 2: 2つのティアの例, KNFSD ファンアウトアーキテクチャ

この構成には以下の機能が含まれています。

ソースマウント – データのキャッシュ元となり、処理済みデータの書き戻し先となるソース NFS ファイルサーバーです。
長距離転送 – データはプライマリの Tier 1 KNFSD インスタンスにキャッシュされ、低帯域幅・高レイテンシー環境に対応します。
Tier 1 KNFSD インスタンス – このプライマリ層のインスタンスは、長距離トラフィックのキャッシュを一元的に担い、書き込みをソースファイラーに返します。
キャッシュ間転送 – KNFSD の Tier 1 と Tier 2 インスタンス間のデータ転送は、Amazon Virtual Private Cloud (Amazon VPC) 内で行われます。
Tier 2 KNFSD インスタンス – スループット要件に対応するためにファンアウト構成を取るインスタンスです。ワークロードの性能特性に合わせてインスタンスタイプを選択でき、ローカルの Amazon VPC を活用した高速転送が可能です。
コンピュート・キャッシュ間転送 – コンピュートインスタンスは、同じ低レイテンシー・高帯域幅のローカル Amazon VPC 接続を使用して Tier 2 KNFSD インスタンスにマウントします。
エラスティックコンピュート – Amazon EC2 インスタンスはワークロードの処理に合わせてスケールし、変更なしに Tier 2 KNFSD インスタンス上の依存ソースデータにアクセスします。必要に応じて結果を書き戻し、スループット要件を満たすために Tier 2 のスケールアップを促すシグナルも提供します。

オブザーバビリティとメトリクス

従来の NFS インフラはクローズドなシステムとして運用されることが多く、ストレージが遅いと感じていても、その原因を診断したり、キャパシティに関する適切な判断を下したりするための詳細情報が不足しがちです。KNFSD は、CloudWatch Agent と OpenTelemetry ベースの KNFSD メトリクスエージェントを使用して、70 以上のカスタムメトリクスを CloudWatch に公開します。これらのメトリクスはキャッシュインフラの各層を包括的に可視化し、インフラのパフォーマンスをデータに基づいて深く理解するための基盤を提供します。以下の図は、ダッシュボードに表示されるメトリクスの例を複数示しています。

図 3: KNFSDで利用可能な複数の指標ビュー

メトリクスのカテゴリ

公開されているメトリクスは、次の 5 つの主要領域をカバーしています。

NFS 接続数とクライアント数 – クラスターの使用率を追跡し、KNFSD インスタンスのスケールアウトが必要なタイミングを把握できます。
読み取り/書き込みスループットとレイテンシー (RTT および EXE) – クライアントがローカル速度に近いパフォーマンスを得られているかを確認し、劣化を早期に検出できます。
FS-Cache のヒット率/ミス率、LRU (least recently used) アクティビティ、ストレージ使用率 – ソースからデータを取得するのではなく、キャッシュがホットデータをどれだけ効果的に提供できているかを把握できます。
NFS スレッドおよびソケットのキュー深度 – プロキシのリクエスト処理パイプラインの飽和を、クライアントに影響が出る前に検出できます。
マウント別・エクスポート別の内訳 – 負荷の原因となっている特定のエクスポートやソースサーバーを特定し、ピンポイントでチューニングできます。

これらのメトリクスを組み合わせることで、プロキシの健全性、キャッシュの有効性、クライアント側の体感を総合的に把握でき、キャパシティ、パフォーマンスチューニング、コスト最適化に関する適切な判断が可能になります。

「AWS がメトリクスと直接連携し、実際の状況をリアルタイムで把握できるソリューションを提供してくれたことは、非常に大きな意味を持ちます。ダッシュボードは完成度が高く、ほとんどのチームがレンダーファームのデータについて持ち得ないレベルの可視性を提供してくれます。」

– Rob Dueckman、シニアソリューションアーキテクト、Integrated Media Technologies (IMT) Global

構築済み CloudWatch ダッシュボード

標準のインフラストラクチャーアズコードデプロイの一環として、構築済みの CloudWatch ダッシュボードがクラスターと同時にデプロイされます。手動でメトリクスを設定することなく、すぐに可視化を開始できます。ダッシュボードにはキャッシュヒット率、アクティブオブジェクト数、読み取り/書き込み帯域幅、IOPS、プロキシごとのトラフィック分散など、運用上重要なメトリクスが一目で確認できる形で表示されます。

Prometheus および Grafana へのエクスポート

メトリクスエージェントは OpenTelemetry ベースのため、必要に応じてテレメトリを Prometheus や Grafana にエクスポートすることも可能です。

インフラのサイジングとコスト管理

最も重要なメトリクスであるキャッシュヒット率は、プロキシがオリジンサーバーへの読み取り負荷をどれだけ効果的に吸収できているかを直接示します。LRU エビクション率やスレッド・ソケットのキュー深度と組み合わせることで、適切な対応策が明確になります。接続が飽和しているがヒット率が良好な場合はスケールアウト (KNFSD インスタンスの追加)、エビクションが増加してヒット率が低下している場合はキャッシュディスクのスケールアップが必要です。

これらのメトリクスはパフォーマンス問題が発生した際の推測作業も不要にします。ネットワークの制約、キャッシュディスクの飽和、プロキシの過負荷を素早く切り分け、やみくもにキャパシティを追加するのではなく、適切な対処を取ることができます。

開発者体験とデプロイ

このプロジェクトは、リポジトリのクローンから稼働クラスターまでの手順を最小限の手間で完了できるよう設計されています。リポジトリには Visual Studio Code Dev Container が同梱されており、Terraform、Packer、Go、Python、AWS Command Line Interface (AWS CLI)、各種リンティング・テストツールを含む開発環境がすぐに使える状態で提供されます。ローカルへのインストールは不要で、リポジトリを開いてコンテナを起動すれば、すぐに AMI のビルドやクラスターのデプロイを開始できます。

デプロイは単一の Terraform モジュールで完結し、Amazon VPC サブネット、AMI ビルド、ソース NFS エクスポートを指定するだけで開始できます。KNFSD インフラ (Amazon EC2 Auto Scaling グループ、セキュリティグループ、ヘルスチェック、DNS レコード、オプションのロードバランサー、FSID データベースなど) は宣言的に作成・管理されます。リリースタグでバージョンを固定し、標準の Terraform ワークフローで任意のタイミングでアップデートできます。

同じ Dev Container 環境が開発ライフサイクル全体をサポートします。Packer による AMI ビルド、パフォーマンスの実行とプロファイリング、テストクラスターのデプロイ、Terratest 統合によるスモークテストの実行まで対応しています。コントリビューター環境とデプロイ環境に差異はなく、両者は同一の環境です。

オートスケーリング

NFS キャッシュのオートスケーリングは、標準的なメトリクスではうまく機能しません。CPU 使用率はプロキシの負荷を適切に反映しないため、NFS 接続が飽和していても CPU 使用率が 40% にとどまるケースがあります。KNFSD では代わりに、インスタンスごとのアクティブ NFS 接続数というカスタム CloudWatch メトリクスを基にスケーリングします。接続数が設定したしきい値を超えると、クラスターは自動的にキャパシティを追加します。スケーリングポリシーはスケールアップのみに設定されています。スケールダウンすると、構築に時間を要したウォームキャッシュデータが失われるだけでなく、より重大な問題として、アクティブな NFS マウントが切断され、クライアントで I/O ストールが発生するためです。ワークロードが落ち着いた後のスケールダウンは、任意のタイミングで手動で行います。

はじめに

KNFSD は Apache 2.0 ライセンスのオープンソースプロジェクトとして、GitHub で公開されています。

リポジトリには以下が含まれています。

開始するための詳細な前提条件
ソース NFS サーバー、KNFSD プロキシ、NFS クライアントのエンドツーエンドのデプロイ手順を解説したステップバイステップのチュートリアル
すべての機能、設定変数、運用上の考慮事項を網羅した包括的なドキュメント
Amazon FSx for NetApp ONTAP、Amazon FSx for OpenZFS、サードパーティの NFS ゲートウェイデバイス向けのすぐに使えるサンプル

質問、機能リクエスト、フィードバックは以下からお寄せください。

まとめ

NFS インフラはデータセンターの壁で止まるように設計されたものではありません。KNFSD を使えば、その必要もなくなります。

数千コアにわたる計算負荷の高いタスクを実行する場合でも、パイプラインを再設計せずにハイブリッドワークフローを AWS に拡張する場合でも、KNFSD はコンピュートがすでに AWS で享受しているのと同じ弾力性を、透過的かつ高性能に、ストレージのロックインなしでデータにもたらします。

今すぐ KNFSD File Cache から始めましょう。

参考資料

AWS HPC コミュニティによる NFS 再エクスポートの詳細: Accelerating file reads with a storage caching server (AWS HPC Blog)
Avatar 2: Way of Water で Wētā FX が NFS 再エクスポートを使用して AWS 上でスケールした方法: How Wētā FX scaled NFS for Avatar: The Way of Water (DigiPro 2023)

参考リンク
AWS Media Services
AWS Media & Entertainment Blog (日本語)
AWS Media & Entertainment Blog (英語)
AWS のメディアチームの問い合わせ先: awsmedia@amazon.co.jp

※ 毎月のメルマガをはじめました。最新のニュースやイベント情報を発信していきます。購読希望は上記宛先にご連絡ください。

翻訳は Visual Compute SSA 森が担当しました。原文はこちらをご覧ください。

Amazon Web Services ブログ