翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
# AWS DMS レプリケーションインスタンスの使用
AWS DMS レプリケーションインスタンスを作成すると、 は Amazon VPC サービスに基づく Virtual Private Cloud (VPC) の Amazon EC2 インスタンスにそのインスタンス AWS DMS を作成します。このレプリケーション インスタンスを使用して、データベース移行を実行します。**[Multi-AZ]** (マルチ AZ) オプションを選択した場合、レプリケーション インスタンスはマルチ AZ 配置を使用して高可用性およびフェイルオーバー サポートを提供します。
マルチ AZ 配置では、 はレプリケーションインスタンスの同期スタンバイレプリカ AWS DMS を別のアベイラビリティーゾーンに自動的にプロビジョニングして維持します。プライマリレプリケーション インスタンスは、同期的にアベイラビリティーゾーン間でスタンバイレプリカにレプリケートされます。このアプローチでは、データの冗長性が確保されて I/O のフリーズは排除されるため、レイテンシーのスパイクは最小限に抑えられます。
![\[AWS Database Migration Service レプリケーションインスタンス\]](http://docs.aws.amazon.com/ja_jp/dms/latest/userguide/images/datarep-conceptual2.png)
AWS DMS は、レプリケーションインスタンスを使用してソースデータストアに接続し、ソースデータを読み取り、ターゲットデータストアで使用するためにデータをフォーマットします。レプリケーション インスタンスもターゲットデータストアにデータをロードします。この処理のほとんどはメモリ内で行われます。ただし、大きいトランザクションではディスクでのバッファリングが必要になることがあります。キャッシュされたトランザクションとログファイルもディスクに書き込まれます。
AWS DMS レプリケーションインスタンスは、次の AWS リージョンで作成できます。
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/dms/latest/userguide/CHAP_ReplicationInstance.html)
AWS DMS は、米国政府機関と顧客が機密性の高いワークロードをクラウドに移行できるようにする という特別な AWS リージョンをサポートしています。 AWS GovCloud (US) AWS GovCloud (US) は、米国政府の特定の規制およびコンプライアンス要件に対応しています。詳細については AWS GovCloud (US)、[GovCloud (米国) とは AWS 」を参照してください。](https://docs.aws.amazon.com/govcloud-us/latest/UserGuide/whatis.html)
以下で、レプリケーション インスタンスの詳細についてご参照ください。
**Topics**
+ [移行に適した DMS AWS レプリケーションインスタンスの選択](CHAP_ReplicationInstance.Types.md)
+ [レプリケーションインスタンス向けの最適なサイズの選択](CHAP_BestPractices.SizingReplicationInstance.md)
+ [レプリケーションエンジンバージョンの操作](CHAP_ReplicationInstance.EngineVersions.md)
+ [パブリックおよびプライベートレプリケーション インスタンス](CHAP_ReplicationInstance.PublicPrivate.md)
+ [IP アドレス指定とネットワークタイプ](CHAP_ReplicationInstance.IPAddressing.md)
+ [レプリケーション インスタンスのためのネットワークのセットアップ](CHAP_ReplicationInstance.VPC.md)
+ [レプリケーション インスタンスのための暗号化キーの設定](CHAP_ReplicationInstance.EncryptionKey.md)
+ [レプリケーション インスタンスの作成](CHAP_ReplicationInstance.Creating.md)
+ [レプリケーション インスタンスの変更](CHAP_ReplicationInstance.Modifying.md)
+ [レプリケーション インスタンスを再起動する](CHAP_ReplicationInstance.Rebooting.md)
+ [レプリケーション インスタンスを削除する](CHAP_ReplicationInstance.Deleting.md)
+ [AWS DMS メンテナンスウィンドウの使用](CHAP_ReplicationInstance.MaintenanceWindow.md)
# 移行に適した DMS AWS レプリケーションインスタンスの選択
AWS DMS は Amazon EC2 インスタンスにレプリケーションインスタンスを作成します。 AWS DMS は現在T3, C5, C6i, R5、R6i Amazon EC2 インスタンスクラスをサポートしています。
+ T3 インスタンスは次世代バースト可能汎用インスタンスタイプです。このインスタンスタイプはいつでも必要な時間だけ CPU 使用率をバーストさせる機能を備えベースラインレベルの CPU パフォーマンスを提供します。T3 インスタンスはコンピューティング、メモリ、ネットワークリソースを提供し、一時的な使用スパイクが発生する CPU 使用率の中程度のアプリケーション向けに設計されています。T3 インスタンスはワークロードがベースラインしきい値を下回って動作している場合、CPU クレジットを累積します。獲得した CPU クレジットはフル CPU コアパフォーマンスで必要に応じて 1 分間バーストさせる機会を T3 インスタンスに提供します。
T3 インスタンスは必要に応じて `unlimited` モードでいつでもバーストできます。`unlimited` モードの詳細については、「[バーストパフォーマンスインスタンスの Unlimited モードでの作業](#CHAP_ReplicationInstance.Types.UnlimitedMode)」をご参照ください。
+ C5 インスタンスはアドバンスト コンピューティング集約型ワークロードを実行するためにコンピューティング比あたりの低コストでコスト効率の高いパフォーマンスを実現する次世代インスタンスタイプです。これには、ハイパフォーマンスウェブサーバー、ハイパフォーマンスコンピューティング (HPC)、バッチ処理、広告配信、高スケーラビリティのあるマルチプレイヤー ゲーム、ビデオ エンコーディングなどのワークロードが含まれます。その他のワークロード C5 インスタンスは科学的モデリング、分散分析、マシンおよび深層学習の推論などに適しています。C5 インスタンスは Intel および AMD のプロセッサーの選択で利用できます。
+ C6i インスタンスは、さまざまなワークロードに対し、同等の Gen5 インスタンスと比較して最大 15 % 優れたコンピューティングコストパフォーマンスと常時オンのメモリ暗号化を提供します。C6i インスタンスは、バッチ処理、分散分析、ハイパフォーマンスコンピューティング (HPC)、広告配信、高スケーラビリティのマルチプレイヤーゲーム、動画エンコーディングなど、コンピューティング集約型のワークロードに最適です。
+ R5 インスタンスは次世代のメモリ最適化 Amazon EC2 インスタンスタイプです。R5 インスタンスはハイパフォーマンス データベース、ウェブ スケール分散インメモリキャッシュ、中規模のインメモリデータベース、リアルタイム ビッグデータ分析、その他のエンタープライズアプリケーションなど、メモリを大量に消費するアプリケーションに最適です。を使用した高スループットトランザクションシステムの継続的な移行やレプリケーションも、大量の CPU とメモリを消費 AWS DMS する可能性があります。
+ R6i インスタンスは、さまざまなワークロードに対し、同等の Gen5 インスタンスと比較して最大 15 % 優れたコンピューティングコストパフォーマンスと常時オンのメモリ暗号化を提供します。R6i インスタンスは SAP 認定を受けており、SQL データベースや noSQL データベースなどのワークロード、Memcached や Redis OSS などの分散ウェブスケールインメモリキャッシュ、SAP HANA などのインメモリデータベース、Hadoop クラスターや Spark クラスターなどのリアルタイムビッグデータ分析に最適です。
+ C7i インスタンスは、同等の前世代のインスタンスよりも優れたコンピューティングパフォーマンスを提供します。 AWS DMS ワークロードの場合、C7i インスタンスはデータ変換プロセスの加速、計算負荷の高いスキーマ変換の処理、大量の移行タスク中の一貫したスループットの維持に優れています。これらのインスタンスは、持続的な CPU パフォーマンスを必要とするコンピューティングパフォーマンスの理想的なバランスを提供します。
+ R7i インスタンスは、同等の前世代のインスタンスよりも優れたコンピューティングパフォーマンスを提供し、メモリを大量に消費するワークロードに対して高いメモリ容量を提供します。 AWS DMS ワークロードの場合、R7i インスタンスは大量の同時データベーストランザクションを処理する大規模なデータベースを含むタスクに特に適しています。これにより、大量のメモリを必要とするレプリケーションシナリオや、大量のメモリバッファを必要とする複雑なデータ検証プロセスを効率的に処理できます。
レプリケーション インスタンスごとに、メモリと vCPU の固有の設定があります。次の表は、各レプリケーション インスタンスタイプの設定を示しています。料金の詳細については「[AWS Database Migration Service 料金表のページ](https://aws.amazon.com/dms/pricing/)」をご参照ください。
**汎用レプリケーションインスタンスタイプ**
| タイプ | vCPU | メモリ (GiB) |
| --- | --- | --- |
| dms.t3.micro | 2 | 1 |
| dms.t3.small | 2 | 2 |
| dms.t3.medium | 2 | 4 |
| dms.t3.large | 2 | 8 |
**コンピューティング最適化レプリケーションインスタンスタイプ**
| タイプ | vCPU | メモリ (GiB) |
| --- | --- | --- |
| dms.c5.large | 2 | 4 |
| dms.c5.xlarge | 4 | 8 |
| dms.c5.2xlarge | 8 | 16 |
| dms.c5.4xlarge | 16 | 32 |
| dms.c5.9xlarge | 36 | 72 |
| dms.c5.12xlarge | 48 | 96 |
| dms.c5.18xlarge | 72 | 144 |
| dms.c5.24xlarge | 96 | 192 |
| dms.c6i.large | 2 | 4 |
| dms.c6i.xlarge | 4 | 8 |
| dms.c6i.2xlarge | 8 | 16 |
| dms.c6i.4xlarge | 16 | 32 |
| dms.c6i.8xlarge | 32 | 64 |
| dms.c6i.12xlarge | 48 | 96 |
| dms.c6i.16xlarge | 64 | 128 |
| dms.c6i.24xlarge | 96 | 192 |
| dms.c6i.32xlarge | 128 | 256 |
| dms.c7i.large | 2 | 4 |
| dms.c7i.xlarge | 4 | 8 |
| dms.x7i.2xlarge | 8 | 16 |
| dms.x7i.4xlarge | 16 | 32 |
| dms.x7i.8xlarge | 32 | 64 |
| dms.x7i.12xlarge | 48 | 96 |
| dms.x7i.16xlarge | 64 | 128 |
| dms.x7i.24xlarge | 96 | 192 |
| dms.x7i.48xlarge | 192 | 384 |
**メモリ最適化レプリケーションインスタンスタイプ**
| タイプ | vCPU | メモリ (GiB) |
| --- | --- | --- |
| dms.r5.large | 2 | 16 |
| dms.r5.xlarge | 4 | 32 |
| dms.r5.2xlarge | 8 | 64 |
| dms.r5.4xlarge | 16 | 128 |
| dms.r5.8xlarge | 32 | 256 |
| dms.r5.12xlarge | 48 | 384 |
| dms.r5.16xlarge | 64 | 512 |
| dms.r5.24xlarge | 96 | 768 |
| dms.r6i.large | 2 | 16 |
| dms.r6i.xlarge | 4 | 32 |
| dms.r6i.2xlarge | 8 | 64 |
| dms.r6i.4xlarge | 16 | 128 |
| dms.r6i.8xlarge | 32 | 256 |
| dms.r6i.12xlarge | 48 | 384 |
| dms.r6i.16xlarge | 64 | 512 |
| dms.r6i.24xlarge | 96 | 768 |
| dms.r6i.32xlarge | 128 | 1024 |
| dms.r7i.large | 2 | 16 |
| dms.r7i.xlarge | 4 | 32 |
| dms.r7i.2xlarge | 8 | 64 |
| dms.r7i.4xlarge | 16 | 128 |
| dms.r7i.8xlarge | 32 | 256 |
| dms.r7i.12xlarge | 48 | 384 |
| dms.r7i.16xlarge | 64 | 512 |
| dms.r7i.24xlarge | 96 | 768 |
| dms.r7i.48xlarge | 192 | 1536 |
上記の表は、すべての AWS DMS レプリケーションインスタンスタイプを示していますが、リージョンで使用できるタイプは異なる場合があります。各リージョンで利用できるレプリケーションインスタンスタイプを確認するには、次の [AWS CLI](https://docs.aws.amazon.com/cli/latest/reference/dms/index.html) コマンドを実行します。
```
aws dms describe-orderable-replication-instances --region your_region_name
```
**Topics**
+ [使用するインスタンスクラスの決定](#CHAP_ReplicationInstance.Types.Deciding)
+ [バーストパフォーマンスインスタンスの Unlimited モードでの作業](#CHAP_ReplicationInstance.Types.UnlimitedMode)
## 使用するインスタンスクラスの決定
どのレプリケーションインスタンスクラスが最適かを判断するために、 が AWS DMS 使用する変更データキャプチャ (CDC) プロセスを見てみましょう。
全ロード \$1 CDC タスク (一括ロードと継続的なレプリケーション) を実行していると想定します。この場合、タスクにはメタデータやその他の情報を格納する独自の SQLite リポジトリがあります。が全ロード AWS DMS を開始する前に、以下の手順を実行します。
+ AWS DMS は、ソースエンジンのトランザクションログから移行するテーブルの変更のキャプチャを開始します (これらの*キャッシュされた変更*と呼ばれます）。全ロードが完了すると、これらのキャッシュされた変更が収集され、ターゲットに適用されます。キャッシュされた変更のボリュームに応じて、これらの変更は、メモリから直接適用できます。ここで、これらの変更から設定しきい値まで収集されます。または、ディスクから適用して、変更がメモリに保持できないときに書き込まれるようにすることもできます。
+ キャッシュされた変更が適用されると、デフォルトではターゲットインスタンスでトランザクション適用プロセス AWS DMS が開始されます。
適用されたキャッシュされた変更フェーズと継続的なレプリケーションフェーズでは、 は 2 つのストリームバッファ AWS DMS を使用します。1 つは受信データと送信データ用です。 は、別のメモリバッファである*ソートと呼ばれる*重要なコンポーネント AWS DMS も使用します。ソーターコンポーネントの 2 つの重要な用途 (他のコンポーネントを含む) は次のとおりです。
+ すべてのトランザクションを追跡し、関連するトランザクションのみを送信バッファに転送します。
+ これにより、トランザクションはソース上と同じコミットの順番で転送されます。
見てわかるように、このアーキテクチャには、 AWS DMSの CDC 用の 3 つの重要なメモリバッファがあります。これらのバッファのいずれでメモリ負荷が生じた場合、移行でパフォーマンス上の問題が発生し、障害が起きる可能性があります。
1 秒あたりのトランザクション数 (TPS) が多い重いワークロードをこのアーキテクチャに接続すると、R5 インスタンス と R6i インスタンスが提供する追加メモリが役立つことが明らかになります。R5 インスタンスと R6i インスタンスを使用すると、メモリ内に多数のトランザクションが保持されるため、継続的なレプリケーション中のメモリ負荷の問題を回避できます。
## バーストパフォーマンスインスタンスの Unlimited モードでの作業
T3 インスタンスなどの `unlimited` として設定したバーストパフォーマンスインスタンスは、必要に応じた期間にわたり、高い CPU 使用率を保持できます。時間あたりインスタンス料金は、すべての CPU 使用率のスパイクを自動的にカバーできます。24 時間移動ベースでまたはインスタンスの存続期間のいずれか短い方の時間で、インスタンスの平均 CPU 使用率がベースライン以下になった場合、インスタンス料金は自動的にすべての CPU 使用率スパイクをカバーします。
汎用のワークロードではほとんどの場合、`unlimited` として設定されたインスタンスは追加料金なしで十分なパフォーマンスを提供します。長時間にわたって高い CPU 使用率でインスタンスを実行する場合には、vCPU 時間ごとに均一追加料金が発生します。T3 インスタンスの料金について詳しくは、[AWS Database Migration Service](https://aws.amazon.com/dms/pricing/) の「T3 CPU クレジット」をご参照ください。
T3 インスタンス用 `unlimited` モードの詳細については、「*Amazon EC2 ユーザーガイド*」の「[バーストパフォーマンスインスタンスの Unlimited モード](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/burstable-performance-instances-unlimited-mode.html)」を参照してください。
**重要**
[AWS 無料利用枠](https://aws.amazon.com/free/)提供の下で`dms.t3.micro`インスタンスを`unlimited`モードで使うと、料金が適用される場合があります。特に、24 時間横揺れ周期における平均使用率が、そのインスタンスのベースライン使用率を超過すると料金が発生することがあります。詳細については、「*Amazon EC2 ユーザーガイド*」の「[ベースライン使用率](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/burstable-credits-baseline-concepts.html#baseline_performance)」をご参照ください。
T3 インスタンスは、デフォルトで `unlimited` として起動します。24 時間の平均 CPU 使用率がベースラインを超えた場合は、余剰クレジットに対して課金されます。場合によっては、T3 スポットインスタンスは `unlimited` のように起動することがあり、すぐに短時間使用する予定もあると思います。CPU クレジットが発生するアイドル時間なしで実行すると、余剰クレジットの料金が発生します。コストの増加を抑えるには、T3 スポットインスタンス を標準モードで起動することをお勧めします。詳細については、「*Amazon EC2 ユーザーガイド*」の「[余剰クレジットにより料金が発生することがある](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/burstable-performance-instances-unlimited-mode-concepts.html#unlimited-mode-surplus-credits)」、「[T3 スポットインスタンス](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-spot-limits.html#t3-spot-instances)」、「[バーストパフォーマンスインスタンスのスタンダードモード](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/burstable-performance-instances-standard-mode.html)」を参照してください。
# レプリケーションインスタンス向けの最適なサイズの選択
適切なレプリケーション インスタンスの選択は、ユースケースのいくつかの要因によって異なります。レプリケーション インスタンスリソースの使用方法を理解しやすいように、次の説明をご参照ください。全ロードと CDC タスクの一般的なシナリオを説明します。
全ロードタスク中、 はテーブルを個別に AWS DMS ロードします。デフォルトでは、一度に 8 つのテーブルがロードされます。 は、フルロードタスク中にソースへの継続的な変更 AWS DMS をキャプチャし、後でターゲットエンドポイントに適用できるようにします。変更はメモリにキャッシュされます。使用可能なメモリがなくなると、変更はディスクにキャッシュされます。テーブルのフルロードタスクが完了すると、 はキャッシュされた変更をターゲットテーブルに AWS DMS すぐに適用します。
テーブルのキャッシュされた変更がすべて適用されると、ターゲットエンドポイントはトランザクション上一貫性のある状態になります。この時点で、ターゲットは最後にキャッシュされた変更に関してソースエンドポイントと同期しています。 AWS DMS その後、 はソースとターゲットの間で継続的なレプリケーションを開始します。そのために、 はソーストランザクションログから変更オペレーション AWS DMS を取得し、トランザクション整合性のある方法でターゲットに適用します。(このプロセスでは、バッチ最適化適用が選択されていないことを前提としています）。 は、可能であれば、レプリケーションインスタンスのメモリを介して継続的な変更を AWS DMS ストリーミングします。それ以外の場合、 はターゲットに適用できるようになるまで、レプリケーションインスタンスのディスクに変更を AWS DMS 書き込みます。
レプリケーション インスタンスが変更処理をどのように処理するか、およびそのプロセスでメモリがどのように使用されるかについて、何らかの制御があります。変更処理のチューニング方法の詳細については、「[変更処理のチューニング設定](CHAP_Tasks.CustomizingTasks.TaskSettings.ChangeProcessingTuning.md)」をご参照ください。
## 考慮すべき要素
メモリとディスク容量は、ユースケースに適したレプリケーションインスタンスを選択する際の重要な要素です。レプリケーションインスタンスを選択するために分析すべきユースケースの特徴について次に説明します。
+ データベースとテーブルのサイズ
データ量は、フルロードパフォーマンスを最適化するためのタスクの設定を決定するうえで役立ちます。例えば、1 TB スキーマが 2 つある場合、テーブルをパーティション化して 500 GB の 4 つのタスクの分割して、それらを並列で実行できます。レプリケーションインスタンスで使用できる CPU リソースにより、実行できる並列処理は異なります。このため、フルロードパフォーマンスを最適化するには、データベースのサイズとテーブルのサイズを把握することをお勧めします。これにより、実行できるタスクの数を判断できます。
+ ラージオブジェクト
移行の範囲内のデータ型がパフォーマンスに影響を及ぼす場合があります。特にラージオブジェクト (LOB) は、パフォーマンスとメモリ消費に影響します。LOB 値を移行するには、 は 2 ステップのプロセス AWS DMS を実行します。まず、LOB 値なしで行をターゲット AWS DMS に挿入します。次に、LOB 値で行 AWS DMS を更新します。このプロセスはメモリに影響を及ぼすため、ソース内の LOB 列を特定し、そのサイズを分析しておくことが重要です。
+ ロード頻度とトランザクションのサイズ
ロード頻度と 1 秒あたりのトランザクション数 (TPS) は、メモリ使用量に影響します。TPS またはデータ操作言語 (DML) のアクティビティ数が多いと、メモリの使用量が上がります。これが発生するのは、変更内容をターゲットに適用するまで DMS はキャッシュするためです。これにより、CDC の実行中にスワッピング (メモリオーバーフローによる物理ディスクへの書き込み) が発生し、レイテンシーが発生します。
+ テーブルキーと参照整合性
テーブルのキーに関する情報により、データの移行に使用する CDC モード (バッチ適用またはトランザクション適用) が定まります。通常、トランザクションの適用はバッチの適用よりも遅くなります。長時間実行されるトランザクションの場合、多くの変更を移行する必要がある可能性があります。トランザクション適用を使用する場合、バッチ適用と比較して、変更を保存するためにより多くのメモリが必要になる AWS DMS 場合があります。プライマリキーなしでテーブルを移行すると、一括適用が失敗し、DMS タスクはトランザクション適用モードに変更されます。CDC 中にテーブル間で参照整合性がアクティブな場合、 はデフォルトでトランザクション適用 AWS DMS を使用します。バッチ適用とトランザクション適用との比較の詳細については、「[DMS バッチ適用機能を使用して CDC レプリケーションパフォーマンスを向上させるにはどうすればよいですか?](https://aws.amazon.com/premiumsupport/knowledge-center/dms-batch-apply-cdc-replication/)」を参照してください。
このようなメトリクスを使用して、レプリケーションインスタンスをコンピューティング最適化またはメモリ最適化する必要があるかを判断します。
## 一般的な問題
移行中にレプリケーションインスタンスでのリソースの競合の原因となる次のとおりの一般的な問題に直面する場合があります。レプリケーションインスタンスメトリクスの詳細については、「[レプリケーションインスタンスのメトリクス](CHAP_Monitoring.md#CHAP_Monitoring.Metrics.CloudWatch)」を参照してください。
+ レプリケーションインスタンスのメモリが不足すると、データはディスクに書き込まれます。ディスクからの読み取りによってレイテンシーが発生する可能性があります。ただしこれは、十分なメモリを備えたレプリケーションインスタンスのサイズを設定することで回避できます。
+ レプリケーションインスタンスに割り当てられるディスクサイズは、必要となるより小さいサイズでも構いません。ディスクサイズは、メモリ内のデータがオーバーフローした場合や、タスクログの保存にも使用されます。最大 IOPS もこれに依存します。
+ 複数のタスクや並列処理の高いタスクを実行すると、レプリケーションインスタンスの CPU 消費量に影響します。これにより、タスクの処理が遅くなり、レイテンシーが発生します。
## ベストプラクティス
レプリケーションインスタンスのサイジングを行う際は、次の 2 つの最も一般的なベストプラクティスの採用を検討します。詳細については、「[のベストプラクティス AWS Database Migration Service](CHAP_BestPractices.md)」を参照してください。
1. ワークロードのサイジングを行い、コンピューティング集約型であるか、メモリ集中型であるかを判断しておきます。これに基づいて、レプリケーションインスタンスのクラスとサイズを決定できます。
+ AWS DMS はメモリ内の LOBs。この操作にはかなりの量のメモリが必要です。
+ タスクの数とスレッドの数は CPU 消費に影響します。フルロード操作中は `MaxFullLoadSubTasks` の使用を最大 8 に抑えます。
1. フルロード中のワークロードが高い場合は、レプリケーションインスタンスに割り当てられるディスク容量を増やします。これにより、レプリケーションインスタンスは割り当てられた IOPS を最大限に利用できます。
上記のガイドラインは考えられるすべてのシナリオをカバーしているわけではありません。レプリケーションインスタンスのサイジングを行う際は、特定のユースケースの詳細を考慮することが重要です。
上記のテストにより、CPU とメモリはワークロードによって異なることが明らかになっています。具体的には、LOB はメモリに影響し、タスク数や並列処理は CPU に影響します。移行の実行後、レプリケーションインスタンスのCPU、解放可能なメモリ、空きストレージ、IOPS をモニタリングします。収集したデータに基づいて、必要に応じてレプリケーション インスタンスのサイズを増減することができます。
# レプリケーションエンジンバージョンの操作
*レプリケーションエンジン*は、レプリケーションインスタンスで実行され、指定した移行タスクを実行するコア AWS DMS ソフトウェアです。 AWS は、新機能とパフォーマンスの向上により、 AWS DMS レプリケーションエンジンソフトウェアの新しいバージョンを定期的にリリースします。レプリケーションエンジンソフトウェアの各バージョンには、他のバージョンと区別するための独自のバージョン番号があります。
新しいレプリケーションインスタンスを起動すると、特に指定しない限り、最新の AWS DMS エンジンバージョンが実行されます。詳細については、「[AWS DMS レプリケーションインスタンスの使用](CHAP_ReplicationInstance.md)」を参照してください。
現在実行中のレプリケーションインスタンスがある場合は、より新しいエンジンバージョンにアップグレードできます (エンジンバージョンのダウングレードAWS DMS はサポートされていません）。レプリケーションエンジンのバージョンの詳細については、「[AWS DMS リリースノート](CHAP_ReleaseNotes.md)」をご参照ください。
## コンソールを使用したエンジンバージョンのアップグレード
を使用してレ AWS DMS プリケーションインスタンスをアップグレードできます AWS マネジメントコンソール。
**コンソールを使用してレプリケーション インスタンスをアップグレードするには**
1. [https://console.aws.amazon.com/dms/v2/](https://console.aws.amazon.com/dms/v2/) で AWS DMS コンソールを開きます。
1. ナビゲーションペインで **[Replication instances]** (レプリケーション インスタンス) を選択します。
1. レプリケーションエンジンを選択し、**[Modify]** (変更) を選択します。
1. **[エンジンバージョン]** で アップグレードするバージョン番号を選択して、**[変更する]** をクリックします。
**注記**
レプリケーション インスタンスをアップグレードする前に、すべてのタスクを停止することをお勧めします。タスクを停止しない場合、 AWS DMS はアップグレード前にタスクを自動的に停止します。タスクを手動で停止した場合、アップグレードの完了後にタスクを手動で開始する必要があります。レプリケーション インスタンスタイプのアップグレードには数分間かかります。インスタンスが使用可能になると、ステータスは **available** に変わります。
## を使用したエンジンバージョンのアップグレード AWS CLI
レ AWS DMS プリケーションインスタンスは AWS CLI、次のように を使用してアップグレードできます。
**を使用してレプリケーションインスタンスをアップグレードするには AWS CLI**
1. 次のコマンドを使用して、レプリケーション インスタンスの Amazon リソースネーム (ARN) を確認します。
```
aws dms describe-replication-instances \
--query "ReplicationInstances[*].[ReplicationInstanceIdentifier,ReplicationInstanceArn,ReplicationInstanceClass]"
```
出力で、アップグレードするレプリケーション インスタンスの ARN を書き留めます。たとえば、`arn:aws:dms:us-east-1:123456789012:rep:6EFQQO6U6EDPRCPKLNPL2SCEEY` などです。
1. 次のコマンドを使用して、使用可能なレプリケーション インスタンスバージョンを調べます。
```
aws dms describe-orderable-replication-instances \
--query "OrderableReplicationInstances[*].[ReplicationInstanceClass,EngineVersion]"
```
出力で、エンジンバージョン番号またはレプリケーション インスタンスクラスに使用できる番号を書き留めます。この情報はステップ 1 の出力に表示されます。
1. 次のコマンドを使ってレプリケーション インスタンスをアップグレードします。
```
aws dms modify-replication-instance \
--replication-instance-arn arn \
--engine-version n.n.n
```
前述の *arn* を、前のステップで書き留めた実際のレプリケーション インスタンス ARN に置き換えます。
*n.n.n* を、たとえば、`3.4.5` など目的のエンジンバージョン番号に置き換えます。
**注記**
レプリケーション インスタンスタイプのアップグレードには数分間かかります。次のコマンドを使用して、レプリケーション インスタンスのステータスを表示できます。
```
aws dms describe-replication-instances \
--query "ReplicationInstances[*].[ReplicationInstanceIdentifier,ReplicationInstanceStatus]"
```
レプリケーション インスタンスが使用可能になると、ステータスは **available** に変わります。
# パブリックおよびプライベートレプリケーション インスタンス
レプリケーションインスタンスがソースデータベースとターゲットデータベースに接続するために使用するについて、パブリック IP アドレスにするかプライベート IP アドレスするかを指定できます。
*プライベート レプリケーション インスタンス*には、レプリケーション ネットワーク外からアクセスできないるプライベート IP アドレスがあります。ソースデータベースとターゲットデータベースの両方が、レプリケーションインスタンスの仮想プライベートクラウド (VPC) に接続されている同じネットワーク内にある場合は、専用インスタンスを使用します。ネットワークは、仮想プライベートネットワーク (VPN) Direct Connect、または VPC ピアリングを使用して VPC に接続できます。
VPC ピアリング接続は、2 つの VPC 間のネットワーク接続です。これを使用すると、各 VPC のプライベート IP アドレスを使用して、あたかも同じネットワーク内にあるかのようにルーティングできます。VPC ピアリングの詳細については、[Amazon VPC ユーザーガイド](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-peering.html) の「*VPC ピアリング*」をご参照ください。
**パブリックレプリケーションインスタンスは、レプリケーションインスタンスの VPC セキュリティグループ、レプリケーションインスタンスのパブリック IP アドレス、または NAT ゲートウェイのパブリック IP アドレスを使用できます。これらの接続によって、データ移行に使用するネットワークが形成されます。
# IP アドレス指定とネットワークタイプ
AWS DMS は常に Amazon Virtual Private Cloud (VPC) にレプリケーションインスタンスを作成します。VPC を作成する際に、使用する IP アドレス指定 (IPv4 または IPv6、あるいはその両方) を決定できます。**その後、レプリケーションインスタンスを作成または変更する際に、デュアルスタックモードを使用して IPv4 アドレスプロトコルまたは IPv6 アドレスプロトコルの使用を指定できます。
**IPv4 アドレス**
VPC を作成する際、10.0.0.0/16 などのクラスレス ドメイン間ルーティング (CIDR) ブロックの形式で VPC の IPv4 アドレスの範囲を指定できます。サブネットグループは、この CIDR ブロック内の IP アドレスの範囲を定義します。これらの IP アドレスはプライベートまたはパブリックです。
プライベート IPv4 アドレスは、インターネットから到達できない IP アドレスです。プライベート IPv4 アドレスは、レプリケーションインスタンスと同じ VPC 内のその他のリソース(Amazon EC2インスタンスなど) との間の通信に使用できます。各レプリケーションインスタンスには、VPC 内通信のためのプライベート IP アドレスが備えられています。
パブリック IP アドレスは、インターネットから到達可能な IPv4 アドレスです。パブリックアドレスは、レプリケーションインスタンスとインターネット上のリソース間の通信に使用できます。レプリケーションインスタンスにパブリック IP アドレスに持たせるかをユーザーは管理できます。
**デュアルスタックモードと IPv6 アドレス**
IPv6 を介してレプリケーションインスタンスと通信する必要があるリソースがある場合は、**デュアルスタックモードを使用します。デュアルスタックモードを使用するには、レプリケーションインスタンスに関連付けるサブネットグループ内の各サブネットに IPv6 CIDR ブロックが関連付けられていることを確認します。この要件を満たすように、新しいレプリケーションサブネットグループを作成するか、既存のレプリケーションサブネットグループを変更することができます。各 IPv6 アドレスは、グローバルに一意です。VPC の IPv6 CIDR ブロックは、Amazon の IPv6 アドレスのプールから自動的に割り当てられます。範囲を自分で選択することはできません。
DMS は、プライベートデュアルスタックモードのレプリケーションインスタンスの IPv6 エンドポイントに対するインターネットゲートウェイアクセスを無効にします。DMS がこれを行うのは、IPv6 エンドポイントをプライベートにして、VPC 内からのみアクセスできるようにするためです。
AWS DMS コンソールを使用してレプリケーションインスタンスを作成または変更し、**ネットワークタイプ**セクションでデュアルスタックモードを指定できます。次の画像は、コンソールの **[Network type]** (ネットワークの種類) セクションを示しています。
![\[AWS データベース移行サービスネットワークタイプ\]](http://docs.aws.amazon.com/ja_jp/dms/latest/userguide/images/datarep-network-type.png)
**リファレンス**
+ IPv4 と IPv6 の詳細については、「**Amazon VPC ユーザーガイド」の「[Amazon VPC の仕組み](https://docs.aws.amazon.com/vpc/latest/userguide/how-it-works.html#vpc-ip-addressing)」を参照してください。
+ デュアルスタックモードを使用したレプリケーションインスタンスの作成の詳細については、「[レプリケーション インスタンスの作成](CHAP_ReplicationInstance.Creating.md)」を参照してください。
+ レプリケーションインスタンスの変更の詳細については、「[レプリケーション インスタンスの変更](CHAP_ReplicationInstance.Modifying.md)」を参照してください。
# レプリケーション インスタンスのためのネットワークのセットアップ
AWS DMS は常に Amazon VPC に基づいて VPC にレプリケーションインスタンスを作成します。レプリケーション インスタンスがある VPC を指定します。アカウントと AWS リージョンにデフォルトの VPC を使用するか、新しい VPC を作成できます。
レプリケーション インスタンスの VPC に割り当てられた Elastic Network Interface がセキュリティグループに関連付けられていることを確認します。また、このセキュリティグループのルールで、すべてのポートですべてのトラフィックが VPC から出る (egress) であることを確認します。このアプローチでは、エンドポイントで適切な受信ルールが有効になっている場合、レプリケーションインスタンスからソースデータベースエンドポイントとターゲットデータベースエンドポイントへの通信が許可されます。すべてのアドレスへの送信をすべてのポートで許可するデフォルト設定をエンドポイントに使用することをお勧めします。
ソースおよびターゲットエンドポイントは、VPC に接続するか、VPC 内に配置されることにより、VPC 内にあるレプリケーション インスタンスにアクセスします。データベースエンドポイントには、レプリケーション インスタンスからの受信アクセスを許可するネットワークアクセスコントロールリスト (ACL) およびセキュリティグループルール (該当する場合) を含める必要があります。この設定方法は使用するネットワーク構成によって異なります。レプリケーション インスタンスの VPC セキュリティグループ、レプリケーション インスタンスのプライベートまたはパブリック IP アドレス、あるいは NAT ゲートウェイのパブリック IP アドレスを使用することができます。これらの接続によって、データ移行に使用するネットワークが形成されます。
**注記**
基盤となるインフラストラクチャの変更により IP アドレスが変更される可能性があるため、VPC CIDR 範囲を使用するか、NAT GW に関連付けられた 伸縮性 IP を介してレプリケーション インスタンスのアウトバウンド トラフィックをルーティングすることをお勧めします。CIDR ブロックを含む VPC の作成方法の詳細については、[VPC とサブネットの使用](https://docs.aws.amazon.com/vpc/latest/userguide/working-with-vpcs.html)の「*Amazon Virtual Private Cloud ユーザーガイド*」をご参照ください。Elastic IP アドレスの詳細については、*Amazon Elastic Compute Cloud ユーザーガイド*の「[Elastic IP アドレス](https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/elastic-ip-addresses-eip.html)」をご参照ください。
## データベース移行のネットワーク設定
AWS Database Migration Service では、複数の異なるネットワーク設定を使用できます。データベース移行に使用されるネットワークの一般的な設定を以下に示します。
**Topics**
+ [すべてのデータベース移行コンポーネントが 1 つの VPC にある設定](#CHAP_ReplicationInstance.VPC.Configurations.ScenarioAllVPC)
+ [複数の VPC を使用する構成](#CHAP_ReplicationInstance.VPC.Configurations.ScenarioVPCPeer)
+ [共有 VPC を使用した構成](#CHAP_ReplicationInstance.VPC.Configurations.ScenarioVPCShared)
+ [Direct Connect または VPN を使用した VPC へのネットワークの設定](#CHAP_ReplicationInstance.VPC.Configurations.ScenarioDirect)
+ [インターネットを使用した VPC へのネットワークの設定](#CHAP_ReplicationInstance.VPC.Configurations.ScenarioInternet)
+ [VPC 内にない RDS; DB インスタンスで ClassicLink を使用する VPC 内の DB インスタンスへの設定方法](#CHAP_ReplicationInstance.VPC.Configurations.ClassicLink)
+ [AWS サービスに接続するネットワークの設定](#CHAP_ReplicationInstance.VPC.Configurations.networkconnecting)
+ [VPC エンドポイントを使用して AWS サービスに接続するネットワークの設定](#CHAP_ReplicationInstance.VPC.Configurations.vpcendpoints)
+ [インターネットを使用して AWS サービスに接続するネットワークの設定](#CHAP_ReplicationInstance.VPC.Configuration.networkconnectingusinginternet)
現実的であれば、ターゲットエンドポイントと同じリージョン、ターゲットエンドポイントと同じ VPC またはサブネットに DMS レプリケーションインスタンスを作成することをお勧めします。
### すべてのデータベース移行コンポーネントが 1 つの VPC にある設定
ソースエンドポイント、レプリケーション インスタンス、ターゲットエンドポイントがすべて同じ VPC にある場合、データベース移行のネットワークが最もシンプルになります。この設定は、ソースとターゲットのエンドポイントが Amazon RDS DB インスタンスまたは Amazon EC2 インスタンスにある場合に適しています。
次の図は、Amazon EC2 インスタンス上のデータベースがレプリケーション インスタンスに接続され、データが Amazon RDS DB インスタンスに移行される設定を示しています。
![\[AWS Database Migration Service All in One VPC の例\]](http://docs.aws.amazon.com/ja_jp/dms/latest/userguide/images/datarep-scenarioAllVPC.png)
この設定で使用される VPC セキュリティグループは、レプリケーション インスタンスからの受信をデータベースポートで許可する必要があります。これにはいくつか方法があります。レプリケーション インスタンスによって使用されるセキュリティグループにエンドポイントへの入力があることを確認できます。または、レプリケーションインスタンスの VPC CIDR 範囲、NAT ゲートウェイ Elastic IP、またはプライベート IP アドレス (使用している場合) を許可することもできます。ただし、レプリケーション IP アドレスが変更されるとレプリケーションが中断される可能性があるため、レプリケーションインスタンスのプライベート IP アドレスを使用することはお勧めしません。
### 複数の VPC を使用する構成
ソース エンドポイントとターゲット エンドポイントが別の VPC にある場合、いずれかの VPC でレプリケーション インスタンスを作成できます。これで、VPC ピアリングを使用して 2 つの VPC をリンクできます。
VPC ピア接続は、同じネットワーク内にあるかのように各 VPC のプライベート IP アドレスを使用してルーティングできるようにする、2 つの VPC 間のネットワーキング接続です。独自の VPC、別の AWS アカウントの VPCs、または別の AWS リージョンの VPC との間で VPC ピアリング接続を作成できます。VPC ピアリングの詳細については、[Amazon VPC ユーザーガイド](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-peering.html) の「*VPC ピアリング*」をご参照ください。
次の図に、VPC ピア接続の設定例を示します。ここでは、VPC 内の Amazon EC2 インスタンスのソースデータベースが VPC ピア接続で VPC と接続されます。この VPC には、レプリケーション インスタンスと Amazon RDS DB インスタンス上のターゲットデータベースが含まれています。
![\[AWS Database Migration Service レプリケーションインスタンス\]](http://docs.aws.amazon.com/ja_jp/dms/latest/userguide/images/datarep-scenarioVPCPeer.png)
VPC ピアリング接続を実装するには、「**Amazon VPC」ドキュメントの「[Amazon Virtual Private Cloud の VPC ピア接続を操作する](https://docs.aws.amazon.com/vpc/latest/peering/working-with-vpc-peering.html)」を参照してください。片方の VPC のルートテーブルにもう一方の VPC の CIDR ブロックが含まれていることを確認します。例えば、VPC A が宛先 10.0.0.0/16 を使用して、VPC B が宛先 172.31.0.0 を使用している場合、VPC A のルートテーブルには 172.31.0.0 が含まれ、VPC B のルートテーブルには 10.0.0.0/16 が含まれている必要があります。詳細については、「**Amazon VPC ピアリング接続」ドキュメントの「[VPC ピアリング接続のルートテーブルを更新する](https://docs.aws.amazon.com/vpc/latest/peering/vpc-peering-routing.html)」を参照してください。
この構成で使用される VPC セキュリティグループは、レプリケーションインスタンスからのデータベースポートでの受信を許可するか、ピアリングされている VPC の CIDR ブロックでの受信を許可する必要があります。
### 共有 VPC を使用した構成
AWS DMS は、組織内の参加している顧客アカウントと共有されているサブネットを、同じアカウントの通常のサブネットと同様に扱います。以下は、 が VPCs、サブネット AWS DMS を処理する方法と、共有 VPCs。
`ReplicationSubnetGroup` オブジェクトを作成すると、カスタムサブネットまたは VPC で動作するようにネットワークを構成できます。`ReplicationSubnetGroup` を作成する場合、アカウント内の特定の VPC のサブネットを指定できます。指定するサブネットのリストには、別のアベイラビリティーゾーンにある少なくとも 2 つのサブネットが含まれている必要があり、すべてのサブネットが同じ VPC 内にある必要があります。を作成するときは`ReplicationSubnetGroup`、サブネットのみを指定します。各サブネットは 1 つの VPC にリンクされるため、 はユーザーに代わって VPC AWS DMS を決定します。
または を作成する AWS DMS `ReplicationInstance`ときに AWS DMS `ReplicationConfig`、 または `ReplicationInstance` Serverless Replication が動作する `ReplicationSubnetGroup`および/または VPC セキュリティグループを指定できます。指定しない場合、顧客のデフォルト `ReplicationSubnetGroup` (デフォルト VPC 内のすべてのサブネットに指定されていない場合は がユーザーに代わって AWS DMS 作成する) とデフォルトの VPC セキュリティグループ AWS DMS を選択します。
移行は、お客様が指定したアベイラビリティーゾーン、または `ReplicationSubnetGroup` 内の任意のアベイラビリティーゾーンで実行できます。がレプリケーションインスタンスの作成またはサーバーレスレプリケーションの開始 AWS DMS を試みると、サブネットのアベイラビリティーゾーンがコアサービスアカウントのアベイラビリティーゾーンに変換され、アベイラビリティーゾーンのマッピングが 2 つのアカウント間で同一でなくても、正しいアベイラビリティーゾーンでインスタンスが起動されます。
共有 VPC を使用する場合は、共有 VPC から使用するサブネットにマップする `ReplicationSubnetGroup` オブジェクトを必ず作成する必要があります。`ReplicationInstance` または `ReplicationConfig` を作成する際は、共有 VPC の `ReplicationSubnetGroup` を指定し、Create リクエストで共有 VPC のために作成した VPC セキュリティグループを指定する必要があります。
共有 VPC の使用に際して、次の点に注意する必要があります。
+ VPC 所有者は、参加者とリソースを共有できませんが、参加者は所有者のサブネットにサービスリソースを作成できます。
+ すべてのリソースはアカウント固有であるため、VPC 所有者は参加者が作成したリソース (レプリケーションインスタンスなど) にアクセスできません。ただし、レプリケーションインスタンスを共有 VPC に作成する限り、レプリケーションエンドポイントまたはタスクに適切な権限が付与されていれば、所有アカウントを問わず VPC 内のリソースにアクセスできます。
+ リソースはアカウント固有であるため、他の参加者はその他のアカウントが所有するリソースにはアクセスできません。自分のアカウントで共有 VPC に作成されたリソースにアクセスできるように他のアカウントに付与できるようなアクセス許可はありません。
### Direct Connect または VPN を使用した VPC へのネットワークの設定
リモートネットワークは、 AWS Direct Connect、ソフトウェアまたはハードウェア VPN 接続などのいくつかのオプションを使用して VPC に接続できます。これらのオプションは、内部ネットワークを AWS クラウドに拡張することでモニタリング、認証、セキュリティ、データ、他のシステムなどの既存のオンサイトサービスを統合するためによく使われます。このタイプのネットワーク拡張を使用することで、VPC などの AWSにホストされたリソースにシームレスに接続できます。
次の図は、ソースエンドポイントが企業データセンターにあるオンプレミスデータベースである設定を示しています。このデータベースは Direct Connect または VPN を使用することで、レプリケーション インスタンスと、Amazon RDS DB インスタンス上のターゲット データベースを含む VPC と接続されます。
![\[AWS Database Migration Service レプリケーションインスタンス\]](http://docs.aws.amazon.com/ja_jp/dms/latest/userguide/images/datarep-scenarioDirect.png)
この設定では VPC セキュリティグループに、VPC の CIDR 範囲または特定の IP アドレスを送信先とするトラフィックをホストに送信するルーティングルールが必要です。このホストは、VPC からのトラフィックをオンプレミスの VPN にブリッジできる必要があります。この場合、NAT ホストは独自のセキュリティグループ設定を含みます。このような設定の場合、レプリケーションインスタンスの VPC の CIDR 範囲、プライベート IP アドレス、またはセキュリティグループから NAT インスタンスへのトラフィックを許可する必要があります。ただし、レプリケーション IP アドレスが変更されるとレプリケーションが中断される可能性があるため、レプリケーションインスタンスのプライベート IP アドレスを使用することはお勧めしません。
### インターネットを使用した VPC へのネットワークの設定
VPN または を使用して AWS リソース Direct Connect に接続しない場合は、インターネットを使用してデータベースを移行できます。この場合 Amazon EC2 インスタンスまたは Amazon RDS DB インスタンスのいずれかに移行できます。この設定では、ターゲットポイントおよびレプリケーション インスタンスを含むインターネットゲートウェイを持つ VPC 内にパブリックレプリケーション インスタンスが必要です。
![\[AWS Database Migration Service レプリケーションインスタンス\]](http://docs.aws.amazon.com/ja_jp/dms/latest/userguide/images/datarep-scenarioInternet.png)
インターネットゲートウェイを VPC に追加するには、[Amazon VPC User Guide](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_Internet_Gateway.html#Add_IGW_Attach_Gateway) の「*インターネットゲートウェイのアタッチ*」をご参照ください。
VPC ルートテーブルにデフォルトでは VPC に向かわないトラフィックをインターネットゲートウェイに送信するルーティングルールが含まれている必要があります。この設定では、エンドポイントへの接続が、プライベート IP アドレスではなくレプリケーション インスタンスのパブリック IP アドレスから行われているかのように見えます。詳細については、*Amazon VPC ユーザーガイド* の「[VPCルートテーブル](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_Route_Tables.html)」をご参照ください。
### VPC 内にない RDS; DB インスタンスで ClassicLink を使用する VPC 内の DB インスタンスへの設定方法
| |
| --- |
| 2022 年 8 月 15 日に、EC2-Classic の提供を終了しｈます。EC2-Classic は、VPC への移行をお勧めします。詳細については、「Amazon EC2 ユーザーガイド」の[「EC2-Classic から VPC へ移行」](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/vpc-migrate.html)およびブログ記事[「EC2-Classic ネットワーキングがリタイア — 準備方法」](https://aws.amazon.com/blogs/aws/ec2-classic-is-retiring-heres-how-to-prepare/)を参照してください。 |
プロキシサーバーと組み合わせて ClassicLink を使用すると、VPC 内に存在しない Amazon RDS DB インスタンスを、VPC 内のレプリケーション サーバーおよび DB インスタンスに接続できます。
ClassicLink を使用すると、EC2-Classic DB インスタンスを同じ AWS リージョン内のアカウント内の VPC にリンクできます。リンクを作成すると、ソース DB インスタンスはプライベート IP アドレスを使用して VPC 内のレプリケーション インスタンスと通信できます。
VPC 内のレプリケーション インスタンスは、ClassicLink を使用して EC2-Classic プラットフォーム上のソース DB インスタンスに直接アクセスできないため、プロキシサーバーを使用する必要があります。プロキシサーバーはソース DB インスタンスを、レプリケーション インスタンスとターゲット DB インスタンスを含む VPC に接続します。プロキシサーバーは、ClassicLink を使用して VPC に接続します。プロキシサーバーでのポート転送により、VPC 内にあるソース DB インスタンスとターゲット DB インスタンスの間で通信が可能になります。
![\[AWS ClassicLink を使用したデータベース移行サービス\]](http://docs.aws.amazon.com/ja_jp/dms/latest/userguide/images/datarep-scenarioClassicLink.png)
#### AWS Database Migration Service での ClassicLink の使用
VPC にない Amazon RDS DB インスタンスを、VPC にある AWS DMS レプリケーションサーバーと DB インスタンスに接続できます。このために Amazon EC2 ClassicLink をプロキシサーバーで使用できます。
以下の手順は、ClassicLink をこの目的に使用する方法を示しています。この手順では、VPC にない Amazon RDS ソース DB インスタンスを、DMS レプリケーションインスタンスとターゲット DB インスタンスを含む VPC AWS に接続します。
+ VPC AWS に DMS レプリケーションインスタンスを作成します。(すべてのレプリケーション インスタンスが VPC 内で作成されます)。
+ VPC セキュリティグループをレプリケーション インスタンスとターゲット DB インスタンスに関連付けます。2 つのインスタンスが VPC セキュリティグループを共有している場合、デフォルトで相互に通信できます。
+ EC2 Classic インスタンスでプロキシサーバーをセットアップします。
+ プロキシサーバーと VPC の間に ClassicLink を使用した接続を作成します。
+ ソースデータベースとターゲットデータベースの AWS DMS エンドポイントを作成します。
+ DMS AWS タスクを作成します。
**ClassicLink を使用して VPC 内にない DB インスタンス上のデータベースを VPC 内の DB インスタンス上の VPC に移行するには**
1. DMS AWS レプリケーションインスタンスを作成し、VPC セキュリティグループを割り当てます。
1. にサインイン AWS マネジメントコンソール し、[https://console.aws.amazon.com/dms/v2/](https://console.aws.amazon.com/dms/v2/) で AWS DMS コンソールを開きます。
AWS Identity and Access Management (IAM) ユーザーとしてサインインしている場合は、 にアクセスするための適切なアクセス許可があることを確認してください AWS DMS。データベース移行に必要なアクセス許可の詳細については、「[を使用するために必要な IAM アクセス許可 AWS DMS](security-iam.md#CHAP_Security.IAMPermissions)」をご参照ください。
1. [**Dashboard**] ページで、[**Replication Instance**] を選択します。[ステップ 1: AWS DMS コンソールを使用してレプリケーションインスタンスを作成する](CHAP_GettingStarted.Replication.md#CHAP_GettingStarted.Replication.ReplicationInstance)の手順に従って、レプリケーション インスタンスを作成します。
1. DMS AWS レプリケーションインスタンスを作成したら、EC2 サービスコンソールを開きます。ナビゲーションペインでC **[Network Interfaces]** (ネットワーク インターフェース) を選択します。
1. *DMSNetworkInterface* を選択し、**[Change Security Groups]** (セキュリティグループの変更) からの**[Actions]** (アクション) メニューを選択します。
1. レプリケーション インスタンスとターゲット DB インスタンスに使用するセキュリティグループを選択します。
1. 前のステップのセキュリティグループをターゲット DB インスタンスに関連付けます。
1. Amazon RDS サービスコンソールを開きます。**[Replication engine version]** (レプリケーション エンジンバージョン) でバージョン番号を選択し、[Modify] (変更) を選択します。
1. ターゲット DB インスタンスを選択します。**[Instance Actions]** (インスタンスアクション) では**[Modify]** (変更) を選択します。
1. **[Security Group]** (セキュリティグループ) パラメーターの場合、前のステップで使用したセキュリティグループを選択します。
1. **[Continue]** (続ける) を選択してから、**[Modify DB Instance]** (DB インスタンス変更) を選択します。
1. ステップ 3: NGINX を使用して EC2 Classic インスタンスでプロキシサーバーを設定します。EC2 Classic インスタンスを起動するには、選択した AMI を使用します。以下の例は、AMI Ubuntu Server 14.04 LTS (HVM) をベースとしています。
EC2 Classic インスタンスでプロキシサーバーをセットアップするには
1. EC2 Classic インスタンスに接続し、次のコマンドを使用して NGINX をインストールします。
```
Prompt> sudo apt-get update
Prompt> sudo wget http://nginx.org/download/nginx-1.9.12.tar.gz
Prompt> sudo tar -xvzf nginx-1.9.12.tar.gz
Prompt> cd nginx-1.9.12
Prompt> sudo apt-get install build-essential
Prompt> sudo apt-get install libpcre3 libpcre3-dev
Prompt> sudo apt-get install zlib1g-dev
Prompt> sudo ./configure --with-stream
Prompt> sudo make
Prompt> sudo make install
```
1. 次のコードを使用して、NGINX デーモンファイル `/etc/init/nginx.conf` を編集します。
```
# /etc/init/nginx.conf – Upstart file
description "nginx http daemon"
author "email"
start on (filesystem and net-device-up IFACE=lo)
stop on runlevel [!2345]
env DAEMON=/usr/local/nginx/sbin/nginx
env PID=/usr/local/nginx/logs/nginx.pid
expect fork
respawn
respawn limit 10 5
pre-start script
$DAEMON -t
if [ $? -ne 0 ]
then exit $?
fi
end script
exec $DAEMON
```
1. `/usr/local/nginx/conf/nginx.conf` に NGINX 設定ファイルを作成します。設定ファイルに、以下の内容を追加します。
```
# /usr/local/nginx/conf/nginx.conf - NGINX configuration file
worker_processes 1;
events {
worker_connections 1024;
}
stream {
server {
listen DB instance port number;
proxy_pass DB instance identifier:DB instance port number;
}
}
```
1. コマンドラインから、次のコマンドを使用して NGINX を起動します。
```
Prompt> sudo initctl reload-configuration
Prompt> sudo initctl list | grep nginx
Prompt> sudo initctl start nginx
```
1. プロキシサーバーと、ターゲット DB インスタンスおよびレプリケーション インスタンスを含むターゲット VPC の間に ClassicLink 接続を作成します。
1. EC2 コンソールを開き、プロキシサーバーを実行中の EC2 Classic インスタンスを選択します。
1. **[Actions]** (アクション) で、**[ClassicLink]** を選択し、続いて **[Link to VPC]** (VPC へのリンク) を選択します。
1. 先に使用したセキュリティグループをこの手順で選択します。
1. **[VPC link]** (VPC リンク) を選択します。
1. ステップ 5: の手順を使用して AWS DMS エンドポイントを作成します[ステップ 2: ソースとターゲットのエンドポイントを指定する](CHAP_GettingStarted.Replication.md#CHAP_GettingStarted.Replication.Endpoints)。ソース エンドポイントを指定する場合、サーバー名として内部 EC2 DNS ホスト名を使用する必要があります。
1. の手順を使用して AWS DMS タスクを作成します[ステップ 3: タスクを作成してデータを移行する](CHAP_GettingStarted.Replication.md#CHAP_GettingStarted.Replication.Tasks)。
### AWS サービスに接続するネットワークの設定
AWS サービスと接続するには、インターネット接続または Virtual Private Cloud (VPC) エンドポイントを使用します。これは、次の場合に適用されます。
ソースエンドポイントまたはターゲットエンドポイントは、次のような AWS サービスを使用します。
+ AWS Secrets Manager
+ Amazon Simple Storage Service
ターゲットエンドポイントは、次のような AWS サービスです。
+ Amazon S3
+ Amazon Kinesis
+ Amazon DynamoDB
+ Amazon Redshift
+ Amazon OpenSearch Service
+ Amazon Athena
### VPC エンドポイントを使用して AWS サービスに接続するネットワークの設定
VPC エンドポイントは、 AWS リソース間の安全な接続を提供し、インターネットアクセスを必要とせずに VPC リソースを AWS サービスに接続します。プライベートサブネット内のアプリケーションは、 AWS ネットワーク内にとどまりながら AWS サービスにアクセスできるため、セキュリティが向上し、レイテンシーが短縮されます。以下の画像を参照してください。
![\[\]](http://docs.aws.amazon.com/ja_jp/dms/latest/userguide/images/aws_dms_vpc_endpoints.jpg)
詳細については、[「VPC エンドポイントを AWS DMS ソースエンドポイントとターゲットエンドポイントとして](https://docs.aws.amazon.com/dms/latest/userguide/CHAP_VPC_Endpoints.html)設定する」および[AWS DMS 「Secrets Manager VPC エンドポイントの設定](https://docs.aws.amazon.com/dms/latest/userguide/CHAP_Advanced.Endpoints.secretsmanager.html)」を参照してください。
### インターネットを使用して AWS サービスに接続するネットワークの設定
レプリケーションインスタンスは、データ移行中に AWS リソースに接続するためにインターネットアクセスが必要です。
VPC 内におけるプライベートサブネットおよびパブリックサブネットの詳細については、「*Amazon Virtual Private Cloud ユーザーガイド*」の「[例: プライベートサブネットにサーバーがある VPC および NAT](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-example-private-subnets-nat.html)」を参照してください。必要なサービスとの接続について、必ずネットワーク設定をテストする必要があります。
## レプリケーション サブネットグループの作成
データベースの移行に使用するネットワークの一部として、使用する予定の 仮想プライベートクラウド (VPC) のサブネットを指定する必要があります。ここでの VPC は、Amazon VPC サービスに基づいている必要があります。*サブネット*とは、指定されたアベイラビリティーゾーンにある VPC 内の IP アドレス範囲です。これらのサブネットは、VPC が配置されている AWS リージョンのアベイラビリティーゾーン間で分散できます。
AWS DMS コンソールでレプリケーションインスタンスまたはインスタンスプロファイルを作成するときは、選択したサブネットを使用できます。
レプリケーションサブネットグループを作成し、使用するサブネットを定義できます。少なくとも 2 つのアベイラビリティーゾーンにあるサブネットを指定する必要があります。
**レプリケーションサブネットグループを作成する方法**
1. にサインイン AWS マネジメントコンソール し、[https://console.aws.amazon.com/dms/v2/](https://console.aws.amazon.com/dms/v2/) で AWS DMS コンソールを開きます。
IAM ユーザーとしてサインインしている場合は、 AWS DMSにアクセスするための適切なアクセス許可があることを確認します。データベース移行に必要なアクセス許可の詳細については、「[を使用するために必要な IAM アクセス許可 AWS DMS](security-iam.md#CHAP_Security.IAMPermissions)」をご参照ください。
1. ナビゲーションペインで **[サブネットグループ]** を選択します。
1. **[サブネットグループの作成]** を選択します。
1. **[レプリケーションサブネットグループの作成]** ページで、レプリケーションインスタンスの設定を指定します。次の表で設定について説明します。
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/dms/latest/userguide/CHAP_ReplicationInstance.VPC.html)
1. **[サブネットグループの作成]** を選択します。
## DNS を使用したドメイン エンドポイントの解決
通常、 AWS DMS レプリケーションインスタンスは Amazon EC2 インスタンスのドメインネームシステム (DNS) リゾルバーを使用してドメインエンドポイントを解決します。DNS 解決が必要な場合は、Amazon Route 53 Resolverを使用できます。Route 53 DNS レゾルバーの使用方法の詳細については、「[Route 53 レゾルバーの使用開始](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resolver-getting-started.html)」をご参照ください。
独自のオンプレミス ネームサーバーを使用して Amazon Route 53 Resolverを使用して特定のエンドポイントを解決する方法については、「[独自のオンプレミスネームサーバーの使用](CHAP_BestPractices.md#CHAP_BestPractices.Rte53DNSResolver)」をご参照ください。
# レプリケーション インスタンスのための暗号化キーの設定
AWS DMS は、レプリケーションインスタンスで使用されるストレージとエンドポイント接続情報を暗号化します。レプリケーションインスタンスで使用されるストレージを暗号化するために、 AWS DMS AWS KMS key は AWS アカウントに固有の を使用します。この KMS キーは AWS Key Management Service () で表示および管理できますAWS KMS。アカウント (`aws/dms`) でデフォルトの KMS キーあるいは自分で作成するカスタム KMS キーを使用できます。既存の AWS KMS 暗号化キーがある場合は、そのキーを暗号化に使用することもできます。
AWS DMS リソースを暗号化するための KMS キー識別子を指定することで、独自の暗号化キーを指定できます。独自の暗号化キーを指定した場合、データベース移行の実行に使用されるユーザーアカウントがそのキーにアクセスできる必要があります。独自の暗号化キーを作成して暗号化キーへのユーザーアクセスを許可する方法の詳細については、*[AWS KMS 開発者ガイド](https://docs.aws.amazon.com/kms/latest/developerguide/create-keys.html)*をご参照ください。
KMS キー識別子を指定しない場合、DMS AWS はデフォルトの暗号化キーを使用します。KMS は、アカウントの AWS DMS AWS のデフォルトの暗号化キーを作成します。 AWS アカウントには、 AWS リージョンごとに異なるデフォルトの暗号化キーがあります。
DMS リソースの暗号化に使用されるキーを管理するには、 AWS を使用します AWS KMS。 AWS KMS ナビゲーションペインで **KMS** を検索 AWS マネジメントコンソール することで、 で を見つけることができます。
AWS KMS は、安全で可用性の高いハードウェアとソフトウェアを組み合わせて、クラウド向けにスケーリングされたキー管理システムを提供します。を使用すると AWS KMS、暗号化キーを作成し、これらのキーの使用方法を制御するポリシーを定義できます。 は AWS KMS をサポートしているため AWS CloudTrail、キーの使用状況を監査して、キーが適切に使用されていることを確認できます。 AWS KMS キーは、DMS AWS やその他のサポートされている AWS サービスと組み合わせて使用できます。サポート対象 AWS サービスには、Amazon RDS、Amazon S3、Amazon Elastic Block Store (Amazon EBS)、Amazon Redshift が含まれます。
特定の暗号化キーを使用して DMS AWS リソースを作成した場合、それらのリソースの暗号化キーを変更することはできません。 AWS DMS リソースを作成する前に、必ず暗号化キーの要件を確認してください。
# レプリケーション インスタンスの作成
データベースを移行する最初のステップは、レプリケーション インスタンスの作成です。レプリケーション インスタンスは、割り当てるタスクを実行してソースデータベースからターゲットデータベースにデータを移行するのに十分なストレージと処理能力を前提とします。このインスタンスの必要なサイズは、移行する必要のあるデータの量、および、インスタンスが実行するタスクにより異なります。レプリケーション インスタンスの詳細については、「[AWS DMS レプリケーションインスタンスの使用](CHAP_ReplicationInstance.md)」をご参照ください。
**AWS コンソールを使用してレプリケーションインスタンスを作成するには**
1. AWS DMS コンソールのナビゲーションペインで**レプリケーションインスタンス**を選択し、レ**プリケーションインスタンスの作成**を選択します。
1. [**Create replication instance**] ページで、レプリケーションのインスタンス情報を指定します。次の表は、指定できる設定について説明しています。
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/dms/latest/userguide/CHAP_ReplicationInstance.Creating.html)
1. 必要がある場合は、[**Advanced (アドバンスト)**] タブを選択して、ネットワークおよび暗号化設定の値を設定します。次の表で設定について説明します。
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/dms/latest/userguide/CHAP_ReplicationInstance.Creating.html)
1. [**Maintenance**] 設定を指定します。次の表で設定について説明します。メンテナンス設定の詳細については、「[AWS DMS メンテナンスウィンドウの使用](CHAP_ReplicationInstance.MaintenanceWindow.md)」をご参照ください。
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/dms/latest/userguide/CHAP_ReplicationInstance.Creating.html)
1. **[Create replication instance]** (レプリケーションインスタンスの作成) を選択します。
# レプリケーション インスタンスの変更
インスタンスクラスの変更やストレージの増量など、レプリケーション インスタンスの設定を変更できます。
レプリケーション インスタンスを変更する際に、変更内容を即時に適用することができます。変更をすぐに適用するには、 AWS マネジメントコンソールで **[Apply Immediately]** (すぐに適用) オプションを選択します。または、 を呼び出すときに `--apply-immediately`パラメータを使用するか AWS CLI、DMS API を使用する`true`ときに `ApplyImmediately`パラメータを に設定します。
変更の即時適用を選択しない場合、この変更は保留中の変更キューに保存されます。次のメンテナンスウィンドウ実行中に、キューのすべての保留中の変更が適用されます。
**注記**
変更の即時適用を選択した場合、保留中の変更キューにあるすべての変更も同様に適用されます。ダウンタイムを必要とする保留中の変更がある場合、[**Apply changes immediately**] を選択すると予想外のダウンタイムが発生することがあります。
**AWS コンソールを使用してレプリケーションインスタンスを変更するには**
1. にサインイン AWS マネジメントコンソール し、[https://console.aws.amazon.com/dms/v2/](https://console.aws.amazon.com/dms/v2/) で AWS DMS コンソールを開きます。
1. ナビゲーションペインで **[Replication instances]** (レプリケーション インスタンス) を選択します。
1. 変更するレプリケーション インスタンスを選択します。次の表は、行うことができる変更を示しています。
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/dms/latest/userguide/CHAP_ReplicationInstance.Modifying.html)
## レプリケーションインスタンスを変更する際のベストプラクティス
レプリケーションインスタンスを変更する場合、これらのベストプラクティスに従うことで、移行ワークフローへの影響を最小限に抑えながら更新を成功させることができます。変更前、変更中、変更後に以下の重要なステップを実行して、プロセス全体でデータの整合性と運用効率を維持します。
**計画変更のタイミング:**
+ すぐに変更を適用するか、次回のメンテナンス期間中にスケジュールすることができます。
+ トラフィックが少ない時間帯にスケジュールすれば、影響を最小限に抑えられます。
**変更前のステップ:**
+ アクティブなレプリケーションタスクをすべて停止します。
+ すべてのタスクが正常に停止したことを確認します。
+ 現在の構成タスク設定を文書化します。
**変更中:**
+ 変更の進行状況をモニタリングします。
+ 「利用可能」ステータスが表示されるのを待って、続行します。
**変更後のステップ:**
+ 以前に停止したタスクをすべて再開します。
+ タスクが正しく実行されていることを確認します。
# レプリケーション インスタンスを再起動する
AWS DMS レプリケーションインスタンスを再起動して、レプリケーションエンジンを再起動できます。再起動すると、レプリケーション インスタンスは一時的に機能停止になります。その間、インスタンスのステータスは [**Rebooting**] に設定されます。 AWS DMS インスタンスがマルチ AZ 用に設定されている場合、再起動はフェイルオーバーで実行できます。再起動が完了すると、 AWS DMS イベントが作成されます。
AWS DMS インスタンスがマルチ AZ 配置の場合、再起動時に、ある AWS アベイラビリティーゾーンから別のアベイラビリティーゾーンへの計画的なフェイルオーバーを強制できます。 AWS DMS インスタンスの計画されたフェイルオーバーを強制すると、 は、別のアベイラビリティーゾーンのスタンバイインスタンスに自動的に切り替える前に、現在のインスタンスのアクティブな接続 AWS DMS を閉じます。計画されたフェイルオーバーで再起動すると、レプリケーション AWS DMS インスタンスクラスのスケーリング時など、インスタンスの計画されたフェイルオーバーイベントをシミュレートできます。
**注記**
再起動によって、あるアベイラビリティーゾーンから別のアベイラビリティーゾーンへのフェイルオーバーが強制されると、アベイラビリティーゾーンの変更は数分間反映されないことがあります。この遅延は AWS マネジメントコンソール、 および AWS CLI AWS DMS API の呼び出しに表示されます。
再起動時にレプリケーションインスタンス上で移行タスクが実行されている場合、データ損失は発生しません。ただし、タスクは停止して、タスクのステータスがエラー状態に変わります。
移行タスク内のテーブルが一括ロード (フルロードフェーズ) の途中で、まだ開始されていない場合、テーブルはエラー状態になります。ただし、その時点で完了したテーブルは完全な状態で維持されます。フルロードフェーズ中に再起動が発生した場合は、次のいずれかのステップを実行することをお勧めします。
+ ステータスが完了であるテーブルをタスクから削除して、残りのテーブルについてタスクを再開する。
+ ステータスがエラーのテーブルと保留中のテーブルを対象とする新しいタスクを作成する。
移行タスクのテーブルが継続的なレプリケーションフェーズにある場合、再起動が完了するとタスクが再開されます。
ステータスが **Available** 状態でない場合、 AWS DMS レプリケーションインスタンスを再起動することはできません。 AWS DMS インスタンスは、以前にリクエストされた変更やメンテナンスウィンドウアクションなど、いくつかの理由で使用できない場合があります。通常、 AWS DMS レプリケーションインスタンスの再起動に必要な時間は短くなります (5 分未満）。
## AWS コンソールを使用したレプリケーションインスタンスの再起動
レプリケーションインスタンスを再起動するには、 AWS コンソールを使用します。
**AWS コンソールを使用してレプリケーションインスタンスを再起動するには**
1. にサインイン AWS マネジメントコンソール し、[https://console.aws.amazon.com/dms/v2/](https://console.aws.amazon.com/dms/v2/) で AWS DMS コンソールを開きます。
1. ナビゲーションペインで **[Replication instances]** (レプリケーション インスタンス) を選択します。
1. 再起動するレプリケーション インスタンスを選択します。
1. [**再起動**] を選択します。**[レプリケーションインスタンスの再起動]** ダイアログボックスが開きます。
1. レプリケーションインスタンスをマルチ AZ 配置向けに設定し、別の AWS アベイラビリティーゾーンにフェイルオーバーする場合は **[Reboot with planned failover?]** チェックボックスをオンにします。
1. [**再起動**] を選択します。
## CLI を使用してレプリケーション インスタンスを再起動する
レプリケーションインスタンスを再起動するには、次のパラメータを指定して コマンドを使用します AWS CLI [https://docs.aws.amazon.com/cli/latest/reference/dms/reboot-replication-instance.html](https://docs.aws.amazon.com/cli/latest/reference/dms/reboot-replication-instance.html)。
+ `--replication-instance-arn`
**Example シンプルな再起動の例**
次の の AWS CLI 例では、レプリケーションインスタンスを再起動します。
```
aws dms reboot-replication-instance \
--replication-instance-arn arn of my rep instance
```
**Example フェイルオーバーによるシンプルな再起動の例**
次の の AWS CLI 例では、フェイルオーバーを使用してレプリケーションインスタンスを再起動します。
```
aws dms reboot-replication-instance \
--replication-instance-arn arn of my rep instance \
--force-planned-failover
```
## API を使用してレプリケーション インスタンスを再起動する
レプリケーションインスタンスを再起動するには、次のパラメータを指定して AWS DMS API [https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBInstance.html](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBInstance.html)アクションを使用します。
+ `ReplicationInstanceArn = arn of my rep instance`
**Example シンプルな再起動の例**
次のコードの例では、レプリケーション インスタンスを再起動します。
```
1. https://dms.us-west-2.amazonaws.com/
2. ?Action=RebootReplicationInstance
3. &DBInstanceArn=arn of my rep instance
4. &SignatureMethod=HmacSHA256
5. &SignatureVersion=4
6. &Version=2014-09-01
7. &X-Amz-Algorithm=AWS4-HMAC-SHA256
8. &X-Amz-Credential=AKIADQKE4SARGYLE/20140425/us-east-1/dms/aws4_request
9. &X-Amz-Date=20140425T192732Z
10. &X-Amz-SignedHeaders=content-type;host;user-agent;x-amz-content-sha256;x-amz-date
11. &X-Amz-Signature=1dc9dd716f4855e9bdf188c70f1cf9f6251b070b68b81103b59ec70c3e7854b3
```
**Example フェイルオーバーによるシンプルな再起動の例**
次のコード例では、レプリケーションインスタンスを再起動し、別の AWS アベイラビリティーゾーンにフェイルオーバーします。
```
1. https://dms.us-west-2.amazonaws.com/
2. ?Action=RebootReplicationInstance
3. &DBInstanceArn=arn of my rep instance
4. &ForcePlannedFailover=true
5. &SignatureMethod=HmacSHA256
6. &SignatureVersion=4
7. &Version=2014-09-01
8. &X-Amz-Algorithm=AWS4-HMAC-SHA256
9. &X-Amz-Credential=AKIADQKE4SARGYLE/20140425/us-east-1/dms/aws4_request
10. &X-Amz-Date=20140425T192732Z
11. &X-Amz-SignedHeaders=content-type;host;user-agent;x-amz-content-sha256;x-amz-date
12. &X-Amz-Signature=1dc9dd716f4855e9bdf188c70f1cf9f6251b070b68b81103b59ec70c3e7854b3
```
# レプリケーション インスタンスを削除する
AWS DMS レプリケーションインスタンスは、使用が終了したら削除できます。レプリケーション インスタンスを使用する移行タスクがある場合は、レプリケーション インスタンスを削除する前に、タスクを停止して削除する必要があります。
AWS アカウントを閉じると、アカウントに関連付けられたすべての AWS DMS リソースと設定が 2 日後に削除されます。これらのリソースには、すべてのレプリケーション インスタンス、ソースおよびターゲットのエンドポイント設定、レプリケーションタスク、および SSL 証明書が含まれます。2 日後に AWS DMS を再度使用する場合は、必要なリソースを再作成します。
レプリケーションインスタンスが削除基準をすべて満たしていて、長期間ステータスが `DELETING` のままの場合は、サポートに連絡して問題のトラブルシューティングを行います。
## AWS コンソールを使用したレプリケーションインスタンスの削除
レプリケーションインスタンスを削除するには、 AWS コンソールを使用します。
**AWS コンソールを使用してレプリケーションインスタンスを削除するには**
1. にサインイン AWS マネジメントコンソール し、[https://console.aws.amazon.com/dms/v2/](https://console.aws.amazon.com/dms/v2/) で AWS DMS コンソールを開きます。
1. ナビゲーションペインで **[Replication instances]** (レプリケーション インスタンス) を選択します。
1. 削除するレプリケーション インスタンスを選択します。
1. **[削除]** を選択します。
1. ダイアログボックスで、[**Delete**] を選択します。
## CLI を使用したレプリケーション インスタンスの削除
レプリケーションインスタンスを削除するには、次のパラメータを指定して コマンドを使用します AWS CLI [https://docs.aws.amazon.com/cli/latest/reference/dms/delete-replication-instance.html](https://docs.aws.amazon.com/cli/latest/reference/dms/delete-replication-instance.html)。
+ `--replication-instance-arn`
**Example 削除の例**
次の の AWS CLI 例では、レプリケーションインスタンスを削除します。
```
aws dms delete-replication-instance \
--replication-instance-arn arn of my rep instance
```
## API を使用したレプリケーション インスタンスの削除
レプリケーションインスタンスを削除するには、次のパラメータを指定して AWS DMS API [https://docs.aws.amazon.com/dms/latest/APIReference/API_DeleteReplicationInstance.html](https://docs.aws.amazon.com/dms/latest/APIReference/API_DeleteReplicationInstance.html)アクションを使用します。
+ `ReplicationInstanceArn = arn of my rep instance`
**Example 削除の例**
次のコードの例では、レプリケーション インスタンスを削除します。
```
1. https://dms.us-west-2.amazonaws.com/
2. ?Action=DeleteReplicationInstance
3. &DBInstanceArn=arn of my rep instance
4. &SignatureMethod=HmacSHA256
5. &SignatureVersion=4
6. &Version=2014-09-01
7. &X-Amz-Algorithm=AWS4-HMAC-SHA256
8. &X-Amz-Credential=AKIADQKE4SARGYLE/20140425/us-east-1/dms/aws4_request
9. &X-Amz-Date=20140425T192732Z
10. &X-Amz-SignedHeaders=content-type;host;user-agent;x-amz-content-sha256;x-amz-date
11. &X-Amz-Signature=1dc9dd716f4855e9bdf188c70f1cf9f6251b070b68b81103b59ec70c3e7854b3
```
# AWS DMS メンテナンスウィンドウの使用
すべての AWS DMS レプリケーションインスタンスには、利用可能なシステム変更が適用される毎週のメンテナンスウィンドウがあります。メンテナンスウィンドウは、変更やソフトウェアのパッチなどが実行されるタイミングをコントロールする機会と考えることができます。
が特定の週にメンテナンスが必要である AWS DMS と判断した場合、レプリケーションインスタンスの作成時に選択した 30 分のメンテナンスウィンドウ中にメンテナンスが発生します。 は 30 分のメンテナンスウィンドウ中にほとんどのメンテナンス AWS DMS を完了します。ただし、大規模な変更の場合より長い時間がかかる場合があります。
## 既存の移行タスクにおけるメンテナンスの効果
インスタンスで AWS DMS 移行タスクが実行されている場合、パッチが適用されると次のイベントが発生します。
+ 移行タスクのテーブルで継続的な変更フェーズ (CDC) のレプリケートを実行している場合、 AWS DMS は、タスクを一時停止して、パッチの適応後に再開します。その後、パッチが適用されると、移行は中断されたところから再開します。
+ AWS DMS が**既存のデータを**移行する、または**既存のデータを移行して進行中の変更タスクをレプリケー**トする場合、DMS はパッチの適用中に全ロードフェーズにあるすべてのテーブルの移行を停止して再起動します。また、DMS は、パッチの適用中に CDC フェーズにあるすべてのテーブルを停止して、再開します。
## メンテナンスウィンドウ設定の変更
メンテナンスウィンドウの時間枠は、 AWS マネジメントコンソール、、 AWS CLIまたは AWS DMS API を使用して変更できます。
### コンソールを使用したメンテナンス ウィンドウ設定の変更
メンテナンスウィンドウの時間枠は、 AWS マネジメントコンソールを使用して変更できます。
**コンソールを使用して優先メンテナンスウィンドウを変更するには**
1. にサインイン AWS マネジメントコンソール し、[https://console.aws.amazon.com/dms/v2/](https://console.aws.amazon.com/dms/v2/) で AWS DMS コンソールを開きます。
1. ナビゲーションペインで **[Replication instances]** (レプリケーション インスタンス) を選択します。
1. 変更するレプリケーション インスタンスを選択してから、[**Modify**] を選択します。
1. [**Maintenance**] タブを展開し、メンテナンスウィンドウの日時を選択します。
1. [**Apply changes immediately**] を選択します。
1. **[Modify]** (変更) を選択します。
### CLI を使用したメンテナンスウィンドウ設定の変更
希望するメンテナンスウィンドウを調整するには、以下のパラメータを指定 AWS CLI [https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-instance.html](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-instance.html)して コマンドを使用します。
+ `--replication-instance-identifier`
+ `--preferred-maintenance-window`
**Example**
次の AWS CLI 例では、メンテナンスウィンドウを火曜日の午前 4 時～午前 4 時 30 分に設定します。。
```
aws dms modify-replication-instance \
--replication-instance-identifier myrepinstance \
--preferred-maintenance-window Tue:04:00-Tue:04:30
```
### API を使用したメンテナンスウィンドウ設定の変更
希望するメンテナンスウィンドウを調整するには、以下のパラメータを指定して AWS DMS API [https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBInstance.html](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBInstance.html)アクションを使用します。
+ `ReplicationInstanceIdentifier = myrepinstance`
+ `PreferredMaintenanceWindow = Tue:04:00-Tue:04:30`
**Example**
次のコード例では、メンテナンスウィンドウを火曜日の午前 4:00 ～ 4:30 UTC に設定します 。
```
1. https://dms.us-west-2.amazonaws.com/
2. ?Action=ModifyReplicationInstance
3. &DBInstanceIdentifier=myrepinstance
4. &PreferredMaintenanceWindow=Tue:04:00-Tue:04:30
5. &SignatureMethod=HmacSHA256
6. &SignatureVersion=4
7. &Version=2014-09-01
8. &X-Amz-Algorithm=AWS4-HMAC-SHA256
9. &X-Amz-Credential=AKIADQKE4SARGYLE/20140425/us-east-1/dms/aws4_request
10. &X-Amz-Date=20140425T192732Z
11. &X-Amz-SignedHeaders=content-type;host;user-agent;x-amz-content-sha256;x-amz-date
12. &X-Amz-Signature=1dc9dd716f4855e9bdf188c70f1cf9f6251b070b68b81103b59ec70c3e7854b3
```