OCI Database with PostgreSQL実践Vol1 RDS対比と東京大阪DR

1. この記事について — なぜOCI Database with PostgreSQLか

1-1. 本記事のゴール

本記事のゴールは、AWSのRDS/Aurora PostgreSQLでの実務経験を持つ読者が、OCI Database with PostgreSQLの料金構造・制約・接続設計・DR設計を実務レベルで理解し、実際に手を動かして最小構成のDBシステムを作成し、psqlで接続してデータ操作までを一気通貫で体験できることです。加えて、2026年6月にGAしたReplication with Warm Standbyを使い、東京リージョンと大阪リージョンをまたいだDR構成を組むところまでを扱います。

Database with PostgreSQLはAlways Free対象外のサービスであるため、本記事は30日間$300の無料トライアルクレジットを前提にハンズオン構成を組んでいます。トライアルクレジットの範囲内であれば、DBシステムの作成からWarm Standbyの検証まで、実質無課金で完走できる設計にしています。具体的な料金試算は§2で詳しく扱います。

すでに有償枠(Pay As You Go)のテナンシを運用している場合も、本記事のハンズオン規模であれば数ドル程度の課金で完走できるよう、最小構成での検証手順を採用しています。トライアルクレジットの有無にかかわらず、安心して手を動かせる構成を心がけました。

読み終える頃には、「なぜOCIのPostgreSQLサービスだけがAlways Free対象外なのか」「private subnet必須という制約が接続設計にどう影響するのか」「Warm Standbyの自動フェイルオーバー非対応という仕様が運用設計にどう跳ね返るのか」の3点について、公式ドキュメントの一次情報に基づいて答えられるようになっているはずです。

本記事で扱う数値・GA日付・仕様は、すべて公式ドキュメントおよびOracle公式Price List API(cetools)の一次情報に基づいています。独自に数値を作成したり、未確認の推測を事実として記載したりすることはしません。不明な点や実機検証が必要な箇所については、その旨を明示したうえで記述します。

1-2. 読者像 — RDS/Aurora PostgreSQL実務者

本記事が主に想定しているのは、AWSでRDS for PostgreSQLまたはAurora PostgreSQLの構築・運用経験を持つエンジニアです。RDS/Auroraでの「インスタンスクラス課金」「Multi-AZ配置」「リードレプリカ」「自動フェイルオーバー」といった概念に馴染みがある方であれば、OCI Database with PostgreSQLの仕組みは、共通点と相違点の両方が見えてくることで、より深く理解できる構成にしています。

一方で、OCIの利用自体が初めての方や、VCN・サブネットといったネットワーク基礎から確認したい方は、まず「OCI入門」シリーズVol3(VCN・サブネット・ゲートウェイ)を読んでから本記事に戻ることをおすすめします。本記事は、VCN・プライベートサブネットの基礎知識を前提として進めます。

RDS/Aurora実務者が本記事を読むことで得られる最大の価値は、「OCIのデータベース系サービスは基本的にAlways Freeが手厚い」という、他のOCI系記事から抱きがちな印象が、Database with PostgreSQLには当てはまらないという事実を、料金モデルの違いとあわせて正確に把握できる点です。

RDS/Aurora実務者がOCIのDatabase with PostgreSQLを検討する場面としては、既存ワークロードのマルチクラウド展開、Oracle Cloudクレジットの有効活用、あるいは東京・大阪という国内2リージョンでのDR要件を満たしたいといった動機が想定されます。いずれのケースでも、まず気になるのは「AWSでの構築・運用経験がどこまで通用するか」という点でしょう。本記事は、この問いに対して、共通する部分(psql・拡張機能・レプリケーションといったPostgreSQL自体の作法)と、異なる部分(課金モデル・ネットワーク制約・DRの切り替え方式)を明確に切り分けて説明することを心がけています。

1-3. 用語整理 — Database with PostgreSQLとDatabase Optimized Storage

OCIのPostgreSQLサービスは、正式名称を「OCI Database with PostgreSQL」といいます。「OCI PostgreSQL」「OCI Postgres」といった略称でも文脈上は通じますが、本記事では公式の正式名称に準拠して「Database with PostgreSQL」または「本サービス」と表記します。

