AWS DMS でのネイティブ CDC サポートの使用方法

AWS Database Migration Service (AWS DWS) は、本日よりネイティブ CDC サポートを開始し、特定のチェックポイントから AWS DMS レプリケーションを開始および停止する機能を提供します。この機能を利用すると、Microsoft SQL Server のログシーケンス番号 (LSN)、Oracle のシステム変更番号 (SCN)、AWS DMS 固有の復旧チェックポイントなどのチェックポイントを使用できます。このリリースの一環として、データレプリケーションを停止し、AWS DMS のチェックポイント機能を使用して再開する機能も提供しています。

このリリースにより、AWS DMS を使用するお客様は、データベースがコミットシーケンス (ログシーケンス番号 (LSN) のことです) を使用するのと同じ仕組みを利用できます。また、より多くの統合ユースケースが公開されます。たとえば、Oracle Data Pump または SQL Server BCP を使用して、初期データをターゲットデータベースにロードした後、DMS ログシーケンス番号を使用して変更データキャプチャ (CDC) を開始できるようになりました。今回提供されるチェックポイント機能とネイティブな開始ポイントのサポートにより、環境を休止して前回のレプリケーション実行後に行われた変更を処理することができます。たとえば、最後のチェックポイントから 1 日に 1 回変更をレプリケートできます。

リリースの時点では、Oracle、SQL Server、MySQL データベースに加えて、Amazon Aurora with MySQL Compatibility もサポートしています。今後、他のデータベースのサポートも予定されています。

AWS DMS 入門

AWS Database Migration Service は、データベースを AWS に簡単かつ安全に移行するのに役立ちます。ソースデータベースは移行中も完全に動作し続けるため、データベースに依存するアプリケーションのダウンタイムを最小限に抑えることができます。AWS Database Migration Service は、最も広く使用されている商用データベースとオープンソースデータベースの間でデータを移行できます。

このサービスは、Oracle から Oracle のような同種移行だけでなく、Oracle から Amazon Aurora、Microsoft SQL Server から MySQL など、異なるデータベースプラットフォーム間の異種移行もサポートします。また、AWS DMS を使用して、Aurora、PostgreSQL、MySQL、MariaDB、Oracle、SAP ASE、SQL Server、MongoDB などのサポートされているソースから、Amazon Redshift、Amazon DynamoDB、Amazon S3 にデータをストリーミングすることもできます。さらに、AWS DMS は、高可用の継続的データレプリケーションに使用できます。

AWS DMS は、変更データキャプチャ (CDC) を使用して継続的データレプリケーションを実行します。CDC を使用すると、変更されたデータを識別して追跡し、ダウンストリームアプリケーションが消費および操作できる変更のストリームとして提供できます。ほとんどのデータベース管理システムは、データベースコンテンツとメタデータに対する変更を記録するトランザクションログを管理します。 AWS DMS は、エンジン固有の API 操作および関数を使用して、トランザクションログを読み取ります。AWS DMS は、データベースに加えられた変更を非侵入的な方法でキャプチャします。

Example 社の紹介

AWS の架空の顧客である Example 社は、AWS DMS で対処すべき典型的な検討課題をいくつか抱えています。Example 社には 10 TB の Oracle データベースがありますが、Aurora with PostgreSQL Compatibility データベースでレポート用の読み取り専用コピーを作成したいと考えています。また、このアプリケーションを AWS に移行することを望んでいます。Oracle データベースの代わりに Aurora with PostgreSQL Compatibility を使用することを検討しています。また、実際の本番データで AWS のアプリケーションをテストしたいと考えています。

このブログ記事では、Example 社が AWS DMS の新機能を使用してどのように要件を満たしたかを見ていきます。

データベースのトランザクションログ

トランザクションログは、データベースシステムに対するすべての変更をキャプチャします。ログには、データベースサーバーがデータベースクラスターを復旧できるようにするため、実行された各トランザクションの十分な情報が含まれています。サーバーがクラッシュした場合、トランザクションログ内の変更とアクションを再生することにより復旧を行います。トランザクションログには、ログシーケンス番号 (LSN) と呼ばれる増分番号も記録されます。

Oracle の用語では、トランザクションログは REDO ログ、ログ順序番号 (LSN) はシステム変更番号 (SCN) と呼ばれます。 Oracle の REDO ログファイルは、トランザクションログと同様に、REDO レコードを追跡します。REDO レコードは、データベースの 1 つのブロックに加えられた変更を記述する変更ベクトルの集合です。データブロックは、データベースによって使用されるデータの最小単位です。

トランザクション処理の際は、必要な REDO レコードがディスクにフラッシュされて初めて、トランザクションの正常終了がユーザープロセスに通知されます。コミットが発生するたびに、データベースは LSN に似た SCN を割り当てて、コミットされた各トランザクションの REDO レコードを識別します。

Example 社のレポート要件

Example 社は、Aurora with PostgreSQL Compatibility データベースで動作するレポートアプリケーションを入手し、オンプレミスの Oracle データベースを Aurora with PostgreSQL Compatibility に移行したいと考えています。

AWS SCT でスキーマを変換し、AWS DMS でデータを移行するため、Example 社は AWS データベースブログの Oracle データベースから Amazon Aurora with PostgreSQL Compatibility データベースへの移行の概要に関する記事の手順を実行しました。

