OCI FSDR実践Vol1 東京大阪DRの境界と料金モデル

1. この記事について — なぜ東京⇔大阪のFull Stack DRか

1-1. 本記事のゴール

本記事のゴールは、AWSでElastic Disaster Recovery(DRS)やResilience Hubの実務経験を持つ読者が、OCI Full Stack Disaster Recoveryの課金モデル・概念設計・ネイティブ保護対象の正確な範囲を理解し、実際に東京⇔大阪の最小構成でDR Protection Groupを作成してスイッチオーバーするところまでを一気通貫で体験できることです。

FSDRはOCIのデータベース系サービスと同様にAlways Free対象外であり、Oracle Cloud Free Tierユーザーは利用自体ができません。本記事は、この前提を正面から扱ったうえで、公式Price List API(cetools)で確認した単価に基づく料金を試算します。具体的な課金モデルは§2で詳しく扱います。

本記事で最も重視しているのは、FSDRがオーケストレーションできる対象とできない対象の境界を、誇張なく正直に伝えることです。FSDRという名前から「Full Stack」がすべてのレイヤーを自動で保護してくれるサービスだと誤解されがちですが、実際にネイティブに保護できるメンバーはCompute・Base Database/Exadata/Autonomous Database・MySQL DB System・OKE・Integration(OIC)に限られます。この境界を曖昧にしたまま導入すると、実際の障害時に「保護されていると思っていたコンポーネントが復旧しない」という重大な事故につながりかねません。§3で、この境界と、境界の外側にあるサービス(PostgreSQL等)をどう統合設計するかを扱います。

読み終える頃には、「FSDRは何を自動化し、何をユーザー定義ステップに委ねる必要があるのか」「東京・大阪とも1ADリージョンである状況で、なぜFSDRのようなクロスリージョンDRオーケストレーションが実質的に唯一の広域冗長化手段になるのか」「停止中のスタンバイインスタンスがなぜ課金対象になるのか」の3点について、公式ドキュメントの一次情報に基づいて答えられるようになっているはずです。

これら3点は、いずれも導入前の見積もりや設計レビューの場で必ず問われる論点でもあります。特に3点目の課金の落とし穴は、実際に運用を始めてから気づくと手戻りが大きいため、本記事では§2で独立した節を設けて詳しく扱います。

本記事で扱う数値・GA日付・仕様は、すべて公式ドキュメント、公式リリースノート、Oracle公式Price List API(cetools)の一次情報に基づいています。独自に数値を作成したり、未確認の推測を事実として記載したりすることはしません。トライアルテナンシでの正確な利用可否境界など、公式ドキュメントに明記がなく断定できない事項については、その旨を明示したうえで記述します。

1-2. 読者像 — AWSレジリエンス実務者

本記事が主に想定しているのは、AWSでElastic Disaster Recovery(DRS)・Resilience Hub・AWS Backupといったレジリエンス関連サービスの構築・運用経験を持つエンジニアです。DRSの「継続的レプリケーション」「ドリル起動」「リカバリ起動」、Resilience Hubの「評価とレジリエンススコア」、AWS Backupの「バックアッププランとリストア」といった概念に馴染みがある方であれば、FSDRの「DR Protection Group」「DR Plan」「プリチェック」という設計は、共通点と相違点の両方が見えてくることで、より深く理解できる構成にしています。

一方で、OCIの利用自体が初めての方は、まず「OCI入門」シリーズを一通り読んでから本記事に戻ることをおすすめします。特に、東京リージョンがアベイラビリティドメイン(AD)を1つしか持たない1ADリージョンであるという構造(「OCI入門」Vol1で扱った内容)は、本記事の前提として重要です。AWSのMulti-AZ構成に慣れた読者ほど、OCIの東京リージョン単体ではAWSのAZ分散に相当する冗長化ができないという事実に驚くはずですが、この制約こそが、大阪リージョンとのクロスリージョンDRが「あれば望ましい」オプションではなく、広域障害に備える実質的に唯一の選択肢になる理由です。

Resilience Hubの実務経験を持つ読者は、「評価してレジリエンススコアを算出する」という発想がFSDRには存在しない点にも注意してください。FSDRはあくまで切り替え操作(スイッチオーバー・フェイルオーバー・ドリル)を担うサービスであり、構成の弱点を自動的に診断してスコア化する機能は持ちません。弱点の洗い出しやRTO/RPOの妥当性検証は、§3-7の設計論に沿って利用者自身で整理する必要があります。

1-3. 用語整理 — FSDRは「オーケストレーター」

OCIのディザスタリカバリサービスは、正式名称を「Oracle Cloud Infrastructure Full Stack Disaster Recovery」といいます。本記事では公式の略称に準拠して「FSDR」または「本サービス」と表記します。

