翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
ディシジョンマトリックス
移行はそれぞれ異なり、独自の課題、制約、考慮すべき複数の要因はありますが、ユースケースに最も適した移行戦略とサービスを特定するために使用できる共通の基準があります。これらの要因を特定し優先順位を付けることで、選択肢を絞り込みやすくなります。次の表を決定木として使用します。ユースケースにとって最も重要な要素から始め、移行に最適なツールを選択します。
注記
次の表は、考慮すべき高レベルの方向性要因を示しています。移行プロジェクトの基準の完全なリストは含まれていません。目的は、ブロックレベルのレプリケーション (Application Migration Service 提供) と論理的なデータレベルのレプリケーション (多数のネイティブデータベース移行ツール提供) の 2 つの大きく異なるデータ移行方法を一般化して比較することです。これら 2 つの方法は、多くの移行シナリオに適用でき、場合によっては一緒に使用できますが、表が強調する独自の利点もあります。
条件 |
AWS Application Migration Service |
データベースツール (ネイティブツールまたは AWS DMS) |
|---|---|---|
アーキテクチャ |
物理 (ブロックレベル) |
論理、データベースエンジンレベル |
スケール |
大規模な移行 |
詳細、スケール制限 |
スピードと複雑さ |
迅速な終了シナリオ、複雑さの軽減 |
より低速で複雑なアプローチ、より多くの計画とテストが必要 |
タイムライン |
アグレッシブなスケジュールをサポート |
追加の労力と時間が必要 |
移行タイプ |
リフトアンドシフトはそのまま (1 対 1 のみ) |
分解および統合オプションを使用したリプラットフォームまたはモダナイゼーション (1 対多、多対 1) |
事前プロビジョニング |
不要。自動移行 |
データベースとインフラストラクチャのプロビジョニングが必要 |
ダウンタイム |
RTO (数分以内) のダウンタイムが必要 |
ダウンタイムはほぼゼロになる (同期/非同期拡張クラスター、CDC レプリケーション、および同様の方法による) が、非常にコストがかかる |
データ変更率 |
ネットワークやパフォーマンスが制限されている可能性がある |
その他のオプションも利用可能 |
制限 |
ほとんどのクラスターシステムをサポートしていません。* は x86 プラットフォームのみをサポートします** |
ネイティブデータベースツールは、クラスター化されたデータベースと x86 以外のプラットフォームをサポートします。 AWS DMS は大半のデータベースエンジンに対応しています。 |
* ブロックレベルのレプリケーションメソッドは、ネットワーク接続ストレージ (NAS)、NFS 共有などの共有ドライブ、または CIFS/SMB 共有をサポートしていません。移行時に移行されたシステムに直接アタッチされたブロックレベルのストレージのみをサポートします。(詳細については、SAN/NAS サポートに関する Application Migration Service のよくある質問を参照してください）。これにより、ほとんどのクラスターシステムはさまざまな実装の共有ストレージに依存するため、Application Migration Service によるレプリケーションの適用可能性が制限されます。詳細については、このガイドの前半の「 を使用した移行」セクションの「利点と欠点」を参照してください。 AWS Application Migration Service
** ブロックレベルのレプリケーション方法では、レプリケーションエージェントを OS AWS レベルでインストールする必要があり、そのエージェントは Windows または Linux オペレーティングシステムに基づく x86 プラットフォームのみをサポートします (「Application Migration Service でサポートされているオペレーティングシステム」を参照）。Non-x86プラットフォームは、この移行方法の対象外です。これには、ARM、RISC/CISC システム、PowerPC バリエーション、pSeries、iSeries、zSeries などの IBM システム、および AIX、HP-UX、Solaris、Linux for PowerPC、メインフレーム上の zLinux、その他の非 x86 アーキテクチャなどのそれぞれのオペレーティングシステムが含まれます。