もう1つ押さえておきたい用語が「Database Optimized Storage」です。これは、Database with PostgreSQL専用に最適化されたストレージオプションで、料金体系上もコンピュート(OCPU時間課金)とは別建てで課金される、独立した課金項目です。RDS/Auroraの感覚でいうと、gp3ストレージやAuroraストレージに近い概念です。ただし課金単位や性能特性はOCI独自の設計であるため、既存のAWSストレージ課金の感覚をそのまま持ち込まないよう注意してください。詳細な料金試算は§2-2で扱います。

RDS/Aurora実務者が本記事を読み進める際に、頭の中でAWSの用語と対応付けながら読めるよう、主な用語の対応イメージを整理しておきます。あくまで概念的な近さを示す対応であり、課金単位や機能範囲まで完全に一致するわけではない点に注意してください。

1-4. 既刊OCIシリーズとの役割分担

本記事は「OCI Database with PostgreSQL実践」シリーズの第1弾ですが、OCIのデータベース系サービスとしては、既刊の「OCI Autonomous Database実践」シリーズおよび「OCI MySQL HeatWave実践」シリーズに続く3本目のデータベース実践記事です。3記事はいずれもOCIのマネージドデータベースを扱いますが、対象サービスと差別化軸はそれぞれ完全に独立しています。

この役割分担が成立する理由は単純で、3サービスは搭載しているデータベースエンジンそのものが異なります。Autonomous DatabaseはOracle Database、MySQL HeatWaveはMySQL、そしてDatabase with PostgreSQLはPostgreSQLと、エンジンレベルで完全に別物です。AWSでいえば、Autonomous Database(Oracle独自エンジン)をAuroraのような独自最適化エンジンに見立てると、Aurora・RDS for MySQL/Aurora MySQL・RDS for PostgreSQL/Aurora PostgreSQLがそれぞれ別サービスであるのと同じ感覚で捉えると理解しやすいはずです。

なぜ3本目のデータベース実践記事が必要かといえば、PostgreSQLというエンジンそのものが、AWS実務者にとって最もなじみ深いOSSデータベースだからです。RDS for PostgreSQLやAurora PostgreSQLを本番運用している組織は多く、その実務者がOCIへの展開やマルチクラウド構成を検討する際、最初に探すのはOracle独自エンジンやMySQLではなく、PostgreSQL互換のマネージドサービスであるはずです。この需要に対して、既刊2シリーズはいずれも答えを持っていませんでした。本記事は、その空白を埋める位置づけです。

日本語圏での競合状況を見ても、Database with PostgreSQLの単発の作ってみた記事(フェイルオーバー挙動確認・拡張機能利用・private subnet接続など)は存在するものの、RDS/Aurora PostgreSQL対比軸に2026年の新機能(PG17・stop-start・Warm Standby・Query Insights)、料金試算、接続設計までを通した体系的な実践記事は、本記事執筆時点では見当たりません。この空白が、本記事が3本目のデータベース実践記事として書かれる理由です。

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

本記事は、DBシステムの作成からpsql接続、拡張機能の利用、そしてWarm StandbyによるクロスリージョンDR構成までを扱います。一方で、DBシステムを配置するVCN・プライベートサブネットの構築手順そのものは「OCI入門」シリーズVol3、接続に使うCompute VMの作成手順は同シリーズVol4、より安全な踏み台レス接続の手段としてのBastionは「OCIセキュリティ実践」シリーズVol1に委譲し、本記事では重複させずに接続・データ操作・DR設計の実践深度に集中します。

この委譲構成により、本記事はネットワーク基礎の再解説に紙面を割かず、Database with PostgreSQL固有のトピックにより多くの分量を割いています。

また、Warm Standbyで扱うのはあくまでデータベース単体のDR(データベースエンジンレベルのレプリケーションとフェイルオーバー)です。アプリケーション層・ロードバランサー・DNS切り替えまでを含めた「スタック全体」のディザスタリカバリ設計については、本記事では扱わず、今後公開予定の「Full Stack Disaster Recovery実践」に委ねます。本記事はデータベースネイティブなDRの土台を作る記事、Full Stack Disaster Recovery実践はその土台の上にアプリケーション全体のDRを組む記事、という棲み分けです。