FSDRを理解するうえで最も重要な位置づけの整理が、「FSDRはDRを実行するサービスではなく、DRをオーケストレーションするサービスである」という点です。FSDR自体がデータをレプリケーションするわけではありません。Compute・Block Volume・データベース等、各リソースが個別に持つレプリケーション機能(Block Volumeのクロスリージョンレプリケーション、Autonomous DatabaseのAutonomous Data Guard等)を、DR Protection Groupという単位でグルーピングし、DR Planという手順書に沿って、プライマリリージョンからスタンバイリージョンへの切り替えを一括で実行・管理する役割を担います。

AWSの用語に置き換えると、FSDRは個々のレプリケーション機構(DRSのブロックレベルレプリケーション、Auroraのグローバルデータベース等)そのものではなく、複数リソースにまたがるDR手順を定義・実行・検証する「オーケストレーションレイヤー」に近い立ち位置です。Resilience Hubが評価・可視化を担う一方、FSDRは実際の切り替え操作(スイッチオーバー・フェイルオーバー)を担う点が異なります。この用語整理を押さえておくと、§3の概念設計が理解しやすくなります。

もう1つ整理しておきたいのが、AWS Backupとの対比です。AWS Backupは「バックアップとリストア」という、時点復旧を軸にしたサービスです。FSDRのユーザー定義ステップの一部(§3-4で扱うPostgreSQL Cold DRのバックアップ/リストア方式)は、この発想に近い動きをしますが、FSDR自体はバックアップの取得・保管を担うサービスではありません。あくまで、各サービスが個別に持つバックアップ機能やレプリケーション機能を、DR Planという手順書の中で正しい順序に沿って実行するオーケストレーターである、という位置づけを一貫して意識してください。

1-4. 既刊OCIシリーズとの役割分担 — 2本の予告を回収する

本記事は「OCI Full Stack Disaster Recovery実践」シリーズの第1弾ですが、既刊の2つのシリーズが、本記事へ明示的にDR設計を委譲する予告をしています。

本記事はこの2つの予告を回収する位置づけです。PostgreSQL実践Vol1が示した通り、Database with PostgreSQLのようなデータベース単体のネイティブDR(Warm Standby)と、FSDRによるスタック全体のオーケストレーションは、役割が異なるレイヤーの話です。この棲み分けは§3-4で改めて具体的な設計パターンとして扱います。ネットワーク実践Vol1が示した通り、東京リージョンでの可用性設計は単一AD内のフォルトドメイン分散が限界であり、その先のリージョン単位の冗長化を担うのが本記事の主題です。

← OCI Database with PostgreSQL実践Vol1(Warm StandbyによるDBネイティブDR)を読む

1-5. 守るべき対象 — これまでのOCIシリーズとの接続

本記事は「OCI Full Stack Disaster Recovery実践」の1本目ですが、実質的にはこれまで公開してきたOCIの各実践シリーズが構築してきたワークロードを、東京⇔大阪でどう守るかという横断的な視点を持つ記事でもあります。「OCI入門」シリーズで組んだ基礎環境、各サービスの実践記事で構築したCompute・データベース・コンテナ基盤といった「守るべき対象」を思い浮かべながら読むことで、本記事の内容がより具体的に理解できるはずです。

ただし、ここで注意しておきたいのが、§1-3で整理した「FSDRはオーケストレーター」という位置づけです。守るべき対象が増えたからといって、それらすべてをFSDRが自動的に保護してくれるわけではありません。守るべき対象の中には、FSDRがネイティブにDR Protection Groupのメンバーとして扱えるものと、扱えないものが混在しています。

この見取り図はあくまで概要であり、正確な対応/非対応の一覧と、非対応サービスの統合設計パターンは§3-3・§3-4で詳しく扱います。ここで押さえておきたいのは、「FSDRを導入すれば守るべき対象すべてが自動的にDR対応になる」という前提そのものが誤りだという点です。この誤解を解くことが、本記事全体を通じた最も重要なメッセージです。

既刊シリーズを順に読んできた読者であれば、ここまでに構築したワークロードのうち、どれがFSDRでそのまま守れて、どれに追加のDR設計が必要になるかを、本記事を読み終えた時点で判断できるようになることを目指しています。逆に本記事から読み始めた読者にとっては、この見取り図が、今後どのOCIサービスをどう組み合わせて使うかを検討する際の判断材料になるはずです。

1-6. 本記事が扱う範囲

