Compute Cloud@Customer

解決する課題

クラウドの俊敏さは欲しいものの、データを自国・自社の外に出せない、あるいは現場設備との通信に低遅延が要る、という要件はクラウド移行の障壁になりがちです。Compute Cloud@Customer は、OCI のコンピュート基盤そのものを自社データセンター内のラックとして動かし、この対立を解消します。

• データ所在地（データレジデンシ）や規制で、データを自社施設の外に出せない
• 工場・店舗・拠点の設備と低遅延で通信したい（現地でデータ処理を完結させたい）
• 既存のオンプレ資産と同一ネットワーク内でクラウド的に動かしたい
• ハードウェアの調達・保守・パッチからは解放され、クラウドの運用体験を手元で得たい
• 接続が不安定な環境でも、ローカルでコンピュートを動かし続けたい

主要概念と用語

• Compute Cloud@Customer ラック: 自社データセンターに設置される、OCI のコンピュート・ストレージ・ネットワーク機能を内蔵したハードウェア。Oracle が所有・遠隔管理し、顧客は上で動くサービスを使う
• OCI Dedicated Region との違い: Dedicated Region は多数の OCI サービスを含むリージョンを顧客施設に構築する。Compute Cloud@Customer は、コンピュート、ネットワーク、ストレージを中心とするラック規模の IaaS
• ローカル管理面: VM、VCN、ストレージなどの作成・変更・削除を、Compute Cloud@Customer Console、対応する OCI CLI / API、Terraform からローカルに実行する
• テナンシ / コンパートメント / IAM: IAM リソースの変更元は OCI テナンシにあり、ラックへ同期・キャッシュされる。接続断中にローカルで IAM を変更することはできない
• シェイプ / VM: ラックの容量の範囲内で、フレキシブルシェイプ（OCPU・メモリ指定）の VM を起動する
• 遠隔管理（Oracle 運用）: ハードウェアの監視・パッチ・ファームウェア更新は Oracle が遠隔で実施し、顧客はインフラ運用から解放される

仕様・制限・クォータ

• ラックは有限の物理容量（OCPU・メモリ・ストレージ）を持ち、起動できる VM 総量はその範囲に収まる。クラウドのように事実上無制限ではない点が最大の違い
• 提供されるのはコンピュート中心のサービス群で、パブリック OCI の全サービスがそのまま使えるわけではない。利用可能なサービスは提供仕様に従う
• 設置にはデータセンター側の前提条件（電力・冷却・物理スペース・ネットワーク接続）を満たす必要がある
• 容量を増やしたい場合は、原則としてラックの追加・拡張で対応する（クラウドのオンデマンド拡張とは性質が異なる）
• Oracle が遠隔管理するため、ハードウェアやコントロールプレーンの保守ウィンドウが伴う
• OCI テナンシとの常時接続が前提。短時間の断には耐えるが、接続断は障害として復旧し、IAM 同期や Oracle の監視・保守が止まる時間を最小化する
• 具体的な提供シェイプ・容量・対応リージョン・前提値は版や地域で変わるため、契約・公式ドキュメントで確認する

内部の仕組み

Compute Cloud@Customer は、OCI のコンピュート、ストレージ、ネットワークを顧客データセンター内の Oracle 管理基盤で提供します。クラウド資源のライフサイクル操作は、ローカルの Compute Cloud@Customer Console、対応する OCI CLI / API、Terraform が受け付けます。一方、ユーザー、グループ、動的グループ、ポリシーなどの IAM リソースは OCI テナンシで変更し、ラックへ同期・キャッシュします。この二つの管理面を同じものとして扱わないことが重要です。

データと処理は顧客施設内に留まるため、データ所在地要件を満たしつつ、現地設備と低遅延で通信できます。OCI テナンシとの接続が切れても、既存ワークロードに加え、ローカル管理面からの作成・変更・削除や OCPU 変更は継続できます。ただし、IAM の変更・同期、OCI 側からの基盤管理、Oracle の監視や自動保守は接続回復まで止まります。