同様に、Kubernetes(OKE)からの接続やTerraformによるIaC化といった、より発展的なトピックも本記事の範囲外です。本記事はあくまでコンソール操作を軸にしたハンズオンとして、Database with PostgreSQLというサービス自体の理解に焦点を絞っています。

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

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

本記事は、料金モデルと制約を理解しないまま先にハンズオンへ進むと、想定外の課金や接続トラブルに直面しやすい構成です。そのため、まず課金モデル・制約の整理を読んでから、ハンズオンへ進む構成としています。既にAWSでPostgreSQLの実務経験が豊富で、料金モデルの違いだけを素早く確認したいという方は、課金モデルの章を重点的に読み、ハンズオンの手順は必要な部分だけをつまみ読みする、という読み方でも問題ありません。

一方、東京⇔大阪のクロスリージョンDR設計に主眼がある方は、DBシステム作成・接続の基本を一通り押さえたうえで、Warm Standbyを扱う章を重点的に読むことをおすすめします。DR設計は、単体のDBシステムの挙動を理解していないと判断を誤りやすい領域のため、順を追って読み進めることをおすすめします。

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

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

OCIのデータベース系サービスを何本か触ったことがある方ほど、「OCIのデータベースはAlways Freeが手厚い」という印象を持ちやすいのですが、Database with PostgreSQLに限ってはこの前提が成立しません。本章では、まずこの前提の違いを正面から確認したうえで、具体的な料金試算・RDS/Aurora対比・接続やバージョンに関する制約を整理します。有償が前提のサービスだからこそ、手を動かす前に課金モデルを正確に理解しておくことが、本記事のハンズオンを安全に進めるうえで欠かせません。

2-1. Always Free対象外という前提

OCIの公式Free Tierドキュメント(取得日: 2026年8月10日)によれば、Always Free枠の対象となるデータベース系サービスは、Autonomous AI Database・NoSQL Database・MySQL HeatWaveの3種類のみです。Database with PostgreSQLは、このAlways Free対象リストに含まれていません。

「OCI Autonomous Database実践」シリーズや「OCI MySQL HeatWave実践」シリーズを先に読んだ読者ほど、この対象外という事実に驚くかもしれません。AWSの感覚に置き換えると、RDS無料利用枠(12か月間の時間制限付き無料枠)に近いものをOCIのDatabase with PostgreSQLに期待してしまいがちですが、そのような無料枠は存在せず、作成した瞬間から課金が発生する前提でハンズオンを設計する必要があります。

なお、Database with PostgreSQL自体のサービス提供は、2023年11月にGAし、東京・大阪の両リージョンでも同時期に提供が開始されています。リージョン提供自体は日本国内の2リージョンで既に確立されており、Always Free対象外という制約は、あくまで無料枠の有無に関する話であって、リージョン提供状況の話ではない点を区別して理解してください。

2-2. 料金試算 — OCPU時間課金とストレージ課金の2階建て

Database with PostgreSQLの料金は、コンピュート(OCPU時間課金)とDatabase Optimized Storage(GB/月課金)の2階建てで構成されています。以下は、Oracle公式Price List API(cetools、USD PAYG単価、取得日: 2026年8月10日)で確認した単価です。

この2つの単価をもとに、最小構成での概算を試算してみます。最小1ノード・2 OCPU構成の場合、コンピュート課金は2 OCPU × $0.098/OCPU/hr = 約$0.196/時間です。これに加えて、Database Optimized Storageの課金が別途発生します。仮に最小構成のストレージを使う場合でも、GB単位の月額課金がコンピュート課金に上乗せされる点は見落とさないようにしてください。

本記事§3のハンズオンのように、数時間程度DBシステムを起動して検証を終える場合、コンピュート課金は$1未満に収まります。ストレージ課金は月額換算のため、数時間の検証であれば日割り・時間割りで見ればごくわずかです。§5で扱うWarm Standbyの検証では、プライマリ・スタンバイの2システムを稼働させることになるため、単純計算で課金がおおよそ倍になりますが、それでも数ドル規模に収まる試算です。30日間$300のトライアルクレジットの範囲内であれば、本記事のハンズオンをすべて無課金で完走できます。

検証シナリオ別に、コンピュート課金の目安を整理すると次の通りです(いずれも2 OCPU構成・ストレージ課金は別途)。