本記事は、FSDRの課金モデル・概念設計・ネイティブ保護対象の境界の理解から、実際にDR Protection Groupを作成してスイッチオーバーするところまでを扱います。一方で、東京・大阪の各リージョンにおけるVCN・Compute・データベースそのものの構築手順は、「OCI入門」シリーズおよび各サービスの実践記事(Database with PostgreSQL実践・MySQL HeatWave実践等)に委譲し、本記事ではFSDR固有のトピック(DR Protection Group・DR Plan・プリチェック・スイッチオーバー実行)に集中します。

また、FSDRがネイティブに保護しないサービス(PostgreSQL・Cache・Queue+Kafka等)については、それぞれのサービスが持つネイティブDR機能(Warm Standby等)との統合設計の考え方を§3-4で扱いますが、各サービスのネイティブDR機能自体の詳細な操作手順までは扱いません。詳細は各サービスの実践記事を参照してください。

1-7. 本記事の読み進め方

本記事は、FSDRの課金モデルと保護対象の境界を理解しないまま先にハンズオンへ進むと、想定外の課金や、実際には保護されていないコンポーネントを見落とすリスクに直面しやすい構成です。そのため、まず課金モデル(§2)と概念設計・保護対象の境界(§3)を読んでから、ハンズオン(§4〜§5)へ進む構成としています。

すでにAWSでDRSやResilience Hubの実務経験が豊富で、料金モデルと保護対象の違いだけを素早く確認したいという方は、§2と§3を重点的に読み、ハンズオンの手順は必要な部分だけをつまみ読みする、という読み方でも問題ありません。

なお、本記事は執筆時点で確認できた公式ドキュメント・公式リリースノート・Oracle公式Price List APIの一次情報に基づいて構成しています。料金・仕様は将来改定される可能性があるため、本番導入や予算確保の判断材料として使う際は、公開時点の最新の公式情報もあわせて確認することをおすすめします。

また、本記事は東京⇔大阪という国内2リージョン間のDR構成に焦点を絞っています。海外リージョンとのDR構成や、3リージョン以上を組み合わせたより複雑なトポロジーについては、本記事では扱いません。国内2リージョンでの最小構成を理解しておけば、より複雑な構成へ応用する際の土台になるはずです。

← OCIネットワーク実践(Production編)Vol1(東京リージョンの可用性設計)を読む

2. サービス仕様と料金 — 課金モデルを先に知る

FSDRは、OCIのデータベース系サービスと同様にAlways Free対象外のサービスです。加えて、FSDR自体の利用可否がテナンシの契約形態によって明確に分かれるという、他の多くのOCIサービスとは異なる特徴を持っています。本章では、この利用可否の境界、GA以降の機能拡張の歴史、具体的な料金試算、そしてAWS Elastic Disaster Recoveryとの対比を整理します。

2-1. 利用可否の境界 — Free Tier不可・トライアルは公式言及なし

OCI公式ドキュメント「Using Oracle Cloud Infrastructure Full Stack Disaster Recovery」の利用可否ページ(取得日: 2026年8月10日)には、次の原文が明記されています。

日本語に訳すと、「FSDRはUniversal CreditsまたはPay As You Goを利用する全Oracle Cloud顧客が利用可能」「FSDRはOracle Cloud Free Tierユーザーには利用不可」という2点です。Always Free対象外という表現がよく使われるDatabase with PostgreSQL等とは異なり、FSDRはそもそもFree Tierテナンシからはサービス自体にアクセスできないという、より踏み込んだ制約です。

一方で、本記事執筆にあたり公式ドキュメントを確認した範囲では、30日間$300クレジットのトライアルテナンシにおけるFSDRの利用可否について、明示的な言及は見つかりませんでした。トライアルテナンシは技術的にはUniversal Creditsの枠組みで動作しますが、公式ドキュメントがFree Tierとトライアルを明確に区別してFSDRの利用可否を述べていない以上、「トライアルテナンシでも問題なく使える」と断定できません。トライアルテナンシでFSDRの導入検証を計画している場合は、事前にOCIコンソールでFSDRのサービスページにアクセスできるか、または少額の課金が発生する操作(DR Protection Groupの作成等)を試みて実際の挙動を確認することをおすすめします。本記事のハンズオン(§4〜§5)は、この境界が不明である前提のもと、Pay As You Goテナンシでの検証を基準に記述しています。

この点は、Database with PostgreSQL実践Vol1で扱った「トライアルクレジットの範囲内であれば無課金で完走できる」という前提とは、性質が異なります。Database with PostgreSQLはAlways Free対象外であっても、トライアルテナンシで利用できました。一方FSDRは、そもそもテナンシの種別によって利用可否自体が変わりうる、という一段階厳しい制約です。この違いを踏まえたうえで、本記事ではPay As You Go(またはUniversal Credits)テナンシでの検証を前提に進めます。

2-2. GA履歴 — 2022年10月から継続的に機能拡張

