ネイティブデータベースツールと AWS DMS を使用した移行 - AWS 規範ガイダンス
利点欠点

翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

ネイティブデータベースツールと AWS DMS を使用した移行

多くの DBA は、データベースの移行と複製を処理するさまざまなツールに精通しています。これらのツールは、通常、データベースエンジンベンダーやサードパーティー企業によって提供され、Application Migration Service が提供する完全にアプリケーションに依存しないブロックレベルのレプリケーションアプローチとは異なり、特定のデータベースエンジンの論理レベルで動作します。 

最も単純なアプローチからより複雑なアプローチまで、これらのツールのリストを次に示します。

  • フルバックアップ/復元は、IT スタッフにとって非常に馴染みのある、使いやすいプロセスです。その方法はデータベースエンジンのタイプに応じて異なります。このプロセスは通常、同じデータベースサーバーにコロケーションされている複数の論理データベースを移動し、Amazon Relational Database Service (Amazon RDS) などのマネージドサービスにデータベースを復元するためにも使用できます。バックアップ/復元は最も単純な方法ですが、バックアップのサイズと、ターゲットデータベースでの作成、コピー、および復元に必要な時間により、他のオプションに比べてカットオーバー時間が大幅に長くなります。このアプローチの詳細については、 AWS 「 規範ガイダンス」ウェブサイトの「ネイティブ SQL Server のバックアップ/復元」と「Oracle RMAN」を参照してください。

  • 論理的なバックアップまたはエクスポート論理データベースの全体または一部のコピーを取るもう 1 つの方法です。このネイティブデータベースエンジンツールを使用すると、大規模なデータベースサーバーを分解し、特定のアプリケーションに関連する特定のデータベースを選んで移行できます。移行対象をフルバックアップ/復元するよりも細かく制御でき、ターゲットとして Amazon RDS もサポートされます。ただし、この方法でも、前の方法と同じ理由から、カットオーバー時間が長くなります。

  • ネイティブデータベースの高可用性 (HA) ツールには、Microsoft SQL Server の Always On または分散可用性グループクラスターと Oracle の Data Guard レプリケーションが含まれます。このアプローチでは、拡張されたクロスサイト HA クラスター間で をセットアップするための多大な労力が必要であり、完全に同期したアクティブ/アクティブデプロイを実現するためにレイテンシーが長くなるため、パフォーマンスが低下する可能性があります。ただし、この方法では、カットオーバー中のダウンタイムはほぼゼロに近い状態になります。

  • 変更データキャプチャ (CDC) レプリケーションは、AWS Database Migration Service (AWS DMS) と Oracle GoldenGate、Qlik、Talend などのネイティブデータベースレプリケーションツールでサポートされています。これらのツールを使用すると、ターゲットデータベースとソースデータベースの同期が保たれるため、データベースの一部または全体をコピーする際のダウンタイムがほとんど発生しないというメリットがあります。このメソッドを AWS Schema Conversion Tool (AWS SCT) および異種移行 AWS DMS に使用し、データベースを同時に移行およびモダナイズすることもできます。

  • データベースの移行中にネットワークのスループットがボトルネックになる場合、 AWS DMS と AWS Snowball を組み合わせて使用することで、非常に大規模なデータベースの移行とモダナイズが可能となります。詳細については、ブログ記事「 AWS DMS と を使用して大規模なデータベース移行を有効にする AWS Snowball」を参照してください。

利点

移行にデータベースツールを使用することには、ブロックレベルのレプリケーション方法に比べて以下の利点があります。 

  • ツールの中には、ダウンタイムを最小限に抑えて移行できるものもあります。これには、ネイティブ HA クラスターまたは CDC レプリケーションをサポートする AWS DMS および ネイティブツールが含まれます。

  • ほとんどの DBAs に慣れているツールを使用して、クラスター化されたデータベースを移行できます。

  • 移行ワークフローの一部としてデータベースのモダナイズを行い、Amazon RDS や Amazon Aurora などのマネージドデータベースサービスに移行できます。

  • モノリシックインフラストラクチャからマイクロサービスに移行する場合、大規模なデータベースサーバーまたはクラスターを分割する場合、または小規模なデータベースを大規模なインスタンスまたは にマージする場合、統合と分解 (またはデータベースの部分的な移行) を活用できます AWS のサービス。 

欠点

前のセクションで説明した利点のほとんどは、一般的なリフトアンドシフト移行シナリオの範囲外であり、リプラットフォームアプローチに該当します。さらに、ネイティブデータベースの移行方法を用いた大規模な移行では、次のような欠点があります。

  • 準備 — ネイティブデータベースメソッドを使用する前に、ターゲットインフラストラクチャ、データベースサーバー、およびクラスターを事前にプロビジョニングして設定する必要があります。

  • 複雑さ — フルバックアップや論理バックアップ/復元などの方法によっては、最初のバックアップが作成されてからのすべての変更を検出するために、別のレプリケーション方法と組み合わせる必要があります。

  • スケーラビリティ – 大規模な移行時にこれらのメソッドを他のデータベースクラスターやサーバーにロールアウトできるシンプルな自動化フレームワークはありません。