この試算からも分かる通り、本記事のようなスポットでの検証であれば、コンピュート課金だけを見ればごくわずかな金額に収まります。一方で、常時稼働を前提とした本番運用を検討する場合は、1ヶ月あたりの参考値のように、コンピュート課金だけでも相応の金額になる点を踏まえて予算計画を立ててください。

参考として、OCPU数を変えた場合の月額コンピュート課金の目安も整理しておきます(いずれも常時稼働・ストレージ課金は別途)。

この試算はコンピュート課金のみの単純計算であり、Database Optimized Storageの課金は含んでいません。実際のサイジングを検討する際は、想定データ量に応じたストレージ課金もあわせて見積もってください。RDS/Auroraでインスタンスクラスごとの月額を試算してきた読者であれば、同じ要領でOCPU数から月額の目安を逆算できます。

この対比から分かる通り、RDS(無料利用枠あり)とAurora(無料利用枠なし)で課金の前提が分かれるAWSに対し、OCIのDatabase with PostgreSQLは「常に課金対象」という一貫した前提である点が特徴です。RDSの無料利用枠に慣れている読者ほど、この違いを事前に理解しておくことが重要です。

2-3. 接続に関する制約 — private subnet必須・IPv6非対応

Database with PostgreSQLには、接続方式に関わる重要な制約が2つあります。1つ目は、パブリックエンドポイントが提供されないという制約です。DBシステムは必ずプライベートサブネットへ配置する仕様であり、インターネットから直接psql接続できません。2つ目は、IPv6サブネットに対応していないという制約です。VCN・サブネットをIPv6デュアルスタックまたはIPv6シングルスタックで構成している場合、Database with PostgreSQLのDBシステムをそのサブネットには配置できません。

この制約は、AWSのRDS/Auroraで「パブリックアクセス可能」設定を選んだ経験がある読者にとっては、やや窮屈に感じられるかもしれません。RDSでは、開発環境限定でパブリックサブネットに配置し、セキュリティグループでアクセス元を絞るという運用も選択肢として存在しますが、Database with PostgreSQLではその選択肢自体が存在せず、必ず何らかの踏み台(Compute VMまたはBastion)を経由した接続設計が前提になります。この接続方式の具体的な手順は§4で扱います。

見方を変えると、この制約はAWSの「VPCのプライベートサブネットにRDSを配置し、踏み台やVPN経由でのみ接続を許可する」という、セキュリティ観点で推奨されることの多い設計パターンを、選択肢としてではなく仕様として強制している構成だとも捉えられます。パブリックサブネットへの誤配置によるセキュリティインシデントのリスクという観点では、この制約はむしろ安全側に倒れた設計であるとも言えます。一方で、開発初期の検証段階でとにかく素早く接続確認をしたいというケースでは、踏み台の準備が必須になる分、初動の手間が増える点はデメリットとして意識しておいてください。

2-4. 対応バージョン — PostgreSQL 14〜17

Database with PostgreSQLが対応するPostgreSQLのメジャーバージョンは、本記事執筆時点でPostgreSQL 14から17までです。公式リリースノートによれば、2026年4月29日にPostgreSQL 17への対応が追加されており、比較的新しいメジャーバージョンまで追随しています。

RDS for PostgreSQLもAurora PostgreSQLも同様にメジャーバージョンを複数サポートしていますが、OCIのDatabase with PostgreSQLも2025年から2026年にかけて継続的に新バージョン・新拡張機能を追加しており、サービスとしての活発さがリリースノートから読み取れます。DBシステム作成時にバージョンを選択できるため、既存のPostgreSQLワークロードとの互換性を確認したうえで、適切なバージョンを選んでください。

バージョン対応以外にも、直近1年間のリリースノートを見ると、Database with PostgreSQLは継続的に機能追加が行われているサービスであることが分かります。

この更新頻度からも分かる通り、Database with PostgreSQLはメンテナンスモードや新規受付終了とは無縁の、積極的に機能拡張が続けられているサービスです。特に2026年6月16日には、Query Insights(パフォーマンス分析)・Kerberos認証・stop-start・Warm Standbyという4つの機能が同時に追加されており、この日を境にサービスの実用度が大きく上がったといえます。本記事の差別化軸の1つも、この2026年6月以降の新機能を体系的に扱う点にあります。

