翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
# を使用した大規模なデータ移行の実行 AWS DataSync
大規模なデータ移行では、さまざまな形式の数百万のファイルやオブジェクトを含む大量のデータを転送できます。 AWS DataSync は、スケジューリング、モニタリング、暗号化、データ検証を管理することで、これらの複雑な転送を簡素化します。
## 大規模なデータ移行とは
大規模なデータ移行では、通常、さまざまな送信元に分散しているテラバイト以上のデータを、新しい送信先のストレージ環境 (この場合は AWS) に転送します。これらの移行では、ビジネスの中断を最小限に抑えながらデータを正常に移行するために、組織内で慎重な計画と調整を行う必要があります。
DataSync は、通常であれば複雑になるこうした移行を簡素化できます。移行に DataSync を使用する利点には、次のようなものがあります。
+ データ転送プロセスの管理と、高性能で安全なデータ転送に必要なインフラストラクチャの両方が自動化されます。
+ 暗号化や整合性検証を含むエンドツーエンドのセキュリティにより、データは安全かつ完全で、すぐに使用できる状態で届けられます。
+ 専用ネットワークプロトコルと並列のマルチスレッドアーキテクチャで移行が高速化されます。
## 大規模なデータ移行の主なステージ
通常、大規模な移行は次のステージに分割できます。
+ **(ステージ 1) データ移行の計画** - このステージでは、移行する理由と扱うデータの種類の把握に取り組みます。計画のアクティビティには以下が含まれます。
+ 移行する理由を把握する
+ 移行のあらゆる側面を支援するチームを編成する。
+ データの場所、形式、使用パターンを特定する
+ 利用可能なハードウェアリソースとネットワーク要件を評価する (オンプレミスデータセンターから移行する場合)
+ DataSync を使用して概念実証 (POC) テストを実行し、移行タイムラインの見積もりとカットオーバー期間の計画を立て、DataSync をどのように設定する必要があるかを確認する
+ **(ステージ 2) 大規模なデータ移行の実装** - ここでは計画を検証して移行を開始します。実装のアクティビティには以下が含まれます。
+ 移行計画を検証する
+ データ転送が想定どおりであるかのモニタリングと検証を含む段階的なカットオーバーを実行する
+ 各カットオーバー間で必要に応じて最適化および調整する
+ 完了後に未使用のリソースをクリーンアップする
## その他のリソース
AWS 規範ガイダンスには、大規模な移行の計画と実装に役立つ以下のリソースがあります。このガイドを使用して、DataSync が一般的な移行プロセスとアクティビティのコンテキストでどのように機能するかを理解してください。
+ [AWS クラウドへの大規模な移行](https://aws.amazon.com/prescriptive-guidance/large-migrations/?large-migration-strategies.sort-by=item.additionalFields.sortText&large-migration-strategies.sort-order=desc&large-migration-playbooks.sort-by=item.additionalFields.sortText&large-migration-playbooks.sort-order=desc&large-migration-patterns.sort-by=item.additionalFields.sortText&large-migration-patterns.sort-order=desc)
+ [AWS 大規模な移行の戦略とベストプラクティス](https://docs.aws.amazon.com/prescriptive-guidance/latest/strategy-large-scale-migrations/welcome.html)
+ [AWS 大規模な移行で共有ファイルシステムを移行する](https://docs.aws.amazon.com/prescriptive-guidance/latest/patterns/migrate-shared-file-systems-in-an-aws-large-migration.html) – このリソースには、ファイル共有レベルで移行を計画するためにダウンロードして使用できる **SFS-Discovery-Workbook** が含まれています。
# ステージ 1: 大規模なデータ移行の計画
大規模なデータセットを移行する際は計画が不可欠です。移行するデータ、移行の動機、必要な場所にデータ AWS DataSync を取得するのに役立つ方法を理解する必要があります。
**Topics**
+ [移行の要件の収集](gathering-migration-requirements.md)
+ [DataSync の概念実証の実行](datasync-large-migration-poc.md)
+ [移行タイムラインの見積もり](datasync-large-migration-timelines.md)
# 移行の要件の収集
大規模なデータ移行の最初のステップでは、組織全体でさまざまな情報を収集する必要があります。
この情報は、移行[プロセス](https://docs.aws.amazon.com/prescriptive-guidance/latest/strategy-large-scale-migrations/process.html)を作成するのに役立ちます。大規模な移行の場合、この移行プロセスには送信元から送信先のストレージへオペレーション ([ウェーブ](https://docs.aws.amazon.com/prescriptive-guidance/latest/application-portfolio-assessment-guide/wave-planning.html)で実行) をカットオーバーする複数の転送と手順を含めることができます。
## 移行する理由を把握する
への移行を開始する前に AWS、データを移行する理由を明確に理解する必要があります。これにより、期限の遵守、リソースの管理、チーム間の調整など、移行に関する一般的な課題に対処できます。
移行の動機を判断するためにサポートが必要な場合は、次の質問に答えてください。
+ オンプレミスのストレージスペースを解放しますか?
+ ハードウェアサポートの契約期限を迎えていますか?
+ これはデータセンターを廃止するためのものですか?
+ 移行のタイムラインはどのようなものですか？
+ 他のクラウドストレージからデータを転送しますか?
+ データセットの一部またはすべてを移行しますか?
+ これはデータアーカイブ用ですか?
+ アプリケーションまたはユーザーは、定期的にこのデータにアクセスする必要がありますか?
## ロジスティクスの把握
ストレージ環境、移行、組織に関する基本的なロジスティクスを扱います。
1. 現在のデータストレージインフラストラクチャの基本を理解します。
1. [DataSync エージェント](do-i-need-datasync-agent.md)が必要かどうかを確認します。例えば、オンプレミスストレージから転送する場合はエージェントが必要です。
1. エージェントが必要な場合は、[エージェントの要件](agent-requirements.md)を理解するようにしてください。
+ エージェントは、VMware ESXi、Linux カーネルベース仮想マシン (KVM)、Microsoft Hyper-V ハイパーバイザー上で仮想マシン (VM) として実行できます。また、エージェントを AWS内で Amazon EC2 インスタンスとしてデプロイすることもできます。
+ 大規模な移行は通常、メモリを大量に消費します。エージェントに十分な RAM があることを確認してください。
1. 移行に関与する必要があるリーダー、ネットワーク、ストレージ、IT 部門の主要なステークホルダーを特定します。これには次が含まれる場合があります。
+ プロジェクトとその結果に専念する[シングルスレッドのリーダー](https://docs.aws.amazon.com/prescriptive-guidance/latest/strategy-large-scale-migrations/people.html)を見つけます。
+ 移行するデータの所有権と分類の責任者を決定します。
+ ソースを管理するユーザーと、最終的に移行先の AWS ストレージサービスを管理するユーザーを特定します。
+ データの他のプロセスを作成および管理するユーザーを確認します AWS。
1. 部門間のコミュニケーションチャネルを確立します。
1. 不測の事態に備えてロールバックプランを作成します。
1. ウェーブ、検証、カットオーバーの手順など、移行プロセス全体を文書化します。これを移行全体のランブックとして使用します。移行を計画および実装する際に、このプロセスを更新します。
## 移行するデータの確認
ストレージチームやアプリケーションチームと協力して、移行するデータの特性を分析します。この情報は、DataSync で実行できる移行戦略を決定するのに役立ちます。
**Contents**
+ [データ使用パターンの決定](#review-migration-data-usage)
+ [データ構造とレイアウトの特定](#review-migration-data-structure)
+ [共有とフォルダのドキュメント化](#review-migration-data-document-shares)
+ [ファイルサイズの分析](#review-migration-data-file-sizes)
### データ使用パターンの決定
+ アクティブに使用されており、頻繁に変更されるデータについては、事業活動の中断を避けるために、複数のウェーブの増分転送を計画してください。
+ アーカイブと見なされる可能性のある読み取り専用データの場合、ウェーブを計画する必要はありません。
+ データ使用パターンが混在している場合は、これらの異なるデータセットを個別に移行するウェーブを計画します。例えば、1 つのウェーブをアーカイブデータ用に、残りのウェーブをアクティブなデータの移行専用にすることができます。
### データ構造とレイアウトの特定
+ データが期間 (年、月、日) またはその他のパターン別に整理されているかどうかを確認します。
+ この組織構造を使用して移行ウェーブを計画します。例えば、1 つのウェーブ中に 1 年分のアーカイブデータを移行できます。
### 共有とフォルダのドキュメント化
+ 共有とフォルダのインベントリを作成します (それぞれのファイルまたはオブジェクト数を含む)。
+ アクティブなデータセットを持つ共有とフォルダを特定します。これには、移行中に増分転送が必要になる場合があります。
+ [DataSync のクォータ](datasync-limits.md)を確認します。こうすることで、DataSync を設定するときにデータセットをどのようにパーティショニングするかを計画するのに役立ちます。
### ファイルサイズの分析
+ 小さいファイル (KB) と比べ、大きいファイル (MB または GB) の転送ではより高いデータスループットが求められます。
+ 多数の小さなファイルを扱う場合は、ストレージシステムでのメタデータの操作が増え、データスループットが低下することが予想されます。DataSync は、送信元と送信先の場所を比較および検証するときに、これらのオペレーションを実行します。
## ストレージ要件の特定
互換性のある AWS ストレージサービスを選択してデータを移行するには、ソースストレージシステムの特性とパフォーマンスを評価する必要があります。
この情報は、移行中の事業活動への影響を最小限に抑えるために[転送をスケジュールする](task-scheduling.md)のに役立ちます。
**Contents**
+ [送信元のストレージのサポートの確認](#determine-storage-requirements-protocols)
+ [メタデータ保持要件の確認](#determine-storage-requirements-metadata)
+ [送信元のストレージからのパフォーマンスメトリクスの収集](#determine-storage-requirements-performance)
+ [送信先 AWS ストレージサービスの選択](#determine-storage-requirements-destination)
### 送信元のストレージのサポートの確認
DataSync は、NFS、SMB、HDFS、S3 互換オブジェクトストレージクライアントを介したアクセスを許可するさまざまなストレージシステムと連携できます。
その他のクラウドストレージから移行する場合は、DataSync がそのプロバイダーと連携できることを確認します。サポートされている送信元の場所のリストについては、「[でデータを転送できる場所 AWS DataSync](working-with-locations.md)」を参照してください。
### メタデータ保持要件の確認
DataSync はデータ転送中にファイルまたはオブジェクトのメタデータを保持できます。メタデータがどのように保持されるかは、転送場所と、それらの場所で同様の種類のメタデータが使用されているかどうかによって異なります。
DataSync では、NTFS 任意アクセスリスト (DACL) などのファイルメタデータを保持するための追加のアクセス許可が必要になる場合があります。
詳細については、「[DataSync のファイルとオブジェクトのメタデータの処理方法を理解する](metadata-copied.md)」を参照してください。
### 送信元のストレージからのパフォーマンスメトリクスの収集
送信元のストレージの平均ワークロードとピークワークロード中のベースライン IOPS とディスクスループットを測定します。データを転送すると、送信元と送信先のストレージシステムの両方に I/O オーバーヘッドが追加されます。
このパフォーマンスデータをストレージシステムの仕様と比較して、使用可能なパフォーマンスリソースを決定します。
### 送信先 AWS ストレージサービスの選択
この時点で、 AWS ストレージサービスがデータにとってどのような意味を持つかがわかります。まだの場合、決定にあたって考慮すべきはデータの使用パターンとストレージパフォーマンスの 2 点です。例えば、アーカイブデータがある場合は Amazon S3 を、アクティブなデータの場合は Amazon FSx または Amazon EFS を検討します。
データに適したオブジェクトまたはファイルベースのストレージを決定する方法については、[「 AWS ストレージサービスの選択](https://docs.aws.amazon.com/decision-guides/latest/storage-on-aws-how-to-choose/choosing-aws-storage-service.html)」を参照してください。
## ネットワーク要件の特定
DataSync を使用してデータを移行するには、ソースストレージ、エージェント、および 間のネットワーク接続を確立する必要があります AWS。また、十分なネットワーク帯域幅とインフラストラクチャを計画する必要もあります。
ネットワークエンジニアやストレージ管理者と協力して、次のネットワーク要件を収集します。
**Contents**
+ [使用可能なネットワーク帯域幅の評価](#datasync-migration-network-bandwidth)
+ [ネットワークを に接続するためのオプションの検討 AWS](#datasync-migration-network-connection-options)
+ [エージェントの通信用のサービスエンドポイントの選択](#datasync-migration-network-service-endpoint)
+ [十分なネットワークインフラストラクチャの計画](#datasync-migration-network-interfaces)
### 使用可能なネットワーク帯域幅の評価
利用可能なネットワーク帯域幅は、転送速度と全体的な移行時間に影響します。オンプレミスのストレージシステムから転送する場合は、以下を行います。
+ ネットワークチームと協力して、帯域幅の平均使用率とピーク使用率を確認します。
+ データ転送が可能な時間帯を特定し、日常業務の中断を回避します。これにより、移行のウェーブとカットオーバーのタイミングを把握できます。
DataSync がどれだけの帯域幅を使用するかを制御できます。詳細については、「[AWS DataSync タスクの帯域幅制限の設定](configure-bandwidth.md)」を参照してください。
通常、他のクラウドストレージからの転送はパブリックインターネット経由で行われるため、これらの転送では帯域幅の制限や考慮事項が少なくなります。
### ネットワークを に接続するためのオプションの検討 AWS
DataSync の転送のためのネットワーク接続を確立するには、次のオプションを検討してください。
+ **Direct Connect** - DataSync で Direct Connect を使用するための[アーキテクチャとルーティングの例](direct-connect-architecture.md)を確認します。[Amazon CloudWatch](https://docs.aws.amazon.com/directconnect/latest/UserGuide/monitoring-cloudwatch.html) を使用して Direct Connect のアクティビティをモニタリングできます。
+ **VPN** - [AWS Site-to-Site VPN](https://docs.aws.amazon.com/vpn/latest/s2svpn/VPC_VPN.html) はトンネルあたり最大 1.25 Gbps のスループットを提供します。
+ **パブリックインターネット** - ネットワーク使用状況データについては、インターネットサービスプロバイダーにお問い合わせください。
### エージェントの通信用のサービスエンドポイントの選択
DataSync エージェントは DataSync サービスとの通信に[サービスエンドポイント](choose-service-endpoint.md)を使用します。使用するエンドポイントのタイプは、ネットワークを AWSに接続する方法によって異なります。
### 十分なネットワークインフラストラクチャの計画
作成する転送タスクごとに、DataSync はデータ転送用のネットワークインフラストラクチャを自動的に生成して管理します。このインフラストラクチャは、*ネットワークインターフェイス*または *Elastic Network Interface* と呼ばれ、仮想ネットワークカードを表す Amazon Virtual Private Cloud (VPC) の論理ネットワークコンポーネントです。詳細については、「[https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-eni.html](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-eni.html)」を参照してください。
各ネットワークインターフェイスは、送信先 VPC サブネットで 1 つの IP アドレスを使用します。移行に十分なネットワークインフラストラクチャがあることを確認するには、以下を実行します。
+ DataSync が DataSync 送信先の場所用に作成する[ネットワークインターフェイス](required-network-interfaces.md)の数をメモします。
+ DataSync タスクに対して十分な IP アドレスがサブネットにあることを確認します。例えば、エージェントを使用するタスクには 4 つの IP アドレスが必要です。移行用に 4 つのタスクを作成する場合、サブネットには 16 個の使用可能な IP アドレスが必要になります。
# DataSync の概念実証の実行
で概念実証 (POC) を実行する AWS DataSync と、データ移行計画の以下の側面を検証できます。
+ 送信元と送信先の場所間のネットワーク接続を確認します。
+ 最初の DataSync タスク設定を検証します。
+ データ転送パフォーマンスを測定します。
+ 移行タイムラインの見積もりを行います。
+ 移行に取り組む主要なステークホルダーと成功の基準を定義します。
## 概念実証の開始
1. 以下の手順で DataSync のエージェントを作成します。
1. [エージェントをデプロイします](deploy-agents.md)。
1. エージェント用の[サービスエンドポイント](choose-service-endpoint.md)を選択します。
1. [エージェントをアクティブ化します](activate-agent.md)。
1. [エージェントのネットワーク接続を検証します](test-agent-connections.md)。
1. 移行するデータを表すデータの小さなサブセットを選択します。
例えば、送信元のストレージに大きなファイルと小さなファイルが混在している場合、POC で転送するデータのサブセットにはそれを反映する必要があります。こうすることで、ストレージシステム、ネットワーク、DataSync のパフォーマンスを事前に把握できます。
1. [オンプレミス](transferring-on-premises-storage.md)または[他のクラウド](transferring-other-cloud-storage.md)ストレージシステムに DataSync の送信元の場所を作成します。
1. [AWS ストレージサービス](transferring-aws-storage.md) に DataSync の送信先の場所を作成します。
1. データサブセットのみを転送する[フィルター](filtering.md)を使用して[ DataSync の転送タスクを作成します](create-task-how-to.md)。
1. [DataSync のタスクを開始します](run-task.md)。
1. 以下をモニタリングして転送パフォーマンスメトリクスを収集します。
+ タスク実行のデータとファイルのスループット。これを行うには、DataSync コンソールまたは [DescribeTaskExecution](https://docs.aws.amazon.com/datasync/latest/userguide/API_DescribeTaskExecution.html) オペレーションを使用します。`DescribeTaskExecution` を使用する場合は、次の方法でこれらのメトリクスを計算します。
+ **データスループット**: `BytesWritten` を `TransferDuration` で割る
+ **ファイルスループット**: `FilesTransferred` を `TransferDuration` で割る
+ 送信元と送信先のストレージの使用率。ストレージ管理者と緊密に連携して、この情報を取得します。
+ ネットワークの使用状況。
1. 以下の手順を使用してデータ送信先の場所で転送されたデータを検証します。
+ CloudWatch ログでタスク実行エラーを確認します。
+ アクセス許可とメタデータが送信先の場所に保存されていることを確認します。
+ アプリケーションとユーザーが想定どおりに送信先データにアクセスできることを確認します。
+ 発生した問題に対処します。詳細については、「[AWS DataSync の問題のトラブルシューティング](troubleshooting-datasync.md)」を参照してください。
1. DataSync がデータの準備、転送、検証にかかる時間を把握するには、タスクをさらに数回実行します。(詳細については「[タスクの実行ステータス](run-task.md#understand-task-execution-statuses)」 を参照してください)。
タスクをさらに複数回実行すると、DataSync はデフォルトで増分転送を実行し、前回のタスク実行から変更されたデータのみをコピーします。
増分転送では転送時間が短くなる可能性がありますが、DataSync は場所をスキャンして比較し、転送対象を特定することで、常に同じ方法で転送を準備します。これらの準備時間を使用して、移行の[カットオーバータイムラインの見積もり](datasync-large-migration-timelines.md#datasync-large-migration-cutover-timelines)を行うことができます。
1. 必要に応じて、POC 中に確認できた内容に基づいて移行計画を更新します。
# 移行タイムラインの見積もり
これまでに収集した情報を使用して、 AWS DataSyncを使用した移行にかかる時間を見積もることができます。
## データ転送タイムラインの見積もり
移行要件の収集と DataSync の概念実証 (POC) で集めた以下の情報に基づいて、DataSync がデータを転送するのにかかる時間を見積もることができます。
+ [使用可能なネットワーク帯域幅](gathering-migration-requirements.md#datasync-migration-network-bandwidth)
+ 送信元と送信先のストレージの使用率のメトリクス
+ [DataSync POC](datasync-large-migration-poc.md) のパフォーマンスメトリクス
**データ転送タイムラインの見積もりを行うには**
1. POC のデータとファイルのスループットを、使用可能なネットワーク帯域幅と比較します。
1. スループットが使用可能な帯域幅より低い場合 (ネットワーク帯域幅が 10 Gbps でスループットが 300 MiB/秒など) は、帯域幅の使用率を最大化するためにデータセットを複数のタスクにパーティショニングすることを検討してください。
DataSync には、データセットをパーティションニングするためのいくつかのオプションがあります。詳細については、「[データのパーティショニングによる移行の高速化](datasync-large-migration-data-partitioning.md)」を参照してください。
1. 理論上の最小転送時間を提供する次の式を使用して、転送にかかる日数を計算します。
```
(DATA_SIZE * 8 bits per byte)/(CIRCUIT * NETWORK_UTILIZATION percentage * 3600 seconds per hour * AVAILABLE_HOURS) = Number of days
```
この式を使用する場合は、以下を独自の値に置き換えます。
+ `DATA_SIZE`: 移行するデータの量 (バイト単位)。
+ `CIRCUIT`: 使用可能なネットワーク帯域幅 (ビット/秒単位)。
+ `NETWORK_UTILIZATION`: 使用しているネットワークの割合。
+ `AVAILABLE_HOURS`: 1 日に使用可能な運用時間数。
例えば、100 TB のデータ、1 Gbps のインターネット接続、80% のネットワーク使用率、1 日あたり 24 時間の可用性を持つ移行では次のように計算します。
`(100,000,000,000,000 bytes * 8) / (1,000,000,000 bps * 0.80 * 3600 * 24) = 11.57 days`
この場合、実際の条件を考慮する前では、移行には約 12 日かかることになります。
1. 以下の実際の条件を考慮して、計算された転送期間を調整します。
+ ネットワークパフォーマンスの変動
+ ストレージパフォーマンスのバリエーション
+ 移行ウェーブ間のダウンタイム
## カットオーバータイムラインの見積もり
アクティブなデータセットを移行する場合は、事業活動を中断させないためにカットオーバーが必要になる可能性があります。
カットオーバーにかかる時間を過小評価しないでください。大規模な移行では、移行全体の最大 30% がカットオーバーアクティビティにかかることも珍しくありません。
1. 増分変更のためにスキャンされるデータ量を減らすために、ウェーブでカットオーバーを実行する必要があるかどうかを評価します。
これを行うための 1 つの戦略は、共有、フォルダ、またはストレージシステムに基づいてパーティショニングするデータセットをカットオーバーすることです。
1. POC 中に DataSync がデータの準備、転送、検証に通常どの程度の時間がかかったのかを確認します。
特に、タスク実行の準備期間に注意してください。この情報を確認するには、[DescribeTaskExecution](https://docs.aws.amazon.com/datasync/latest/userguide/API_DescribeTaskExecution.html) オペレーションを実行し、期間の [PrepareDuration](https://docs.aws.amazon.com/datasync/latest/userguide/API_TaskExecutionResultDetail.html#DataSync-Type-TaskExecutionResultDetail-PrepareDuration) の値を確認します (ミリ秒単位)。
1. 並列タスク間の時間差を測定することで、カットオーバーにかかる時間を見積もります。
並列タスクの詳細については、「[データのパーティショニングによる移行の高速化](datasync-large-migration-data-partitioning.md)」を参照してください。
1. カットオーバーの見積もりを使用してカットオーバーをスケジュールします。これらは基本的に、送信元のデータを変更できないメンテナンスウィンドウです。
## 次の手順
タイムラインの見積もりが完了したら、移行の実装を開始する準備が整います。
# ステージ 2: 大規模なデータ移行の実装
計画中に収集した情報を使用して、 AWS DataSync を使用して新しいストレージシステムへの移行を開始できます。まだ準備できていない場合は、[大規模な移行に関するAWS 規範的ガイダンスのリソース](datasync-large-migration.md#review-migration-data-resources)を確認することをお勧めします。
**Topics**
+ [データのパーティショニングによる移行の高速化](datasync-large-migration-data-partitioning.md)
+ [DataSync の転送タスクの実行](datasync-large-migration-running-tasks.md)
+ [転送のモニタリング](datasync-large-migration-monitoring.md)
# データのパーティショニングによる移行の高速化
大規模な移行では、データセットを複数の DataSync タスクでパーティショニングすることをお勧めします。送信元のデータを複数のタスク (場合によってはエージェント) にパーティショニングすることで、転送を並列化し、移行タイムラインを短縮できます。
パーティショニングは、DataSync [クォータ](datasync-limits.md)内にとどまり、タスクのモニタリングとデバッグを簡素化するのに役立ちます。
次の図は、複数の DataSync のタスクとエージェントを使用して、同じ送信元のストレージの場所からデータを転送する方法を示しています。このシナリオでは、各タスクは送信元の場所の特定のフォルダに焦点を当てます。これらのアプローチの詳細と例については、[AWS DataSync 「スケールアウトアーキテクチャを使用してデータ転送を高速化する方法](https://aws.amazon.com/blogs/storage/how-to-accelerate-your-data-transfers-with-aws-datasync-scale-out-architectures/)」を参照してください。
![\[送信元のデータをパーティショニングして大規模な移行を高速化するための DataSync の 1 つのアプローチを示す図。\]](http://docs.aws.amazon.com/ja_jp/datasync/latest/userguide/images/datasync-partition-by-folder.png)
## フォルダまたはプレフィックスによるデータセットのパーティショニング
DataSync の送信元の場所を作成するときに、DataSync が読み取るフォルダ、ディレクトリ、またはプレフィックスを指定できます。例えば、最上位ディレクトリとのファイル共有を移行する場合、異なるディレクトリパスを指定する複数の場所を作成できます。その後、これらの場所を使用して、移行中に複数の DataSync タスクを実行できます。
## フィルターを使用したデータセットのパーティショニング
[フィルター](filtering.md)を適用して、転送時に送信元の場所からデータを含めたり除外したりすることができます。大規模な移行のコンテキストでは、フィルターはデータセットの特定の部分にタスクをスコープするのに役立ちます。
例えば、年別に整理されたアーカイブデータを移行する場合、特定の年または複数年に一致する包含フィルターを作成できます。タスクを実行するたびに、別の年に合わせてフィルターを変更することもできます。
## マニフェストを使用したデータセットのパーティショニング
[マニフェスト](transferring-with-manifest.md)とは、DataSync で転送するファイルまたはオブジェクトのリストです。マニフェストを使用する場合、DataSync は転送対象を決定するために送信元の場所にあるすべてを読み取る必要はありません。
マニフェストは、ソースストレージのインベントリから、またはイベント駆動型アプローチを使用して作成できます (例えば、[「何億ものオブジェクト AWS DataSync の実装](https://aws.amazon.com/blogs/storage/implementing-aws-datasync-with-hundreds-of-millions-of-objects/)」を参照）。タスクを開始するたびに異なるマニフェストを使用することもできます。これにより、同じタスクで異なるデータセットを転送できます。
# DataSync の転送タスクの実行
移行の各ウェーブ中、データ転送は通常同じ一般的なプロセスに従います。
1. 初回の全データの転送を実行します。
1. 送信先のデータを検証します。
1. 最初の転送以降に変更された可能性のあるデータに対して増分転送を実行します。
1. オペレーションを送信先の場所にカットオーバーします。
1. カットオーバーの結果を確認します。
## タスクの実行
全体的な移行時間を最小限に抑えるには、営業時間内に DataSync の転送タスクを実行することが必要になる可能性があります。このような状況では、初回の完全転送を実行し、その後にユーザーやアプリケーションからの送信元の場所に対する変更を考慮した増分転送を実行するのが一般的です。
営業時間中にネットワーク関連の問題が発生しないようにするため、タスクで使用する帯域幅の量を制限できます。詳細については、「[AWS DataSync タスクの帯域幅制限の設定](configure-bandwidth.md)」を参照してください。
1. 以下の手順で初回の完全転送を実行します。
1. [DataSync のタスク](run-task.md) (タスクを並行して実行している場合は複数のタスク) を開始します。
1. タスク実行の進行状況とパフォーマンスをモニタリングします。
1. データが想定どおりに転送されたことを確認します (ファイルメタデータが保持されているかなど)。
1. 以下の手順で増分転送を実行します。
1. 定期的に実行するように[タスクをスケジュールします](task-scheduling.md)。
1. タスクの実行をモニタリングし、エラーが発生した場合はエラーを修正します。
## カットオーバーの実行
初回の転送と増分転送の後、送信先の場所へのオペレーションのカットオーバープロセスを開始できます。
1. スケジュールされたメンテナンスウィンドウを開始します。
1. 送信元のストレージシステムを更新して、アプリケーションとユーザーの読み取り専用にします。
1. 最後の増分転送を実行して、送信元と送信先の場所間の残りの差分をコピーします。
1. 徹底的なデータ検証を実施します (CloudWatch ログや[タスクレポート](task-reports.md)を確認するなど)。
1. アプリケーションとユーザーを送信先の場所の新しい環境に切り替えます。
1. アプリケーションの機能をテストし、ユーザーが送信先の場所のデータにアクセスできることを確認します。
1. 移行チームと転送について確認するための遡及分析会議をスケジュールします。以下のような深掘りするための質問を行います。
+ カットオーバーは成功しましたか? 成功しなかった場合は、どのような問題がありましたか?
+ 使用可能な帯域幅をすべて使用しましたか?
+ 送信元と送信先のストレージは完全に使用されましたか?
+ 追加のタスクでデータスループットを向上させることができますか?
+ より長いメンテナンスウィンドウを計画する必要がありますか?
1. 必要に応じて、次のウェーブが始まる前に移行計画を更新します。
# 転送のモニタリング
AWS DataSync には、転送の検証とデバッグに役立つモニタリングオプションがいくつか用意されています。
## CloudWatch メトリクスを使用した転送のモニタリング
DataSync のタスク実行のメトリクスを使用して、カスタム CloudWatch ダッシュボードを作成できます。詳細については、「[Amazon CloudWatch メトリクスを使用したデータ転送のモニタリング](monitor-datasync.md)」を参照してください。
## タスクレポートによる 転送のモニタリング
数百万のファイルまたはオブジェクトを転送する場合は、タスクレポートの使用を検討してください。タスクレポートには、タスクの実行中に DataSync が試行した転送、スキップ、検証、削除の詳細が記されています。詳細については、「[タスクレポートによるデータ転送のモニタリング](task-reports.md)」を参照してください。
、Amazon Athena AWS Glue、Amazon Quick などの AWS サービスを使用してタスクレポートを視覚化することもできます。詳細については、「[AWS Storage Blog](https://aws.amazon.com/blogs/storage/derive-insights-from-aws-datasync-task-reports-using-aws-glue-amazon-athena-and-amazon-quicksight/)」を参照してください。
## CloudWatch Logs を使用した転送のモニタリング
少なくとも、基本情報や転送エラーをログに記録するようにタスクを設定することをお勧めします。詳細については、[Amazon CloudWatch Logs によるデータ転送のモニタリング](configure-logging.md)を参照してください。