横にスクロール

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

• ハイブリッド前提で設計する。機微データや低遅延処理はラックで、バースト需要やバックアップ・分析はパブリック OCI 側で受ける役割分担を考える
• ラックは有限容量なので、シェイプとワークロードの容量計画を前もって行い、ピークと余裕を見積もる
• IAM は OCI テナンシを変更元にし、同期対象と接続断中に実行できない変更を運用手順へ明記する
• VM・ブートボリュームのバックアップを計画し、災害対策としてパブリック OCI リージョンへの退避経路を用意する
• アプリはステートを外部化しておき、容量追加や保守時の移設・再配置に強い構成にする
• ネットワークは現地データセンターのセグメントと整合させ、必要な通信のみを許可する

運用・監視

• VM・ネットワーク・ストレージの作成や状態確認は、Compute Cloud@Customer Console / 対応する API・CLI・Terraform からローカルに行う
• メトリクスやログは OCI の Monitoring / Logging に相当する仕組みで取得し、容量使用率（残り OCPU・メモリ・ストレージ）を継続的に監視する
• ハードウェアとコントロールプレーンの保守・パッチは Oracle が遠隔で実施するため、顧客はワークロード側の運用に集中できる
• 容量が逼迫してきたら、VM の整理・配置見直し、またはラックの拡張・追加を検討する
• OCI への接続断中も、既存 VM とローカルの資源ライフサイクル操作は継続できる。反対に、IAM 同期と Oracle の監視・保守は停止するため、切断を定常運用にせず早期復旧する

コスト

Compute Cloud@Customer の料金は標準の OCI 請求構造でテナンシの請求へ計上されます。契約、導入構成、サービス利用量、コミットメントによって条件が変わるため、単純な「ラック全体の完全従量課金」と決めつけず、見積書と課金明細で確認します。ハードウェアの所有と基盤保守は Oracle 側です。

セキュリティ

• データと処理が自社施設内に留まるため、データ所在地・主権の要件を満たしやすい
• 認証・認可は OCI テナンシ側の IAM ポリシー / コンパートメントで制御し、ラックへ同期されることと接続断時のキャッシュ動作を踏まえる
• VM から OCI サービスへアクセスする際は鍵のハードコードを避け、インスタンスプリンシパル相当の仕組みを使う
• ネットワークはプライベートサブネットと NSG / セキュリティリスト相当で境界を制御し、現地セグメントとの通信を必要最小限にする
• ハードウェアとファームウェアのパッチは Oracle が遠隔で適用するため、基盤の脆弱性対応が運用に組み込まれる
• 物理セキュリティ（設置施設の入退室管理など）は顧客側の責任分界に含まれる点を、責任共有モデルとして押さえる

関連サービス・比較

最も近い関連サービスは OCI Dedicated Region です。どちらも OCI を自社施設に持ち込む構成ですが、持ち込む範囲と規模が異なります。Compute Cloud@Customer はラック規模の IaaS、Dedicated Region は多数の OCI サービスを含むリージョンです。AWS では Outposts が近い選択肢です。

ハンズオン / CLI例

Compute Cloud@Customer の資源操作では、OCI CLI をラックのローカル・サービス・エンドポイントへ向けます。自己署名または組織 CA を使う環境では CA バンドルも指定します。まず読み取り操作で接続先と認証を確認してください。

# ローカルComputeエンドポイントで利用可能なシェイプを確認
oci compute shape list \
  --compartment-id "ocid1.compartment.oc1..xxxx" \
  --endpoint "https://iaas.<ccc-name>.<domain>" \
  --cert-bundle "/path/to/ccc-ca.pem" \
  --output table

# 同じローカルエンドポイントでVMを一覧表示
oci compute instance list \
  --compartment-id "ocid1.compartment.oc1..xxxx" \
  --endpoint "https://iaas.<ccc-name>.<domain>" \
  --cert-bundle "/path/to/ccc-ca.pem" \
  --query "data[].{Name:\"display-name\", State:\"lifecycle-state\", Shape:shape}" \
  --output table