なお、Query Insights・Kerberos認証については、本記事では概要の紹介にとどめ、深掘りは扱いません。Query Insightsはクエリレベルのパフォーマンス分析機能で、RDS Performance Insightsに近い位置づけの機能です。Kerberos認証は、既存のKerberos認証基盤を持つ組織がDatabase with PostgreSQLに接続する際の認証方式の選択肢として追加されたものです。いずれも本記事の主眼であるRDS/Aurora対比・課金モデル・DR設計とは別軸の機能であるため、必要な場合は公式ドキュメントを別途参照してください。

2-5. 拡張機能とレプリケーション機能の概要

§2-4で触れた通り、Database with PostgreSQLはpg_cron・pgaudit・pglogical・PostGISといった主要な拡張機能に対応しています。これらの拡張機能の具体的な有効化手順は§4で扱いますが、AWSのRDS/Aurora PostgreSQLで同名の拡張機能を利用してきた読者であれば、概ね同様の感覚で利用できる設計になっています。

また、reader endpoint・read replicaといった読み取り分散の仕組みも提供されています。詳細な構成方法は§4で扱いますが、RDS/Auroraのリードレプリカに相当する機能がOCI側にも用意されている点は、読み取り負荷分散を検討するうえで押さえておきたいポイントです。

2-6. Warm Standbyの概要 — 詳細は§5で

Database with PostgreSQLには、2026年6月16日にGAした「Replication with Warm Standby」という機能があります。これは、テナンシがサブスクライブしている任意のリージョン間でレプリケーション構成を組める機能で、東京リージョンと大阪リージョンのような国内2リージョン間でのDR構成にも利用できます。詳細な構成手順・RPOのSLO・フェイルオーバーの仕様は§5でまとめて扱いますが、本章では「有償のDBシステムに、有償のDR機能が追加された」という位置づけだけ押さえておいてください。

2-7. よくある誤解 — AWS実務者が陥りやすいポイント

ここまでの内容を踏まえ、RDS/Aurora PostgreSQLの実務経験を持つ読者が抱きやすい誤解を整理します。

誤解1: OCIのデータベースは基本的にAlways Freeで試せるはず

「OCI Autonomous Database実践」や「OCI MySQL HeatWave実践」を先に読んだ読者ほど陥りやすい誤解です。§2-1で見た通り、Database with PostgreSQLはAlways Free対象外であり、作成した瞬間から課金が発生します。

誤解2: RDSの無料利用枠(12か月間)に相当するものがあるはず

かつてRDSには12か月無料利用枠があったが、2025年7月以降の新規AWSアカウントはクレジット制に移行済みです。いずれにせよDatabase with PostgreSQLには期間限定無料枠自体が存在しません。無課金で試したい場合は、30日間$300のトライアルクレジットを使う前提になります。

誤解3: パブリックサブネットに配置して直接インターネットから接続できるはず

RDSではパブリックアクセス可能な配置も選択肢として存在しますが、§2-3で見た通り、Database with PostgreSQLはパブリックエンドポイントを提供せず、必ずプライベートサブネットへの配置が前提です。

誤解4: Warm StandbyもAurora Global Databaseと同様に自動フェイルオーバーするはず

§5で詳しく扱いますが、Warm Standbyは自動フェイルオーバーに対応しておらず、手動でのpromote操作が前提です。Aurora Global Databaseの感覚をそのまま持ち込むと、運用設計を誤る可能性があります。

これら4つの誤解に共通するのは、「他のOCIデータベース系サービスやAWSの類似サービスで得た知識を、そのままDatabase with PostgreSQLに当てはめてしまう」という点です。本記事のここまでの内容を踏まえておけば、これらの誤解にはまることなく、次章のハンズオンへ進めるはずです。

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

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

