OCI Storage Gateway

解決する課題

Storage Gateway が提供していたのは、既存のオンプレミス資産を改修せずに、ファイル単位でクラウドのオブジェクトストレージを利用する経路です。現在は既存構成の棚卸しと移行が課題になります。

• オンプレのアプリやスクリプトは NFS マウント前提で動いており、HTTP/REST の Object Storage API を直接呼ぶように書き換えたくない
• バックアップやアーカイブの保管先を、容量に上限のあるオンプレ NAS から実質無制限の Object Storage に移したい
• 大量の非構造データ（ログ、メディア、ゲノム、CAD など）をクラウドへ段階的に移行しつつ、オンプレからもファイルとして読み書きしたい
• クラウド側で蓄積したオブジェクトを、オンプレや別システムから標準ファイルプロトコルで参照したい

主要概念と用語

• Storage Gateway インスタンス: オンプレ（または OCI Compute）上で動かすゲートウェイのソフトウェア本体。Linux 上のコンテナ/仮想アプライアンスとして配置し、NFS サービスを提供する
• ファイルシステム（File System / Gateway 上の共有）: ゲートウェイが NFS で公開する論理共有。1 つの共有が 1 つの Object Storage バケットに対応づく
• マッピング（バケットとの紐付け）: 各ファイルシステムを特定のリージョン・コンパートメント・バケットへ関連付ける設定。書き込んだファイルが対象バケットのオブジェクトになる
• キャッシュ（ローカルキャッシュ）: ゲートウェイのローカルディスク領域。直近アクセスしたデータやアップロード待ちのデータを保持し、読み書きのレイテンシを下げる
• クラウド同期（アップロード/リフレッシュ）: ローカルへの書き込みをバックグラウンドで Object Storage に送る処理と、バケット側の変更をゲートウェイに反映する処理
• メタデータ保持: ファイル名・ディレクトリ構造・タイムスタンプなどをオブジェクト側に保ったまま相互変換する仕組み

仕様・制限・クォータ

• 提供終了: 2024年2月28日以降は新規ダウンロード不可。既存環境にも更新がないため、継続利用ではなく移行期限と撤去条件を決める
• クライアントとの接続は NFS（ファイルプロトコル） で行い、背後は OCI Object Storage。アプリから見ると普通のファイル共有として振る舞う
• 1 つのファイルシステムは 1 つの Object Storage バケットに対応づく。複数バケットを 1 共有に混在はしない
• 書き込みはまずローカルキャッシュに着地し、非同期で Object Storage にアップロードされる。したがって書き込み直後に必ずクラウド側へ反映済みとは限らない（結果整合的に同期）
• キャッシュ容量はゲートウェイのローカルディスクに依存する。ワーキングセット（よく使うデータ）がキャッシュに収まる設計が望ましい
• 性能はゲートウェイホストの CPU・メモリ・ディスク・ネットワーク帯域に律速される。低帯域回線では大容量アップロードがボトルネックになりやすい
• ファイルロックや高頻度ランダム更新を多用するプライマリの業務 NAS 用途には不向き。バックアップ・アーカイブ・参照・移行といった用途が適する
• 具体的な対応 OS バージョン・最大ファイルサイズ・推奨スペックなどは変動するため、公式ドキュメントの値を確認する

内部の仕組み

旧 Storage Gateway は、オンプレ側に置くソフトウェアアプライアンスとして動作し、フロント側は NFS、バック側は Object Storage の REST API という二面を持っていました。クライアントがファイルを書くと、ゲートウェイはそれをローカルキャッシュに保存し、バックグラウンドで Object Storage へオブジェクトとしてアップロードします。読み取り時はキャッシュにあればそこから即返し、なければ Object Storage から取得してキャッシュに載せます。

• 書き込みパス: NFS 書き込み → ローカルキャッシュ → 非同期アップロードキュー → Object Storage バケット
• 読み取りパス: NFS 読み取り → キャッシュヒットなら即応答 / ミスならクラウドから取得してキャッシュに格納
• メタデータ変換: ファイルのパスや属性をオブジェクトのキー・メタデータへ写像し、双方向に整合させる
• ゲートウェイ自体はステートを持つため、キャッシュ用ディスクの信頼性と容量が安定運用の鍵になる

横にスクロール

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

