

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

# AWS DMS サーバーレスコンポーネント
<a name="CHAP_Serverless.Components"></a>

レプリケーションの実行に必要なリソースを管理するために、 AWS DMS Serverless には、サービスによって実行されるさまざまな内部アクションを明らかにする詳細な状態があります。レプリケーションを開始すると、 AWS DMS Serverless は容量負荷を計算して、計算した容量をプロビジョンし、次のとおり、レプリケーションのステータスに応じてデータレプリケーションを開始します。

次の図は、 AWS DMS サーバーレスレプリケーションの状態遷移を示しています。

![\[AWS DMS サーバーレスレプリケーションの状態\]](http://docs.aws.amazon.com/ja_jp/dms/latest/userguide/images/datarep-replicationstate_updated.png)

+ レプリケーションを開始した後の最初のステータスは「**初期化中**」です。このステータスでは、必要なパラメータがすべて初期化されます。
+ その直後のステータスには、「**メタデータリソースを準備しています**」、「**接続をテストしています**」、「**メタデータを取得しています**」などがあります。これらの状態では、 AWS DMS Serverless はソースデータベースに接続して、必要な容量を予測するために必要な情報を取得します。
  + レプリケーション状態が**接続のテスト**の場合、 AWS DMS Serverless はソースデータベースとターゲットデータベースへの接続が正常にセットアップされていることを確認します。
  + 「**接続をテストしています**」の次のレプリケーションステータスは、「**メタデータを取得しています**」です。ここで、 は容量の計算に必要な情報 AWS DMS を取得します。
  + が必要な情報 AWS DMS を取得すると、次の状態は**容量の計算**になります。このステータスの場合、システムはレプリケーションの実行に必要となる基盤のリソースのサイズを計算します。
+ 「**キャパシティを計算しています**」の次に遷移するステータスは、「**キャパシティをプロビジョニングしています**」です。レプリケーションのステータスがこの状態の場合、 AWS DMS Serverless は基盤となるコンピューティングリソースを初期化します。
+ すべてのリソースのプロビジョニングが正常に完了した後のレプリケーションのステータスは、「**レプリケーション開始**」です。この状態では、 AWS DMS Serverless はデータのレプリケーションを開始します。レプリケーションのフェーズには以下が含まれます。
  + **フルロード:** このフェーズでは、DMS はレプリケーションの開始時と同じようにソースデータストアをレプリケートします。
  + **CDC (初期):** このフェーズでは、DMS はフルロードフェーズ中に発生したソースデータストアに変更をレプリケートします。`StopTaskCachedChangesNotApplied` タスク設定が `false` の場合、DMS はこのフェーズを実行するだけです。
  + **CDC (進行中):** CDC の初期フェーズの後、DMS は変更が発生したときにソースデータベースにレプリケートします。`StopTaskCachedChangesApplied` タスク設定が `false` の場合、DMS は CDC の初期フェーズの後にレプリケーションの実行を継続するだけです。
+ 最後のステータスは、「**実行中**」です。**実行中**ステータスの場合、データレプリケーションが進行中です。
+ 停止したレプリケーションは、**[停止済み]** 状態になります。正常に完了したフルロードのみのレプリケーションタスクでは、レプリケーションが停止状態になる可能性があります。これらの状況は、停止または失敗した状態でレプリケーションを再開または再起動することを考慮する必要があります。
  + がリソースのプロビジョニング AWS DMS を解除するため、48 時間以内に開始されていないレプリケーションを再起動することはできません。

**Topics**
+ [サポートされているエンドポイント](#CHAP_Serverless.SupportedVersions)
+ [サーバーレスレプリケーションの作成](#CHAP_Serverless.create)
+ [AWS DMS サーバーレスレプリケーションの変更](#CHAP_Serverless.modify)
+ [コンピューティング設定](#CHAP_Serverless.computeconfig)
+ [AWS DMS サーバーレスでの Auto Scaling について](#CHAP_Serverless.autoscaling)
+ [AWS DMS サーバーレスレプリケーションのモニタリング](#CHAP_Serverless.monitoring)
+ [フルロード Oracle から Amazon Redshift および Amazon S3 への移行の拡張スループットの向上](#CHAP_Serverless.Throughput)
+ [AWS DMS サーバーレスでのストレージの自動スケーリングについて](#CHAP.Serverless.storage.autoscaling)

 AWS DMS Serverless の場合、 AWS DMS コンソールの左側のナビゲーションパネルに新しいオプション **Serverless レプリケーション**があります。**サーバーレスレプリケーション**を使用すると、レプリケーションのインスタンスタイプやタスクの代わりに*レプリケーション*を指定してレプリケーションを定義できます。さらに、DMS がレプリケーション用にプロビジョンする DMS キャパシティユニット (DCU) の最大値と最小値を指定できます。DCU は 2GB の RAM です。レプリケーションが現在使用している DCU ごとにアカウントに AWS DMS 請求されます。 AWS DMS 料金の詳細については、[AWS 「 Database Migration Service の料金](https://aws.amazon.com/dms/pricing/)」を参照してください。

AWS DMS は、テーブルマッピングとワークロードの予測サイズに基づいてレプリケーションリソースを自動的にプロビジョニングします。このキャパシティユニットは、指定する最小キャパシティユニット値と最大キャパシティユニット値の範囲内の値となります。

## サポートされているエンドポイント
<a name="CHAP_Serverless.SupportedVersions"></a>

 AWS DMS Serverless では、サービスがその設定を処理するため、エンジンバージョンを選択および管理する必要はありません。 AWS DMS Serverless は、次のソースをサポートしています。
+ MongoDB
+ Amazon DocumentDB (MongoDB 互換性)
+ Microsoft SQL Server
+ PostgreSQL 互換データベース
+ MySQL 互換データベース
+ MariaDB
+ Oracle
+ Amazon S3
+ IBM Db2

AWS DMS Serverless は、次のターゲットをサポートしています。
+ Microsoft SQL Server
+ [PostgreSQL]
+ MySQL 互換データベース
+ Oracle
+ Amazon S3
+ Amazon Redshift
+ Amazon DynamoDB
+ Amazon Kinesis Data Streams
+ Amazon Managed Streaming for Apache Kafka
+ Amazon OpenSearch Service
+ Amazon DocumentDB (MongoDB 互換性)
+ Amazon Neptune



 AWS DMS Serverless の一部として、 AWS DMS サーバーレスレプリケーションを作成、設定、開始、管理できるコンソールコマンドにアクセスできます。コンソールの **[サーバーレスレプリケーション]** のセクションを使用して、このようなコマンドを実行するには、次のいずれかを実行する必要があります。
+ 新しい AWS Identity and Access Management (IAM) ポリシーと IAM ロールを設定して、そのポリシーをアタッチします。
+  AWS CloudFormation テンプレートを使用して、必要なアクセスを提供します。

AWS DMS Serverless では、サービスにリンクされたロール (SLR) がアカウントに存在する必要があります。 はこのロールの作成と使用 AWS DMS を管理します。必要な SLR があることを確認する方法の詳細については、「[のサービスにリンクされたロール AWS DMS](slr-services-sl.md)」を参照してください。

## サーバーレスレプリケーションの作成
<a name="CHAP_Serverless.create"></a>

2 つの既存の AWS DMS エンドポイント間でサーバーレスレプリケーションを作成するには、次の手順を実行します。 AWS DMS エンドポイントの作成の詳細については、「」を参照してください[ソースおよびターゲットエンドポイントの作成](CHAP_Endpoints.Creating.md)。

**サーバーレスレプリケーションの作成**

1. にサインイン AWS マネジメントコンソール し、[https://console.aws.amazon.com/dms/v2/](https://console.aws.amazon.com/dms/v2/) で AWS DMS コンソールを開きます。

1. ナビゲーションペインで、**[サーバーレスレプリケーション]** を選択して、**[レプリケーションの作成]** をクリックします。

1. **[レプリケーションの作成]** ページで、次のとおりサーバーレスレプリケーションの設定を指定します。    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/dms/latest/userguide/CHAP_Serverless.Components.html)

   **[設定]** セクションで、レプリケーションのニーズに応じて設定を行います。

   **[テーブルマッピング]** セクションでは、テーブルマッピングを設定して、レプリケートするデータを選択したりフィルタリングしたりするためのルールを定義します。マッピングを指定する前に、ソースデータベースとターゲットデータベースのデータ型マッピングのドキュメントセクションを確認してください。ソースデータベースとターゲットデータベースのデータ型マッピングの詳細については、[DMS AWS エンドポイントの使用](CHAP_Endpoints.md) トピックのソースエンドポイントタイプとターゲットエンドポイントタイプのデータ型セクションを参照してください。

   **[コンピューティング設定]** セクションで、次のとおり設定します。コンピューティング設定の詳細については、「[コンピューティング設定](#CHAP_Serverless.computeconfig)」を参照。    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/dms/latest/userguide/CHAP_Serverless.Components.html)

   **[メンテナンス]** 設定はそのままにします。

1. **[レプリケーションインスタンスを作成]** をクリックします。

AWS DMS は、移行を実行するサーバーレスレプリケーションを作成します。

## AWS DMS サーバーレスレプリケーションの変更
<a name="CHAP_Serverless.modify"></a>

レプリケーションの設定を変更するには、`modify-replication-config` アクションを使用します。変更できるのは、、`CREATED`、`STOPPED`または `FAILED`状態の AWS DMS レプリケーション設定のみです。`modify-replication-config` アクションの詳細については、「*AWS Database Migration Service API リファレンス*」の「[ModifyReplicationConfig](https://docs.aws.amazon.com/dms/latest/APIReference/API_ModifyReplicationConfig.html)」を参照してください。

**を使用してサーバーレスレプリケーション設定を変更するには AWS マネジメントコンソール**

1. にサインイン AWS マネジメントコンソール し、[https://console.aws.amazon.com/dms/v2/](https://console.aws.amazon.com/dms/v2/) で AWS DMS コンソールを開きます。

1. ナビゲーションペインで **[サーバーレスレプリケーション]** を選択します。

1. 変更するレプリケーションを選択します。次の表では、レプリケーションの現在のステータスに基づいて実行できる変更について説明しています。    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/dms/latest/userguide/CHAP_Serverless.Components.html)

**注記**  
タスクのステータスが開始または実行中の場合、DMS タスクに関連付けられたエンドポイントを変更することはできません。

## コンピューティング設定
<a name="CHAP_Serverless.computeconfig"></a>

コンピューティング設定のパラメータまたはコンソールのセクションを使用してレプリケーションのプロビジョニングを設定します。コンピューティング設定オブジェクトには次のフィールドがあります。


| オプション | 説明 | 
| --- | --- | 
|   **MinCapacityUnits**   | これは、 がプロビジョニングする DMS キャパシティーユニット (DCU) の最小数 AWS DMS です。これは、自動スケーリングでスケールダウンできる最小の DCU でもある。 | 
|   **MaxCapacityUnits**   | レプリケーションの容量予測に応じて、 AWS DMS がプロビジョンできる最大 DMS キャパシティユニット (DCU)。自動スケーリングでスケールアップできる最大 DCU でもある。 | 
|   **KmsKeyId**   | レプリケーションストレージと接続情報の暗号化に使用する暗号キー。(デフォルト) aws/dms を選択した場合、 はアカウントと に関連付けられたデフォルトの KMS キー AWS DMS を使用します AWS リージョン。説明とアカウント番号が、キーの ARN とともに表示されます。暗号化キーの使用の詳細については、「[暗号化キーの設定と AWS KMS アクセス許可の指定](CHAP_Security.md#CHAP_Security.EncryptionKey)」を参照。このチュートリアルでは、[(デフォルト) aws/dms] が選択されたままにする。 | 
|   **ReplicationSubnetGroupId**   | 選択した VPC 内のレプリケーションを作成するレプリケーションサブネットグループ。ソースデータベースが VPC 内にある場合は、レプリケーションの場所として、ソースデータベースを含むサブネットグループを選択する。レプリケーション サブネットグループの詳細については、「[レプリケーション サブネットグループの作成](CHAP_ReplicationInstance.VPC.md#CHAP_ReplicationInstance.VPC.Subnets)」をご参照ください。 | 
|   **VpcSecurityGroupIds**   | レプリケーションのインスタンスが VPC 内で作成されます。ソースデータベースが VPC 内にある場合は、データベースが配置されている DB インスタンスへのアクセス許可を付与する VPC セキュリティグループを選択する。 | 
|   **PreferredMaintenanceWindow**   | このパラメータは、システムメンテナンスを実行できる毎週の時間帯を協定世界時 (UTC) で定義する。デフォルトは、1 週間のうちのランダムな日に発生する AWS リージョン 8 時間の時間枠からランダムに選択された 30 分のウィンドウです。 | 
|   **マルチ AZ**   | このオプションのパラメータを使用すると、フェイルオーバーをサポートするために別のアベイラビリティーゾーンにレプリケーションのスタンバイレプリカが作成される。変更データキャプチャ (CDC) または進行中のレプリケーションを使用する場合は、このオプションを有効にする必要がある。 | 

## AWS DMS サーバーレスでの Auto Scaling について
<a name="CHAP_Serverless.autoscaling"></a>

レプリケーションをプロビジョニングして `RUNNING`状態になると、 AWS DMS サービスは、変化するワークロードに適応するために基盤となるリソースの容量を管理します。この管理では、次のレプリケーション設定に基づいてレプリケーションリソースをスケールします。
+ `MinCapacityUnits`
+ `MaxCapacityUnits`

レプリケーションは、使用率のしきい値の上限を一定期間超えるとスケールアップし、容量使用率が長期間にわたり最小容量使用率のしきい値を下回るとスケールダウンします。

**注記**  
サーバーレスレプリケーションは、フルロードの進行中は自動スケールダウンできません。

### AWS DMS サーバーレスでの Auto Scaling のチューニング
<a name="CHAP_Serverless.autoscaling.tuning"></a>

レプリケーションの自動スケーリングパラメータを調整するには、 を最大値`MaxCapacityUnits`に設定し、 がリソースのプロビジョニング AWS DMS を管理することをお勧めします。トランザクション量の急増に対応できるように、自動スケーリングの利点を最大限に活用するには、DCU の最大容量を最大に設定することをお勧めします。料金見積りツールには、レプリケーションで最大 DCU を継続的に使用する場合の最大月額コストが表示されます。実際には使用した容量に対してのみ課金されるため、最大 DCU は実際のコストを示すものではありません。

レプリケーションでリソースをフルキャパシティーで使用していない場合、 AWS DMS はコストを節約するためにリソースのプロビジョニングを徐々に解除します。ただし、リソースのプロビジョニングとプロビジョニング解除には時間がかかるため、`MinCapacityUnits` にはレプリケーションワークロードの突発的なスパイクに対応できる値を設定することをお勧めします。これにより、レプリケーションのプロビジョニングが不足しなくなりますが、 はより高いワークロードレベルのリソースを AWS DMS プロビジョニングします。

レプリケーションのアンダープロビジョニングにより、最大容量設定がデータ要件に対して低すぎるか、最小容量設定がレプリケーションワークロードの突然の急増の処理には低すぎる場合、`CapacityUtilization` メトリクスが常に最大値になり、レプリケーションの失敗につながる場合があります。リソースのプロビジョニング不足が原因でレプリケーションが失敗した場合、 はレプリケーションログにout-of-memoryイベント AWS DMS を作成します。レプリケーションワークロードの急増または設定のチューニングにより out-of-memory 状態が発生した場合、システムは組み込みの自動スケーリング機能を使用して、状況に対応し処理を再開します。ただし、この自動復旧メカニズムは即時ではなく、有効になるまでに時間がかかる場合があります。復旧を高速化するには、タスク設定を変更し、特に `MinCapacityUnits` 値を増やしてからタスクを再開することで、手動アクションを実行できます。この手動介入により、自動スケーリングプロセスを待つよりも早く out-of-memory エラーを解決できます。

## AWS DMS サーバーレスレプリケーションのモニタリング
<a name="CHAP_Serverless.monitoring"></a>

AWS には、 AWS DMS サーバーレスレプリケーションをモニタリングし、潜在的なインシデントに対応するためのツールがいくつか用意されています。
+ [AWS DMS サーバーレスレプリケーションメトリクス](#CHAP_Serverless.monitoring.metrics)
+ [AWS DMS サーバーレスレプリケーションログ](#CHAP_Serverless.monitoring.logs)

### AWS DMS サーバーレスレプリケーションメトリクス
<a name="CHAP_Serverless.monitoring.metrics"></a>

サーバーレスレプリケーションのモニタリングには、次の統計の Amazon CloudWatch メトリクスが含まれます。これらの統計はサーバーレスレプリケーションごとにグループ化されています。


|  メトリクス  |  単位  |  説明  | 
| --- | --- | --- | 
| CapacityUtilization | 割合 (%) |  サーバーレスレプリケーションによるメモリ使用率  | 
| CDCIncomingChanges | 割合 (%) |  ターゲットへの適用を待機している、特定の時点での変更イベントの合計数。これは、ソースエンドポイントのトランザクション変更レートの測定と同じではありません。通常、このメトリクスの数値が大きい AWS DMS 場合は、キャプチャされた変更をタイムリーに適用できず、ターゲットレイテンシーが高くなることを示します。  | 
| CDCLatencySource (CDCレイテンシーソース) | 秒 |  ソース エンドポイントからキャプチャされた最後のイベントと、 AWS DMS インスタンスの現在のシステム タイムスタンプの間の間隔 (秒)。CDCLatencySource は、ソースインスタンスとレプリケーション インスタンス間のレイテンシーを表します。高い CDCLatencySource は、ソースからの変更をキャプチャするプロセスが遅延することを意味します。進行中のレプリケーションのレイテンシーを特定するには、このメトリクスを CDCLatencyTarget とともに表示できます。CDCLatencySource と CDCLatencyTarget の両方が高い場合は、まず CDCLatencySource を調べてください。 ソースとレプリケーションの間にレプリケーションラグがない場合、CDCLatencySource は 0 になる場合がある。CDCLatencySource は、レプリケーションがソースのトランザクションログ内の次のイベントを読み取ろうとして、前回ソースから読み取った際と比べ、新しいイベントがない場合にも 0 になる場合がある。このような状況になると、レプリケーションは CDCLatencySource を 0 にリセットする。  | 
| CDCLatencyTarget (CDCレイテンシーターゲット) | 秒 |  ターゲットのコミットを待機中の最初のイベント タイムスタンプと AWS DMS インスタンスの現在のタイムスタンプの間の間隔 (秒)。ターゲットのレイテンシーは、レプリケーションインスタンスのサーバー時間と、ターゲットコンポーネントに転送された最も古い未確定のイベント ID との差。つまり、ターゲットのレイテンシーは、レプリケーションインスタンスと、適用されても TRG エンドポイントがまだ確認していない最も古いイベントとの間のタイムスタンプの差 (99%)。CDCLatencyTarget が高い場合は、ターゲットに変更イベントを適用するプロセスが遅延していることを示します。進行中のレプリケーションのレイテンシーを特定するには、このメトリクスを CDCLatencySource とともに表示できます。CDCLatencyTarget が高くても CDCLatencySource が高くない場合は、次の場合に調査してください。 [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/dms/latest/userguide/CHAP_Serverless.Components.html)  | 
| CDCThroughputBandwidthTarget (CDCスループット帯域幅ターゲット) | KB/秒 |  ターゲットに送信される送信データ (KB/秒)。CDCThroughputBandwidth は、サンプリングポイントで送信された送信データを記録 ネットワークトラフィックが見つからない場合、値は 0 です。CDC は長時間実行トランザクションを発行しないため、ネットワークトラフィックは記録されない場合があります。  | 
| CDCThroughputRowsSource (CDCスループット行ソース) | 行数/秒 |  ソースから受信した 1 秒あたりの行数単位の変更数。  | 
| CDCThroughputRowsTarget (CDCスループット行ターゲット) | 行数/秒 |  ターゲットに送信された 1 秒あたりの行数単位の変更数。  | 
| FullLoadThroughputBandwidthTarget | KB/秒 |  ターゲットに送信される全ロードによるネットワーク帯域幅 (1 秒あたりの KB 数)。  | 
| FullLoadThroughputRowsTarget | 行数/秒 |  ターゲットに送信される全ロードによる変更 (1 秒あたりの行数)。  | 

### AWS DMS サーバーレスレプリケーションログ
<a name="CHAP_Serverless.monitoring.logs"></a>

Amazon CloudWatch を使用して、 AWS DMS 移行プロセス中にレプリケーション情報をログに記録できます。レプリケーション設定を選択して、ログ記録を有効にします。

サーバーレスレプリケーションは、CloudWatch アカウントにステータスログをアップロードして、レプリケーションの進行状況の可視性を向上し、トラブルシューティングをサポートします。

AWS DMS は、 というプレフィックスを持つ専用ロググループにサーバーレスにリンクされたログをアップロードします`dms-serverless-replication-<your replication config resource ID>`。このロググループ内には、`dms-serverless-replication-orchestrator-<your replication config resource ID>` というログストリームがあります。このログストリームは、レプリケーションのレプリケーションステータスと、この段階で行われている作業の詳細を示す関連メッセージをレポートします。ログのエントリ例については、以下の「[サーバーレスレプリケーションのログの例](#CHAP_Serverless.monitoring.logs.examples)」を参照してください。

**注記**  
AWS DMS は、レプリケーションを実行するまでロググループまたはストリームを作成しません。レプリケーションのみを作成する場合、 AWS DMS はロググループまたはストリームを作成しません。

実行済みのレプリケーションのログを表示するには、次のステップを実行します。

1.  AWS DMS コンソールを開き、ナビゲーションペインから**サーバーレスレプリケーション**を選択します。**[サーバーレスレプリケーション]** ダイアログが開きます。

1. **[設定]** セクションに移動し、[一般] 列の **[サーバーレスログを表示する]** を選択します。CloudWatch ロググループが開きます。

レプリケーションが失敗した場合、 はレプリケーション状態が のログエントリと`failed`、失敗の理由を説明するメッセージ AWS DMS を作成します。失敗したレプリケーションのトラブルシューティングを行う場合、最初のステップとして、CloudWatch ログを確認する必要があります。

**注記**  
Standard と同様に AWS DMS 、データ移行自体の進行状況、つまり基盤となるレプリケーションタスクによって出力されるログをより詳細にログ記録できるようにするオプションがあります。次の JSON の例のとおり、レプリケーション設定で `EnableLogging` の `Logging` フィールドを `true` に設定することで、このようなログ記録を有効にできます。  

```
{
  "Logging": {
    "EnableLogging": true
  }
}
```
有効にした場合、このログはサーバーレスレプリケーションのステータスが `running` である間、初めて表示されます。このログは、以前のログストリームと同じロググループに表示され、新しいログストリームである `dms-serverless-serv-res-id-{unique identifier}` の下に表示されます。サーバーレスレプリケーションログを解釈する方法については、次のセクションを参照してください。

#### サーバーレスレプリケーションのログの例
<a name="CHAP_Serverless.monitoring.logs.examples"></a>

このセクションには、サーバーレスレプリケーションのログエントリの例が記載されています。

##### 例: レプリケーションの起動
<a name="CHAP_Serverless.monitoring.logs.examples.start"></a>

サーバーレスレプリケーションを実行すると、 は次のようなログエントリ AWS DMS を作成します。

```
{'replication_state':'initializing', 'message': 'Initializing the replication workflow.'}
```

##### 例: レプリケーションの失敗
<a name="CHAP_Serverless.monitoring.logs.examples.fail"></a>

レプリケーションのエンドポイントのいずれかが正しく設定されていない場合、 は次のようなログエントリ AWS DMS を作成します。

```
{'replication_state':'failed', 'message': 'Test connection failed for endpoint X.', 'failure_message': 'X'}
```

失敗後のログにこのメッセージが表示されている場合は、特定されたエンドポイントが正常であり、適切に設定されているかを確認します。

## フルロード Oracle から Amazon Redshift および Amazon S3 への移行の拡張スループットの向上
<a name="CHAP_Serverless.Throughput"></a>

AWS DMS は、Oracle から Amazon Redshift および Amazon S3 へのフルロード移行のスループットパフォーマンスを大幅に向上させます。DMS は、テーブルマッピングでカスタム `parallel-load` オプションを使用せずに、テーブルに対して自動的にこの機能を有効にします。カスタマイズされた並列ロードオプションを持つテーブルの場合、DMS サーバーレスは、指定されたテーブルマッピング設定に基づいてテーブルロードを分散します。拡張スループットを使用するには、以下の作業を行います。
+ パーティションや境界を参照しない選択ルールを指定します。例えば、テーブルマッピングのテーブル設定に `parallel-load` が含まれている場合、DMS Serverless は拡張スループット機能を使用しません。詳細については、「[選択ルールと選択アクション](CHAP_Tasks.CustomizingTasks.TableMapping.SelectionTransformation.Selections.md)」を参照してください。
+ `MaxFileSize` と `WriteBufferSize` を 64 MB に設定します。詳細については、「[のターゲットとして Amazon Redshift を使用する場合のエンドポイント設定 AWS DMS](CHAP_Target.Redshift.md#CHAP_Target.Redshift.ConnectionAttrib)」を参照してください。
+ データが非常に少ないデータストアの場合は `CompressCsvFiles` を `true` に、高密度データのデータストアの場合は `false` に設定することをお勧めします。
+ 次のタスク設定を `0` に設定します。
  + `ParallelLoadThreads`
  + `ParallelLoadQueuesPerThread`
  + `ParallelApplyThreads`
  + `ParallelApplyQueuesPerThread`
  + `ParallelLoadBufferSize`
+ 並列データ移行をサポートするには、`MaxFullLoadSubTasks` を `49` に設定します。
+ `LOB mode` を `inline` に設定します。詳細については、「[AWS DMS タスクでのソースデータベースの LOB サポートの設定](CHAP_Tasks.LOBSupport.md)」を参照してください。

AWS DMS では、次のレプリケーションのスループットパフォーマンスは向上しません。
+ 並列ロードを使用したテーブルとのレプリケーション。詳細については、「[選択したテーブルおよびビューさらにコレクションで並列ロードを使用する](CHAP_Tasks.CustomizingTasks.TableMapping.SelectionTransformation.Tablesettings.md#CHAP_Tasks.CustomizingTasks.TableMapping.SelectionTransformation.Tablesettings.ParallelLoad)」を参照してください。
+ データ変換ルールを使用したレプリケーション。
+ フィルタールールを使用したレプリケーション。
+ 変換ルールを使用したレプリケーション。
+ Amazon Redshift Serverless をターゲットとするレプリケーション。

## AWS DMS サーバーレスでのストレージの自動スケーリングについて
<a name="CHAP.Serverless.storage.autoscaling"></a>

レプリケーションプロセスを開始すると、 AWS DMS Serverless はレプリケーションに 100GB の初期ストレージを割り当てます。ストレージは主に、ログファイルと、キャッシュされたトランザクションで消費されます。キャッシュされたトランザクションでは、ストレージは、キャッシュされたトランザクションをディスクに書き込む必要がある場合にのみ使用されます。したがって、 AWS DMS Serverless は大量のストレージを使用しません。例外には次のようなものがあります。
+ 膨大なトランザクションをロードする、サイズの大きなテーブル。サイズの大きなテーブルをロードするには時間がかかります。そのため、サイズの大きなテーブルをロードする間、キャッシュされたトランザクションが書き込まれる可能性が高くなります。
+ キャッシュされたトランザクションをロードする前に停止するよう設定されているタスク。この場合、すべてのテーブルのロードが完了するまで、すべてのトランザクションがキャッシュされます。この設定では、キャッシュされたトランザクションにより、かなりの量のストレージが消費されることがあります。
+ Amazon Redshift にロードされるテーブルを使用する設定になっているタスク。Amazon Aurora がターゲットの場合、この設定は問題になりません。

したがって、 AWS DMS Serverless は 15 分ごとにストレージ使用率をモニタリングします。割り当てられたストレージが 90% 利用されると、 AWS DMS Serverless は追加のストレージでレプリケーションをスケールアップします。レプリケーションの 100% ストレージが使用されており、呼び出しプロセス前または実行中にレプリケーションタスクが失敗した場合、DMS Serverless はスケーリングが正常に完了するとタスクを再開します。

**注記**  
  
以前に停止したタスクを再開すると、不完全なテーブルのフルロードオペレーションが最初から再開されます。
ストレージスケーリングイベント中の DMS タスクのパフォーマンスには影響しません。
2 つのストレージの自動スケーリングイベントの間に冷却期間はありません。