• Database with PostgreSQLがAlways Free対象外であることを理解し、トライアルクレジットまたは有償枠での検証である前提を持てたか(§2-1)
• コンピュート(OCPU時間課金)とDatabase Optimized Storage(GB/月課金)の2階建て課金であることを理解したか(§2-2)
• DBシステムを配置するVCN・サブネットがIPv4であり、IPv6デュアルスタック/シングルスタックではないことを確認したか(§2-3)
• パブリックエンドポイントが提供されないため、Compute VMまたはBastion経由の接続設計が必要であることを理解したか(§2-3)
• 利用したいPostgreSQLのメジャーバージョン(14〜17)を決めたか(§2-4)
• DBシステムを配置するVCN・プライベートサブネットを準備済みか(§3で必要になります)

これらの項目にすべて問題がなければ、Database with PostgreSQLのDBシステム作成に進む準備が整っています。

次章では、実際にOCIコンソールを操作して最小構成のDBシステムを作成し、stop-start機能を使った課金制御までを見ていきます。

3. DBシステム作成ハンズオン

本章では、実際にOCIコンソールを操作して、最小構成のDBシステムを作成します。§2で整理した通り、Database with PostgreSQLはAlways Free対象外のため、ここから先の操作にはトライアルクレジットまたは有償枠での課金が発生する前提で進めます。

3-1. 事前準備 — VCN・プライベートサブネット

DBシステムの作成には、あらかじめVCNとプライベートサブネットが必要です。§2-3で確認した通り、Database with PostgreSQLはパブリックエンドポイントを提供しないため、DBシステムを配置するサブネットは必ずプライベートサブネットにしてください。VCN・プライベートサブネットの作成手順自体は、「OCI入門」シリーズVol3で詳しく扱っているため、本記事では割愛します。まだVCN・サブネットを準備していない場合は、先にそちらを参照してください。

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

3-2. 最小構成の設計 — 1ノードFlexシェイプ

本記事のハンズオンでは、コストを抑えるため、最小構成の1ノードFlexシェイプでDBシステムを作成します。Flexシェイプでは、OCPU数を柔軟に選択でき、§2-2で試算した通り、2 OCPU程度の最小構成であれば時間課金を抑えつつハンズオンを進められます。ストレージについても、検証に必要な最小限のサイズを選択してください。

RDS/Auroraでインスタンスクラスを選ぶ感覚に近いですが、OCIのFlexシェイプはOCPU数を1単位から柔軟に指定できる点が特徴です。本番相当のサイジングを検討する段階になったら、想定ワークロードに応じてOCPU数・ストレージサイズを見直してください。

3-3. 作成ダイアログの操作

コンソールでDBシステムの作成ダイアログを開き、以下の項目を設定します。

すべての項目を設定したら、作成します。DBシステムのプロビジョニングには数分から十数分程度の時間がかかります。

3-4. プロビジョニング確認

作成すると、DBシステムの状態が「プロビジョニング中」から「使用可能」に変わるまで、コンソール上でステータスを確認できます。状態が「使用可能」になれば、§4で扱う接続作業に進める状態です。

3-5. stop-start機能による課金制御

2026年6月16日に追加されたstop-start機能を使うと、DBシステムを一時的に停止(INACTIVE)状態にでき、その間はコンピュート課金が発生しません。ハンズオンの合間や検証を中断するタイミングでこの機能を使うことで、Database Optimized Storageの課金は継続するものの、コンピュート課金部分を抑えられます。

RDS/Auroraにも「一時停止」機能はありますが、停止できる期間に制限がある(自動的に再開される)点はOCIとの違いとして意識しておくとよいでしょう。本記事のハンズオンでは、検証を終えたタイミングでstop-start機能を使い、コンピュート課金を抑えることをおすすめします。

4. 接続とデータ操作

§2-3で確認した通り、Database with PostgreSQLはパブリックエンドポイントを提供しないため、接続には何らかの踏み台が必要です。本章では、Compute VM経由の接続とBastionサービス経由の接続の2通りを扱ったうえで、拡張機能の有効化とreader endpoint/read replicaについて整理します。

4-1. Compute VM経由のpsql接続

最もシンプルな接続方法は、同一VCN内のプライベートサブネットまたはパブリックサブネットにCompute VMを作成し、そのVM上からDBシステムのプライベートIPに対してpsqlコマンドで接続する方法です。Compute VMの作成手順自体は「OCI入門」シリーズVol4で扱っているため、本記事では割愛します。

← OCI入門 Vol4(コンピュート・Always Free枠)を読む