FSDRは、2022年10月25日にGAして以降、現在まで継続的に機能拡張が続けられている、活発なサービスです。公式リリースノート(取得日: 2026年8月10日、確認件数19件)から、主要な更新を時系列で整理します。

この履歴から分かる通り、FSDRはメンテナンスモードや新規受付終了とは無縁の、対応リソース種別を着実に広げ続けているサービスです。特に2025年以降、OKE対応(2025-01)・MySQL DB System対応(2025-08)という、ネイティブ保護対象そのものを拡大するアップデートが続いている点は、本記事の差別化軸の1つでもあります。§3-3で、この拡大を踏まえた最新の保護対象一覧を整理します。

2-3. 2025年以降の主要アップデートの中身

GA履歴の中でも、実務への影響が大きい4件について、内容をもう少し詳しく整理しておきます。

OKE対応(2025年1月29日): それまでComputeやデータベース系リソースが中心だったDR Protection Groupのメンバーに、OKE(Kubernetes Engine)クラスターが追加されました。コンテナ化されたワークロードを、個別のComputeノードではなくOKEクラスター単位でDR設計へ組み込めるようになった点が大きな変化です。

MySQL DB System対応(2025年8月26日): OCI MySQL HeatWaveのDBシステムが、ネイティブ保護対象に追加されました。既刊「OCI MySQL HeatWave実践」シリーズで構築したワークロードも、この対応以降はFSDRのDR Protection Groupへ直接組み込めるようになっています。

Automatic DR Configuration(2025年10月29日): DR Protection Groupのメンバー構成やDR Planのステップを、手動で1つずつ設定するのではなく、既存のリソース構成から自動検出・自動生成する機能です。§4-4で扱うスイッチオーバープランの自動生成機能も、この流れの延長線上にある機能強化です。

Integration対応(2025年12月17日): OIC(Oracle Integration Cloud)がDR Protection Groupのメンバーとして追加されました。統合ワークフロー自体をDR設計へ組み込めるようになった、比較的新しい対応です。

2-4. 料金体系 — Compute/DB系/OKE/OICのOCPU・ECPU課金

FSDRの料金は、DR Protection Groupのメンバーとして追加したリソースのOCPU数・ECPU数・メッセージ数に応じた従量課金です。以下は、Oracle公式Price List API(cetools、USD PAYG単価、取得日: 2026年8月10日)で確認した単価です。

RDS/Auroraのようなインスタンスクラス課金に慣れた読者にとっては、「OCPU数に対して課金される」というモデル自体はDatabase with PostgreSQL実践Vol1で扱ったコンピュート課金と同じ発想で理解できるはずです。異なるのは、課金の対象がDBシステム自体ではなく、FSDRのオーケストレーション機能に対して、DR Protection Groupのメンバーとして登録したリソースの規模に応じて発生するという点です。

なお、ECPUベースのメンバー(B110274)は、メンバーとなるリソース自体がECPU課金モデルを採用している場合に適用される単価です。OCPU課金かECPU課金かは、DR Protection Groupに追加する個々のリソースの課金モデルに連動して決まるため、対象リソースの課金体系を事前に確認しておくことをおすすめします。

公式ドキュメント(billing-details)によれば、課金対象になるのは、プライマリ・スタンバイ両方のDR Protection Groupに追加したComputeインスタンス(moving配置はプライマリのみ、non-moving配置は両方)、Base Database/Exadata/Autonomous Database/MySQL DB SystemといったDB系リソース、OKE、OICのOCPU数・ECPU数・メッセージ数です。一方、Block Volume/File Storage/Object Storage、Flexible Load Balancer/Network Load Balancerといったメンバーは、FSDR側の課金対象には含まれません(各サービス自体の利用料は別途発生します)。

2-5. 料金試算 — 公式計算例と最小構成ハンズオンの目安

公式ドキュメントの料金計算例(Example 3)では、プライマリDR Protection Groupに30 OCPU分のリソース、スタンバイDR Protection Groupに18 OCPU分のリソースを追加したケースを想定し、合計48 OCPU分のFSDR料金が発生するという試算が示されています。48 OCPU × $0.0128/OCPU/hr ≒ $0.614/時間という計算です。

本記事§4〜§5のハンズオンのように、moving配置のCompute 1台(1 OCPU)のみをDR Protection Groupのメンバーとする最小構成であれば、FSDR自体の料金は1 OCPU × $0.0128/OCPU/hr = $0.0128/時間とごくわずかです。moving配置はプライマリリージョンのみに課金が発生するため、通常稼働時のFSDR料金はさらに小さくなります。

