移行ウェーブ、サーバー、データベース

移行プロジェクトは、以下の未解決の質問リストから始まります。これらの質問は、前のセクションで説明した 3 つのシナリオに共通しています。

ただし、これらの質問に対処するには、まずいくつかの定義を明確にする必要があります。ガイドのこのセクションでは、データベースという用語と、移行の波の文脈における意味に焦点を当てています。この定義は重要です。この用語を理解することで、特定の移行ウェーブの全体的な移行アプローチが変更されたり、異なるウェーブ間でサーバーを移行することで移行ウェーブが変更される可能性があるためです。

データベースという用語は、DBMS ソフトウェアを実行するサーバーを意味する言葉か、それとも論理データベースのエントリポイントを意味するのか。同じサーバ上にある複数のデータベースのうちの 1 つのデータベースを指すのか、それともサーバークラスターを指すのか。コンテキストによって、どちらの意味でもデータベースと呼ぶことがあります。データベース管理者 (DBA) は通常、物理サーバーではなく論理データベースのこととして考えます。ただし、移行、特に大規模なリフトアンドシフト移行というコンテキストにおいては通常、物理サーバーまたはサーバーのクラスターがデータベースに該当します。

論理データベースは常にアプリケーションとその依存関係の一部であるため、データベースの移行は、対象となるアプリケーションに合わせて調整し、関連付ける必要があります。ただし、その論理データベースの物理的な場所は異なる可能性があります。例えば、次のような場所にある可能性があります。

アプリケーションとデータベースサーバーの間に明確な one-to-oneの依存関係がない場合、特に異なるアプリケーションの複数の論理データベースが同じ物理サーバーにコロケーションされている場合、移行ウェーブの依存関係マッピングの作成は複雑です。このようなデータベースシステムには、リプラットフォームアプローチが必要です。これはデータベースの分解または統合を伴うアプローチのため、リフトアンドシフトによる大規模な移行作業を複雑にします。 

これは、データベース移行ツール (データベースエンジンのベンダーやサードパーティーのネイティブツールなど) が役立つ場所です。これらのツールは、 のブロックレベルのレプリケーションアプローチではなく論理データベースレベルで機能し AWS Application Migration Service、物理サーバーとロケーション間で論理レベルでデータまたはデータベースを移動できます。これらのネイティブデータベース移行ツールは、論理データベースを 1 つの物理サーバーに統合するのに役立ちます。また、さまざまな物理データベースサーバー間で論理データベースを分解して、さまざまなアプリケーションに合わせ、さまざまな移行ウェーブに分散させることもできます。