Compute VM上にpsqlクライアントをインストールしたうえで、DBシステム作成時に設定した管理者ユーザー名・パスワードを使い、DBシステムのプライベートIPとポート(デフォルト5432)を指定して接続します。RDS/Auroraで、踏み台EC2からpsqlで接続する運用に慣れている読者であれば、感覚的にはほぼ同じ手順です。

4-2. Bastion経由のセッション接続

Compute VM経由の接続は、常時起動する踏み台サーバーが必要になる点がやや重い運用です。より踏み台レスに近い接続方法として、OCI Bastionサービス経由のセッション接続があります。Bastionサービスの詳しい仕組みとセッション接続の手順は、「OCIセキュリティ実践」シリーズVol1で扱っているため、本記事では概要のみ紹介します。

→ OCIセキュリティ実践Vol1(Bastionによる踏み台レス接続)を読む

Bastionサービスを使う場合、DBシステムのプライベートIP・ポートに対するポートフォワーディングセッションを作成し、ローカル端末からOCI CLIを経由してトンネルを張ることで、常時起動する踏み台サーバーを持たずにpsql接続できます。AWSのSSM Session Managerに近い使い勝手で、検証用途であればCompute VMを都度用意するよりも運用コストを抑えられます。

4-3. 拡張機能の有効化 — pg_cron・pgaudit・pglogical・PostGIS

psql接続ができたら、必要に応じて拡張機能を有効化します。Database with PostgreSQLで利用できる主な拡張機能は、pg_cron・pgaudit・pglogical・PostGISです。

拡張機能の有効化は、psqlで接続した状態から CREATE EXTENSION コマンドを実行して行います。RDS/Aurora PostgreSQLで同名の拡張機能を有効化してきた読者であれば、概ね同様の操作感で利用できます。

4-4. reader endpointとread replica

読み取り負荷を分散したい場合、reader endpointとread replicaの仕組みを利用できます。read replicaを追加すると、書き込みはプライマリのDBシステムへ、読み取りはreader endpoint経由でread replicaへ振り分けることができます。RDS/Auroraのリードレプリカに相当する機能で、読み取り負荷が高いワークロードのスケールアウトに利用します。

read replicaの追加自体もコンピュート課金・ストレージ課金の対象となるため、検証目的で試す場合は、§2-2の料金試算を踏まえたうえで、検証後にread replicaを削除するか、stop-start機能で課金を抑えることをおすすめします。

5. Replication with Warm Standbyで東京⇔大阪DR

本章では、2026年6月16日にGAしたReplication with Warm Standbyを使い、東京リージョンと大阪リージョンをまたいだDR構成を組みます。国内2リージョンでのデータベースDRは、日本国内の読者にとって実務上のニーズが特に高いユースケースであり、本記事の差別化の核となる章です。

5-1. Warm Standbyの概要と要件

Replication with Warm Standbyは、テナンシがサブスクライブしている任意のリージョン間でレプリケーション構成を組める機能です。公式ドキュメントによれば、東京と大阪のように、同一テナンシがサブスクライブしている国内2リージョン間での構成が可能です。利用にはPostgreSQL 14以上のバージョンが要件となります。

5-2. RPOのSLOと運用への影響

Warm StandbyのRPO(目標復旧時点)のSLOは、300秒から10,800秒の範囲で設定でき、デフォルトは300秒です。RPO 300秒とは、障害発生時に最大5分程度のデータ損失が許容範囲として設計されていることを意味します。より長いRPOを許容できるワークロードであれば、10,800秒(3時間)まで緩めることもできます。この値は、レプリケーションの構成方針や、プライマリ・スタンバイ間の帯域・レイテンシとのトレードオフを踏まえて選択してください。

AWSのAurora Global Databaseと比較すると、Aurora Global Databaseの典型的なRPOは1秒未満とされることが多く、Warm StandbyのRPO SLO(デフォルト300秒)はやや緩やかな設計です。国内2リージョン間のDRという用途において、この300秒というRPOが許容できるかどうかは、対象ワークロードの重要度に応じて事前に検討しておく必要があります。

5-3. 自動フェイルオーバー非対応という仕様

Warm Standbyで特に押さえておきたいのが、自動フェイルオーバーに対応していないという仕様です。プライマリリージョンで障害が発生した場合でも、スタンバイへの切り替えは自動的には行われず、運用者が手動でpromoteする必要があります。

