オンプレミスの Oracle データベースを AWS に同期する方法

20 年間にわたって企業のソフトウェア開発を第一線から観察していると、ここ数年の否定できないトレンドは明らかです。それは、データベースのクラウドへの移行です。

私はすでにいくつかの移行プロジェクトに参加していましたが、その目標は既存のオンプレミス データベースをアマゾン ウェブ サービス (AWS) クラウド データベースに移行することでした。 AWS のドキュメント資料を見れば、これがいかに簡単であるかがわかりますが、私がここで言いたいのは、そのような計画の実行は必ずしも気楽なものではなく、場合によっては失敗する可能性があるということです。

この投稿では、次の場合の実体験を取り上げます。

• ソース : 理論的には、ソースが何であるかは実際には重要ではありません (最も人気のある DB の大部分に対して、非常に似たアプローチを使用できます)。Oracle は長年にわたり、大企業で選ばれるデータベース システムでした。そこが私の焦点です。
• ターゲット : この面について具体的にする理由はありません。 AWS 内の任意のターゲット データベースを選択でき、このアプローチは依然として適合します。
• モード : 完全リフレッシュまたは増分リフレッシュを行うことができます。バッチ データ ロード (ソースとターゲットの状態が遅延される) または (ほぼ) リアルタイム データ ロード。ここでは両方について触れます。
• 頻度 : 1 回限りの移行の後にクラウドへの完全な切り替えを行うか、ある程度の移行期間が必要で、両方の側で同時にデータを最新の状態にする必要がある場合があります。これは、オンプレミスと AWS の間で毎日の同期を開発することを意味します。前者はよりシンプルではるかに理にかなっていますが、後者はより頻繁に要求され、はるかに多くのブレークポイントがあります。ここでは両方について説明します。

問題の説明

多くの場合、要件は単純です。

AWS 内でサービスの開発を開始したいので、すべてのデータを「ABC」データベースにコピーしてください。素早く簡単に。今は AWS 内のデータを使用する必要があります。後ほど、活動に合わせて DB 設計のどの部分を変更する必要があるかを考えます。

先に進む前に、考慮すべき点があります。

• 「持っているものをコピーして、後で対処する」という考えに飛びつきすぎないでください。つまり、はい、これが最も簡単で、すぐに完了しますが、これにより、新しいクラウド プラットフォームの大部分を本格的にリファクタリングしない限り、後で修正することが不可能になるような根本的なアーキテクチャ上の問題が発生する可能性があります。 。クラウドのエコシステムがオンプレミスのエコシステムとはまったく異なることを想像してみてください。今後、いくつかの新しいサービスが導入される予定です。当然のことながら、人々は同じものをまったく異なる方法で使い始めるでしょう。オンプレミスの状態をクラウドに 1 対 1 で複製することは、ほとんどの場合良い考えではありません。特定のケースに当てはまる可能性がありますが、必ず再確認してください。
• 次のような意味のある疑問を持って要件に質問してください。
  • 新しいプラットフォームを利用する典型的なユーザーは誰でしょうか?オンプレミスでは、トランザクション ビジネス ユーザーになることができます。クラウドでは、データ サイエンティストやデータ ウェアハウス アナリストになることも、データの主なユーザーがサービス (Databricks、Glue、機械学習モデルなど) になることもあります。
  • クラウドに移行した後も、通常の日常業務は継続されると予想されますか?そうでない場合、どのように変化すると予想されますか?
  • 時間の経過とともにデータが大幅に増加することを計画していますか?おそらく、答えは「はい」です。多くの場合、それがクラウドに移行する唯一の最も重要な理由だからです。新しいデータモデルがそれに対応できるように準備されている必要があります。
• エンド ユーザーは、新しいデータベースがユーザーから受け取る一般的な予想されるクエリについて考えることが期待されます。これにより、パフォーマンスとの関連性を維持するために既存のデータ モデルをどの程度変更する必要があるかが定義されます。

移行のセットアップ

ターゲットデータベースを選択し、データモデルについて十分に議論したら、次のステップは AWS Schema Conversion Tool に慣れることです。このツールが役立つ分野はいくつかあります。

1. ソース データ モデルを分析して抽出します。 SCT は、現在のオンプレミス データベースの内容を読み取り、まずソース データ モデルを生成します。
2. ターゲット データベースに基づいてターゲット データ モデル構造を提案します。
3. ターゲット データベース デプロイメント スクリプトを生成して、ターゲット データ モデルをインストールします (ツールがソース データベースから検出した内容に基づいて)。これにより展開スクリプトが生成され、その実行後、クラウド内のデータベースはオンプレミス データベースからデータをロードできるようになります。