この試算はFSDR自体のオーケストレーション料金のみであり、実際にDR Protection Groupのメンバーとなるリソース側の利用料(Compute自体の課金・Block Volumeのクロスリージョンレプリケーション費用等)は別途発生します。ハンズオンで実費が主に発生するのは、FSDR料金そのものよりも、保護対象リソース側(両リージョンのCompute・Block Volumeレプリケーション)である点に注意してください。数時間程度の検証であれば、合計でも数ドル規模に収まる想定です。

参考として、OCPU数を変えた場合のFSDR単体の月額料金目安も整理しておきます(B95485単価$0.0128/OCPU/hrをそのまま730時間換算した参考値です)。

この参考値はあくまでFSDR自体のオーケストレーション料金のみの単純計算であり、保護対象リソース側の課金は含んでいません。本番導入のサイジングを検討する際は、DR Protection Groupに追加する予定のリソース全体のOCPU/ECPU数を洗い出したうえで、保護対象リソース側の料金とあわせて見積もってください。

2-6. 停止中スタンバイも課金という落とし穴

公式ドキュメント(billing-details)には、DR Protection Groupのメンバーとして追加したインスタンスは、スタンバイリージョン側で停止(Stopped)状態であっても、FSDR自体の課金対象になり続けると明記されています。これは、AWSのEC2料金モデル(停止中インスタンスはコンピュート料金が発生しない)に慣れた読者にとって、特に見落としやすいポイントです。

この落とし穴は、コスト効率を重視するならmoving配置、即時復旧(短いRTO)を重視するならnon-moving配置という、§3-2で扱うトレードオフの判断材料にも直結します。

2-7. AWS Elastic Disaster Recoveryとの料金対比

AWS Elastic Disaster Recovery(DRS)の公式料金ページ(取得日: 2026年8月10日)によれば、DRSは「1時間あたり1ソースサーバーにつき$0.028」という、レプリケーション対象サーバー単位のシンプルな時間課金です。この料金には、継続的なデータレプリケーション・テスト起動・リカバリ起動・ポイントインタイムリカバリが含まれており、別途EBSボリューム・EC2インスタンス・EBSスナップショットの利用料が発生します。

この対比から分かる通り、DRSがサーバー単位のレプリケーションに特化したシンプルな課金モデルであるのに対し、FSDRはCompute・データベース・OKE・OICを横断したオーケストレーション料金という、対象範囲の広さに応じた課金モデルを取っています。DRSの「1台$0.028/hr」という感覚をそのままFSDRに当てはめると、実際の試算(§2-4・§2-5)とズレる可能性があるため、注意してください。

2-8. よくある誤解 — AWSレジリエンス実務者が陥りやすいポイント

ここまでの内容を踏まえ、AWSでDRS・Resilience Hubの実務経験を持つ読者が抱きやすい誤解を整理します。

誤解1: トライアルテナンシでも問題なくFSDRを試せるはず

§2-1で見た通り、公式ドキュメントはFree Tier不可を明記する一方、トライアルテナンシについては明示的に言及していません。断定はできないため、事前にコンソールでの挙動確認をおすすめします。

誤解2: DRSと同じ「1台いくら」というシンプルな課金のはず

§2-7で見た通り、FSDRはDR Protection Groupメンバーの種類(Compute/DB系/OKE/OIC)に応じたOCPU/ECPU/メッセージ課金であり、DRSのサーバー単位課金とは構造が異なります。

誤解3: スタンバイを停止しておけば課金は止まるはず

§2-6で見た通り、non-moving配置のスタンバイインスタンスは、停止状態でもFSDR自体の課金は継続します。コスト削減にはmoving配置の検討、またはDR Protection Groupからのメンバー除外が必要です。

誤解4: FSDRを導入すればOCI上の主要サービスは自動的にDR対応になるはず

この誤解が最も重大です。FSDRがネイティブに保護できる対象には明確な境界があります。詳細は§3-3で扱います。

誤解5: OKE対応・MySQL対応と聞けば、既存のOKEクラスターやMySQL DB Systemがすぐ組み込めるはず

§2-3で見た通り、OKE対応・MySQL DB System対応はいずれも2025年に追加された比較的新しい機能です。既存のワークロードをDR Protection Groupへ組み込む際は、対応が追加された時期以降のFSDRであることを前提に、必要な前提条件(ネットワーク構成・IAMポリシー等)を公式ドキュメントで個別に確認することをおすすめします。

2-9. 作成前チェックリスト

§4のハンズオンへ進む前に、本章で整理した内容を踏まえて確認しておきたい項目を整理します。

