OCI Dedicated Region

解決する課題

規制やデータ主権の要件でデータを自国・自社施設の外に出せない一方、オンプレミスを自前で作り込むとクラウドの俊敏性や運用性を失います。OCI Dedicated Region は、この「クラウドの中身を手元に置きたい」要求に応えます。

• データを国外・社外のデータセンターに置けないが、クラウドの運用性は手放したくない
• 金融・公共・通信など、厳格な規制やデータ所在地（データレジデンシー）要件がある
• オンプレの基幹系と極めて低い遅延で連携させたいが、自前で IaaS 基盤は作りたくない
• 標準 OCI API と有効化されたサービスを、顧客が選ぶ場所で使いたい
• 設備の調達・保守・パッチといった基盤運用は委ねたい

主要概念と用語

• Dedicated Region: 多数の OCI サービスを、顧客が選んだデータセンター内に Oracle が構築・運用するリージョン。施設・電源・空調・物理セキュリティは顧客、クラウド基盤の構築・運用・パッチは Oracle が担う
• フォールトドメイン（FD）: リージョン内でインスタンスを障害境界へ分散する単位。利用できる可用性ドメイン（AD）の数や構成は導入ごとに確認し、複数 AD を一律の前提にしない
• コントロールプレーン / データプレーン: 操作を受け付ける管理面と、実際のワークロードが動く実行面。専有リージョン内に両方を内包し、外部依存を最小化する設計
• クラウドサービス群（Compute / Storage / Networking / Database 等）: パブリックで提供される主要サービスを専有環境で利用できる。提供されるサービスの範囲は時期や契約で異なる
• Oracle 運用責任 / 顧客責任: ハードウェア・ソフトウェア基盤の運用は Oracle、施設と物理環境・ワークロードは顧客という責任分界
• OCI Compute Cloud@Customer / Exadata Cloud@Customer: より小さい単位でクラウドを持ち込む関連オファリング。専有リージョンはこれらよりはるかに広い「リージョン丸ごと」に相当
• テナンシモデル: 単一テナントまたは複数テナントで構成できる。契約・アーキテクチャ策定時に決める項目で、導入後にその場で変換する前提にはしない

仕様・制限・クォータ

• 専有リージョンは顧客のデータセンター内に設置され、施設・電源・冷却・物理セキュリティは顧客が用意し、基盤の運用・保守・パッチは Oracle が担当する
• 現行の DR25 基本構成は3ラックから始まり、容量・ネットワーク拡張ラックを追加できる。電力・冷却・床面積などの詳細は導入構成ごとに確認する
• パブリックリージョンと同じ OCI API・コンソール・SDK・CLI が使え、運用手順を共通化できる
• Oracle は Dedicated Region で200超の OCI サービスを案内しているが、実際に有効化されるサービスと機能差は導入時に確認する
• リージョン内ではフォールトドメインへ分散できる。複数 AD が提供される場合だけ AD 間分散を設計し、地域災害への DR は別地域の Dedicated Region などへ組む
• 料金は利用量と契約上のコミットメントを含む。期間・最低利用・構成条件は契約固有であり、固定費だけ、または完全従量だけと決めつけない
• 設備容量は物理的に有限のため、クォータ・サービス制限はパブリック以上に事前のキャパシティ計画が重要になる

内部の仕組み

OCI Dedicated Region は、Oracle がパブリックリージョンを構築するのと同じアーキテクチャ・同じソフトウェアスタックを、顧客のデータセンター内のハードウェア上に展開したものです。コントロールプレーン（操作・管理を司る面）とデータプレーン（ワークロードが動く面）を専有環境内に内包し、外部のパブリックリージョンへ常時依存しなくてもリージョンとして自立して動作するよう設計されています。

• ハードウェアの設置後、Oracle がリモートと現地保守でリージョンを構築・運用し、ソフトウェア更新やパッチもパブリックと同じ運用プロセスで適用される
• 顧客は施設側（建物・電源・空調・物理セキュリティ・ネットワーク引き込み）を提供し、その内側のクラウド基盤運用は Oracle が担う、という責任分界になる
• データは専有リージョン内に留まり、データ所在地・データ主権の要件を満たしやすい
• 利用できる FD、必要に応じて AD へ分散し、リージョン内の冗長設計を組む。単一施設を越える DR は別地域へ設計する

