データベース

Datastream を使用して Oracle から PostgreSQL への移行を最小限のダウンタイムで実現

2021年6月10日

Google Cloud Japan Team

※この投稿は米国時間 2021 年 5 月 26 日に、Google Cloud blog に投稿されたものの抄訳です。

デジタルトランスフォーメーションを推進する企業が直面する最大の課題の一つに、以前のデータベースからの移行があります。これらのデータベースは、一般的にオンプレミスのデータセンターに固定されており、アップグレードに費用がかかるだけでなく、メンテナンスも困難です。

Google ではこれを簡素化したいと考えています。そこで、Oracle データベースを Cloud SQL for PostgreSQL に移行し、ダウンタイムや摩擦を最小限に抑えることができるオープンソースのツールキットを構築しました。

https://storage.googleapis.com/gweb-cloudblog-publish/images/Oracle_to_PostgreSQL.max-1100x1100.jpg

クリックして拡大

Oracle から Postgres への移行ツールキットは、既存のオープンソースや Google Cloud サービス、Google が開発した独自のツールを組み合わせて使用しており、スキーマの変換や、低レイテンシで継続的なデータレプリケーションの設定、最後に Oracle から Cloud SQL for PostgreSQL への移行の検証を行うプロセスをサポートしています。

移行は複数のステップを経て行われ、複雑で反復処理となる場合もあります。Google はこのステップを単純化することに努め、ドキュメント化されたステージで詳細なプロセスを作り、実行しやすくしました。

データベースの移行には、一般的に以下のようなステージがあります。

リソースのデプロイと準備: 必要なリソースをデプロイし、後続のステージで使用する Docker イメージを構築します。
Ora2Pg によるスキーマの変換: ニーズに合致するまで、スキーマの変換、再構築、レビュー、修正が繰り返されることが多くなります。
継続的なデータの移行: ここでは Datastream と Dataflow.
が活用されます。Datastream が、Oracle から LogMiner でログを読み込んでデータを取り込み、Google Cloud Storage にデータを格納します。新しいファイルが書き込まれると、Pub/Sub 通知が発行され、Dataflow がカスタムテンプレートを使用してファイルを受け取り、Cloud SQL for PostgreSQL にデータを読み込みます。これにより、CDC を使用して一貫した方法でデータを移行でき、ダウンタイムを少なく抑えることができます。
データ移行の検証: このステージでは、すべてのデータが正しく移行され、移行先のデータベースの使用を開始しても問題ないことを確認できます。また、この検証により、下流オブジェクト（ビューや PL / SQL など）が正しく変換されているかどうかを確認することも可能です。
PostgreSQL 使用へのカットオーバー: アプリケーションが Oracle の読み込みから Postgres の読み込みに切り替わります。

これらのステップを踏むことで、ビジネスへの影響を最小限に抑えながら確実な移行を実行できます。

移行処理は反復作業になる傾向があるため、本番環境に移行する前に、テスト環境で単一のテーブルや単一のスキーマを移行してみてください。また、このツールキットを使って、部分的なデータベースを移行することもできます。例えば、あるアプリケーションの特定のスキーマを移行し、アプリケーションの残りの部分は Oracle に残すことができます。

この投稿では、各ステージについてさらに詳しく解説し、最良の結果を導くために推奨されるプロセスや検討事項について説明していきます。

リソースのデプロイと準備

Oracle から Postgres への移行ツールキットをインストールするには、Docker がインストールされた VM が必要です。この VM は拠点として使用され、Oracle と PostgreSQL のデータベースにアクセスできる必要があります。この拠点は、リソースのデプロイ、Ora2Pg の実行、データ検証クエリの実行に使用されます。

ツールキットでは、移行処理で使用される多くのリソースがデプロイされます。また、Dataflow、Datastream、Ora2Pg、データ検証の実行に使用される複数の Docker イメージも構築されます。

初期にデプロイされる Google Cloud のリソースは以下の通りです。

現在無効になっている Datastream、Dataflow、Cloud Storage、Pub/Sub に必要な API はすべて有効になります
Cloud SQL for PostgreSQL の移行先インスタンス
Datastream と Dataflow の間で転送されるデータをステージングする Cloud Storage バケット

Cloud Storage の通知機能で新しいファイルが利用可能になったことを知らせる、Pub/Sub トピックとサブスクリプションの設定

移行準備の手順:

以下に使用する Docker イメージが構築されます

Ora2Pg
データ検証
Datastream の管理

Oracle DB と Cloud SQL for PostgreSQL インスタンスの両方への接続性がテストされます

開始前に、移行したいデータベースが Datastream の使用に対応していることを確認してください。

Ora2Pg によるスキーマの変換

スキーマの移行は複雑なプロセスになりがちで、場合によっては Oracle の非標準的機能の使用によって発生した問題を修正するために、手動での調整が必要になることもあります。このプロセスは繰り返し行われることが多いため、目的の PostgreSQL スキーマを構築するステージと、そのスキーマを適用するステージの 2 つに分けられています。

ツールキットでは、構築するベースとなる Ora2pg 構成ファイルが定義されます。デフォルトで選択されている機能は、データ移行テンプレート（特に PostgreSQL へテーブルを確実に複製するための Oracle の ROWID 機能の使用に際して）や、Ora2Pg のデフォルトの命名規則（すべての名前の小文字への変更）にも対応しています。データ移行の Dataflow テンプレートを使用する場合は、このテンプレートではこれらのオプションが使用されていることを前提としているため、オプションを調整しないでください。

