OCI GoldenGate

解決する課題

• 稼働中の DB を止めずに別 DB へ移行したい(ダウンタイムを最小化した DB 移行・クラウド移行)
• オンプレや別クラウドの DB と OCI の DB をほぼリアルタイムで同期し続けたい
• 種類の違う DB(Oracle と PostgreSQL、MySQL など)の間で異種間レプリケーションをしたい
• 本番 DB に負荷をかけずに、変更分だけを分析基盤やデータレイクへ流し込みたい
• レプリケーション基盤のサーバー構築・運用そのものをなくしたい(マネージドで運用負荷を下げたい)

主要概念と用語

• GoldenGate: DB の変更を捉えて別の宛先へ転送・適用する、Oracle のデータレプリケーション製品。OCI 版はそのフルマネージド提供形態
• CDC(変更データキャプチャ): DB の REDO ログ・トランザクションログから変更(挿入・更新・削除)だけを抽出する方式。全件コピーではないため負荷が小さい
• デプロイメント(Deployment): レプリケーション処理が動くマネージドな実行環境。OCI が裏側の計算資源を確保・運用する
• Extract(エクストラクト): ソース DB のログを読み、変更をキャプチャするプロセス
• Replicat(レプリカット): キャプチャされた変更をターゲット DB へ適用するプロセス
• トレイルファイル(Trail File): キャプチャした変更を一時的に格納する中間ファイル。Extract が書き、Replicat が読む
• 接続(Connection): ソース/ターゲットの DB への接続定義。資格情報は OCI Vault のシークレットで管理する
• 初期ロード(Initial Load): 複製開始時に既存データを一括で移す処理。以後は CDC で差分だけを連携する

仕様・制限・クォータ

• ソース/ターゲットは Oracle Database を中心に、MySQL・PostgreSQL・各種異種 DB やストリーミング基盤など幅広く対応する。対応する組み合わせは公式の対応マトリクスで確認する
• 連携モデルは CDC が基本。初回は初期ロードで既存データを移し、以降は変更分だけを継続的に流す
• **単方向・双方向(双方向同期)・多対一(集約)・一対多(分配)**といったトポロジを構成できる
• デプロイメントはプライベートサブネットに配置でき、ソース/ターゲットへはネットワーク到達性の確保が前提となる
• 変動の大きい**対応バージョン・対応 DB・上限値(クォータ)**は断定せず、要件確定時に公式ドキュメントで最新を確認する
• 1 テナンシ/コンパートメントあたりのデプロイメント数などにサービス上限があり、必要に応じて引き上げ申請ができる

内部の仕組み

OCI GoldenGate は、変更データキャプチャ(CDC)を軸にしたレプリケーションをマネージドに提供します。中核となるのがデプロイメントで、これはレプリケーション処理を動かす実行環境です。利用者はサーバーを自前で構築せず、デプロイメントを作成するだけで実行基盤が用意されます。

実際のデータの流れは Extract と Replicat の 2 つのプロセスが担います。Extract はソース DB の REDO ログ・トランザクションログを読み、変更だけを抽出してトレイルファイルに書き出します。テーブルを丸ごと読むのではなくログから差分を取るため、ソース DB への負荷が小さいのが特徴です。トレイルファイルに溜まった変更を、Replicat がターゲット DB へ順序を保って適用します。

複製を始めるときは、まず初期ロードで既存データをターゲットへ移し、その時点以降の変更を CDC で連携します。これにより、ソースを止めずに両者を同期させ続けられ、最終的にアプリの向き先を切り替えるだけでほぼ無停止の移行が実現できます。ソースとターゲットの DB が異なる種類でも、GoldenGate が差を吸収して異種間レプリケーションを成立させます。

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

• 無停止移行は CDC で差分を追従: 初期ロードで現状を移し、以降の変更を CDC で連携し続け、切り替え時のダウンタイムを最小化する
• 資格情報は OCI Vault に集約: 接続のパスワードはコードや設定に直書きせず、OCI Vault のシークレットを参照する
• プライベート経路を基本に: デプロイメントとソース/ターゲットはプライベートサブネットに置き、到達経路を最小化する
• ラグ(遅延)を監視前提で設計: Extract / Replicat のラグを継続監視し、しきい値超過でアラートを出す運用にする
• 双方向同期は競合解決を設計: 双方向トポロジでは同一行への同時更新が起こりうるため、競合検知・解決(CDR)の方針を事前に決める
• 対象テーブルを絞る: 必要なスキーマ・テーブルだけを複製対象にし、不要な変更まで流さないようにして負荷とコストを抑える

運用・監視

• デプロイメントには**専用の管理コンソール(GoldenGate のサービスマネージャ画面)**があり、Extract / Replicat の状態やラグを GUI で確認できる
• OCI Monitoring のメトリクスで、レプリケーションのラグ・処理量・プロセス状態を監視し、遅延や停止を検知してアラートを出す
• 操作は OCI Audit に記録され、デプロイメントや接続の作成・変更を後から追跡できる
• パッチ適用はマネージドで、メンテナンス時間帯を指定して適用できる。バージョン更新の運用負荷が小さい
• トレイルファイルのディスク使用量やプロセスの異常停止を監視し、滞留や失敗を早期に検知する
• 接続資格情報をローテーションしたら、対応する OCI Vault のシークレットバージョンを切り替えて反映する

コスト

課金は基本的にデプロイメントの稼働(実行環境の計算資源)が中心で、稼働している時間とサイジングに応じて費用が発生します。これに、トレイルファイルなどが使うストレージや、リージョン/クラウドをまたぐデータ転送の分が加わります。具体的な単価は変動するため、ここでは考え方を整理します。

セキュリティ

• ソース/ターゲットへの接続資格情報は接続に直書きせず、OCI Vault のシークレットとして暗号化保管し、参照だけにする
• デプロイメントはプライベートサブネットに配置し、**セキュリティリスト / NSG(ネットワークセキュリティグループ)**で接続元を最小化する
• 通信は TLS で暗号化する。管理コンソールへのアクセスも保護された経路で行う
• OCI IAM ポリシーで、デプロイメントや接続の作成・利用権限をコンパートメント単位に最小化する
• 操作は OCI Audit に残り、誰がいつ複製設定を作成・変更したかを後から監査できる

関連サービス・比較

DB の移行・連携という観点では、AWS の Database Migration Service(DMS)が近い対応サービスです。GoldenGate は継続的な双方向同期や異種間レプリケーションなど、より高度な連携に強みがあります。

ハンズオン / CLI例

# レプリケーションを動かすデプロイメント(実行環境)を作成
oci goldengate deployment create \
  --compartment-id "$COMPARTMENT_OCID" \
  --display-name "app-gg-deployment" \
  --subnet-id "$SUBNET_OCID" \
  --license-model "LICENSE_INCLUDED" \
  --cpu-core-count 2 \
  --is-auto-scaling-enabled true \
  --deployment-type "DATABASE_ORACLE" \
  --wait-for-state ACTIVE

# ソース/ターゲット DB への接続を作成(資格情報は OCI Vault のシークレットを参照)
oci goldengate connection create \
  --compartment-id "$COMPARTMENT_OCID" \
  --display-name "source-db-conn" \
  --connection-type "ORACLE" \
  --technology-type "ORACLE_DATABASE" \
  --password-secret-id "$PASSWORD_SECRET_OCID"

# 作成したデプロイメントの一覧と状態を確認
oci goldengate deployment list \
  --compartment-id "$COMPARTMENT_OCID" \
  --output table