OCI 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 に送る処理と、バケット側の変更をゲートウェイに反映する処理
• メタデータ保持: ファイル名・ディレクトリ構造・タイムスタンプなどをオブジェクト側に保ったまま相互変換する仕組み

仕様・制限・クォータ

• クライアントとの接続は 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 読み取り → キャッシュヒットなら即応答 / ミスならクラウドから取得してキャッシュに格納
• メタデータ変換: ファイルのパスや属性をオブジェクトのキー・メタデータへ写像し、双方向に整合させる
• ゲートウェイ自体はステートを持つため、キャッシュ用ディスクの信頼性と容量が安定運用の鍵になる

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

• バックアップ/アーカイブのクラウド退避: オンプレのバックアップ製品の保管先を Storage Gateway の NFS 共有に向け、実体を Object Storage（必要に応じて低頻度/アーカイブ階層）に蓄積する
• 段階的なクラウド移行（リフト前の橋渡し）: アプリ改修前にまずファイル層だけクラウドへ寄せ、後段で Object Storage API ネイティブへ移行する踏み台にする
• オンプレ↔クラウドのデータ受け渡し: クラウド側のジョブが生成したオブジェクトをオンプレからファイルとして参照、またはその逆を実現する
• キャッシュ設計: よくアクセスするワーキングセットがローカルキャッシュに収まるようディスクを見積もる。キャッシュ不足はクラウド往復が増えレイテンシ悪化につながる
• 帯域の確保: 大量アップロードが想定される場合は回線帯域を確保し、必要なら FastConnect 等の専用接続でクラウドへの経路を安定させる
• ゲートウェイの冗長/監視: ゲートウェイは単一障害点になり得るため、ホストの可用性・キャッシュディスクの健全性・同期遅延を監視する

運用・監視

• **同期の遅延（アップロード未完了量）**を最重要指標として監視する。回線断やゲートウェイ停止時に未アップロードデータが滞留していないかを確認する
• キャッシュ使用率を監視し、逼迫したら退避ポリシーやディスク増設を検討する
• ゲートウェイホストの 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 内の他のストレージとの役割の違いを押さえるのが重要です。

ハンズオン / CLI例

ゲートウェイ本体はオンプレ等にデプロイして構成しますが、橋渡し先となる Object Storage 側は oci CLI で準備できます。以下は連携用バケットを作成し、状態を確認する例です。

# 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) ゲートウェイが Object Storage へアクセスする API キー用に
#    対象バケットだけ許可する最小権限ポリシーを用意しておく（IAM）
#    例: そのコンパートメントの object-family を read/write 許可

# 4) ゲートウェイ側でこのバケットを共有にマッピングし、
#    オンプレのクライアントから NFS でマウントして利用する
#    （マッピングとマウントはゲートウェイの管理コンソール/CLI で実施）
sudo mount <ゲートウェイのIP>:/gateway-archive /mnt/gw-archive