Amazon Web Services ブログ

Amazon QLDB のAmazon Aurora PostgreSQL への移行

本投稿は Migrate an Amazon QLDB Ledger to Amazon Aurora PostgreSQL (記事公開日: 2024 年 7 月 18 日) のブログを翻訳したものです。

「監査のユースケースで Amazon QLDB をAmazon Aurora PostgreSQL に置き換える」のブログでは、データ変更に対して信頼できる監査を維持することが重要な要件である台帳データベースの一般的なユースケースにおいて、Amazon Aurora PostgreSQL 互換エディションが Amazon QLDB の優れた代替手段である理由を説明しました。

この投稿では、Amazon QLDB 開発者ガイドのチュートリアルにある米国自動車省 (DMV) のサンプル台帳を例として、Amazon QLDB 台帳を Amazon Aurora PostgreSQL に移行するプロセスを示します。このソリューションをあなた自身の移行におけるベースとして使用し、スキーマと移行戦略に合わせて必要に応じて変更することができます。

移行決定

データベースを移行するときは、どのデータを移行するかを決定する必要があります。一部のアプリケーションでは、すべての履歴データを含むデータベース全体を移行することが求められます。また、最新のデータ (たとえば、過去 12 ヶ月分) のみを移行し、古いデータをアーカイブするのが最適な選択である場合もあります。ただし、アプリケーションのカットオーバーを迅速に行うために最新のデータを移行し、後で古いデータを新しいデータベースに移行することを決定する企業もあります。現在、一括で移行できることはほとんどないため、カットオーバーまでの期間、ターゲットデータベースをソースデータベースと同じ最新の状態に保つ必要があります。

この記事で紹介したソリューションは、ベースとして移行元の台帳データ全体をターゲットデータベースに移行し、移行元で継続中の変更をカットオーバーまでターゲットにコピーすることです。このソリューションはモジュール式なので、特定の移行戦略に合わせてカスタマイズできます。

また、移行中にターゲットデータベース内のデータをモデル化し、台帳データをそのモデルに適合するように変換する方法を決定する必要があります。Amazon QLDB ドキュメントデータモデルは、ネストされた要素を含む可能性のある複雑で構造化されたドキュメントをサポートします。Amazon QLDB のテーブルには、ドキュメント構造の異なるオブジェクトが含まれている場合があります。台帳の柔軟な文書モデルをより厳格なリレーショナルデータベーススキーマにマッピングするのは難しい場合があります。さらに、文書の構造は時間の経過とともに変化する可能性があります。移行プロセスでは、特定の文書のすべてのリビジョンが同じ構造であることを前提とすることはできません。このような課題を考えると、データを JSON として Amazon Aurora PostgreSQL に移行することもできます。これにより移行が大幅に簡素化されますが、リレーショナルデータベースのデータにアクセスするための最も効率的なオプションではない可能性があります。別の方法は、移行中に台帳データを正規化し、文書モデルをリレーショナルモデルに変換し、時間の経過とともに発生した文書モデルへの変更を考慮に入れることです。このアプローチはより複雑で、より多くのコーディングが必要であり、予期しない変換エラーが発生して移行プロセスが中断される傾向がありますが、RDBMS でのデータへのアクセス方法および使用方法によっては、より適切な選択となる場合があります。

このソリューションでは、両方のアプローチを提示します。車両登録サンプルアプリケーションの台帳データはリレーショナルモデルに正規化されますが、台帳からの改訂メタデータは Amazon Aurora PostgreSQL に JSONB タイプとして保存されます。

ソリューション概要

移行は、フルロードと継続的なレプリケーションの 2 つのフェーズで実行されます。フルロードでは、ソースデータベースからターゲットデータベースへのデータの効率的な一括ロードが実行されます。ソースデータベースは、アプリケーションがターゲットデータベースを切り替えて使用するまでトラフィックを処理し続ける可能性があるため、フルロードでは移行されなかったデータ変更が含まれている可能性があります。継続的なレプリケーションまたは変更データキャプチャ（CDC）フェーズでは、継続的に変更を取得してターゲットデータベースに移行し、アプリケーションがターゲットデータベースを参照するまでソースと同じ最新の状態に保ちます。