次に、スキーマ変換ツールを使用するためのヒントをいくつか紹介します。

まず、出力を直接使用することはほとんどありません。データの理解と目的、クラウドでのデータの使用方法に基づいて調整を行う参考結果のようなものだと考えています。

第 2 に、以前は、テーブルはおそらく、具体的なデータ ドメイン エンティティに関する短い短い結果を期待するユーザーによって選択されました。しかし現在では、データは分析目的で選択される可能性があります。たとえば、これまでオンプレミス データベースで機能していたデータベース インデックスは役に立たなくなり、この新しい使用法に関連する DB システムのパフォーマンスは明らかに向上しません。同様に、ソース システムで以前と同様に、ターゲット システムでもデータを別の方法で分割したい場合があります。

また、移行プロセス中にいくつかのデータ変換を行うことを検討することをお勧めします。これは基本的に、一部のテーブルのターゲット データ モデルを変更することを意味します (テーブルが 1:1 のコピーではなくなるようにします)。後で、変換ルールを移行ツールに実装する必要があります。

移行ツールの構成

ソースデータベースとターゲットデータベースが同じタイプの場合 (例: オンプレミスの Oracle と AWS の Oracle、PostgreSQL と Aurora Postgresql など)、具体的なデータベースがネイティブにサポートする専用の移行ツールを使用するのが最善です (例: データポンプのエクスポートとインポート、Oracle Goldengate など)。

ただし、ほとんどの場合、ソース データベースとターゲット データベースに互換性がないため、明らかに選択されるツールは AWS Database Migration Service になります。

AWS DMS では基本的に、以下を定義するテーブル レベルでタスクのリストを設定できます。

• 接続先の正確なソース DB とテーブルは何ですか?
• ターゲットテーブルのデータを取得するために使用されるステートメントの仕様。
• 変換ツール (存在する場合)。ソース データをターゲット テーブル データにマッピングする方法を定義します (1:1 ではない場合)。
• データをロードする正確なターゲット データベースとテーブルは何ですか?

DMS タスクの構成は、JSON などの使いやすい形式で行われます。

最も単純なシナリオでは、ターゲット データベースで展開スクリプトを実行し、DMS タスクを開始するだけです。しかし、それだけではありません。

1 回限りの完全なデータ移行

実行するのが最も簡単なケースは、リクエストがデータベース全体をターゲットのクラウド データベースに一度移動する場合です。基本的に、必要な作業は次のようになります。

1. ソーステーブルごとに DMS タスクを定義します。
2. DMS ジョブの構成を正しく指定してください。これは、適切な並列処理、変数のキャッシュ、DMS サーバー構成、DMS クラスターのサイジングなどをセットアップすることを意味します。これは、広範なテストと最適な構成状態の微調整が必​​要なため、通常、最も時間のかかるフェーズです。
3. 各ターゲット テーブルがターゲット データベースに予想されるテーブル構造で作成 (空) されていることを確認します。
4. データ移行が実行される時間枠をスケジュールします。その前に、(パフォーマンス テストを実行して) 移行が完了するのに十分な時間枠があることを確認してください。移行自体中、ソース データベースはパフォーマンスの観点から制限される可能性があります。また、移行の実行中はソース データベースが変更されないことが予想されます。そうしないと、移行完了後に移行されたデータがソース データベースに保存されたデータと異なる可能性があります。

DMS の構成が適切に行われていれば、このシナリオでは何も悪いことは起こりません。すべてのソース テーブルが取得され、AWS ターゲット データベースにコピーされます。唯一の懸念事項は、アクティビティのパフォーマンスと、ストレージ容量不足によってアクティビティが失敗しないように、すべてのステップでサイズ設定が適切であることを確認することです。

毎日の増分同期

ここからが事態が複雑になり始めます。つまり、世界が理想的であれば、おそらく常に問題なく機能するでしょう。しかし、世界は決して理想的なものではありません。

DMS は、次の 2 つのモードで動作するように構成できます。

• 全ロード – 上で説明および使用したデフォルト モード。 DMS タスクは、ユーザーが開始したとき、または開始がスケジュールされたときに開始されます。完了すると、DMS タスクは完了します。
• 変更データ キャプチャ (CDC) – このモードでは、DMS タスクが継続的に実行されます。 DMS は、テーブル レベルでの変更についてソース データベースをスキャンします。変更が発生すると、変更されたテーブルに関連する DMS タスク内の構成に基づいて、ターゲット データベースに変更をただちに複製しようとします。

CDC を使用する場合は、さらに別の選択を行う必要があります。つまり、CDC がソース DB からデルタ変更を抽出する方法です。

#1. Oracle REDO ログ リーダー

