Oracle DatabaseからCloudSQL for PostgreSQLへの移行手段を調査してみた
はじめに
こんにちは。クラウドエース SRE ディビジョンの原子(はらこ)です。
Zenn 記事の執筆は初めてなのですが、絵文字を設定するんですね。なんとなく、骨付き肉の絵文字にしてみました。というと、テキサス BBQ の骨付きバックリブが好物です。どうでもいいですね。
記事を読み始める前に
さて、本記事は Oracle Database(以下、Oracle DB)から Cloud SQL for PostgreSQL(以下、Cloud SQL) への移行手段について調査し、まとめた内容になっています。具体的な移行のやり方 (方法) の紹介ではありません。したがって、検証作業などは行っておらず、移行手段ごとの特徴から比較と考察を行う流れになっています。
加えて、筆者は DB 移行を実業務で行ったことはありませんので、2023 年 12 月時点の Google Cloud 公式ドキュメントベースでの内容となっています。少なくとも、やってみた系の記事ではないことをご了承ください。
これらのことから本記事のターゲットは、Oracle DB を Cloud SQL へ移行する手段を調べてもよくわからないと感じる方や、どんな手段で移行できるのかを大雑把に知りたい方になっています。
想定環境
今回想定する環境は下記の通りです。
-
システム規模
小~中規模程度とします。具体的には、大手 EC サイトのような規模ではなく、組織内外のユーザー数人〜数百人程度で使用しているシステム、といった規模感です。 -
ミッションクリティカル性
業務で使用するシステムとし、稼働停止すると困りますが、事前に周知があれば 1、2 日程度の停止は許容できるものとします。金融システムのような、超ミッションクリティカルのものとはしません。 -
運用環境
移行元の DB(システム)は、オンプレミス・クラウドを問わないものとします。 -
移行するデータ量
数 GB ~ 数百 GB -
Oracle DB のバージョン
Oracle Database 11g Version 11.2.0.4 以降 -
ネットワーク構成
移行には移行元環境と Google Cloud の接続を確立する必要がありますが、今回は接続経路を確立済みとします。
特に解説はしませんが、プライベート接続を構成する場合、下記のような Google Cloud サービスがありますので参考にしてみてください。
大まかな移行方式の違い
私が調査を行った限り、想定環境での移行には、大まかに 2 つの移行方式が取れることがわかりました。
具体的な手段は次項で紹介します。
エクスポート/インポート
移行元の構成を SQL ダンプファイルや CSV ファイル形式などでエクスポートし、そのデータを移行先でインポートする方式です。
データの整合性を保つためには、DB の稼働を停止した状態で、エクスポート/インポートから DB の切り替えまで行う必要があります。したがって、移行開始から完了までダウンタイムが続くことになるので、ダウンタイムが長い移行方式となっています。
レプリケーション
レプリケーションとは、運用環境を含む DB の複製を作成することです。PostgreSQL 標準のレプリケーション機能や、ツールを介した Change Data Capture (以下、CDC) 等で移行元 DB との差分を抽出し、複製した DB へ継続的にデータを同期させます。最後に DB の稼働を停止し、両 DB の内容が一致していることを確認した後、複製先 DB に切り替えることで移行を完了します。
同期は継続的に行われるので、同期中に DB の稼働を停止する必要がありません (データ更新も可能)。したがって、ダウンタイムは内容一致の確認と DB の切り替え時のみとなり、最小限のダウンタイムで移行を完了することができます。
移行手段を調べてみる
具体的な移行手段としては、以下の 3 つの手段を確認することができました。
- Ora2Pg を利用したエクスポート/インポート
- Striim を利用したレプリケーション
- Database Migration Service (以下、DMS)
Ora2Pg を利用したエクスポート/インポート
Oracle DB からエクスポートしたデータは、直接 PostgreSQL にインポートすることができません。
そこで、Ora2Pg というマイグレーションツールを用いることで、PostgreSQL 向けに変換したデータのエクスポートと、移行先 DB へのインポート作業を実行できます。
特徴
- 移行期間中はダウンタイムが必要 : エクスポート/インポートでの移行時、データの整合性を維持するためには、稼働を停止した状態での作業が必要になります。
- 移行用リソースの用意が必要 : Ora2Pg をホストするリソースの用意や、パラメータ調整等の作業が必要になります。移行の潜在的な中断を避けるためには、Ora2Pg 専用のマシンを用意することが推奨されているようです。
- オープンソースソフトウェア (OSS) : Ora2Pg は OSS ですので、使用料金は発生しません。
外部コスト
特徴で述べたように、Ora2Pg は OSS なので、使用に伴う外部コストは発生しません。
Striim を利用したレプリケーション
Striim はストリーミングデータの統合、分析プラットフォームです。
異種 DB 間でレプリケーションを行うには、エクスポート/インポートと同様に、データの変換を行う必要があります。
そこで、Striim を利用して、データの変換を含むレプリケーションのパイプラインを構築することで、異種 DB 間でのレプリケーションを実現できるようです。
特徴
- 継続的な同期 : データは継続的に同期されるので、移行中に DB を更新しても、その内容は複製先 DB に反映されます。
- ダウンタイムが最小限 : データ移行中に稼働を停止しなくても整合性が保たれるので、ダウンタイムは内容一致の確認と DB 切り替え時のみになります。
- パイプライン構築が必要 : はじめに述べたように、Striim 上で DB の変換を含むレプリケーションのパイプライン構築が必要です。
外部コスト
Striim の使用には、ライセンス料と従量課金の支払いが必要となるため、外部コストが発生します。詳しい料金は以下を確認してください。
Database Migration Service
外部環境にある DB を Google Cloud 環境に移行する、Google Cloud 提供のフルマネージドサービスです。移行元には MySQL, PostgreSQL, Oracle DB などをサポートし、異種 DB への移行にも対応しています。
DMS は、内部的には CDC ベースのレプリケーションによる移行になります。
特徴
- コンソール上で操作可能 : ドキュメントを見る限り、DMS の操作・設定は GUI のみで完結できそうでした。
- フルマネージドサービス : 移行用リソースの用意や管理などが不要です。
- 異種間の移行をサポート : 組み込みの変換機能を使用することで、DB の変換から移行まで一括で行えます。
-
ダウンタイムが最小限 : CDC ベースのレプリケーションによる移行になるので、ダウンタイムを最小限に抑えられます。
参考程度になりますが、以下の事例では、合計約 1TB のデータを DMS で移行した際に発生したダウンタイムが、最大 10 分であったと記載されていました。
外部コスト
異種 DB 間の移行には、追加料金が発生します。(同種 DB 間であれば無料)
詳しくは、以下の DMS の料金についてのドキュメントを参考にしてください。
移行手段の比較
ずらずらと書いてしまいましたので、比較項目を設けて表形式にしました。
下記の表を元に比較していきたいと思います。
| 比較項目 | Ora2Pg を利用したエクスポート/インポート | Striimを利用したレプリケーション | Database Migration Service |
|---|---|---|---|
| 外部コスト | なし | あり : 2,180 USD (※) | あり : 169.58 USD (※) |
| ダウンタイム | 長い | 最小限 | 最小限 |
| フルマネージド | ×(リソースの用意が必要) | ×(パイプライン構築が必要) | ⚪︎ |
※ 下記条件での試算に基づく金額
移行するデータ量を 300GB (うち 280GB はバックフィルで移行し、その後 20GB 分の変更が発生したと想定)、移行は1ヶ月以内で完了するものと想定しました。
バックフィルとは、移行元 DB テーブル内に存在するデータの履歴スナップショットを取得することです。
詳しい料金形態は、各移行手段の紹介時に記載した公式の料金ページをご確認ください。
Striim の料金
1ヶ月分の Srtiim Cloud Enterprise サブスクリプション料金 + データ量 * データ入力料金 + データ量 * データ出力料金
2,000 + 300 * 0.50 + 300 * 0.10 = 2,180 USD
DMS の料金
Cloud SQL 東京リージョンへの移行と想定しました。
(バックフィルサイズ - 無料分の50GB) * バックフィル料金 + 変更データ量 * CDC (レプリケーション) 料金
(280 - 50) * 0.514 + 20 * 2.568 = 169.58 USD
表をもとに比較
外部コストに着目すると、Ora2Pg を利用したエクスポート/インポートのみ、外部コストが発生しないことがわかります。
ダウンタイムについては、Ora2Pg を利用したエクスポート/インポートのみ、他の2つと比べて長めとなっています。
上記のような点から、Ora2Pg を利用したエクスポート/インポートのダウンタイムは長めですが、外部コストをかけずに移行できる手段と言えそうです。
一方で Striim を利用したレプリケーション、もしくは DMS を使った移行では、ダウンタイムを最小限に抑えることができそうですが、外部コストが発生する手段になっています。外部コスト量を比較すると、Striim のコンピューティング使用料を加味せずとも、DMS の方が少ない外部コストで移行を実現できそうなことがわかります。
また、最後の比較項目については DMS だけがフルマネージドサービスとなっており、リソースの用意やパイプライン構築といった作業が不要になります。
作業量について
本来は作業量の比較もしたいところですが、詳細な要件を考慮しなければ、具体的な作業量の予測は難しいと判断し、今回は不明として考えました。
DB 移行は 100% の移行が求められる点から、多くの手間がかかることは推測できます。しかし具体的な作業量は、移行元 DB で使用している特有機能の有無や、移行元のシステム等によりけりであると考えられるためです。
考察してみる
移行手段の特徴から比較が行えたので、想定環境に当てはめて考察してみました。
まず、業務で使用するシステムという点で、長時間のダウンタイムは避けたいところです。ダウンタイムの発生を最小限に抑える選択肢としては、Striim を利用したレプリケーション、もしくは DMS を使った移行が良さそうです。
しかし、数 GB 程度であれば、Ora2Pg を利用したエクスポート/インポートでも、それほど長時間のダウンタイムは発生しないように思えます。発生しうるダウンタイムが予測でき、尚且つ許容範囲内であれば、外部コストをかけずに移行できる可能性があるのではないでしょうか。
また、1、2 日以上のダウンタイムが予想される場合でも、長期休暇期間中などユーザーのシステム利用が少なく、長時間のダウンタイムが許容できる状況であれば、有効な手段だと考えられます。
したがって、移行するデータ量が多く、長期間のシステム停止が許容できない場合に、DMS もしくはStriim を利用したレプリケーションによる移行を選択することになりそうです。
今回比較した限り 2 つの違いは、外部コストと作業内容 (DMS のみフルマネージド) です。
概算ではありますが、外部コストの比較をしたところ DMS の方が安価な選択肢と言える結果になりました。特段理由がなければ、フルマネージドサービスという点も含め、外部コストを抑えられる DMS を使った移行の方が良さそうです。
しかし、Striim を利用すれば、パイプライン構築からできるという見方もあると思います。今回の想定を超える詳細な要件や、予想される作業に対する人件費といった内部コストも含めた比較を行う必要が出てくるでしょう。
まとめ
以上、Oracle DB から Cloud SQL への移行手段について、調査した内容の紹介でした。
調査を通して、移行手段ごとの特徴をおさえることができました。
その後の考察では、ダウンタイムと外部コストという要素から、ある程度まで選択肢を絞ることはできました。しかし、具体的なダウンタイムの予測や内部コストといった、実施環境に左右される要素の考慮も必要だと考えられます。したがって、各移行手段の特徴を踏まえて、個々の要件に応じた柔軟な選定作業が求められることになりそうです。
ただ、今回の想定環境と考察は一例ですので、DB (システム) 要件によっては、移行手段が限られてくる可能性が無いとも言えません。具体的な移行計画を立てる際には、更に詳細な調査と検証が必要になるでしょう。
加えて、今一度注意していただきたいのが、今回は検証を行っていないという点です。実際の移行作業は、アプリケーションの改修や切り替え前のテスト等、DB 以外に対しても作業が必要だと思われ、決して簡単に終わるものではないことは推測できます。確かにシステムの規模次第とも言えますが、膨大な作業が待ち受けている可能性があります。決して安易な気持ちで取り組むべきものではないでしょう。
こんなことを言われると、DB 移行なんてしたくないと思ってしまいそうですよね。
そこで、DB の移行作業を支援してくれる migVisor というツールが存在するようです。
このツールについては、弊社から公開されている以下の記事で紹介されていますので、ご確認ください。
さいごに
いかがでしたでしょうか。
本記事のようなケースでの移行を考えている方にとって、少しでも助けになれたら嬉しいです。
また、オンプレミスの PostgreSQL から AlloyDB への移行というケースではありますが、DMS を使った移行についての記事が弊社から公開されています。
DMS を使った移行手順や使用感など、今回触れることができなかった内容になっていますので、ぜひ参考にしてください。
最後まで読んでいただき、ありがとうございました。
Discussion