フルロードフェーズでは、Amazon QLDB 台帳は AWS Step Functions ステートマシンによってAmazon Simple Storage Service (Amazon S3) のバケットにエクスポートされます。エクスポートには、エクスポートが開始された時点のすべてのトランザクションのデータが含まれます。AWS Glue ジョブは、エクスポートされたファイルから台帳文書のリビジョンを抽出し、AWS Database Migration Service(AWS DMS) が使用できる CSV 形式に変換します。AWS Glue ジョブは、変換された CSV ファイルを Amazon S3 に書き込みます。AWS DMS タスクは Amazon S3 から CSV ファイルを読み取り、そのデータを Aurora PostgreSQL データベースにロードします。この記事では Amazon Aurora PostgreSQL へのデータ移行について説明していますが、AWS DMS は様々なターゲットエンドポイントをサポートしているため、ここで説明するプロセスを他のデータベースへの移行にも適用できます。

次の図は、ソリューションのアーキテクチャを示しています。

継続的なレプリケーションフェーズでは、台帳への新しい更新がキャプチャされ、ほぼリアルタイムでターゲットの Aurora PostgreSQL データベースに移行されます。このプロセスは Amazon QLDB ストリーミング機能に依存しています。このソリューションでは、エクスポートの最後の台帳ブロックを識別して、エクスポート開始後にコミットされた最初のブロックからストリームを開始できるようにします。新しいトランザクションが台帳にコミットされると、Amazon QLDB はそれらの変更を Amazon Kinesis Data Streams に送信します。AWS Lambda 関数は、次の図に示すように、Amazon Kinesis Data Streams からのイベントを使用し、そのデータをターゲットデータベースに書き込みます。

前提条件

移行ソリューションは、インフラストラクチャをセットアップし、移行に使用されるコードをデプロイする複数の AWS CloudFormation テンプレートを使用してデプロイされます。CloudFormation テンプレートと関連ファイルは GitHub repo で入手でき、PCにダウンロードする必要があります。以下のコマンドでプロジェクトコードをダウンロードします。

git clone git@github.com:aws-samples/example-qldb-ledger-migration.git

プロジェクトには次のファイルが含まれています。

  • setup.yml – 車両登録台帳、ターゲットの Aurora PostgreSQL データベース、および関連する VPC ネットワーキングをデプロイしてデータを作成します
  • ledger-export.yml – コンポーネントをデプロイして台帳からデータをエクスポートします
  • ledger-full-migration.yml – AWS Glue コンポーネントと AWS DMS コンポーネントをデプロイして、エクスポートされた台帳データをターゲットデータベースに抽出、変換、ロード (ETL) します
  • ledger-cdc-migration.yml – Amazon QLDB ストリーミング用の Kinesis Data Stream と、ターゲットデータベースに台帳の変更を書き込むストリームコンシューマーを設定します
  • dmv-postload-ddl.sql – 移行のフルロードフェーズが完了した後にターゲットデータベースにインデックスを作成するための SQL ステートメントが含まれます

ソースデータベースとターゲットデータベースの作成

このデモンストレーションでは、ソースとして動作する Amazon QLDB 台帳とターゲットとして機能する Aurora PostgreSQL クラスターを作成し、VPC と関連ネットワーク、データベース認証情報を保持する AWS Secrets Manager シークレット、S3 バケット、AWS Identity and Access Management(IAM) ロール、および Aurora クラスターを起動するために必要なその他のコンポーネントを作成します。セットアップにより、台帳データベースにデータが入力され、Aurora PostgreSQL クラスターにデータベースとスキーマが作成され、移行用のデータベースユーザーが作成されます。

このソリューションは RDS Data API に依存していますが、すべてのリージョンで利用できるわけではありません。この表を参照して、使用しているリージョンが Data API をサポートしていることを確認してください。

このソリューションをあなた自身の移行の基礎として使用していて、Amazon QLDB 台帳と Aurora PostgreSQL クラスターがすでにセットアップされている場合、このセクションはスキップできます。

