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

# SQL Server データベースの移行戦略
<a name="strategies"></a>

大まかに言うと、SQL Server データベースをオンプレミスから AWS クラウドに移行するには 2 つのオプションがあります。SQL Server に留まる ([同種移行](homogeneous-migration.md)) か、SQL Server から移行する ([異種移行](heterogeneous-migration.md)) です。同種移行では、データベースエンジンを変更する必要はありません。つまり、ターゲットデータベースは SQL Server データベースでもあります。異種移行では、SQL Server データベースを MySQL、PostgreSQL、MariaDB などのオープンソースデータベースエンジン、または Amazon Aurora、Amazon DynamoDB、Amazon Redshift などの AWS クラウドネイティブデータベースに切り替えます。

SQL Server データベースを AWS に移行するには、リホスト、リプラットフォーム、リアーキテクト ( リファクタリング ) という 3 つの一般的な戦略があります。これらは[アプリケーション移行戦略の 7 R](https://docs.aws.amazon.com/prescriptive-guidance/latest/strategy-database-migration/planning-phase.html) の一部であり、次の表で説明しています。


****  

| 方針 | タイプ | いつ選択するか | 例 | 
| --- | --- | --- | --- | 
| **リホスト** | 同種 | オペレーティングシステム、データベースソフトウェア、または構成の変更の有無にかかわらず、SQL Server データベースをそのまま移行したいと考えています。 | SQL サーバーから Amazon EC2 へ | 
| **リプラットフォーム** | 同種 | フルマネージド型のデータベース製品を使用して、データベースインスタンスの管理に費やす時間を削減したいと考えています。 | SQL Server から Amazon RDS for SQL Server へ | 
| **リアーキテクト (リファクタリング)**  | 異種 | オープンソースおよびクラウドネイティブのデータベース特徴量を活用するために、データベースとアプリケーションを再構築、再書き込み、リアーキテクトしたいと考えています。 | SQL Server から Amazon Aurora PostgreSQL、MySQL、または MariaDB へ | 

SQL Server データベースをリホストするかリプラットフォームするかを決める場合は、このガイドの後半にある「 [Amazon EC2 と Amazon RDS のどちらを選択するか](comparison.md)」で、サポートされている特徴量を並べて比較してください。

## 適切な移行戦略を選択する
<a name="choose-strategy"></a>

適切な戦略の選択は、ビジネス要件、リソースの制約、移行期間、コストに関する考慮事項によって異なります。次の図は、7 つの戦略すべてを含めて、移行に伴う労力と複雑さを示しています。

 ![\[Comparison of SQL Server migration strategies\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/migration-sql-server/images/migration-strategy-comparison.png) 

SQL Server データベースをリファクタリングし、Amazon Aurora PostgreSQL 互換エディションや Aurora MySQL 互換エディションなどのオープンソースまたは AWS クラウドネイティブデータベースに移行すると、データベースのモダナイズと最適化に役立ちます。オープンソースデータベースに移行することで、高額なライセンス (コスト削減)、ベンダーロックイン期間、監査を回避できます。ただし、ワークロードの複雑さによっては、SQL Server データベースのリファクタリングは複雑で時間がかかり、リソースを大量に消費する作業になる可能性があります。

複雑さを軽減するために、データベースの移行を一度に行うのではなく、段階的なアプローチを検討するとよいでしょう。最初の段階では、データベースのコア機能に集中することができます。次のフェーズでは、追加の AWS サービスをクラウド環境に統合してコストを削減し、パフォーマンス、生産性、コンプライアンスを最適化できます。例えば、オンプレミスの SQL Server データベースを Aurora MySQL 互換エディションに置き換えることが目標の場合、最初のフェーズで Amazon EC2 でデータベースをリホストするか、Amazon RDS for SQL Server でデータベースをリプラットフォームすることを検討し、次のフェーズで Aurora MySQL 互換エディションにリファクタリングすることを検討してください。このアプローチは、移行フェーズではコスト、リソース、リスクを削減するのに役立ち、第 2 フェーズでは最適化とモダナイズに重点を置きます。

## オンラインとオフラインの移行
<a name="online-offline"></a>

SQL Server データベースをオンプレミス環境または別のクラウド環境から AWS クラウドに移行するには、移行のタイムラインと許容できるダウンタイムの長さに基づいて、オフライン移行とオンライン移行の 2 つの方法があります。
+ **オフライン移行**: この方法は、アプリケーションに計画的なダウンタイムを許容できる場合に使用されます。オフライン移行では、移行期間中はソースデータベースがオフラインになります。ソースデータベースがオフラインの間は、AWS 上のターゲットデータベースに移行されます。移行が完了すると、確認と検証のチェックが行われ、ソースデータベースとのデータ整合性が確保されます。データベースがすべての確認チェックに合格したら、アプリケーションを AWS のターゲットデータベースに接続して AWS へのカットオーバーを実行します。
+ **オンライン移行：**この方法は、アプリケーションのダウンタイムをゼロに近いか最小限に抑える必要がある場合に使用されます。オンライン移行では、ソースデータベースは複数のステップで AWS に移行されます。最初のステップでは、ソースデータベースがまだ稼働している間に、ソースデータベース内のデータがターゲットデータベースにコピーされます。以降のステップでは、ソースデータベースからのすべての変更がターゲットデータベースに反映されます。ソースデータベースとターゲットデータベースが同期すると、カットオーバーの準備が整います。カットオーバー中、アプリケーションは AWS でターゲットデータベースへの接続をオンに切り替え、ソースデータベースへの接続は残りません。AWS Database Migration Service(AWS DMS) または [AWS Marketplace](https://aws.amazon.com/marketplace/) から入手できるツール (Attunity など ) を使用して、ソースデータベースとターゲットデータベースを同期できます。