Filestore

解決する課題

• 複数の VM・コンテナで同じファイルを共有したい（Web コンテンツ・アップロード・HPC の中間データ等）
• NFS サーバーを自前で構築・運用したくない（OS パッチ・冗長化・バックアップを任せたい）
• GKE の Pod から ReadWriteMany な永続ボリュームを使いたい
• レンダリング・ゲノム解析・EDA などで高スループット・低レイテンシな共有領域が欲しい

主要概念と用語

• インスタンス: Filestore の単位。1 つの NFS エンドポイント（IP アドレス）を持つ
• サービスティア: 主力は ZONAL と REGIONAL。GKE の複数共有には ENTERPRISE、互換用途には従来の BASIC_HDD / BASIC_SSD
• ファイル共有（share）: インスタンス上のエクスポート単位。クライアントは IP:/<share名> でマウントする
• 容量とカスタム性能: 容量は明示指定する。Zonal / Regional は範囲内で拡大・縮小でき、IOPS を容量と独立して設定可能。Basic は拡張のみ
• 接続方式: Direct Peering、Private Services Access、Private Service Connect のいずれかで VPC から内部到達する
• スナップショット / バックアップ: 特定時点のコピー。バックアップは別リージョンへの復元にも使える

仕様・制限・クォータ

• NFSv3 は全ティア、NFSv4.1 は Zonal / Regional / Enterprise で利用可能。NFSv4.1 は Kerberos による認証・完全性・転送時暗号化とファイル ACL に対応
• 作成時に容量を指定。ティアごとに最小・最大容量と増減の刻みが決まっている
  • BASIC（HDD/SSD）: 1 TiB 〜 数十 TiB 規模
  • ZONAL: 〜100 TiB 規模、ENTERPRISE: 〜10 TiB 規模（要件に応じた高容量・高スループット。最小・最大の最新値は公式参照）
• 可用性の範囲はティア依存：BASIC / ZONAL は単一ゾーン、REGIONAL / ENTERPRISE はリージョン内の複数ゾーンへ冗長化
• Zonal / Regional のカスタム性能は、固定 IOPS または TiB あたり IOPS を容量と独立して購入できる。従来 Basic の性能特性とは分けて考える
• インスタンスは VPC 内の内部 IP で公開され、インターネットから直接はマウントできない
• プロジェクト/リージョンごとに容量・インスタンス数のクォータがあり、引き上げ申請が可能

内部の仕組み

Filestore は Google が運用するマネージドな NFS サービスで、インスタンスの内部エンドポイントを VM や GKE ノードからマウントします。同じ共有を複数クライアントが同時に読み書きできるため、アプリケーション側ではファイルロック、UID/GID、同時更新の扱いまで設計します。

• 接続は Direct Peering、Private Services Access、Private Service Connect から選び、同じ VPC または接続可能なネットワークから内部到達する
• REGIONAL / ENTERPRISE ティアは、リージョン内の複数ゾーンにデータを冗長化し、ゾーン障害に耐える
• ENTERPRISE は GKE 向けに複数共有（マルチシェア）を 1 インスタンスに同居させ、多数の小さな PV を効率的に割り当てられる

横にスクロール

設計パターン / ベストプラクティス

• GKE の共有ボリューム: CSI ドライバ経由で ReadWriteMany の PersistentVolume として利用。多数 Pod が必要なら ENTERPRISE のマルチシェアで PV を効率配分
• HPC / レンダリング: 高スループットが要るなら ZONAL。必要容量と IOPS を別々に見積もり、複数クライアントで性能試験する
• 可用性要件で選ぶ: ゾーン障害に耐える必要があれば REGIONAL / ENTERPRISE、コスト最優先で単発用途なら BASIC_HDD
• 同一ゾーン配置: レイテンシ最小化のため、マウントするクライアントと Filestore を同じゾーン（BASIC/ZONAL）に置く
• バックアップの自動化: スナップショット/バックアップをスケジュール化し、誤削除・障害に備える

運用・監視

• Cloud Monitoring でメトリクスを監視。file.googleapis.com/nfs/server/used_bytes_percent（使用率）、read_ops_count・write_ops_count、read_bytes_count・write_bytes_count などで容量と I/O を把握
• 使用率と購入 IOPS の消費を別々に監視し、容量変更またはカスタム性能変更を計画する
• マウントできないときは、ファイアウォールルール、接続方式、割り当て IP、クライアントの NFS パッケージ、NFSv4.1 の認証設定を確認
• スナップショット/バックアップの取得状況とリストア手順を定期的に検証

コスト

課金は主にプロビジョニング済み容量（GiB）× ティア単価 × 時間で決まります。EFS の「使った分だけ」とは異なり、確保した容量に対して課金される点が重要です。

セキュリティ

• 接続は VPC 内の内部 IP に限定され、インターネットへは公開されない
• 保存時の暗号化は既定で有効。CMEK（顧客管理鍵） で Cloud KMS の自前鍵も利用可能
• ファイアウォールルールで NFS（2049 等）の到達元を必要なサブネット/タグに絞る
• IAM で Filestore インスタンスの作成・削除・スケール等の管理操作権限を制御する
• NFS のファイルアクセス権は UID/GID（POSIX） ベース。クライアント側の uid/gid 設計を揃える

関連サービス・比較（AWS との対応）

ハンズオン / CLI例

# Filestore インスタンスを作成（BASIC_SSD・1TiB・共有名 vol1）
gcloud filestore instances create demo-fs \
  --zone=asia-northeast1-a \
  --tier=BASIC_SSD \
  --file-share=name=vol1,capacity=1TiB \
  --network=name=default

# 割り当てられた内部 IP（NFS エンドポイント）を確認
gcloud filestore instances describe demo-fs \
  --zone=asia-northeast1-a \
  --format="value(networks.ipAddresses[0])"

# VM 側でマウント（nfs-common 導入済みとする）
# 例: IP が 10.0.0.2 の場合
sudo mkdir -p /mnt/filestore
sudo mount 10.0.0.2:/vol1 /mnt/filestore

# 容量をスケールアップ（例: 2TiB へ。縮小は不可）
gcloud filestore instances update demo-fs \
  --zone=asia-northeast1-a \
  --file-share=name=vol1,capacity=2TiB