Example 社では、プロダクションデータベースから既存のデータを移行することはせず、特定の時点のデータベースのコピーを作成しました。既存の変更を移行するため、そのデータベースにソースエンドポイントを設定しました。この方法により、完全移行時にプロダクションデータベースに AWS DMS から追加の負荷がかからないようにすることができました。

Example 社は、アプリケーションが使用する Oracle データベースで CDC を実行したいと考えましたが、1 秒あたりのトランザクション (TPS) の数値が高いため、特定の時間に CDC を開始するのは望ましくないことがわかりました。TPS が高いため、トランザクションの重複や欠落が起こらないと保証できる時間を見つけることは不可能でした。

Example 社のレポート環境

Example 社はまた、この記事の前述の説明に従ってスキーマを変換し、Aurora with PostgreSQL Compatibility にデータを移行しました。既存のデータを移行した後、Example 社はソースエンドポイントを変更し、CDC を実行してデータを移行するプロダクションデータベースを反映させる必要がありました。同社は、Aurora with PostgreSQL Compatibility に AWS でレポート環境を作成するため、以下の手順を実行しました。

CDC のための DMS タスクの作成

まず、AWS マネジメントコンソールで、プロダクションデータベースとターゲットエンドポイントを Aurora with PostgreSQL Compatibility に反映させる新しいソースエンドポイントを使用して、新しいタスクを作成します。データ変更のみをレプリケートするオプションを選択します。以前に DMS ですべてのデータを移行済みであるため、[Target table preparation mode (ターゲットテーブルの準備モード)] で [Do nothing (何もしない)] を選択します。

Oracle での SCN の取得

次のクエリにより、データベースレプリケーションを開始する最新の SCN を取得できます。DMS はこの SCN を使用して、適切な時点から CDC を開始できます。

SELECT
      SCN,
      scn_to_timestamp(scn) SCN_TimeStamp
    FROM (
          SELECT dbms_flashback.get_system_change_number() as SCN
          FROM dual
        )

CDC のためのタスク設定

次に、前のステップで取得した SCN から開始するように CDC を構成する必要があります。

[Log Sequence Number (ログシーケンス番号)] セクションに、前のステップで Oracle データベースから取得した SCN を入力します。タスクを作成したら、タスクを起動して DMS コンソールからタスクを監視できます。

ログシーケンス番号から開始することで、トランザクションの喪失を防ぎ、CDC の開始ポイントを明確にすることができます。

Example 社の移行環境

Oracle データベースから Aurora with PostgreSQL Compatibility への移行の一環として、Example 社は CDC プロセスを停止してから開始したいと考えています。それは、CDC サービスの負荷をかけずにアプリケーションをテストできるようにするためです。DMS のチェックポイント機能により、ソースデータベースの LSN または SCN に依存せずにレプリケーションを停止および開始することができます。

これを行うため、Example 社は、記録環境の作成について前に説明した手順に従って、データベースの 2 つ目のレプリカを作成しました。ただし、今回はチェックポイント機能を使用して、レプリケーションを停止して開始しました。

この方法を使用すると、特定の時刻または特定のコミット時間にレプリケーションを停止できます。

DMS を使用すると、特定のサーバー時間またはタスク設定で説明したコミット時間に CDC を確実に停止できます。また、DMS は、メタデータ情報をターゲットデータベースのテーブルに継続的に書き込みます。このチェックポイントデータを保存することにより、レプリケーションインスタンスとタスクをシャットダウンしてコストを節約できます。

CDC の再開

Example 社は、夜間にのみ、また、前回のレプリケーション以降に変更されたデータのみをレプリケートすることを計画しています。

これを実現するために、まず、ターゲットインスタンスのメタデータテーブル awsdms_txn_state に対して、チェックポイントデータを取得するクエリを実行しました。次に、新しいレプリケーションインスタンスを起動し、前のステップで取得したチェックポイントからレプリケーションを開始するタスクを作成しました (次のスクリーンショットを参照)。

これにより、レプリケーションが実行されていた時間についてのみレプリケーションインスタンスの支払いが発生するようにして、他のすべての時間は環境を休止することができました。

また、describe-replication-tasks API アクションの呼び出し結果の一部としてチェックポイント情報を取得することもできます。この情報は、タスクをフィルタリングしてチェックポイントを検索するだけで取得できます。レプリケーションタスクが停止または失敗した状態の場合、最新のチェックポイントを取得できます。

次回のブログ記事では、Example 社が AWS Lambda 関数と AWS CloudFormation テンプレートを使用してどのようにこのプロセスを自動化したかを見ていきます。

結論

Example 社の要件は Oracle データベースを移行することでした。AWS DMS は、商用データベースでもオープンソースデータベースでも機能します。DMS は、どちらのデータベースに対しても、ネイティブの開始ポイントとチェックポイントに同じ機能を提供します。

この記事では、Example 社がネイティブ SCN サポートを使用してレポート環境を作成した方法を紹介しました。また、同社が新しいチェックポイント機能を使用して、特定の時間にのみレプリケーションインスタンスを実行し、また、前回のレプリケーション以降に変更されたデータのみをレプリケートすることで、コストを節約した方法も紹介しました。

著者について

Ganesh Raja は、アマゾンウェブサービスのソリューションアーキテクトです。 AWS の顧客と協力してデータベースプロジェクトに関する助言や技術支援を行い、AWS を使用する場面でソリューションの価値を向上させる手助けをしています。

Amazon Web Services ブログ