Compute Cloud@Customer

解決する課題

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

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

主要概念と用語

• Compute Cloud@Customer ラック: 自社データセンターに設置される、OCI のコンピュート・ストレージ・ネットワーク機能を内蔵したハードウェア。Oracle が所有・遠隔管理し、顧客は上で動くサービスを使う
• Dedicated Region との違い: Dedicated Region Cloud@Customer は、OCI のフルリージョン（多数のサービス群）を自社施設に丸ごと持ち込む大規模オプション。Compute Cloud@Customer はコンピュート中心の小型ラックで、設置面積・電力・前提条件が小さい
• コントロールプレーン: ラック内に同梱され、OCI コンソール / API / CLI 互換の操作をローカルで提供する。VM やネットワークの作成・管理を、クラウドと同じ感覚で行える
• テナンシ / コンパートメント / IAM: クラウドの OCI と同じ概念で論理分離・権限管理を行う
• シェイプ / VM: ラックの容量の範囲内で、フレキシブルシェイプ（OCPU・メモリ指定）の VM を起動する
• 遠隔管理（Oracle 運用）: ハードウェアの監視・パッチ・ファームウェア更新は Oracle が遠隔で実施し、顧客はインフラ運用から解放される

仕様・制限・クォータ

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

内部の仕組み

Compute Cloud@Customer は、OCI のコンピュート基盤を1つのラックに凝縮し、顧客のデータセンターに設置するハイブリッド構成です。ラック内にはコンピュート・ストレージ・ネットワークに加え、OCI 互換のコントロールプレーンが同梱されており、コンソール・API・CLI をローカルで提供します。これにより、クラウドの OCI と同じテナンシ・コンパートメント・IAM・シェイプの概念で VM を作成・運用できます。

データと処理は顧客施設内に留まるため、データ所在地要件を満たしつつ、現地設備との低遅延通信が可能になります。一方で、ハードウェアの監視・パッチ・ファームウェア更新といった基盤運用は、Oracle が遠隔から担います。顧客はインフラ保守から解放され、クラウドと同じ運用体験に集中できます。

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

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

運用・監視

• VM・ネットワーク・ストレージの作成や状態確認は、ラック内のローカルコンソール / API / CLI から、パブリック OCI と同じ操作で行える
• メトリクスやログは OCI の Monitoring / Logging に相当する仕組みで取得し、容量使用率（残り OCPU・メモリ・ストレージ）を継続的に監視する
• ハードウェアとコントロールプレーンの保守・パッチは Oracle が遠隔で実施するため、顧客はワークロード側の運用に集中できる
• 容量が逼迫してきたら、VM の整理・配置見直し、またはラックの拡張・追加を検討する
• 施設側のネットワーク接続が切れても、ラック上の VM はローカルで動作を継続できる前提で運用設計する

コスト

Compute Cloud@Customer は、自前でハードウェアを購入・保守する CAPEX モデルではなく、**OCI と同じ従量課金（OPEX 寄り）**でラックの利用に対して支払う形です。ハードウェアの所有・保守は Oracle 側にあり、調達・減価償却・故障対応の負担を抱えずに済みます。

セキュリティ

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

関連サービス・比較

最も近い関連サービスは Dedicated Region Cloud@Customer です。どちらも OCI を自社施設に持ち込むハイブリッド構成ですが、持ち込む範囲と規模が異なります。Compute Cloud@Customer はコンピュート中心の小型ラック、Dedicated Region はフルリージョン相当の大規模オプションです。AWS では Outposts が対応します。

ハンズオン / CLI例

操作は OCI CLI 互換です。ラック内のコントロールプレーンに対し、パブリック OCI と同じコマンド体系で VM を作成・確認できます（エンドポイントや OCID は環境に合わせて置き換えてください）。

# ラック上の Compute インスタンス（VM）を作成
# シェイプとリソースはラックの容量の範囲内で指定する
oci compute instance launch \
  --compartment-id "ocid1.compartment.oc1..xxxx" \
  --availability-domain "AD-1" \
  --shape "VM.Standard.E4.Flex" \
  --shape-config '{"ocpus": 2, "memoryInGBs": 16}' \
  --image-id "ocid1.image.oc1..xxxx" \
  --subnet-id "ocid1.subnet.oc1..xxxx" \
  --display-name "edge-app-1"

# 作成した VM の状態を一覧で確認
oci compute instance list \
  --compartment-id "ocid1.compartment.oc1..xxxx" \
  --query "data[].{Name:\"display-name\", State:\"lifecycle-state\", Shape:shape}" \
  --output table

# ラックの容量計画の参考に、利用可能なシェイプを確認
oci compute shape list \
  --compartment-id "ocid1.compartment.oc1..xxxx" \
  --output table