Filestore

解決する課題

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

主要概念と用語

• インスタンス: Filestore の単位。1 つの NFS エンドポイント（IP アドレス）を持つ
• サービスティア: 性能・容量・可用性の区分。BASIC_HDD / BASIC_SSD（旧 Standard/Premium）、ZONAL、REGIONAL、ENTERPRISE
• ファイル共有（share）: インスタンス上のエクスポート単位。クライアントは IP:/<share名> でマウントする
• 容量（capacity）: 作成時に GiB 単位で指定。自動伸縮はなく、後から手動でスケールアップ（縮小は不可）
• VPC ピアリング / Private Services Access: Filestore は割り当て済み IP 範囲を使い、VPC とピアリングして内部 IP で接続する
• スナップショット / バックアップ: 特定時点のコピー。バックアップは別リージョンへの復元にも使える

仕様・制限・クォータ

• プロトコルは NFSv3（EFS の NFSv4.1 とは異なる点に注意）
• 作成時に容量を指定。ティアごとに最小・最大容量と増減の刻みが決まっている
  • BASIC（HDD/SSD）: 1 TiB 〜 数十 TiB 規模
  • ZONAL / ENTERPRISE: 1 TiB〜100 TiB（要件に応じた高容量・高スループット）
• 可用性の範囲はティア依存：BASIC / ZONAL は単一ゾーン、REGIONAL / ENTERPRISE はリージョン内の複数ゾーンへ冗長化
• スループットは容量にほぼ比例（BASIC/ZONAL）。容量を増やすほど性能も上がる
• インスタンスは VPC 内の内部 IP で公開され、インターネットから直接はマウントできない
• プロジェクト/リージョンごとに容量・インスタンス数のクォータがあり、引き上げ申請が可能

内部の仕組み

Filestore は Google が運用するマネージドな NFS サーバー群で、各インスタンスに専用の内部 IP が割り当てられます。クライアント（VM / GKE ノード）はその IP に対して標準の NFSv3 でマウントし、同一ファイルシステムを多数から同時に読み書きできます。

• 接続は Private Services Access（VPC ピアリング）経由。Filestore 用に確保した IP レンジが VPC とピアリングされ、内部経路で到達する
• REGIONAL / ENTERPRISE ティアは、リージョン内の複数ゾーンにデータを冗長化し、ゾーン障害に耐える
• ENTERPRISE は GKE 向けに**複数共有（マルチシェア）**を 1 インスタンスに同居させ、多数の小さな PV を効率的に割り当てられる

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

• GKE の共有ボリューム: CSI ドライバ経由で ReadWriteMany の PersistentVolume として利用。多数 Pod が必要なら ENTERPRISE のマルチシェアで PV を効率配分
• HPC / レンダリング: 高スループットが要るなら ZONAL / ENTERPRISE。容量＝性能なので、必要スループットから逆算して容量を決める
• 可用性要件で選ぶ: ゾーン障害に耐える必要があれば 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 を把握
• 使用率が逼迫する前にスケールアップ（容量追加）を計画。縮小不可なので余裕を持たせる
• マウントできないときは、ファイアウォールルール（NFS のポート 2049 等）、VPC ピアリング/Private Services Access の設定、クライアントの nfs-common 導入を確認
• スナップショット/バックアップの取得状況とリストア手順を定期的に検証

コスト

課金は主にプロビジョニング済み容量（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