OCI Storage Software Appliance

解決する課題

REST API を直接呼べない既存アプリやスクリプトでも、ファイルプロトコルのまま実体をクラウドのオブジェクトストレージに置けるようにします。

• 既存アプリは NFS マウント前提で動いており、HTTP/REST のオブジェクトストレージ API を呼ぶように書き換えたくない
• バックアップやアーカイブの保管先を、容量に上限のあるローカル NAS から大容量のオブジェクトストレージへ移したい
• 大量の非構造データ（ログ、メディア、解析結果など）をファイルとして読み書きしつつ、実体はクラウドに蓄積したい
• 直近よく使うデータには低レイテンシでアクセスしたいが、全データを手元に置く容量は確保できない

主要概念と用語

• Storage Software Appliance: NFSv4 のフロントとオブジェクトストレージのバックを橋渡しするソフトウェア本体。ホスト上で動かし、POSIX 準拠のファイルアクセスを提供する
• アプライアンスファイルシステム: アプライアンスが NFSv4 で公開する論理的なファイル共有。書き込まれたファイルが背後のオブジェクトストレージにオブジェクトとして保存される
• キャッシュ（ローカルキャッシュ）: 直近アクセスしたデータやアップロード待ちのデータを保持するホスト側のディスク領域。クラウドへの往復を減らし I/O を高速化する
• LRU（Least Recently Used）: キャッシュが閾値に達したときに、最も長く使われていないデータから追い出す管理ポリシー
• ピン留め（Pin）: 特定ファイルをキャッシュに固定し、明示的に解除するまで追い出されないようにする機能
• I/O モード: 非同期（asynchronous）と POSIX Sync の 2 モード。前者は書き込みを後追いでアップロードし、後者は整合性を優先する
• オブジェクトストレージ（バックエンド）: アプライアンスが HTTPS でデータを保存するクラウド側の実体

仕様・制限・クォータ

• クライアントとの接続は NFSv4（ファイルプロトコル）、背後は HTTPS でオブジェクトストレージにアクセスする。アプリから見ると普通のファイル共有として振る舞う
• 書き込まれたファイルは、アプライアンスのファイルシステムを経由してオブジェクトとして保存される。直接 REST API を呼ぶ必要はない
• キャッシュは LRU ポリシーで管理され、ファイルシステムの設定で指定したキャッシュ閾値を維持する。重要ファイルはピン留めで常駐させられる
• I/O は非同期と POSIX Sync の 2 モードがあり、非同期はアップロードがバックグラウンドで進むため、書き込み直後に必ずクラウドへ反映済みとは限らない
• 性能はアプライアンスホストの CPU・メモリ・ディスク・ネットワーク帯域に律速される。低帯域回線では大容量アップロードがボトルネックになりやすい
• ファイルロックや高頻度ランダム更新を多用するプライマリの業務 NAS 用途には不向き。バックアップ・アーカイブ・参照・連携といった用途が適する
• 対応 OS バージョン・最大ファイルサイズ・推奨スペックなどは変動するため、公式ドキュメントの値を確認する

内部の仕組み

Storage Software Appliance は、フロント側が NFSv4、バック側がオブジェクトストレージの HTTPS API という二面を持つソフトウェアとして動作します。クライアントがファイルを書くと、アプライアンスはまずローカルのファイルシステム/キャッシュに保存し、その実体をオブジェクトとしてクラウドへ送ります。読み取り時はキャッシュにあればそこから即返し、なければクラウドから取得してキャッシュに載せます。

• 書き込みパス: NFSv4 書き込み、ローカルファイルシステム/キャッシュ、オブジェクトストレージへ HTTPS でアップロード
• 読み取りパス: NFSv4 読み取り、キャッシュヒットなら即応答、ミスならクラウドから取得してキャッシュに格納
• キャッシュ管理: 閾値超過時に LRU で古いデータを追い出す。ピン留めしたファイルは追い出し対象外
• 整合性モード: 非同期は遅延を抑える代わりに後追いでアップロード、POSIX Sync は整合性を優先する
• アプライアンス自体はステートを持つため、キャッシュ用ディスクの信頼性と容量が安定運用の鍵になる

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

• バックアップ/アーカイブのクラウド退避: バックアップ製品の保管先をアプライアンスの NFS 共有に向け、実体をオブジェクトストレージに蓄積する
• 段階的なクラウド連携: アプリ改修前にまずファイル層だけクラウドへ寄せ、後段でオブジェクトストレージ API ネイティブへ移行する踏み台にする
• ワーキングセットのキャッシュ最適化: よくアクセスするデータがローカルキャッシュに収まるようディスクを見積もる。重要かつ高頻度のファイルはピン留めでヒット率を上げる
• 整合性要件に応じたモード選択: スループット重視なら非同期、書き込み順序や即時の永続化が重要なら POSIX Sync を選ぶ
• 帯域の確保: 大量アップロードが想定される場合は回線帯域を確保し、必要なら専用接続でクラウドへの経路を安定させる
• アプライアンスの冗長/監視: アプライアンスは単一障害点になり得るため、ホストの可用性・キャッシュディスクの健全性・アップロード遅延を監視する

運用・監視

• **アップロード未完了量（同期遅延）**を最重要指標として監視する。回線断やアプライアンス停止時に未アップロードデータが滞留していないかを確認する
• キャッシュ使用率を監視し、逼迫したらピン留め方針の見直しやディスク増設を検討する
• アプライアンスホストの CPU・メモリ・ディスク I/O・ネットワーク帯域をシステム指標として取得する
• 障害切り分けの基本は、まずクライアントからアプライアンスへの NFS 到達性、次にアプライアンスからオブジェクトストレージへの到達性と認証情報、最後にキャッシュディスクの空き、の順で確認する
• オブジェクトストレージ側のオブジェクト数・容量増加は監視や使用状況レポートで傾向を把握する

コスト

アプライアンス本体よりも、背後のオブジェクトストレージ利用とアプライアンスを動かすインフラがコストの中心になります。

セキュリティ

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

関連サービス・比較

Storage Software Appliance は AWS の Storage Gateway に相当し、ファイルアクセスをクラウドのオブジェクトストレージへ橋渡しします。OCI 内では後継にあたる Storage Gateway との役割の違いを押さえるのが重要です。

ハンズオン / CLI例

アプライアンス本体はホストにデプロイして管理コンソール/CLI で構成しますが、橋渡し先となるオブジェクトストレージ側は 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 "appliance-archive" \
  --storage-tier "Standard"

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

# 3) アプライアンスがバックエンドへアクセスする資格情報には、
#    対象範囲だけ許可する最小権限を割り当てておく（IAM ポリシー）

# 4) アプライアンス側でこのバケットをファイルシステムにマッピングし、
#    クライアントから NFSv4 でマウントして利用する
#    （マッピングとマウントはアプライアンスの管理コンソール/CLI で実施）
sudo mount -t nfs4 アプライアンスのIP:/appliance-archive /mnt/appliance