• FSDRがFree Tier不可であり、Universal CreditsまたはPay As You Goテナンシでの検証が前提であることを理解したか(§2-1)
• トライアルテナンシでの利用可否は公式ドキュメントに明記がなく断定できないことを理解し、必要であれば事前にコンソールで挙動を確認したか(§2-1)
• DR Protection GroupメンバーのOCPU/ECPU/メッセージ課金という料金体系を理解したか(§2-4)
• 停止中のnon-moving配置スタンバイインスタンスもFSDR料金が継続することを理解したか(§2-6)
• 東京・大阪の両リージョンで、DR Protection Groupのメンバーとする最小構成(Compute 1台)を準備できる状態か(§4で必要になります)
• FSDRがネイティブに保護する対象には境界があり、「FSDRを導入すればすべて安心」ではないことを理解したか(§2-8・詳細は§3-3)

これらの項目にすべて問題がなければ、次章の概念設計を経て、DR Protection Groupの作成に進む準備が整っています。次章では、DR Protection Group・DR Plan・プリチェックという主要概念に加えて、FSDRがネイティブに保護できる対象の正確な境界を、公式ドキュメントの一次情報に基づいて整理します。

3. 概念設計 — DR Protection GroupとDR Plan

3-1. DR Protection Groupとメンバー

DR Protection Group(DRPG)は、ディザスタリカバリの単位として扱うOCIリソースの集合です。アプリケーションを構成するCompute・Block Volume・データベース等、まとめて切り替える必要があるリソースを1つのDRPGとして定義し、プライマリリージョンとスタンバイリージョンにそれぞれ1つずつ、対となるDRPGを作成します。AWSの用語で近いものを挙げると、Resilience Hubの「アプリケーション」定義に近い発想ですが、FSDRのDRPGはあくまで切り替え操作の単位であり、評価やスコアリングの機能は持ちません。

3-2. moving vs non-moving — 配置方式のトレードオフ

DRPGにComputeインスタンスをメンバーとして追加する際、moving(移動)とnon-moving(非移動)という2つの配置方式を選択できます。

どちらを選ぶかは、コストとRTOのトレードオフです。本記事§4のハンズオンでは、コスト効率を優先し、moving配置のCompute 1台という最小構成を採用します。

3-3. ★FSDRネイティブ保護対象の境界 — 対応/非対応を正直に整理する

本記事で最も重視している論点です。FSDRという名称、そして「Full Stack」という表現から、OCI上のあらゆるサービスを自動的にDR対応させてくれると誤解されがちですが、実際にDRPGのメンバーとしてネイティブに追加できるリソースには明確な範囲があります。公式ドキュメントで確認できるネイティブ対応メンバーと、本記事のシリーズで扱ってきた既刊サービスのうち非対応にあたるものを整理すると、次の通りです。

Block Volume/File Storage/Object Storageといったストレージ系、Flexible Load Balancer/Network Load BalancerといったLB系は、DRPGメンバーとして直接追加するのではなく、Computeインスタンスの構成要素(ボリュームグループ等)として間接的に扱われる、あるいはDR Plan内のステップとして手動/自動で切り替える対象になります。

この境界を正直に示す理由は明確です。「守るべき対象が増えた」という論点でFSDRを紹介する記事は、対応メンバーだけを紹介して「FSDRを入れればすべて安心」という印象を与えがちです。しかし実際には、本サイトのシリーズで扱ってきたPostgreSQL・Cache・Queue+Kafkaといったサービスは、FSDRのDRPGに直接メンバーとして追加できません。これらのサービスのDRを実現するには、各サービスが個別に持つネイティブDR機能と、FSDRのユーザー定義ステップを組み合わせる設計が必要です。次節で、この組み合わせ方を具体的に扱います。

3-4. 非対応サービスの統合設計パターン — ユーザー定義ステップでの連携

FSDRがネイティブ対応しないサービスをDR設計に組み込む場合、それぞれのサービスが持つネイティブDR機能を土台に、FSDRのDR Planへユーザー定義ステップとして統合するというパターンが、公式チュートリアルでも示されています。

代表例として、Database with PostgreSQLの場合、公式チュートリアル「Automate Cold Disaster Recovery for OCI Database with PostgreSQL using OCI Full Stack Disaster Recovery」(docs.oracle.com/en/learn/full-stack-dr-pgsql-cold-dr、実在確認済)が、バックアップ・リストア方式によるCold DRをFSDRのユーザー定義ステップとして統合する手順を公開しています。このチュートリアルでは、Switchoverプランに「バックアップ作成→コピー→リストア」「DNS更新」「ソース側インスタンスの終了」という3種類のカスタムステップを、Failoverプランに「バックアップからのリストア」「DNS更新」という2種類のカスタムステップを、それぞれPythonスクリプトとして追加します。この方式のRPOは、バックアップ取得頻度に依存し、1日1回のバックアップスケジュールを推奨事例として1日(24時間)としています。