横にスクロール

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

• パブリックリージョン向けに設計したアーキテクチャをほぼそのまま移植できる前提で、IaC（Terraform / Resource Manager）を共通化する
• 利用できるフォールトドメインへ分散し、導入構成に複数 AD がある場合だけ AD 間にも分散する
• データ主権が目的なら、バックアップ・DR の保管先も要件に整合する場所（専有リージョン内や別の許可された拠点）に設計する
• パブリックと専有を併用するハイブリッド構成では、どのデータがどこに留まるべきかを分類し、配置ポリシーを明文化する
• 設備容量が有限のため、キャパシティ計画とクォータ管理を前倒しで行い、ピーク需要を見越して確保する
• 認証・権限は IAM ポリシーで最小権限に統一し、パブリックと同じガバナンスを専有にも適用する

運用・監視

• パブリックリージョンと同じツール（OCI コンソール / CLI / SDK、Monitoring、Logging）でメトリクスとログを収集・監視できる
• 基盤（ハードウェア・クラウドソフトウェア）の監視・保守・パッチは Oracle 側が担い、顧客はワークロードの監視に集中できる
• 施設側の電源・冷却・物理アクセスは顧客運用の責任範囲となるため、データセンター運用と Oracle の保守窓口の連携体制を整える
• 容量の逼迫は物理増設を伴うため、使用率トレンドを継続監視し、増設リードタイムを見込んで早めに計画する
• 障害切り分けでは、ワークロード起因か基盤起因かを明確にし、基盤起因は Oracle のサポート経路へ確実にエスカレーションする

コスト

Dedicated Region の請求は、サービスの利用量に加えて契約上のコミットメントや導入構成を含みます。期間、最低利用、増設条件などは契約・時期で変わるため、OCI の利用明細と個別契約を合わせて評価します。

セキュリティ

• データが専有リージョン内に留まるため、データ所在地・データ主権・規制対応の要件を満たしやすい
• 施設の物理セキュリティ・入退室管理は顧客側、クラウド基盤側のセキュリティは Oracle 側という責任分界を明確にする
• 認証情報のハードコードを避け、サービス間アクセスはインスタンスプリンシパル / リソースプリンシパルを使う
• シークレットは OCI Vault で集中管理し、暗号鍵のライフサイクルを統制する
• 操作権限は IAM ポリシーで最小権限に絞り、パブリックと同じガバナンス・監査をそのまま適用する

関連サービス・比較

最も近い関連サービスは、同じく顧客施設へクラウドを持ち込む OCI Compute Cloud@Customer です。Cloud@Customer がラック単位で機能を持ち込むのに対し、Dedicated Region は OCI のリージョンそのものを丸ごと再現する点が決定的に異なります。他クラウドでは AWS Outposts が近い発想ですが、持ち込む範囲の広さに差があります。

ハンズオン / CLI例

Dedicated Region 自体は Oracle との契約・プロビジョニングで構築します。利用時は標準 OCI CLI の認証プロファイルにテナンシ、署名鍵、リージョン情報を設定し、各サービスのDedicated Region 専用エンドポイントへ向けます。まず読み取り操作で realm / domain 情報と接続先を確認してください。

# Dedicated RegionのIdentityエンドポイントでADを確認
oci iam availability-domain list \
  --compartment-id "ocid1.tenancy.oc1..xxxx" \
  --endpoint "https://identity.<dedicated-region-domain>" \
  --output table

# Computeエンドポイントで既存インスタンスを確認
oci compute instance list \
  --compartment-id "ocid1.compartment.oc1..xxxx" \
  --endpoint "https://iaas.<dedicated-region-domain>" \
  --query "data[].{Name:\"display-name\", State:\"lifecycle-state\", Shape:shape}" \
  --output table