• 移行前に書き込みを確定: 新規書き込みを止め、アップロード未完了量がゼロであることを確認してからファイル数・容量・チェックサムを採取する
• アクセス方式から移行先を選定: バッチ同期、読み取り中心のマウント、従来型の共有など、必要な意味論ごとに OCI CLI sync・rclone・OCIFs・Virtual ZFS を比較する
• 並行検証後に撤去: 読み書き、属性、再試行、障害復旧を移行先で試し、ロールバック期間を経て旧ゲートウェイとキャッシュを撤去する
• バックアップ/アーカイブのクラウド退避: オンプレのバックアップ製品の保管先を Storage Gateway の NFS 共有に向け、実体を Object Storage（必要に応じて低頻度/アーカイブ階層）に蓄積する
• 段階的なクラウド移行（リフト前の橋渡し）: アプリ改修前にまずファイル層だけクラウドへ寄せ、後段で Object Storage API ネイティブへ移行する踏み台にする
• オンプレ↔クラウドのデータ受け渡し: クラウド側のジョブが生成したオブジェクトをオンプレからファイルとして参照、またはその逆を実現する
• キャッシュ設計: よくアクセスするワーキングセットがローカルキャッシュに収まるようディスクを見積もる。キャッシュ不足はクラウド往復が増えレイテンシ悪化につながる
• 帯域の確保: 大量アップロードが想定される場合は回線帯域を確保し、必要なら FastConnect 等の専用接続でクラウドへの経路を安定させる
• ゲートウェイの冗長/監視: ゲートウェイは単一障害点になり得るため、ホストの可用性・キャッシュディスクの健全性・同期遅延を監視する

運用・監視

• EOLリスクと移行期限を運用課題として登録し、更新がない状態で長期継続しない
• 同期の遅延（アップロード未完了量）を最重要指標として監視する。回線断やゲートウェイ停止時に未アップロードデータが滞留していないかを確認する
• キャッシュ使用率を監視し、逼迫したら退避ポリシーやディスク増設を検討する
• ゲートウェイホストの CPU・メモリ・ディスク I/O・ネットワーク帯域をシステム指標として取得する
• 障害切り分けの基本は、(1) クライアント〜ゲートウェイ間の NFS 到達性、(2) ゲートウェイ〜Object Storage 間の到達性と認証情報、(3) キャッシュディスクの空き、の順で確認する
• Object Storage 側のオブジェクト数・容量増加は OCI Monitoring / 使用状況レポートで傾向を把握する

コスト

旧 Storage Gateway の継続費用には、背後の Object Storage とゲートウェイを動かすインフラに加え、更新されないソフトウェアを維持するセキュリティ・移行リスクも含めます。

セキュリティ

• 保存時暗号化: 実体が置かれる Object Storage はデフォルトで暗号化され、Vault（KMS）の顧客管理キーも利用できる
• 転送時暗号化: ゲートウェイ〜Object Storage 間は HTTPS で保護される。クライアント〜ゲートウェイ間の NFS は内部ネットワークに閉じ、必要に応じて経路を暗号化・分離する
• 認証情報の管理: ゲートウェイが Object Storage へアクセスするための API キー/資格情報を安全に保管し、権限は対象バケットへの最小限に絞る（IAM ポリシー）
• ネットワーク分離: NFS は認証が弱いため、ゲートウェイへの到達元を信頼できるネットワーク・送信元に限定する

Well-Architected の観点

• 信頼性（Reliability）: オンプレ容量の制約から解放され、実質無制限・高耐久の Object Storage を保管先にできる。一方でゲートウェイ自身は単一障害点になり得るため、ホスト冗長・キャッシュ健全性・同期遅延の監視で信頼性を担保する
• コスト（Cost）: 高価なオンプレ NAS の増設を避け、使った分だけ課金される Object Storage へ寄せられる。アクセス頻度に応じた階層選択でさらに最適化できる
• 性能はキャッシュとネットワークに律速されるため、低レイテンシが厳密に要るプライマリ用途では適性を見極める

試験で問われるポイント

関連サービス・比較

Storage Gateway は AWS の Storage Gateway（特に File Gateway） に近い役割を持っていましたが、OCI版はEOLです。旧構成のデータ経路を理解したうえで、現在利用できる手段へ移行します。

移行例 / CLI

新しいゲートウェイを構築するのではなく、旧環境の未転送データを確定した後、OCI CLI で検証用ディレクトリを Object Storage へ同期する例です。上書き・削除の扱いを確認し、まず小さな検証範囲で実行してください。

# 1) 移行先となる Object Storage バケットを作成
#    Namespace は事前に取得しておく
NAMESPACE=$(oci os ns get --query "data" --raw-output)

oci os bucket create \
  --compartment-id "$COMPARTMENT_OCID" \
  --namespace "$NAMESPACE" \
  --name "gateway-archive" \
  --storage-tier "Standard"

# 2) バケットが作成できたか確認
oci os bucket get \
  --namespace "$NAMESPACE" \
  --bucket-name "gateway-archive"

# 3) 旧共有から退避・検証したディレクトリをバケットへ同期
oci os object sync \
  --namespace "$NAMESPACE" \
  --bucket-name "gateway-archive" \
  --src-dir "/data/gateway-export"

# 4) 同期後にオブジェクト数・容量・チェックサムと読取試験を照合する