なお、§1-4で回収した通り、Database with PostgreSQL実践Vol1で扱った「Replication with Warm Standby」は、この手動バックアップ/リストア方式とは異なる、より短いRPOを狙えるレプリケーション方式です。どちらの方式を採用するかは、要求されるRPO/RTOと運用コストのバランスで判断することになります。いずれの方式でも、PostgreSQL自体の切り替えロジックはFSDRの外側(PostgreSQL側のネイティブ機能、またはユーザー定義スクリプト)が担い、FSDRはあくまでそれをDR Plan全体の実行順序に組み込むオーケストレーターとして機能する、という位置づけは共通しています。

Cache(Valkey)やQueue/Kafkaについても同様に、各サービスが持つレプリケーション・クラスタリング機能を土台に、DNS切り替えやエンドポイント更新といった手順をユーザー定義ステップとしてFSDRのDR Planに組み込む設計が、基本的な統合パターンになります。ネイティブ対応が広がるまでは、この「ネイティブDR + ユーザー定義ステップ」という組み合わせを設計の基本線として押さえておいてください。

→ OCI Database with PostgreSQL実践Vol1(Replication with Warm Standby)を読む

3-5. DR Plan種別 — Switchover・Failover・Start Drill・Stop Drill

DR Planは、DRPGに対して実行する切り替え手順を定義したものです。公式ドキュメント(dr-plans-type.html、取得日: 2026年8月10日)によれば、DR Planには次の4種類があります。

AWSのDRSにおける「テスト起動(ドリル)」と「リカバリ起動(実際の切り替え)」という区分に近い発想ですが、FSDRはさらにSwitchover(計画済み)とFailover(計画外)を明確に分けている点が特徴です。§5のハンズオンでは、Switchoverプランを実行します。

3-6. プリチェック — built-in/user-defined

DR Planの実行前には、プリチェック(precheck)によって、DR Planが正常に実行できる状態かを事前検証できます。FSDRには、あらかじめ用意されたbuilt-in(組み込み)プリチェックと、2025年4月30日にGAしたuser-defined(ユーザー定義)プリチェックの2種類があります。built-inプリチェックのみで検証可能な単純な構成であれば追加設定は不要ですが、§3-4で扱ったようなユーザー定義ステップを含むDR Planでは、そのステップ固有の前提条件(バックアップの存在確認等)をユーザー定義プリチェックとして追加することが推奨されます。

3-7. RTO/RPO設計論

FSDRを使ったDR設計におけるRTO(目標復旧時間)/RPO(目標復旧時点)は、DRPGメンバーの配置方式(moving/non-moving)、各リソースのレプリケーション方式、そしてDR Planのステップ構成に依存します。moving配置はコスト効率を優先する分RTOが長くなり、non-moving配置はRTO短縮を優先する分、費用は割高になるというトレードオフは§3-2の通りです。データベース層についても、§3-4で見たWarm Standby(短いRPO)とCold DR(バックアップ頻度に依存するRPO)のように、方式によってRPOが大きく異なります。本記事のハンズオン規模では実測のRTO/RPOを計測しませんが、本番導入を検討する際は、DRPGメンバーごとの配置方式とレプリケーション方式の組み合わせを整理したうえで、要求されるRTO/RPOを満たせるか検証することをおすすめします。

4. ハンズオン — 東京⇔大阪の最小DR構成

4-1. 前提

本ハンズオンは、東京リージョン(ap-tokyo-1)をプライマリ、大阪リージョン(ap-osaka-1)をスタンバイとして、moving配置のCompute 1台のみをメンバーとする最小構成でDR Protection Groupを作成します。両リージョンとも、あらかじめVCN・サブネットが準備済みであることを前提とします(構築手順は「OCI入門」シリーズVol3を参照してください)。テナンシはPay As You Go(またはUniversal Credits)であることを確認してください。§2-1で見た通り、Free Tierテナンシでは本ハンズオンを実施できません。

← OCI入門 Vol3(VCN・サブネット・ゲートウェイ)を読む

4-2. DR Protection Groupの作成

OCIコンソールのメニューから「Disaster Recovery」→「DR Protection Groups」を開き、まず東京リージョンでプライマリDRPGを作成します。ロールを「Primary」、対となるスタンバイDRPGのリージョンとして大阪リージョンを指定します。続けて大阪リージョンに切り替え、ロールを「Standby」としたスタンバイDRPGを作成し、東京側のプライマリDRPGと関連付けます。

4-3. moving computeをメンバーとして追加

東京リージョンのプライマリDRPGに、対象のComputeインスタンスをmoving配置でメンバーとして追加します。§3-2で扱った通り、moving配置ではスタンバイリージョン側にあらかじめインスタンスを作成しておく必要はありません。スイッチオーバー実行時に、FSDRがスタンバイリージョン側でのインスタンス作成までを含めて処理します。

