

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

# でのレイテンシーの問題のトラブルシューティング AWS Database Migration Service
<a name="CHAP_Troubleshooting_Latency"></a>

このセクションでは、継続的なレプリケーションフェーズ (CDC) 中の AWS DMS タスクレイテンシーの一般的な原因の概要を説明します。 はデータを非同期的に AWS DMS レプリケートします。レイテンシーは、変更がソースにコミットされてから、その変更がターゲットにレプリケートされるまでの遅延を指します。レイテンシーは、次のとおりのレプリケーションコンポーネントの設定ミスが原因で発生する可能性があります。
+ ソースエンドポイントまたはデータソース
+ ターゲットエンドポイントまたはデータソース
+ レプリケーション インスタンス
+ 上記コンポーネント間のネットワーク

レプリケーションに関する情報を収集するための概念実証としてテスト移行を使用することをお勧めします。その後、この情報を使用してレプリケーション設定を調整して、レイテンシーを最小限に抑えることができます。概念実証の移行の実行については、「[PoC (概念実証) を実行する](CHAP_BestPractices.md#CHAP_BestPractices.RunPOC)」を参照してください。

**Topics**
+ [CDC レイテンシーのタイプ](#CHAP_Troubleshooting_Latency_Types)
+ [CDC レイテンシーの一般的な原因](#CHAP_Troubleshooting_Latency_Causes)
+ [レイテンシーに関する問題のトラブルシューティング](CHAP_Troubleshooting_Latency_Troubleshooting.md)

## CDC レイテンシーのタイプ
<a name="CHAP_Troubleshooting_Latency_Types"></a>

このセクションでは、CDC 中に発生する可能性のあるレプリケーションレイテンシーのタイプについて説明します。

### ソースのレイテンシー
<a name="CHAP_Troubleshooting_Latency_Types_Source"></a>

ソースエンドポイントからキャプチャされた最後のイベントのコミット時刻とレプリケーションインスタンスの現在のシステムタイムスタンプ間のレイテンシー (秒単位)。データソースとレプリケーションインスタンス間のレイテンシーは、`CDCLatencySource` CloudWatch メトリクスを使用してモニタリングできます。`CDCLatencySource` メトリクスが高いと、ソースからの変更をキャプチャするプロセスが遅延していることを意味します。たとえば、アプリケーションが 10:00 にソースへの挿入をコミットし、10:02 に変更を AWS DMS 消費する場合、`CDCLatencySource`メトリクスは 120 秒です。

の CloudWatch メトリクスの詳細については AWS DMS、「」を参照してください[レプリケーションタスクのメトリクス](CHAP_Monitoring.md#CHAP_Monitoring.Metrics.Task)。

### ターゲットのレイテンシー
<a name="CHAP_Troubleshooting_Latency_Types_Target"></a>

ターゲットへのコミットを待機している最初のイベントのソースでのコミット時間と DMS レプリケーションインスタンスの現在のタイムスタンプとの間のレイテンシー (秒単位)。データソースとデータターゲットのコミット間のレイテンシーは、`CDCLatencyTarget` CloudWatch メトリクスを使用してモニタリングできます。つまり、`CDCLatencyTarget` にはソースからの読み取り遅延も含まれます。その結果、`CDCLatencyTarget` は常に `CDCLatencySource` 以上になります。

たとえば、アプリケーションが 10:00 にソースへの挿入をコミットし、10:02 に AWS DMS 消費して 10:05 にターゲットに書き込む場合、`CDCLatencyTarget`メトリクスは 300 秒です。

## CDC レイテンシーの一般的な原因
<a name="CHAP_Troubleshooting_Latency_Causes"></a>

このセクションでは、CDC 中のレプリケーションで発生する可能性のあるレイテンシーの原因について説明します。

**Topics**
+ [エンドポイントのリソース](#CHAP_Troubleshooting_Latency_Causes_Endpoint)
+ [レプリケーションインスタンスのリソース](#CHAP_Troubleshooting_Latency_Causes_Replication_Instance)
+ [ネットワーク速度と帯域幅](#CHAP_Troubleshooting_Latency_Causes_Replication_Network)
+ [DMS の設定](#CHAP_Troubleshooting_Latency_Causes_Replication_DMS_Config)
+ [レプリケーションのシナリオ](#CHAP_Troubleshooting_Latency_Causes_Replication_Scenarios)

### エンドポイントのリソース
<a name="CHAP_Troubleshooting_Latency_Causes_Endpoint"></a>

レプリケーションのパフォーマンスとレイテンシーに多大な影響を及ぼすのは次の要因です。
+ ソースデータベースとターゲットデータベースの設定
+ インスタンスサイズ
+ ソースデータストアまたはターゲットデータストアがプロビジョニング不足または設定の誤り

ホストされたソースとターゲットのエンドポイントの問題によって引き起こされるレイテンシーの原因を特定するには、次の CloudWatch AWSメトリクスをモニタリングします。
+ `FreeMemory`
+ `CPUUtilization`
+ `WriteIOPS`、`WriteThroughput`、または `ReadLatency` などのスループットと I/O メトリクス
+ `CDCIncomingChanges` などのトランザクションボリュームメトリクス

CloudWatch メトリクスのモニタリングの詳細については、「[AWS Database Migration Service メトリクス](CHAP_Monitoring.md#CHAP_Monitoring.Metrics)」を参照してください。

### レプリケーションインスタンスのリソース
<a name="CHAP_Troubleshooting_Latency_Causes_Replication_Instance"></a>

レプリケーションインスタンスのリソースはレプリケーションに不可欠であり、ソースとターゲットの両方のレイテンシーにつながる可能性があるため、リソースのボトルネックがないことを確認する必要があります。

レプリケーションインスタンスのリソースのボトルネックを特定するには、次を確認します。
+ CPU、メモリ、1 秒あたりの I/O、ストレージなどの重要な CloudWatch メトリクスでスパイクが発生したり、常に高い値になったりすることがないこと
+ レプリケーションインスタンスのサイズがワークロードに応じて適切に設定されていること。レプリケーションインスタンスの適切なサイズを決定する方法の詳細については、「[レプリケーションインスタンス向けの最適なサイズの選択](CHAP_BestPractices.SizingReplicationInstance.md)」を参照してください。

### ネットワーク速度と帯域幅
<a name="CHAP_Troubleshooting_Latency_Causes_Replication_Network"></a>

ネットワーク帯域幅は、データ送信に影響を与える要因となります。レプリケーションのネットワークパフォーマンスを分析するには、次のいずれかを実行します。
+ インスタンスレベルで `ReadThroughput` メトリクスと `WriteThroughput` メトリクスを確認します。CloudWatch メトリクスのモニタリングの詳細については、「[AWS Database Migration Service メトリクス](CHAP_Monitoring.md#CHAP_Monitoring.Metrics)」を参照してください。
+  AWS DMS 診断サポート AMI を使用します。Diagnostic Support AMI が現在のリージョンで利用できない場合は、サポートされている任意のリージョンからダウンロードして現在のリージョンにコピーすると、ネットワーク分析を実行できます。Diagnostic Support AMI の詳細については、「[AWS DMS 診断サポート AMI の使用](CHAP_SupportAmi.md)」を参照してください。

の CDC AWS DMS は、データの整合性を確保するためにシングルスレッドです。そのため、シングルスレッドのデータ転送速度を計算すると、ネットワークがサポートできるデータ量を決定できます。例えば、タスクが 100 Mbps (メガビット/秒) のネットワークを使用してソースに接続する場合、理論上、レプリケーションの最大帯域幅割り当ては 12.5 Mbps (メガバイト/秒) です。これは 1 時間あたり 45 ギガビットに相当します。ソースでのトランザクションログの生成速度が 45 ギガビット/時を超える場合は、タスクで CDC レイテンシーが発生することを意味します。100 Mbps のネットワークでは、上記の速度は理論上の最大値です。ネットワークトラフィックやソースとターゲットのリソースのオーバーヘッドなどのその他の要因によって、実際に使用できる帯域幅は減少します。

### DMS の設定
<a name="CHAP_Troubleshooting_Latency_Causes_Replication_DMS_Config"></a>

このセクションでは、レイテンシーの軽減に役立つレプリケーションの推奨設定を説明します。
+ **エンドポイント設定**: ソースエンドポイントとターゲットエンドポイント設定がレプリケーションインスタンスのパフォーマンス低下の原因となる場合があります。リソースを大量に利用する機能を有効にするエンドポイント設定は、パフォーマンスに影響します。例えば Oracle エンドポイントの場合、LogMiner はリソースを大量に消費するため、LogMiner を無効にして Binary Reader を使用するとパフォーマンスが向上します。Oracle エンドポイントのパフォーマンスを向上するエンドポイント設定は次のとおりです。

  ```
  useLogminerReader=N;useBfile=Y
  ```

  エンドポイント設定の詳細については、「[DMS AWS エンドポイントの使用](CHAP_Endpoints.md)」トピックのソースエンドポイントとターゲットエンドポイントエンジンのドキュメントを参照してください。
+ **タスク設定**: 特定のレプリケーションシナリオのタスク設定によっては、レプリケーションインスタンスのパフォーマンスが低下する場合があります。例えば、 AWS DMS は、Amazon Redshift 以外のすべてのエンドポイントの CDC にデフォルトでトランザクション適用モード (`BatchApplyEnabled=false`) を使用します。ただし、変更が多数あるソースでは、`BatchApplyEnabled` を `true` に設定するとパフォーマンスが向上する可能性があります。

  タスク設定の詳細については、「[AWS Database Migration Service タスクのタスク設定の指定](CHAP_Tasks.CustomizingTasks.TaskSettings.md)」をご参照ください。
+ **CDC のみのタスクの開始位置**: 以前の位置またはタイムスタンプから CDC のみのタスクを開始すると、タスク開始時に CDC ソースのレイテンシーが増大します。ソースの変更量によっては、タスクのレイテンシーが低減するまで時間がかかります。
+ **LOB 設定**: ラージオブジェクトデータ型は、 がラージバイナリデータをレプリケートする方法により、レ AWS DMS プリケーションパフォーマンスを妨げる可能性があります。詳細については、以下の各トピックを参照してください。
  + [AWS DMS タスクでのソースデータベースの LOB サポートの設定](CHAP_Tasks.LOBSupport.md)
  + [ラージバイナリオブジェクト (LOB) の移行](CHAP_BestPractices.md#CHAP_BestPractices.LOBS).

### レプリケーションのシナリオ
<a name="CHAP_Troubleshooting_Latency_Causes_Replication_Scenarios"></a>

このセクションでは、特定のレプリケーションシナリオと、レイテンシーへの影響について説明します。

**Topics**
+ [タスクの長時間にわたる停止](#CHAP_Troubleshooting_Latency_Causes_Replication_Scenarios_Stoptask)
+ [キャッシュされた変更](#CHAP_Troubleshooting_Latency_Causes_Replication_Scenarios_Cachedchanges)
+ [クロスリージョンレプリケーション](#CHAP_Troubleshooting_Latency_Causes_Replication_Scenarios_Crossregion)

#### タスクの長時間にわたる停止
<a name="CHAP_Troubleshooting_Latency_Causes_Replication_Scenarios_Stoptask"></a>

タスクを停止すると、 はソースから読み取られた最後のトランザクションログの位置 AWS DMS を保存します。タスクを再開すると、DMS は同じトランザクションログ位置からの読み取りを続けようとします。タスクの再開が数時間または数日後の場合、DMS がトランザクションバックログの処理を完了するまで CDC ソースのレイテンシーが増大します。

#### キャッシュされた変更
<a name="CHAP_Troubleshooting_Latency_Causes_Replication_Scenarios_Cachedchanges"></a>

**キャッシュされた変更は**、 が全ロードレプリケーションフェーズ AWS DMS を実行している間にアプリケーションがデータソースに書き込む変更です。DMS は、フルロードフェーズが完了して CDC フェーズが開始されるまで、このような変更を適用しません。多数のトランザクションがあるソースの場合、キャッシュされた変更の適用には時間がかかるため、CDC フェーズが開始されるとソースのレイテンシーが増加します。キャッシュされた変更数を最小限に抑えるため、フルロードフェーズは、トランザクション量が少ないケースで実行することをお勧めします。

#### クロスリージョンレプリケーション
<a name="CHAP_Troubleshooting_Latency_Causes_Replication_Scenarios_Crossregion"></a>

DMS エンドポイントまたはレプリケーションインスタンスを異なる AWS リージョンに配置すると、ネットワークレイテンシーが増加します。これにより、レプリケーションレイテンシーも長くなります。最高のパフォーマンスを得るには、ソースエンドポイント、ターゲットエンドポイント、レプリケーションインスタンスを同じ AWS リージョンに配置します。