AWS CloudFormation を使用してコンポーネントをデプロイするには、以下のステップを実行します。

  1. AWS CloudFormation コンソールのナビゲーションペインで 「スタック」 を選択します。
  2. 「スタックの作成」 を選択し、「新しいリソースを使用（標準）」 を選択します。
  3. 「テンプレートファイルのアップロード」 を選択します。
  4. 「ファイルの選択」 を選択し、PC 上の GitHub プロジェクトから setup.yml ファイルを選択します。
  5. 「次へ」 を選択します。
  6. 「スタックの詳細を指定」ページで、スタック名に ledger-migrate-setup と入力します。
  7.  VPC の CIDR が環境内の他の VPC と競合しない限り、すべての入力パラメータはデフォルトのままにします。競合する場合は、VPCCIDR、DatabaseSubnetCIDRs、PublicSubnetCIDRs の各パラメータを変更して、競合しないようにしてください。また、デフォルトの AuroraDBInstanceClass パラメータを調整する必要がある場合もあります。すべてのインスタンスタイプがすべてのリージョンで利用できるわけではありません。
  8. 「次へ」 を選択します。
  9. 「スタックオプションの設定」 ページで、「次へ」 を選択します。
  10. 「確認して作成」 ページで、IAM リソースの作成の可能性を確認するチェックボックスを選択し、「送信」 を選択します。

スタックが CREATE_COMPLETE ステージになったら、「出力」タブを選択してスタックの出力を表示します。これらの値は、移行プロセスの後続ステップの入力として使用されます。

Amazon QLDB からデータをエクスポート

移行の最初のステップは、ソース台帳から S3 バケットにデータをエクスポートすることです。エクスポートは多数のファイルで構成され、各ファイルには JSON 形式の 1 つ以上の台帳ブロックが含まれます (詳細については、QLDB のジャーナルエクスポート出力を参照してください)。中規模の台帳のエクスポートでも数時間かかる場合があります。エクスポート時間を短縮するために、1 つの台帳に対して複数のエクスポートを並行して実行して、エクスポートごとに台帳の一部を処理することができます。Amazon QLDB はデフォルトで最大 2 つの同時エクスポートをサポートします。台帳が非常に大きい(数百ギガバイト) 場合は、AWS サポートに連絡して制限の引き上げをリクエストしてください。

このソリューションでは、Step Functions を使用してエクスポートを実行します。ステートマシンは、必要な数の同時エクスポートをパラメータとして受け入れます。台帳ダイジェストを取得してジャーナルの最後のブロック番号を取得し、それを使用して台帳を均等に分割し、エクスポート全体で作業を均等に分割します。ステートマシンはエクスポートジョブを開始し、すべて完了するまでループします。すべてのエクスポートジョブが完了すると、ステートマシンは各エクスポートの最後のブロックのダイジェストとプルーフハッシュを取得し、Amazon S3 に保存します。これにより、ソースの台帳が削除された後にエクスポートは暗号で検証されます (このプロセスはこの記事では説明しません)。

エクスポートを実行するには、まず AWS CloudFormation を使用して必要なコンポーネントをデプロイする必要があります。以下のステップを完了します。

  1.  AWS CloudFormation コンソールのナビゲーションペインで 「スタック」 を選択します。
  2. 「スタックの作成」 を選択し、「新しいリソースを使用 (標準)」 を選択します。
  3. 「テンプレートファイルをアップロード」 を選択します。
  4. 「ファイルを選択」 を選択し、コンピューター上の GitHub プロジェクトからledger-export.yml ファイルを選択します。
  5. 「次へ」 を選択します。
  6. 「スタックの詳細を指定」 ページで、「スタック名」 に ledger-export と入力します。
  7.  LedgerName パラメータの値はデフォルト値 (“vehicle-registration”) のままにしておきます。
  8. 「次へ」 を選択します。
  9. 「スタックオプションの設定」 ページで、「次へ」 を選択します。
  10. 「確認して作成」 ページで、IAM リソースの作成の可能性を確認するチェックボックスを選択し、「送信」 を選択します。
  11.  スタックが CREATE_COMPLETE ステージになったら、Step Functions コンソールを開き、ナビゲーションペインで 「ステートマシン」 を選択します。
  12. LedgerExporter ステートマシンを選択します。

    ステートマシンは インプットとしてJSON オブジェクトを受け入れます。
  13.  次のスニペットを JSON エディターに入力します。AWS サポートを通じて同時エクスポートの制限を増やした場合は、ExportCount の値を新しい制限に変更してください。 
    {
  "LedgerName": "vehicle-registration",
  "BucketPrefix": "dmv/",
  "ExportCount": 2
}
  14.  「実行の開始」を選択します。

    ステートマシンは、 vehicle-registration 台帳の場合は約 10 分間実行されますが、台帳が大きい場合はさらに長く実行されます。完了すると、実行ステータスは「成功」になります。実行詳細ページのグラフビューセクションには、ステートマシンのステップが視覚的に表示されます。
  15.  Export ノードを選択し、Output セクションからエクスポート ID をコピーして、テキストエディタに保存します。これらはこれ以降のステップで必要になります。
  16. ダイジェストノードを選択し、LastBlockNum と LastBlockTimestamp の値を、後で使用できるようにテキストエディタにコピーします。

