クラウドインテグレーション事業部の片山です。
2026年10月26日〜28日（現地時間）にラスベガスで開催されたイベント、Oracle AI World 2026に今年も現地参加してきました！

今回は、「How PayPal Built a Multicloud Foundation for Future Innovation」というセッションのレポートをお届けします。

セッション表紙スライド「THR1111: How PayPal Built a Multicloud Foundation for Future Innovation」

セッション概要

本セッションは、PayPalがGoogle Cloud上で運用していたOracle Databaseを、Oracle AI Database@Google CloudのExadata Database Service（ExaDB-D）へ移した事例を紹介するものです。登壇者はPayPalのRaj Kiran Mattewada氏（Database Engineering）と、OracleのArslan Munir氏（Sr. Director, TAM, CSS NA）の2名でした。Munir氏が質問し、Mattewada氏が答える対談形式で、移行の理由、コストの下げ方、移行で得た教訓の順に話が進みました。

登壇者紹介スライド。PayPalのRaj Kiran Mattewada氏（左）とOracleのArslan Munir氏（右）

About PayPal。200以上の国と地域、4億3,900万のアクティブアカウントを持ち、決済・リスク・元帳の中核をOracle Databaseが支える。右側は利用しているOracleの製品とサービスの一覧

冒頭ではPayPalの規模が紹介されました。200以上の国と地域でサービスを提供し、アクティブアカウントは4億3,900万、2025年の決済総額は1.79兆ドルです。その決済・リスク・元帳の中核システムをOracle Databaseが支えています。利用製品にはExadata、Data Guard、GoldenGate、RAC、Oracle Dynamic Scalingなどが並び、移行のあいだはOracleのCustomer Success Services（CSS）が伴走したと語られていました。

セッション内容：作り直さずに移し、DRは小さく持つ

1. なぜ移行したのか：単体構成の限界とRAC

Oracle AI Database@Google Cloudの構成。Google Cloudのリージョン内に、OCIが管理するExadataのインフラが置かれる（図中の旧名称「Oracle Database@Google Cloud」は現在の「Oracle AI Database@Google Cloud」）
（画像出典：Oracle AI Database@Google Cloud https://www.oracle.com/cloud/google/oracle-database-at-google-cloud/ ）

Mattewada氏によると、Google Cloud上のDBの一部は、1台のサーバーに1つのDBを載せた単体構成でした。この構成で困っていたことは3つあったと語られていました。

  1. サーバー障害がそのままDB停止になる：止まればDRサイトへ切り替えるしかない
  2. パッチ適用のたびにDRへ切り替える：メンテナンスの時間枠も限られている
  3. ストレージ容量・I/O・可用性をそろえにくい：DBの成長に合わせて伸ばし続けるのが難しくなっていた

そこで、同じGoogle Cloudの中で使えるExadataを選び、2ノードのRACにしました。1ノードが落ちても残りのノードが処理を引き継ぎ、パッチは片方のノードずつ当てられます。可用性とパッチ適用の悩みが、構成の変更だけで解消したと語られていました。

これは移行先を決めるときの判断軸として使えると感じました。(1)サーバー1台の障害を許容できるか、(2)パッチのたびにDRへ切り替える運用を続けられるか、(3)I/Oとストレージの伸びしろが足りているか、(4)RACが必要か。いずれかで「No」が出るなら、Exadataのようにインフラ側で冗長化と性能を持つ選択肢を検討する価値があります。

2. 移行手順：Data Guardで作り直さずに切り替える

Migration Approach: Oracle Data Guard Lift and Shift。左が移行の5ステップ、右が手順書（ランブック）から得た教訓

移行はData Guardを使って今のDBをそのまま移す「Lift and Shift」方式で、スライドでは「再現性があり、DBの作り直しが要らない経路」と紹介されていました。手順は次の5段階です。

  1. Google Cloud上の既存DBをプライマリのまま動かす
  2. OCI側に2ノードRACのスタンバイを作る
  3. さらに小さな構成のDR用スタンバイを用意する
  4. Data Guardでスイッチオーバーする（RPOは1分未満）
  5. 1週間安定稼働を確認してから、旧環境を廃止する

所要期間は1DBあたり2〜2.5週間です。また、従来の3コピー構成を2コピー構成に置き換えたことも示されていました。DBの数が多くても、同じ手順を繰り返して移していけるところがこの方式の強みです。

3. DRは小さく持ち、Dynamic Scalingで広げる

通常、DRは本番と同じ規模で用意します。PayPalはコストを抑えるため、DR側を小さな構成（Lean DR）にしました。客席からは「RACの本番から小さなDRへ切り替えたら、性能が足りないのでは」という質問が出ました。

