Amazon Web Services ブログ
Amazon RDS for Db2 へのデータマイグレーション戦略
本記事は、2024年5月15日に公開された Data migration strategies to Amazon RDS for Db2 を翻訳したものです。
AWS は re:Invent 2023 で Amazon Relational Database (Amazon RDS) for Db2 を発表しました。RDS for Db2 は、Amazon RDS に新しく追加されたデータベースエンジンです。 最適なパフォーマンスを実現するスケーラブルなハードウェアで、数分で Db2 データベースを展開できます。 また、Multi-AZ デプロイメントを使えば、別の Availability Zone にあるスタンバイデータベースインスタンスにデータを同期レプリケーションする、高可用性データベースを構築できます。
このブログでは、Amazon RDS for Db2 の組み込み機能と AWS Database Migration Service (AWS DMS) または Db2 Migration Tooling (Db2MT) を使用して、セルフマネージド型の Db2 データベースを RDS for Db2 に移行する手順を説明します。 まず、採用できる様々な移行戦略の概要を示し、次に移行方法について説明し、最後に移行の計画のためのベストプラクティスを紹介します。
マイグレーション戦略
マイグレーション戦略は、セルフホスティングの Db2 データベースのオペレーティングシステムによって異なります。 ソースデータベースとターゲットデータベースのオペレーティングシステムが同じ場合 (例えば Linux から Linux へ) 、そのマイグレーションは リホスト と呼ばれます。 ソースデータベースのオペレーティングシステムが宛先データベースとは異なる場合 (例えば z/OS から Linux へ) 、そのマイグレーションは リプラットフォーム と呼ばれます。 次の表は、ソースデータベースの基盤となるオペレーティングシステムに基づく リホスト と リプラットフォーム の詳細をまとめたものです。
マイグレーション戦略 | リホスト | リプラットフォーム | 備考 |
オペレーティングシステム | Linux | Linux 以外 (z/OS、AIX、Windows など) | ネイティブの IBM Db2 マイグレーションツール、DMS、サードパーティ製品を使用できます。 |
マイグレーションのスピード | 高速 | 低速 | リホストの方が変換が不要なので高速です。 リプラットフォームは変換が必要で時間がかかります。 |
Db2 オフライン リストア | はい | いいえ | Db2 のバックアップとリストアを使用します。リストアが完了するまでダウンタイムが発生します。 |
Db2 オンライン リストア | はい | いいえ | Db2 のバックアップとロールフォワードリストアを使用します。短時間のダウンタイムですが、完了までに時間がかかる場合があります。 |
Db2 エクスポートまたはインポート | はい | はい | 論理マイグレーションには Db2 のエクスポートとインポートを使用します。リプラットフォームの場合は変換のために時間がかかります。 |
クライアントからのロード | はい | はい | Db2 を使用します。 |
Amazon S3 からのロード | はい | はい | リプラットフォームの場合は高速です。 |
AWS DMS | はい | はい | レプリケーション |
IBM CDC レプリケーション | はい | はい | レプリケーション |
IBM Q レプリケーション | はい | はい | レプリケーション |
メタデータの忠実性(+) | 高い | 中程度 | リプラットフォームの場合は忠実性に特に注意が必要です。 |
データの品質 | 高い | 中程度 | リプラットフォームの場合は品質に特に注意が必要です。 |
使いやすさ | 簡単 | 複雑 | リホストの方が簡単です。 |
導入のワークロード | 低い | 高い | リプラットフォームには大きなワークロードが必要です。 |
(+)ソースからターゲットに移行される際、データベーススキーマの再構築方法によっては、メタデータが正確に再現されないことがあります。例えば、自動インクリメントの開始点、シーケンス、隠し列、チェック制約、外部キー制約の適用などが正しく適用されない事があります。
Amazon RDS へのリホスト (同一オペレーティングシステムへの移行)
セルフ運用している Db2 データベースが、リトルエンディアンの 64 bit Linux プラットフォーム上で実行されている場合、Amazon RDS for Db2 へリホストできます。 たとえば、Linux on Intel、AMD、Linux POWER LE (リトルエンディアン) 上のセルフ運用している Db2 データベースはリホストできますが、AIX、zLinux、Windows 上のものはリホストできません。
Amazon RDS へのリプラットフォーム (異なるオペレーティングシステムへの移行)
セルフ運用している Db2 のオペレーティングシステムが Linux (リトルエンディアン) 以外の場合、ソースの Db2 データベースを Amazon RDS for Db2 にリプラットフォームする必要があります。 セルフ運用の Db2 データベースが AIX、Windows、zLinux などのオペレーティングシステム上で実行されている場合、Amazon RDS for Db2 でリプラットフォームできます。 再プラットフォームは、より広範な移行プロセスの第一段階と見なされ、組織はデータベースを迅速にAmazon RDS for Db2に移行し、その後、徐々に最適化や再アーキテクチャを検討することができます。
Amazon RDS for Db2 を使用して DB をリホストおよびリプラットフォームする移行方法
移行方法の選択は、ソースDb2のオペレーティングシステムの種類と許容できるダウンタイムによります。移行速度を確認するために、適切なサイズのデータベースを使ったテスト移行を行い、エンドツーエンドの移行時間を把握することをお勧めします。許容できるダウンタイムに応じて、一回限りの移行またはログレプリケーションを用いた移行のいずれかを選択できます。ビジネスニーズに基づいて適切なレプリケーション方法を選択するために、次の意思決定ツリーを参照してください。
Amazon RDS によるリホスト
セルフ運用の Db2 データベースが、Linux 上で実行されている場合は、Amazon RDS for Db2 にリホストできます。Linux からの移行はデータ変換を必要としないため、再プラットフォームよりも簡単かつ短時間で完了します。移行には Db2 のネイティブツールを使用し、複雑なデータ構造の変更や最適化を避けます。
ワンタイムマイグレーション
データベースのバックアップ、リストア、および切り替えを行う全体的な時間が許容できるダウンタイム内であれば、ワンタイム移行を利用できます。 セルフ運用の Db2 Linux データベースのバックアップを直接 Amazon Simple Storage Service (Amazon S3) にコピーし、Amazon RDS for Db2 でリストアするために、Db2 Migration Tooling (Db2MT) を使用します。 Db2MT は、移行を完了するために必要なスクリプトを作成し、バックアップとリストアの両方を並列化して移行を高速化します。 次の図はそのソリューションアーキテクチャーを示しています。
手動でデータ移行を行う場合は、Amazon S3 からオフラインバックアップを復元するため、RDS for Db2 のストアードプロシージャ restore_database を呼び出すことができます。
ログレプリケーションを使用した移行
初期テスト移行によって測定された移行時間が許容できるダウンタイムよりも長い場合、A/Bデプロイメントアプローチを使用して、Linux上のセルフ運用のDb2からAmazon RDS for Db2へのログレプリケーションを使用した移行を実行できます。このアプローチでは、新しいRDS for Db2データベース(A)を旧データベース(B)と並行して使用し、準備が整った時点で切り替えを行います。
Db2MT は、前のセクションで説明したように、ユーザーが管理する Linux の Db2 のオンラインデータベースバックアップを直接 Amazon S3 に取得し、次に Amazon RDS for Db2 で復元するための手順を提供しています。Db2MT はまた、定期的にログを直接 Amazon S3 にアーカイブし、データベースをロールフォワードペンディングモードに維持して、ログを RDS for Db2 に適用する手順も提供します。ロールフォワード操作を完了することで、最終的に切り替えを行うことができます。 次の図は、このソリューションのアーキテクチャを示しています。
Amazon RDS for Db2 のストアードプロシージャ restore_database
を使用して、backup_type
を ONLINE
に設定することで、オンラインバックアップイメージを復元できます。 Amazon RDS for Db2 のストアードプロシージャ rollforward_database
を使用して、アーカイブログを適用できます。 切り替え準備ができたら、ストアードプロシージャ complete_rollforward
を実行して、データベースの復旧を完了し、Amazon RDS for Db2 データベースを接続可能な状態にできます。
Amazon RDS へのリプラットフォーム
もう 1 つの主要な課題は、AIX、Windows、メインフレー上の Db2 on Linux (ビッグエンディアン) から、スピーディかつダウンタイムをほぼゼロに抑えてデータを移行することです。 Amazon RDS へのリプラットフォームは、リホストに比べてより時間がかかります。 これは、AIX、Windows、メインフレーム上の Db2 on Linux から Db2 バックアップイメージを復元できないためです。 これは、リトルエンディアンとビッグエンディアンの違いが原因です。
ソースの Db2 データベースからメタデータを抽出し、Amazon RDS for Db2 に適用する必要があります。 最良の方法は、他のサードパーティツールが使用するリバースエンジニアリング方法と比較して、メタデータの再現度が最も高いネイティブツールである db2look を使用することです。
Db2 のネイティブツールである export を使用して、データをアンロードし、ネイティブツールである import または load を使用して、ソースから RDS for Db2 データベースに移行できます。 移行の相対的な速度については、次の図を参照してください。
AWS DMS は、セルフ運用されている Db2 データベースから Amazon RDS for Db2 に移行する処理を簡素化するマネージドサービスです。AWS DMS は Db2 をターゲットエンドポイントとしてサポートし、Amazon RDS for Db2へのフル ロードとChange Data Capture (CDC) の両方の移行方法に対応しています。
別の方法として、Db2MT を使えば、メタデータを抽出し、データをアンロードすることができます。抽出したメタデータを使用してデータベースオブジェクトを作成し、その後 Db2MT を利用して Amazon S3 から直接 Amazon RDS for Db2 にデータをロードできます。 これらのタスクは自動化されており、簡単なDb2MTコマンドを使用して各タスクを開始できるため、抽出および並列化の複雑なプロセスに取り組む必要はありません。
データベースの移行速度は、適度な量のデータを使ったサンプル移行を行って判断することをお勧めします。これにより、一括の移行か、ログレプリケーションによる移行のどちらを使うべきかが判断できます。
ワンタイム移行
カットオーバー時間を含めた合計時間がダウンタイムの許容範囲内であれば、ワンタイム移行を選択できます。AIX または Windows から移行し、データを Amazon RDS for Db2 にロードする場合は、Db2MT の利用をおすすめします。次の図に、このソリューションのアーキテクチャを示します。
Amazon RDS for Db2 は、Amazon S3 から直接データを読み込む機能をネイティブでサポートしています。Db2MTは DB2REMOTE ID を使用し、Amazon S3へのストレージアクセスを利用して、Amazon RDS for Db2に接続されたDb2クライアントを通じてAmazon S3から直接データをロードします。
ログレプリケーションによる移行
初期テスト移行を通じて測定された移行時間が停止時間の範囲を超える場合、AIX または Windows 上のセルフ運用の Db2 から Amazon RDS for Db2 への移行にログ レプリケーションを使用することができます。
前述の Db2MT を使用して ワンタイム移行を完了するステップに従います。次のいずれかの方法を使用してダウンタイムがほぼゼロの移行を実現できます。
- AWS DMS – AWS では、Db2 をソースとターゲットとしてサポートしています。AWS DMS のレプリケーションインスタンスを使用することで、ソースの Db2 データベースから Amazon RDS for Db2 に変更を同期できます。
- IBM Q Replication – IBM Q Replication を使用して、AIX、Windows、メインフレーム上のLinux (ビッグエンディアン) で実行されている Db2 からのダウンタイムをほとんどなくす移行を実現できます。
次の図は、このソリューションのアーキテクチャを示しています。
移行プロジェクトの計画
データ移行プロセスでは、メタデータの忠実性の確保、データの整合性と品質の確保、AWS DMS などの既存の Amazon RDS サービスを使用したパフォーマンス上の懸念、コスト管理、統合への対処、レガシーアプリケーションのサポート、ネットワーク帯域幅、事業継続、災害対策、安全なアクセスのための入念な計画が必要であり、次のフェーズを含みます。
- 準備と計画:
- データベースサイズと複雑性の分析 – データベースのサイズとデータの複雑さを理解する。これは移行に必要な時間とリソースを見積もるのに役立ちます。
- ピークとオフピーク時間の特定 – ユーザへの影響を最小限に抑えるため、オフピーク時にデータ移行を行うようにスケジューリングします。
- テスト:
- 移行プロセスのテスト – ステージング環境で徹底的なテストを実施し、潜在的な問題を特定し、移行プロセスを洗練します。
- パフォーマンステスト -実際のデータ転送を効率的に処理できるかを確認するために、負荷をかけて移行プロセスをテストします。
- 段階的な移行:
- 段階的なデータ移行 – 一度にすべてのデータを移行するのではなく、小さなチャンクに分割して移行することを検討します。このアプローチはリスクを低減し、移行スピードの改善に役立ちます。
- レプリケーション – 最終的な切り替えまで、新しいデータベースが古いデータベースと同期する状態を維持するために、データベースレプリケーションを使用します。
- 監視とバックアップ:
- 継続的な監視 – 問題やパフォーマンスのボトルネックがないか、移行プロセスを注意深く監視します。
- バックアップ – 万が一の場合に備えて、元のデータベースのバックアップを必ず取っておきます。
- 最終的な切り替えと検証:
- 切り替え – すべてのデータが正確に転送され、新しいシステムの準備が整ったことを確認した後、最終的な切り替えを行います。
- 移行後の検証 – 新しいシステムのデータの整合性とパフォーマンスを確実に確認するため、徹底的なチェックを実施します。
データベースの移行はそれぞれ固有のものであり、前述の戦略は、個々の状況と要件に合わせてカスタマイズする必要があります。さらに、経験豊富なデータベース管理者や技術者のチームを巻き込むことで、スムーズかつ効率的な移行プロセスを実現できます。
まとめ
このブログでは、Db2 から Amazon RDS for Db2 へ移行するためのリホストとリプラットフォームの戦略を示しました。リホストは、Db2MT を使用して既存システムへの変更を最小限に抑えながら Amazon RDS for Db2 に移行することを目指す組織にとって、簡単で効率の良いアプローチとなります。リプラットフォームは、フルロードと CDC を利用可能なAWS DMS または IBM Q Replication を利用可能な Db2MT を使用します。
どちらのアプローチも、アーキテクチャやアプリケーションの機能を変更する複雑さを伴わずに、Amazon RDS for Db2の強化されたスケーラビリティや潜在的なコスト削減などの即時の利点を提供します。また、Amazon RDS によるリホストまたはリプラットフォームは、AWS への移行の足がかりとなり、将来のモダナイゼーションおよび最適化の取り組みの基盤を築きます。
このブログにコメントをお寄せいただき、Db2 用 Amazon RDS に関する今後の投稿についてご要望をお聞かせください。 サービスの詳細は、Amazon RDS for Db2 ユーザーガイドをご覧ください。
著者について
Vikram S Khatri は Amazon RDS for Db2のシニアプロダクトマネージャーです。VikramはDb2に関して20年以上の経験を持っています。彼はゼロから新しい製品を開発することを楽しんでいます。余暇には瞑想やポッドキャストを聞くことを楽しんでいます。
翻訳は、Solution Architect の 野間が担当しました。原文はこちらです。