エクスポートが完了しました。このプロセスにより、ledger-export-<ACCOUNT ID> という名前の S3 バケットが作成されました。このバケットには、JSON 形式でエクスポートされた台帳データを含む dmv というフォルダがあります。フォルダの名前は、ステートマシンへの入力の BucketPrefix パラメーターで設定されました。

データの抽出と変換

台帳のエクスポートが完了したら、次のステップは、エクスポートされた JSON ファイルから台帳データを抽出し、それを CSV ファイルに変換して Amazon Aurora PostgreSQL に効率的に読み込むことです。このソリューションは、抽出と変換を実行する AWS Glue ジョブを作成します。AWS Glue は Apache Spark を使用してエクスポートデータセットを複数のコンピューティングノードに分散して同時処理することで、大規模な台帳からのデータを処理するのに必要な時間を短縮します。AWS Glue ジョブは、エクスポートステップで作成された S3 バケットからエクスポートされたデータを読み取り、その出力をプロセスによって作成された新しい ETL バケットに書き込みます。

AWS Glue ジョブは、k 台帳のテーブルをターゲットデータベース用に設計したスキーマに変換し、台帳文書の構造をリレーショナルデータベースの行と列にフラット化するように構築されています。このプロセスを使用して台帳を移行するには、データモデルに合わせて AWS Glue ジョブの PySpark コードの一部を変更する必要があります。

抽出と変換を実行するには、AWS CloudFormation を使用して必要なコンポーネントをデプロイします。

  1.  AWS CloudFormation コンソールのナビゲーションペインで 「スタック」 を選択します。
  2. 「スタックの作成」 を選択し、「新しいリソースを使用 (標準)」 を選択します。
  3. 「テンプレートファイルをアップロード」 を選択します。
  4. 「ファイルを選択」 を選択し、コンピューター上の GitHub プロジェクトからledger-full-migration.yml ファイルを選択します。
  5. 「次へ」 を選択します。
    このテンプレートは、移行のこのフェーズと次のフェーズに必要なコンポーネントをデプロイします。
  6. 「スタックの詳細を指定」 ページで、「スタック名」 にledger-full-migrage と入力します。
    エクスポートスタックとは異なり、このテンプレートには入力パラメータが必要です。
  7.  次の入力パラメータを指定します。
    1.  LedgerName には、 ledger-migrate-setup スタックの LedgerName 出力パラメータの値を入力します。
    2.  ExportIds には、state 関数実行からコピーしたexport IDs を、カンマ区切りのリスト形式で入力します。
    3.  ベースプレフィックスのエクスポート に、 dmv/と入力します。
    4.  グルーワーカータイプ に、 G.2X と入力します。
    5.  グルーワーカーの数 に、2 と入力します。
    6.  レプリケーション・インスタンス・サブネットに、ledger-migrate-setup スタックのDatabaseSubnetsパラメータからサブネットを入力します。
    7.  レプリケーションインスタンスクラスに、dms.r6i.large と入力します。
    8.  セキュリティグループについては、ledger-migrate-setup スタックのDatabaseSecurityGroups パラメータからセキュリティグループを選択します。
    9.  ターゲットデータベースシークレット名には、ledger-migrate-setup スタックのMigrateDatabaseUserSecretName出力パラメータの値を入力します。
    10.  ターゲットデータベース名には、ledger-migrate-setup スタックのTargetDatabaseName 出力パラメータの値を入力します。
  8. 「次へ」 を選択します。
  9. 「スタックオプションの設定」 ページで、「次へ」 を選択します。
  10. 「確認して作成」 ページで、IAM リソースの作成の可能性を確認するチェックボックスを選択し、「送信」 を選択します。
  11.  CloudFormation スタックのデプロイが完了したら、AWS Glue コンソールに移動し、ナビゲーションペインで ETL ジョブを選択します。
  12.  ledger-dmv-migrate ジョブを選択し、「ジョブの実行」 を選択します。
  13.  ジョブの名前を選択して、ジョブの詳細ページを開きます。
  14.  「実行」 タブを選択すると、ジョブのステータスが表示されます。