4-4. スイッチオーバープランの自動生成

DRPGのメンバー構成が完了したら、DR Planの作成画面から「Switchover」プランを選択し、自動生成機能を使ってプランを生成します。FSDRは、DRPGに登録されたメンバー構成をもとに、必要なステップ(インスタンスの起動・停止、DNS更新等)を自動的に組み立てたプランドラフトを生成します。§3-4で扱ったようなユーザー定義ステップが必要な場合は、この自動生成されたプランに対して手動でステップを追加します。本記事の最小構成では、追加のユーザー定義ステップなしで進めます。

4-5. プリチェックの実行

プランの実行前に、プリチェックを実行します。プリチェックは、DR Planに含まれる各ステップが正常に実行できる状態かどうかを事前に検証するもので、実際のスイッチオーバーとは異なり、稼働中のサービスに影響を与えません。プリチェックの結果が全てPASSであることを確認してから、次章のスイッチオーバー実行に進みます。

5. スイッチオーバー実行と検証

5-1. スイッチオーバーの実行

プリチェックが全てPASSしていることを確認したら、DR Planの実行画面から「Execute」を選択し、Switchoverプランを実行します。実行が始まると、東京リージョン(プライマリ)側のComputeインスタンスの停止処理、大阪リージョン(スタンバイ)側での新規インスタンス起動処理が、プランに定義された順序で自動的に進行します。

5-2. 進捗・ログの確認

実行中は、DR Planの実行画面でステップごとの進捗状況(実行中・成功・失敗・警告付き成功等)をリアルタイムに確認できます。各ステップの詳細ログも同じ画面から確認可能です。

5-3. AI生成ログサマリー(2026年5月GA)

2026年5月15日にGAした機能として、失敗(Failed)・失敗を無視(Failed ignored)・警告付き成功(Succeeded with warning)のいずれかで終了したステップに対して、「View Summary」からAI生成ログサマリーを確認できます。この機能はOCI Generative AI serviceを使い、詳細な実行ログを簡潔な平易な言葉で要約し、エラー内容と推奨アクションを素早く把握できるようにするものです。

公式ドキュメントで確認した範囲では、この機能はbuilt-in(組み込み)のDR Planステップ(built-inプリチェックステップを含む)を対象としており、§3-4で扱ったようなユーザー定義ステップは対象外です。PostgreSQLのCold DR統合と同様、ユーザー定義ステップを多く含むDR Planでは、AI生成ログサマリーの恩恵はbuilt-inステップの部分に限られます。この点に留意してください。

5-4. スイッチバック

検証が完了したら、逆方向(大阪→東京)のSwitchoverプランを実行し、元の構成に戻します。スイッチバックの手順は、ロールが入れ替わったDRPGに対して同様のSwitchoverプランを作成・実行する形になります。

5-5. 後片付けと課金停止

検証を終えたら、DRPGのメンバーから外したComputeインスタンス、moving配置で新規作成されたリソースが残っていないかを両リージョンで確認し、不要なリソースを削除してください。§2-6で扱った通り、DRPGにメンバーとして残っているリソースは、たとえ停止状態であってもFSDR料金が発生し続けます。検証終了後は、DRPGメンバーからの削除、またはDRPG自体の削除まで含めて後片付けを行うことをおすすめします。

6. まとめ・落とし穴チェックリスト

本記事では、AWSでElastic Disaster Recovery(DRS)・Resilience Hubの実務経験を持つ読者を主読者に、OCI Full Stack Disaster Recoveryの課金モデル・概念設計・ネイティブ保護対象の境界、そして東京⇔大阪の最小構成でのスイッチオーバー実行までを、公式ドキュメントの一次情報に基づいて解説しました。最後に、実務で陥りやすい落とし穴を4点、チェックリストとして整理します。

FSDRは、「Full Stack」という名前の印象とは裏腹に、ネイティブに保護できる対象が明確に限定されたオーケストレーションサービスです。この境界を正直に理解したうえで導入すれば、対応リソースについては東京⇔大阪の広域冗長化を効率よく実装でき、非対応リソースについても、各サービスのネイティブDR機能との組み合わせという現実的な設計に落とし込めます。本記事で扱った境界の理解を土台に、実際のワークロードに合わせたDR設計を検討してみてください。

→ OCI Database with PostgreSQL実践Vol1(Warm StandbyによるDBネイティブDR)を読む

→ OCIネットワーク実践(Production編)Vol1(Flexible LB/NLB・DRGルーティング)を読む

→ OCI入門Vol1(テナンシ・コンパートメント・リージョンとAlways Free枠)を読む