1 つのオプションは、Oracle のネイティブ データベース REDO ログ リーダーを選択することです。CDC はこれを利用して変更されたデータを取得し、最新の変更に基づいてターゲット データベースに同じ変更をレプリケートできます。

Oracle をソースとして扱う場合、これは明白な選択のように見えるかもしれませんが、落とし穴があります。Oracle REDO ログ リーダーはソース Oracle クラスターを利用するため、データベース内で実行されている他のすべてのアクティビティに直接影響します (実際には、データベース内にアクティブなセッションが直接作成されます)。データベース）。

構成した DMS タスクが増えるほど (または並行する DMS クラスターが増えるほど)、Oracle クラスターのサイズを大きくする必要がさらに多くなります。基本的には、プライマリ Oracle データベース クラスターの垂直方向のスケーリングを調整します。これは、ソリューションの総コストに確実に影響を及ぼします。プロジェクトに毎日の同期が長期間続く場合は、さらに影響が大きくなります。

#2. AWS DMS ログマイナー

上記のオプションとは異なり、これは同じ問題に対するネイティブの AWS ソリューションです。この場合、DMS はソース Oracle DB には影響しません。代わりに、Oracle REDO ログを DMS クラスタにコピーし、そこですべての処理を実行します。 Oracle リソースは節約されますが、より多くの操作が必要となるため、処理速度は遅くなります。また、容易に推測できるように、Oracle REDO ログのカスタム リーダーは、おそらく Oracle のネイティブ リーダーよりも動作が遅いと考えられます。

ソース データベースのサイズと毎日の変更の数に応じて、最良のシナリオでは、オンプレミスの Oracle データベースから AWS クラウド データベースへのデータのほぼリアルタイムの増分同期が行われる可能性があります。

他のシナリオでは、まだほぼリアルタイムの同期にはなりませんが、ソースとターゲットのクラスターのパフォーマンス構成と並列処理を調整するか、実験することで、許容される遅延 (ソースとターゲットの間) にできるだけ近づけることができます。 DMS タスクの量と、CDC インスタンス間でのそれらの分散。

また、考えられるすべての変更がサポートされているわけではないため、CDC でサポートされているソース テーブルの変更 (列の追加など) を知りたい場合もあります。場合によっては、ターゲット テーブルを手動で変更し、CDC タスクを最初から再起動することが唯一の方法である (途中でターゲット データベース内の既存のデータがすべて失われます)。

物事がうまくいかないとき、たとえ何が起こっても

私はこれを苦労して学びましたが、毎日のレプリケーションの約束を達成するのが難しい DMS に関連する特定のシナリオが 1 つあります。

DMS は、一定の定義された速度でのみ REDO ログを処理できます。タスクを実行する DMS インスタンスがさらに多くても問題ありません。それでも、各 DMS インスタンスは、単一の定義された速度でのみ REDO ログを読み取り、それぞれが REDO ログ全体を読み取る必要があります。 Oracle REDO ログを使用するか、AWS ログマイナーを使用するかは関係ありません。どちらにもこの制限があります。

ソース データベースに 1 日以内に大量の変更が含まれ、Oracle REDO ログが毎日非常に大きくなる (500GB 以上など) 場合、CDC は機能しません。レプリケーションはその日の終わりまでに完了しません。未処理の作業の一部が翌日に持ち込まれ、レプリケートされる新しい変更セットがすでに待機しています。未処理のデータの量は日に日に増加する一方です。

この特定のケースでは、CDC はオプションではありませんでした (多くのパフォーマンス テストと試行を実行した後)。少なくとも当日からのすべての差分変更が同じ日にレプリケートされるようにする唯一の方法は、次のようにアプローチすることでした。

• あまり使用されない非常に大きなテーブルを分離し、週に 1 回だけ (週末などに) 複製します。
• それほど大きくはないものの、それでも大きいテーブルのレプリケーションを複数の DMS タスク間で分割するように構成します。最終的に 1 つのテーブルは 10 個以上の個別の DMS タスクによって並行して移行され、DMS タスク間のデータ分割が確実に明確になり (ここにはカスタム コーディングが含まれます)、毎日実行されます。
• DMS のインスタンスをさらに追加し (この場合は最大 4 つ)、DMS タスクをそれらの間で均等に分割します。これは、テーブルの数だけでなくサイズによっても意味します。

基本的に、DMS のフル ロード モードを使用して日次データをレプリケートしました。それが、少なくとも同日のデータ レプリケーション完了を達成する唯一の方法だったからです。

完璧な解決策ではありませんが、依然として存在しており、何年も経った後でも同じように機能します。結局のところ、それほど悪い解決策ではないかもしれません。 😃