ジョブが完了すると、そのステータスは「成功」 になります。

CloudFormation テンプレートは ledger-etl-<AccountId> という名前の S3 バケットを作成しました。AWS Glue ジョブは、その出力をバケットの dmv というフォルダに書き込みます。Amazon S3 コンソールを開き、ledger-etl-<AccountId> バケットに移動して、dmv フォルダを開くことができます。vehicle-registration 台帳の各テーブルに対応するフォルダのリストが表示されます。これらのフォルダには、テーブル内の削除されていないすべてのドキュメントの最新リビジョンが含まれています。ターゲットの Aurora PostgreSQL データベースに書き込まれる監査テーブルの内容を含む各台帳テーブル用の追加フォルダがあります。監査テーブルには、それぞれの元帳テーブル内のすべての文書の完全な改訂履歴が含まれています。

フォルダとそのコンテンツを確認してみてください。table_counts フォルダには、台帳の各テーブルの名前と、テーブル内のそれぞれのドキュメントリビジョン数を含む1つのファイルが格納されます。これは、すべてのレコードがターゲットデータベースに移行されたことを確認するのに役立ちます。

フルデータ移行

フルデータの移行では、AWS DMS を使用して前のステップの AWS Glue ジョブの CSV 出力を読み取り、それを Amazon Aurora PostgreSQL にロードします。AWS DMS は、データをロードする前にターゲットデータベースのテーブルを切り捨てます。この記事ではターゲットデータベースとして Amazon Aurora PostgreSQL を使用していますが、AWS DMS では AWS Glue ジョブの出力を他の多くのデータベースに移行できます。

移行を開始するには、次の手順を実行します。

  1.  AWS DMS コンソールのナビゲーションペインで 「データベース移行タスク」 を選択します。
  2.  dmv-full-migration task を選択し、「アクション」ドロップダウンで「再起動/再開」を選択します。
  3.  警告としてターゲットデータベースへのデータ損失の可能性がある再起動/再開を選択します。
    移行タスクの実行が開始されます。そのステータスにはジョブの進行状況が反映されます。ジョブが完了すると、そのステータスは 「ロード完了」 になります。この時点で、Amazon QLDB のvehicle-registration 台帳からエクスポートされたすべてのデータが Aurora PostgreSQL データベースに移行されます。次に、Aurora PostgreSQL データベースにインデックスと制約を作成します。
  4.  Amazon RDS コンソールで、前のセクションで行ったように台帳データベースに接続します。
  5.  GitHub プロジェクトの dmv-postload-ddl.sqlファイルからすべての行をコピーし、RDS クエリエディタに貼り付けて、「実行」 を選択します。
  6.  RDS クエリエディタを使用して、次のクエリのいくつかを実行して、移行されたデータを確認します。 
    select * from dmv.person; 
select * from dmv.person_audit_log;
select * from dmv.vehicle;
select * from dmv.vehicle_audit_log;
select * from dmv.vehicle_registration;
select * from dmv.vehicle_registration_audit_log;
select * from dmv.drivers_license;
select * from dmv.drivers_license_audit_log;

    テーブルの ql_audit カラムは PostgreSQL の JSON タイプです。この列には、Amazon QLDB 台帳からのリビジョンメタデータが含まれています。

  7.  次のクエリを実行して、JSON オブジェクトの個々のフィールドにアクセスする方法を確認してください。 
    select person_id, ql_audit->'ql_txid' transaction_id, ql_audit->'ql_txtime' transaction_timestamp from dmv.person_audit_log;