AWSのAurora Global DatabaseやRDS Multi-AZ配置では、障害検知から一定時間内に自動でフェイルオーバーする設計が一般的であるため、この「手動promote前提」という仕様は、AWS実務者にとってはやや意外に感じられるかもしれません。運用設計としては、障害検知の仕組み(監視・アラート)と、promoteする運用手順(Runbook)をあらかじめ整備しておくことが、Warm Standbyを実運用で使ううえでの前提になります。

5-4. Switchover/Conversionの使い分け

プライマリ・スタンバイの切り替えには、Switchoverと Conversionの2つの方式があります。Switchoverは、計画的なメンテナンスなどで、プライマリとスタンバイの役割を入れ替える際に使う方式です。両システムが正常に稼働している状態で、役割を安全に入れ替えられます。一方Conversionは、プライマリで障害が発生した場合などに、スタンバイを独立したDBシステムとして昇格させる方式です。

平常時のメンテナンスにはSwitchover、実際の障害対応にはConversionという使い分けが基本方針になります。いずれの方式も手動操作が前提であるため、§5-3で触れた運用手順の整備が欠かせません。

5-5. 課金への影響

Warm Standby構成では、プライマリ・スタンバイの2つのDBシステムがそれぞれ稼働するため、§2-2で試算したコンピュート課金・ストレージ課金がそれぞれのシステムに対して発生します。単純計算では、単一システムの構成に比べて課金がおおよそ倍になります。本記事のハンズオン規模(最小構成・数時間の検証)であれば、それでも数ドル規模に収まるため、トライアルクレジットの範囲内で検証を完走できます。

継続的にWarm Standby構成を本番運用する場合は、プライマリ・スタンバイ双方の稼働時間分の課金が継続的に発生する前提でコストを試算してください。コストの継続的な監視・予算管理については、「OCIコスト管理・ガバナンス実践」シリーズで扱っているBudgetsやCompartment Quotasの活用が参考になります。

→ OCIコスト管理・ガバナンス実践Vol1を読む

5-6. Full Stack Disaster Recovery実践との棲み分け

本章で扱ったWarm Standbyは、あくまでデータベースエンジンレベルのレプリケーションとフェイルオーバーです。実際のシステム全体のDRを考える場合、アプリケーションサーバー・ロードバランサー・DNS切り替えといった、データベース以外のコンポーネントも含めた設計が必要になります。この「スタック全体」のDR設計については、本記事では扱わず、今後公開予定の「Full Stack Disaster Recovery実践」に委ねます。本記事はデータベースネイティブなDRの土台を作る記事、Full Stack Disaster Recovery実践はその土台の上にアプリケーション全体のDRを組む記事、という棲み分けです。

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

本記事では、AWSのRDS/Aurora PostgreSQL実務者を主読者に、OCI Database with PostgreSQLの課金モデル・接続設計・DBシステム作成・データ操作・そしてWarm Standbyによる東京⇔大阪DR構成までを、公式ドキュメントの一次情報に基づいて解説しました。最後に、実務で陥りやすい落とし穴を4点、チェックリストとして整理します。

Database with PostgreSQLは、OCIのデータベース系サービスの中では珍しく「常に課金対象」というシンプルな前提を持つサービスです。この前提さえ正確に理解しておけば、RDS/Aurora PostgreSQLでの実務経験をそのまま活かして、接続設計・拡張機能の利用・クロスリージョンDR設計まで、大きな戸惑いなく扱えるはずです。

東京⇔大阪という国内2リージョンでのデータベースDRを検討している方は、本記事で扱ったWarm Standbyの仕組みを土台に、今後公開予定の「Full Stack Disaster Recovery実践」で、アプリケーション全体を含めたDR設計へと発展させていくことをおすすめします。

→ OCI Autonomous Database実践Vol1(Oracle独自エンジン・Always Free)を読む

→ OCI MySQL HeatWave実践Vol1(分析統合MySQL・Always Free)を読む

→ OCIセキュリティ実践Vol1(Bastion踏み台レス接続)を読む

→ OCIコスト管理・ガバナンス実践Vol1(Budgets×Compartment Quotas)を読む