詳説：NFS（Network File System） — 仕組み、進化、運用の実践ガイド
エバープレイ編集部はじめに
NFS（Network File System）は、ネットワーク上でファイル共有を実現するためのプロトコルで、UNIX系OSを中心に長年使われてきました。この記事ではNFSの歴史、アーキテクチャ、主要バージョン（v3／v4／v4.1とpNFS）、セキュリティ、性能最適化、運用上の注意点、トラブルシューティング、導入事例までを技術的に深掘りします。開発者、運用エンジニア、アーキテクト向けに、実運用で役立つ具体的な設定や設計のヒントも織り込みます。
NFSの歴史と位置付け
NFSは1980年代初頭にSun Microsystemsが提案したプロトコルで、ネットワーク上のリモートファイルをローカルにマウントして扱える点が特徴です。初期はステートレスな設計を採用し、その後のバージョンで状態管理やロック、セキュリティ機構が追加されました。NFSはNAS（Network Attached Storage）や高可用環境、クラスタリング、コンテナ環境の共有ストレージなど幅広く用いられています。
プロトコルの基本設計（RPCとファイル操作）
NFSは基本的にRPC（Remote Procedure Call）をベースに動作します。クライアントはRPCを通じてサーバにファイル操作を要求し、サーバは応答を返します。主要な操作はREAD、WRITE、OPEN、CLOSE、LOOKUP、CREATE、REMOVE、RENAMEなどで、ファイルシステムのメタデータ（属性）取得やディレクトリ操作もRPCで行われます。
ステートレスとステートフルの違い
初期のNFS（v2／v3）はステートレスな設計が基盤で、サーバ側はクライアントの状態を保持しませんでした。これによりサーバのクラッシュ復旧が容易になる利点がありました。一方、NFSv4以降はステートフルに近い機能（ロック、delegation、open stateの管理）を持つようになり、性能向上やキャッシュの整合性維持に寄与していますが、サーバ障害時の回復処理はより複雑になります。
主要バージョンの比較
- NFSv2：1989年頃の初期版。32ビットオフセット制限などの制約があり、今日ではほとんど使われていません。
- NFSv3：RFC 1813で標準化。非同期WRITEや大きなファイルオフセット（64ビット）をサポートし、広く普及しています。ステートレス設計。
- NFSv4：NFSv3の課題を解決するために設計され、ファイアウォール越え（単一ポート使用）、状態管理、ロックやレイアウトの統合、ACLや統合認証サポートを強化しました。複数のマイナーバージョンが存在します。
- NFSv4.1 / pNFS：並列I/O（pNFS）を含み、スケールアウト型の高性能なデータアクセスをサポートします。クライアントがデータノードに直接アクセスすることで従来のシングルサーバーボトルネックを緩和します。
セキュリティ機構
NFSの認証方式には複数があり、歴史的にはAUTH_SYS（UID/GIDベース）が一般的でしたが、これはなりすましが可能で安全とは言えません。より安全な方式としてRPCSEC_GSSが使われ、Kerberosベースの認証（krb5）や暗号化（krb5i、krb5p）を提供します。NFSv4ではACL（POSIX ACLやNFSv4 ACL）をサポートし、細かなアクセス制御が可能です。
キャッシュと一貫性
NFSクライアントは性能向上のために属性キャッシュやデータキャッシュを行います。v3ではキャッシュの整合性は基本的にタイムスタンプ（attribute cache timeout）で管理され、短く設定すると整合性は上がるが性能低下するというトレードオフがあります。NFSv4はstatefulなopen/close情報やdelegation（クライアントが一時的にファイルの排他的キャッシュを許される）を使ってキャッシュ有効性を高められるため、高効率かつ整合性を保ちやすくなっています。
パフォーマンス最適化の実践ポイント
- マウントオプション：rsize/wsize（読み書きブロックサイズ）、noatime（アクセス時間更新の無効化）、async/syncの選択、actimeoやacregmin/maxなどキャッシュ時間の調整。
- ネットワーク：MTU、スイッチのレイテンシ、Jumboフレーム（対応環境のみ）やRDMA経由のNFS（NFS over RDMA）でレイテンシ削減。
- サーバ側チューニング：I/Oスケジューラ、RAID設定、十分なメモリ確保、並列処理の最適化。
- pNFSの採用：大規模並列アクセスがある場合、pNFSでデータノードに直接I/Oを分散させる。
- キャッシュ戦略：v4のdelegationを活用し、クライアント側キャッシュを活用できる設計にする。
運用上の考慮点とベストプラクティス
- バックアップとスナップショット：NFSはファイルシステムを透過的に共有するため、サーバ上でのポイントインタイムスナップショット（LVM/ZFSなど）を使うのが有効。
- 権限管理：AUTH_SYSだけに頼らず、可能ならKerberos認証を導入。root_squash/no_root_squashの設定に注意。
- 高可用性：冗長化（DRBD、GlusterFS、Cephなどの分散FSやクラスタ構成）とフェイルオーバー設計を取り入れる。
- 監視とログ：遅延やタイムアウト、ステール（STALE）エラーを監視。iostat、nfsstat、netstat、dmesgなどでボトルネックを把握する。
主な運用トラブルと対処法
- stale file handle：サーバ側でエクスポートされるファイルシステムのinode番号やFSIDが変わった場合に発生。再マウントやサーバ側のエクスポート設定確認、UUID管理が解決策。
- permission denied：認証方式、UID/GIDの不整合、export設定（/etc/exports）のエントリ、root_squashなどをチェック。
- 性能低下：ネットワーク飽和、同期I/O（syncマウント）、小さなrsize/wsize、ロック競合が原因となる。プロファイリングと段階的なチューニングが必要。
- ロック待ち・deadlock：NFSのファイルロック（lockdやNLM）に関連する問題。アプリのロック設計やNFSv4の統合ロック管理の利用を検討。
クラウド・コンテナ環境での利用
クラウドやKubernetes環境では、NFSはPersistentVolumeのバックエンドとして広く使われます。メリットはシンプルさと互換性の高さですが、スケーラビリティや性能の点で限界があるため、高負荷環境ではブロックストレージや分散ファイルシステム（CephFS、GlusterFS、Amazon EFSなど）を検討します。K8sではReadWriteManyが必要なケースでNFSが便利です。
互換性と移行の実際
古いNFSサーバから新しいサーバへの移行では、UID/GIDの整合性、エクスポートパス、シンボリックリンクやセッティング（ACL）を保つことが重要です。rsyncやtarでのコピーは一般的ですが、ACLや特殊属性（xattr）を維持するオプションを忘れないでください。クロスプラットフォーム間ではファイル名のエンコーディング（UTF-8）にも注意が必要です。
将来動向と代替技術
NFSは堅牢で互換性の高いプロトコルですが、分散ストレージやオブジェクトストレージの台頭により用途が分散しています。高性能分散アクセスが必要な場合はpNFSや分散ファイルシステム、クラウドネイティブなストレージ（S3互換オブジェクトストレージ）を検討する場面が増えています。一方で組織内共有やレガシー環境では依然として有用です。
まとめ：いつNFSを選ぶか
NFSはセットアップの簡便さ、OS間での互換性、既存エコシステムとの親和性が強みです。小〜中規模のファイル共有、コンテナのReadWriteManyストレージ、迅速なNAS構築には最適です。一方で大規模並列性能や高スケールを求める用途ではpNFSや別の分散ファイルシステムを検討すべきです。運用ではセキュリティ（Kerberos）、監視、バックアップ、キャッシュ設定に注意し、実負荷でのプロファイリングを行うことが成功の鍵です。
参考文献
- RFC 1813 — NFS Version 3 Specification
- RFC 7530 — Network File System (NFS) Version 4 Protocol
- RFC 5661 — NFS Version 4.1 Protocol
- Linux Kernel Documentation — NFS
- Wikipedia — Network File System
投稿者プロフィール