継続的な変更データの複製

フルデータの移行プロセスでは、台帳からエクスポートされたすべてのデータが移行されます。ただし、台帳を使用するアプリケーションが Aurora PostgreSQL データベースを使用するように変更されるまで、エクスポート後も台帳を引き続き使用できます。移行の次のステップは、実行された変更をキャプチャし、ほぼリアルタイムで Aurora PostgreSQL データベースに複製することです。このソリューションでは、Amazon QLDB ストリーミング機能を使用して、台帳の変更を Kinesis Data Stream にほぼリアルタイムで送信します。Lambda 関数はデータストリームからの台帳イベントを処理して、RDS Data API で Aurora PostgreSQL データベースに書き込みます。次の図は、このワークフローを示しています。

AWS CloudFormation を使用して変更データのレプリケーションに必要なコンポーネントをデプロイするには、以下のステップを実行します。

  1.  AWS CloudFormation コンソールのナビゲーションペインで 「スタック」 を選択します。
  2. 「スタックの作成」 を選択し、「新しいリソースを使用 (標準)」 を選択します。
  3. 「テンプレートファイルをアップロード」 を選択します。
  4. 「ファイルを選択」 を選択し、コンピューター上の GitHub プロジェクトから ledger-cdc-migration.ymlファイルを選択します。
  5. 「次へ」 を選択します。
  6. 「スタックの詳細を指定」ページで、「スタック名」に ledger-cdc-migrate と入力します。
  7. 次のスタックパラメータを入力します。
    1. AuroraClusterArn には、ledger-migrate-setup スタックの AuroraClusterArn 出力パラメータの値を入力します。
    2. AuroraDatabaseName には、ledger-migrate-setup スタックの TargetDatabaseName 出力パラメータの値を入力します。
    3. DatabaseUserSecretArnには、ledger-migrate-setup スタックからのMigrateDatabaseUserSecretARN出力パラメータの値を入力します。
    4. KinesisShardCount に 1 と入力します。
    5. LastFullLoadBlock には、エクスポートステートマシンから取得した LastBlockNum の値を入力します。
    6. LedgerName には、ledger-migrate-setup スタックからLedgerName 出力パラメータの値を入力します。
    7. LedgerStreamStartTime には、エクスポートステートマシンから取得したLastBlockTimestamp の値を入力します。
  8. 「次へ」 を選択します。
  9. 「スタックオプションの設定」 ページで、「次へ」 を選択します。
  10. 「確認して作成」 ページで、IAM リソースの作成の可能性を確認するチェックボックスを選択し、送信」 を選択します。
  11. CloudFormation スタックのデプロイが完了したら、AWS Glue コンソールに移動し、ナビゲーションペインで ETL ジョブを選択します。
    スタックのデプロイが完了すると、進行中のレプリケーションがアクティブになります。
  12. レプリケーションの動作を確認するには、Amazon QLDB コンソールの PartiQL エディタに移動します。
  13. 「台帳の選択」ドロップダウンメニューで vehicle-registration 台帳を選択し、次のクエリを入力します。 
    update Person set FirstName = 'Melvin' where GovId = 'P626-168-229-765';
  14.  RDS クエリエディタに移動し、ターゲットデータベースに対して次のクエリを実行します。 
    select * from dmv.person_audit_log where gov_id = 'P626-168-229-765'

    監査テーブルには、Melvin Parker の 2 つのレコードが含まれています。元のバージョンには、「MelVIN」というスペルのファーストネーム、0 の version 、および INSERT を表す I の operation が含まれています。アップデートされたバージョンでは、ファーストネームが「Melvin」と修正され、versionは 1 になり、UPDATE の operation は U になっています。

  15.  次に、以下のクエリを実行します。 
    select * from dmv.person where gov_id = 'P626-168-229-765'

更新されたpersonsテーブルには、Melvin Parkerのレコードの最新リビジョンが含まれています。名前とバージョン番号を書き留めておきます。

後片付け

この記事で作成した AWS インフラストラクチャを削除するには、AWS CloudFormation コンソールを開き、ledger-cdc-migrate, ledger-full-migrate, ledger-export, setup.yml の順に削除します。