これに対する答えがOracle Dynamic Scalingです。負荷に応じてCPUを自動で増減するツールで、切り替え前にスケールアップしておくことも、切り替え後に負荷を見ながら広げることもできます。スケールの操作はオンラインで行えて、処理中のトラフィックには影響しなかったと語られていました。普段トラフィックが来ないDR側には、気兼ねなくパッチを当てられるという利点もあります。

本番側でも使い方は同じです。以前の環境ではCPUを固定量で確保していて、毎月同じ費用がかかっていました。移行後は、1日のうち負荷の高い時間帯だけ広げることで、CPUの費用を大きく下げられたそうです。「一度設定すれば、あとは何もしなくていい。何度もテストした」という言葉が印象的でした。

なお、Oracle Dynamic Scalingは今回の新機能ではありません。ExaDB-DとExadata Cloud@Customerを対象に以前から提供されているツールで、ECPUのスケーリングはオンラインで行えると管理者ガイドに書かれています。

4. 移行後の効果：4つの数字

Efficiency Gains and Dynamic Scaling。ストレージと費用、Dynamic Scaling、コミット遅延、ホスト効率の4つの効果を割合で示す

移行後の効果は、スライドで「丸めた、傾向を示す数字」として割合だけで示されていました。

  • ストレージと費用：ストレージ約47%削減、ランレートの費用約55%削減
  • Dynamic Scaling：18件のテストすべてに合格し、ECPU時間を最大約55%減らせる見込み
  • コミット遅延：約99.8%短縮し、待機イベントの上位から競合が消えた
  • ホスト効率：ホストCPU約42%削減。RACのプライマリを適正な大きさにした

施策ごとの内訳や測定条件、絶対値は示されていないので、他の環境で同じ割合になるとは限りません。それでも、移行の効果をどの指標で説明すればよいかの参考になると感じました。

5. 5つの教訓と、質疑で出た監視の話

Key Take Aways。ほかのOracleユーザーに伝えたい5つの教訓

まとめのスライドでは、「ほかのOracleユーザーに伝えたいこと」として次の5つが挙げられていました。

  1. Data GuardはOCIへの低リスクな移行経路：DBの作り直しは必要なかった
  2. Data Guard Brokerは明示的に計画する：OCIでは、スタンバイを作る段階で手作業の設定が必要になる
  3. TCPSとwalletの標準手順を早めに作る：初回のつまずきをOracle Supportと一度解消すれば、あとはその手順を使い回せる
  4. 需要が来る前にDynamic Scalingを試す：テストでは、ダウンタイムなしでECPU時間を大きく減らせる見込みが確認できた
  5. 最初の移行で手順書を作る：直したことを毎回記録すれば、2本目以降の移行が速くなる

Exadata Database ServiceでData Guardのスタンバイを追加する「Add standby」画面
（画像出典：Oracle AI Database@Google Cloud ドキュメント「Exadata Database」 https://docs.oracle.com/iaas/Content/database-at-gcp/gcpbc-business-continuity-hadr-exadata-database.html ）

スタンバイ自体はOCIコンソールの「Add standby」画面から追加できますが、Brokerには手作業の設定が残る、というのが2の趣旨です。移行手順のスライド（写真5）の右側には、運用操作をdbaascliとdbcactlにそろえること、GoldenGateが依存するACFSの扱い、監視ツールをOCI側のホストに対応させることも挙がっていました。

質疑では監視ツールが話題になりました。OCIの監視機能やEnterprise Managerも使えますが、PayPalはアプリからDBまでのフリート全体を1つのツールで見るため、サードパーティの監視サービスを使っているそうです。注意点として、Dynamic Scalingでスケールしている間はメトリクスが途切れ、グラフが平らになると語られていました。回避策はあるとのことで、導入前に監視側の挙動を確かめておくべき点だと感じました。

おわりに

以上、「How PayPal Built a Multicloud Foundation for Future Innovation」に現地参加してのセッションレポートをお届けしました。

誰もが知る決済大手の事例から、移行の動機と手順、コストの下げ方、運用でつまずいた点まで、実際に移した人の言葉で聞くことができました。Data Guardで今のDBをそのまま移せば、大きな作り直しをせずに、同じクラウドの中で基盤だけを替えられる。その現実的な道筋を示した事例だと感じます。

弊社はOCIとGoogle Cloudの両方を支援しているので、「Google Cloud上のOracleを止めずに強くしたい」という相談には、Oracle AI Database@Google Cloudが有力な選択肢になり得ると考えています。そういったお引き合いをいただいた際は、お客様への提案に活かしていきたいと思います。

なお、同じPayPalからは、複数クラウドにまたがって止まらないDBを扱ったセッションにも登壇がありました。詳細は弊社今井のレポートもあわせてご覧ください。
また、Exadata Database Serviceの止めないパッチ適用については、弊社新川のレポートで詳しく解説されています。

引き続き、現地で聴いたセッションの深掘りレポートをお届けします。

最後までお読みいただきありがとうございました！