Parallelstore

解決する課題

• GPU/TPU を使う学習で、ストレージ I/O がボトルネックになり高価なアクセラレータが遊ぶのを避けたい
• 数百〜数千ノードから同じデータセットへ同時に高スループットでアクセスしたい（分散学習・HPC）
• 大量の小さなファイル（チェックポイント・特徴量・中間ファイル）を低レイテンシで扱いたい
• Lustre のような並列ファイルシステムを自前で構築・運用したくない（ノード冗長化・障害対応を任せたい）
• 永続データは Cloud Storage に置きつつ、計算時だけ高速なスクラッチ領域を一時的に欲しい

主要概念と用語

• インスタンス: Parallelstore の単位。指定した容量でプロビジョニングされ、VPC 内の内部エンドポイントを持つ
• 並列ファイルシステム: データとメタデータを多数のサーバーに分散し、多クライアントから並列に読み書きできる構成。POSIX 互換のファイルアクセスを提供する
• 容量とプロビジョニング: 容量を明示指定して作成する。容量に応じて集約スループットや IOPS の上限が決まる
• データのインポート/エクスポート: Cloud Storage バケットからインスタンスへデータを取り込み（インポート）、計算結果をバケットへ書き戻す（エクスポート）。永続化は Cloud Storage 側で担う
• スクラッチ層: 永続ストレージではなく、ジョブ実行中の高速作業領域として使う位置づけ
• 接続方式: Private Service Access などで VPC から内部到達する。クライアント（VM・GKE ノード）からマウントして使う
• GKE 連携: CSI ドライバ経由で Kubernetes の永続ボリュームとして利用できる

仕様・制限・クォータ

• POSIX 互換のファイルアクセスを提供し、既存のファイル I/O を使うアプリをほぼそのまま動かせる
• 作成時に容量を指定する。容量はサービスが定める範囲・刻みでプロビジョニングし、容量が大きいほど集約スループットの上限も上がる
• 集約スループットは多クライアント並列で発揮される。単一クライアントの逐次 I/O ではなく、多数ノード・多数スレッドで同時アクセスして初めて高い帯域に届く
• インスタンスは VPC 内の内部 IP で公開され、インターネットから直接はマウントできない
• データの永続的な真実の置き場は Cloud Storage とし、Parallelstore はジョブ単位の高速作業領域として扱うのが基本設計
• 提供リージョン/ゾーンは限定される場合があり、クライアントと同一ゾーンに配置するのが前提
• プロジェクト/リージョンごとに容量やインスタンス数のクォータがあり、引き上げ申請が可能
• 容量・性能の最小/最大や刻み、対応リージョンといった変動しやすい数値は公式ドキュメントを参照する

内部の仕組み

Parallelstore は Google がマネージドで運用する並列ファイルシステムです。データとメタデータを多数のストレージサーバーへ分散して配置し、クライアントは並列にアクセスすることで単一サーバー型の NFS では届かない集約スループットと低レイテンシを得ます。アクセラレータ（GPU/TPU）が求めるデータ供給速度に追従させ、計算リソースを遊ばせないことが狙いです。

• クライアント（Compute Engine・GKE ノード）は VPC 内の内部経路を通ってインスタンスをマウントし、多数のクライアントから同時並列で読み書きする
• 永続データは Cloud Storage に置き、ジョブ開始時にインポート、終了時にエクスポートする運用で、高速層と永続層の役割を分離する
• メタデータとデータを分散させることで、大量の小さなファイル（チェックポイントや特徴量）でもスループットを維持しやすい

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

• インポート/計算/エクスポート: 学習・解析の前に Cloud Storage からデータをインポートし、計算後に結果をエクスポートする三段構成にする
• 多並列でアクセス: 集約スループットは多クライアント・多スレッドで引き出す。単一ノードの逐次 I/O を前提にしない
• 同一ゾーン配置: レイテンシ最小化のため、アクセラレータ VM やノードプールと同じゾーンにインスタンスを置く
• GKE 連携: CSI ドライバで永続ボリュームとして接続し、学習 Pod から高速領域を共有する
• チェックポイント高速化: 大規模学習のチェックポイント保存・復元先に使い、書き込み待ちで GPU を止めない
• 容量で性能を見積もる: 必要スループットから逆算して容量を決める。容量不足は性能不足に直結する

運用・監視

• Cloud Monitoring でスループット・IOPS・容量使用率などを監視し、アクセラレータの待ち時間と突き合わせて I/O 律速かを判断する
• インポート/エクスポートのジョブ状態と所要時間を監視し、ジョブ全体のスケジュールに織り込む
• マウントできないときは、ファイアウォールルール、接続方式（Private Service Access 等）、割り当て IP、クライアントのドライバ/パッケージを確認する
• スクラッチ層という前提に立ち、エクスポート漏れによるデータ損失が起きないよう運用手順で担保する
• クライアント側の並列度・スレッド数を調整し、集約スループットを引き出せているか実測で確認する

コスト

課金は主にプロビジョニング済みのインスタンス容量 × 時間で決まります。使った分だけではなく確保した容量に対して課金されるため、ジョブのライフサイクルに合わせて作成・削除し、不要な間は確保し続けないことがコスト最適化の要点です。

セキュリティ

• 接続は VPC 内の内部 IP に限定され、インターネットへは公開されない
• 保存時の暗号化は既定で有効。鍵管理の要件は公式の対応状況を確認する
• ファイアウォールルールでマウントの到達元を必要なサブネット/タグに絞る
• IAM でインスタンスの作成・削除・インポート/エクスポート等の管理操作権限を制御する
• ファイルアクセス権は POSIX（UID/GID） ベース。クライアント側の uid/gid 設計を揃える

関連サービス・比較

ハンズオン / CLI例

# Parallelstore インスタンスを作成（容量・ロケーション・ネットワークを指定）
gcloud parallelstore instances create demo-ps \
  --location=asia-northeast1-a \
  --capacity-gib=12000 \
  --network=default

# インスタンスの内部エンドポイント（アクセスポイント）を確認
gcloud parallelstore instances describe demo-ps \
  --location=asia-northeast1-a \
  --format="value(accessPoints)"

# Cloud Storage バケットからデータをインポート（計算前の取り込み）
gcloud parallelstore instances import-data demo-ps \
  --location=asia-northeast1-a \
  --source-gcs-bucket-uri=gs://my-dataset-bucket/train \
  --destination-parallelstore-path=/train

# 計算結果を Cloud Storage へエクスポート（永続化）
gcloud parallelstore instances export-data demo-ps \
  --location=asia-northeast1-a \
  --source-parallelstore-path=/output \
  --destination-gcs-bucket-uri=gs://my-result-bucket/output

# 使い終わったらインスタンスを削除（スクラッチ層のコストを抑える）
gcloud parallelstore instances delete demo-ps \
  --location=asia-northeast1-a