スタックには、ledger-export-<AccountId> と ledger-etl-<AccountId> という 2 つの S3 バケットが残ります。これは、ソリューションが本番台帳の移行に適合している場合に、重要な Amazon QLDB 台帳データが誤って削除されないようにするためです。vehicle-registration 台帳の移行では、各バケットのコンテンツを削除してからバケットを削除します。

ソリューションを台帳に合わせて調整

この移行ソリューションは、独自の台帳で使用できるように調整できます。カスタムスキーマを作成するには、プロジェクトソースの setup.yml テンプレートファイルにある PrepareTargetDatabase リソースのスキーマ定義を変更する必要があります。また、dmv-postload-ddl.sql ファイルを変更して、カスタムスキーマのプライマリインデックスとセカンダリインデックスを作成する必要があります。

ledger-dmv-migrate のAWS Glue ジョブのPySparkコードでは、141行目から146行目まで、ソース台帳内のテーブルの変換関数と出力列が、table_convertersというPython dictで定義されています。変換機能により、台帳からの 1 つの文書リビジョンを CSV として出力できる列にフラット化します。ソースデータベースとターゲットデータベースのデータモデルのtable_converters および関連する変換関数の定義を変更します。AWS Glue ジョブのソースコードは、GitHub プロジェクトの ledger-full-migration.yml ファイルの PutGlueJobCodeToS3 リソースで定義されています。

table_converters = {
    'Person': {
        'name': 'person',
        'func': convert_person,
        'columns': ['doc_id', 'version', 'person_id', 'first_name', 'last_name', 'dob', 'gov_id', 'gov_id_type',
                    'address', 'ql_audit']

    },
    'Vehicle': {
        'name': 'vehicle',
        'func': convert_vehicle,
        'columns': ['doc_id', 'version', 'vin', 'type', 'year', 'make', 'model', 'color', 'ql_audit']
    },
    'VehicleRegistration': {
        'name': 'vehicle_registration',
        'func': convert_vehicle_registration,
        'columns': ['doc_id', 'version', 'vin', 'license_plate_num', 'state', 'city', 'pending_penalty_amt',
                    'valid_from_dt', 'valid_to_dt', 'primary_owner', 'secondary_owners', 'ql_audit']
    },
    'DriversLicense': {
        'name': 'drivers_license',
        'func': convert_drivers_license,
        'columns': ['doc_id', 'version', 'person_id', 'license_plate_num', 'license_type', 'valid_from_dt',
                    'valid_to_dt', 'ql_audit']
    }
}

Kinesis Data Stream からの台帳更新を使用する Lambda 関数には、同じロジックが含まれていますが、これも変更する必要があります。変更するコードは、GitHub プロジェクトの ledger-cdc-migration.yml ファイル内のStreamConsumerFunction リソースで定義されています。

最後に、ledger-full-migration.yml ファイル内の SourceEndpoint リソースは、AWS Glue ジョブによって生成される CSV ファイルの構造を定義する AWS DMS ソースエンドポイントを定義します。この定義は、新しい構造に合わせて変更する必要があります。AWS DMS テーブル定義形式の詳細については、「AWS DMS のソースとしての Amazon S3 の外部テーブルの定義」を参照してください。

移行を実行する前に、ターゲットデータベースをバックアップしてください。移行ソリューションはターゲットデータベースのテーブルを切り捨て、エラーが発生しても移行全体をロールバックしません。

サマリー

この投稿では、Amazon QLDB 開発者ガイドのチュートリアルにある車両登録サンプルデータベースを使用して、Amazon QLDB 台帳を Amazon Aurora PostgreSQL に移行するためのソリューションを紹介しました。このソリューションを独自の台帳の移行に適応させることができ、モジュラー設計により移行戦略に合わせて調整できます。

このソリューションの詳細や移行計画については、AWS の担当者にお問い合わせください。

著者について

Dan Blaner は、台帳とリレーショナルデータベースを専門とするプリンシパルソリューションアーキテクトです。彼は学ぶこと、物事を理解すること、他の人が物事を理解するのを助けることを楽しんでいます。休みはベースを弾き、仲の良い友達と bad music 作りを楽しんでいます。