行ごとに一貫した独自の識別子を持つ Oracle の ROWID 機能は、テーブルに主キーがない場合に、主キー用のデフォルト代替物として移行に使用されます。この機能は、ツールキットを使用したデータ移行には必須となりますが、アプリケーションでフィールドが必要ない場合には、移行終了後にフィールドを削除できます。この設計では、Oracle の ROWID 値を整数に変換し、PostgreSQL で列をシーケンスとして定義しています。これにより、移行が完了した後も、元の ROWID フィールドを PostgreSQL の主キーとして使い続けることができます。

Ora2Pg テンプレートの最終ステージでは、前のステップで構築した、目的の SQL ファイルを PostgresQL に適用します。反復処理しながらこれを複数回実行するには、再適用する前に PostgreSQL から以前のスキーマのイテレーションを消去してください。

移行ツールキットの目的は、Oracle のテーブルとデータの PostgreSQL への移行をサポートすることなので、デフォルトではすべての Oracle オブジェクトの変換や作成を行いません。しかし、Ora2Pg は、より広範なオブジェクト変換をサポートしています。テーブルとそのデータ以外の追加オブジェクトを変換したい場合は、Docker イメージを使用することで Ora2Pg をサポートするあらゆるタイプを変換できますが、Oracle データベースの複雑さに応じて、さまざまな程度の手動修正が必要になる可能性があります。これらの手順のサポートについては、Ora2Pg のドキュメントをご覧ください。

継続的なデータの移行

データ移行フェーズでは、レプリケーション用に Datastream と Dataflow という 2 つのリソースをデプロイする必要があります。Oracle から必要なデータを引き出す Datastream ストリームが作成され、ストリームが開始されるとすぐに、最初のテーブルスナップショット（バックフィル）のレプリケーションが始まります。これにより、すべてのデータが Cloud Storage に読み込まれ、Dataflow と Oracle から PostgreSQL への移行テンプレートを利用して、Cloud Storage から PostgreSQL に複製されます。

Datastream では、Oracle から選択したテーブルのすべての変更の CDC レプリケーションに LogMiner を利用し、バックフィルと継続的な変更が自動的に調整されます。このパイプラインが Cloud Storage にデータをバッファリングすることの利点は、例えば PostgreSQL のスキーマが変更された場合など、移行をやり直したい場合に、Oracle に対するバックフィルを再実行することなく、簡単にリデプロイできることです。

Dataflow ジョブは、事前に構築された Datastream 対応のテンプレートでカスタマイズされており、Oracle と Cloud SQL for PostgreSQL の間で一貫した低レイテンシのレプリケーションを実現しています。このテンプレートでは、Dataflow のステートフル API を使用して主キーの粒度で順序をトラックし、整合性を持って適用します。前述のように、主キーを持たないテーブルには Oracle ROWID を活用し、目的のテーブルをすべて確実に複製します。これにより、テンプレートは任意の数の PostgreSQL ライターに拡張でき、一貫した順序を失うことなく、大規模で低レイテンシのレプリケーションを維持できます。最初のレプリケーション（バックフィル）の間、パイプラインのこのフェーズがボトルネックになる可能性が高いため、レプリケーションの速度が予想よりも遅い場合、PostgreSQL リソースを監視し、スケールアップを検討することをおすすめします。レプリケーションの速度は、Dataflow ジョブの 1 秒あたりのイベント指標を使用して検証できます。

移行の実行中は、ソースでの DDL の変更はサポートされていないので、移行を実行している期間、ソーススキーマが安定していることを確認してください。

データ移行の検証

異機種間の移行には独特な複雑さが伴うため、移行完了に向けて準備する際に、ツールキットのデータ検証部分を使用することを強くおすすめします。これにより、データがすべてのテーブルで確実に複製され、PostgreSQL インスタンスが良好な状態でカットオーバーの準備が整っていることを確認できるうえ、Ora2Pg を使用してテーブル以外の追加の Oracle オブジェクトを移行した場合に、複雑なビューや PL / SQL ロジックを検証することができます（ただし、これについてはこの記事では扱っていません）。

Google は、オープンソースの最新版データバリデータから作成した検証ツールを提供しています。このツールを使って、スキーマ（列種類の一致）、行数、より複雑な集計など、価値の高いさまざまな検証を行うことができます。

Datastream からバックフィルの完了が報告された後、最初の検証を通して、テーブルが正しく表示されているか、データギャップの原因となるエラーが発生していないかを確認できます。移行処理の後半では、フィルタリングされた検証を構築したり、カットオーバー前の検証のためにデータの特定のサブセットを検証したりできます。なお、このタイプの検証は、ソースから移行先へのレプリケーションが停止した後に実行されるため、ダウンタイムを最小限に抑えるためには、バックフィルの検証よりも速く実行されることが重要です。そのため、検証するテーブルをフィルタリングしたり、数を制限したりするさまざまなオプションが提供されており、移行の整合性に高い信頼性をもたらしながら、より迅速に実行できるようなっています。

移行の一環として PL / SQL を書き直した場合は、より複雑な検証方法が推奨されます。例えば、検証で「--sum "*"」を使用すると、すべての数値列の値の合計が同じ値になります。また、キー（日付 / タイムスタンプ列など）でグループ化して、テーブルのスライスを検証することもできます。これらの機能により、テーブルが有効であるだけでなく、SQL の変換が行われた後も正確であることが保証されます。

PostgreSQL 使用へのカットオーバー

移行の最終ステージであるカットオーバーでは、移行先の Cloud SQL for PostgreSQL インスタンスをアプリケーションの記録システムとして使用開始します。カットオーバーの前にデータベースのダウンタイムが発生するため、ビジネスに支障をきたす可能性がある場合は、事前にスケジュールを組んでおく必要があります。カットオーバーの準備プロセスの一環として、最終的なカットオーバーが行われる前に、アプリケーションが PostgreSQL との読み書きができるように更新されていることと、ユーザーが必要なすべての権限を持っていることを検証することをおすすめします。

カットオーバーのプロセス