数百テラバイトのデータを Azure Cosmos DB に移行する

適用対象: ✅ NoSQL, ✅ MongoDB, ✅ Apache Cassandra, ✅ Apache Gremlin, ✅ Table

Azure Cosmos DB には、テラバイト単位のデータを格納できます。大規模なデータ移行を実行して、運用ワークロードを Azure Cosmos DB に移動することができます。この記事では、Azure Cosmos DB への大規模なデータの移行に伴う課題について説明し、それらの課題に対応して Azure Cosmos DB にデータを移行するツールについて説明します。このケーススタディでは、顧客は Azure Cosmos DB の NoSQL 用 API を使用しています。

ワークロード全体を Azure Cosmos DB に移行する前に、データのサブセットを移行して、パーティションキーの選択、クエリのパフォーマンス、データモデリングなどのいくつかの側面を検証することができます。概念実証を検証した後、ワークロード全体を Azure Cosmos DB に移動できます。

データ移行のためのツール

現在、Azure Cosmos DB の移行方法は、API の選択とデータのサイズによって異なります。データモデリング、クエリパフォーマンス、パーティションキーの選択などを検証するために、より小さなデータセットを移行するには、 Azure Data Factory の Azure Cosmos DB コネクタを使用できます。 Spark を使い慣れている場合は、Azure Cosmos DB Spark コネクタを使用してデータを移行することもできます。

大規模な移行での課題

Azure Cosmos DB にデータを移行するための既存のツールには、大規模な移行で特に明らかになる制限事項がいくつかあります。

スケールアウト機能に制限がある:数テラバイトのデータをできるだけ迅速に Azure Cosmos DB に移行し、プロビジョニング済みのスループット全体を効率的に使用するために、移行クライアントには無制限にスケールアウトできる機能が必要です。
進行状況の追跡とチェックポイント設定の機能がない:大規模なデータセットの移行中は、移行の進行状況を追跡し、チェックポイント処理を行うことが重要です。それ以外の場合、移行中に発生したエラーは移行を停止し、プロセスを最初から開始する必要があります。全移行プロセスの 99% が既に完了しているときに、それを再び開始するのは生産的ではありません。
配信不能キューがない:大規模なデータセット内では、ソースデータの一部に問題がある場合があります。また、クライアントまたはネットワークに一時的な問題がある可能性もあります。いずれの場合も、移行全体が失敗することはありません。ほとんどの移行ツールには、断続的な問題から保護する堅牢な再試行機能がありますが、必ずしも十分であるとは限りません。たとえば、ソースデータドキュメントの% が 0.01 未満の場合、サイズが 2 MB を超える場合、Azure Cosmos DB でドキュメントの書き込みが失敗します。移行ツールでは、移行後に処理可能な別のデッドレターキューに、これらの "失敗した" ドキュメントを保持すると理想的です。

これらの制限の多くは、Azure Data Factory、Azure データ移行サービスなどのツールでは修正されています。

Bulk Executor ライブラリを使用するカスタムツール

前のセクションで説明した課題は、複数のインスタンス間で簡単にスケールアウトでき、一時的な障害に対する回復性があるカスタムツールを使用して解決できます。さらに、このカスタムツールでは、さまざまなチェックポイントで移行を一時停止したり再開したりできます。 Azure Cosmos DB には、これらの機能の一部が組み込まれた Bulk Executor ライブラリが既に用意されています。たとえば、Bulk Executor ライブラリには、一時的なエラーを処理する機能が既にあり、単一ノード内でスレッドをスケールアウトして、ノードあたり約 500 K の RU を使用することができます。また、Bulk Executor ライブラリは、ソースデータセットを、チェックポイント処理として独立して操作されるマイクロバッチにパーティション分割します。

このカスタムツールでは、Bulk Executor ライブラリを使用して複数のクライアント間でのスケールアウトをサポートし、取り込みプロセス中のエラーを追跡します。このツールを使用するには、Azure Data Lake Storage (ADLS) でソースデータを個別のファイルにパーティション分割して、異なる移行ワーカーが各ファイルを取得して Azure Cosmos DB に取り込めるようにする必要があります。カスタムツールでは、個別のコレクションが使用されます。それには ADLS 内の個々のソースファイルの移行の進行状況に関するメタデータが格納されており、それらに関連したエラーが追跡されています。

次の図は、このカスタムツールを使用した移行プロセスについて説明しています。このツールは一連の仮想マシンで実行されており、各仮想マシンは Azure Cosmos DB の追跡コレクションに対してクエリを実行し、いずれかのソースデータパーティションでリースを取得します。この処理が完了すると、ソースデータパーティションはツールによって読み取られ、Bulk Executor ライブラリを使用して Azure Cosmos DB に取り込まれます。次に、追跡コレクションが更新されて、データインジェストの進行状況と発生したエラーが記録されます。データパーティションが処理された後、ツールは次に使用可能なソースパーティションを照会しようとします。すべてのデータが移行されるまで、次のソースパーティションの処理が続行されます。このツールのソースコードは、Azure Cosmos DB 一括インジェストリポジトリで入手できます。

移行ツールの設定

追跡コレクションには、次の例に示すようなドキュメントが含まれています。ソースデータ内のパーティションごとに、このようなドキュメントが 1 つあります。各ドキュメントには、ソースデータパーティションのメタデータ (その場所、移行の状態、エラー (ある場合) など) が含まれています。

{ 
  "owner": "25812@bulkimporttest07", 
  "jsonStoreEntityImportResponse": { 
    "numberOfDocumentsReceived": 446688, 
    "isError": false, 
    "totalRequestUnitsConsumed": 3950252.2800000003, 
    "errorInfo": [], 
    "totalTimeTakenInSeconds": 188, 
    "numberOfDocumentsImported": 446688 
  }, 
  "storeType": "AZURE_BLOB", 
  "name": "sourceDataPartition", 
  "location": "sourceDataPartitionLocation", 
  "id": "sourceDataPartitionId", 
  "isInProgress": false, 
  "operation": "unpartitioned-writes", 
  "createDate": { 
    "seconds": 1561667225, 
    "nanos": 146000000 
  }, 
  "completeDate": { 
    "seconds": 1561667515, 
    "nanos": 180000000 
  }, 
  "isComplete": true 
}

データ移行の前提条件

データ移行を開始する前に、考慮すべきいくつかの前提条件があります。

データサイズを推定する:

ソースデータのサイズは Azure Cosmos DB のデータサイズに正確にマップされていない可能性があります。 Azure Cosmos DB でのデータのサイズを確認するために、ソースからいくつかのサンプルドキュメントを挿入できます。サンプルドキュメントのサイズによって、Azure Cosmos DB 移行後の合計データサイズを推定できます。

たとえば、Azure Cosmos DB での移行後の各ドキュメントが約 1 KB で、ソースデータセットに約 600 億個のドキュメントがある場合は、Azure Cosmos DB の推定サイズが 60 TB に近くになることを意味します。

十分な RU を備えたコンテナーを事前に作成する:

Azure Cosmos DB はストレージを自動的にスケールアウトしますが、最小のコンテナーサイズから開始することはお勧めしません。コンテナーを小さくすると、スループットの可用性が低下します。これは、移行が完了するまでにかかる時間が長くなることを意味します。代わりに、最終的なデータサイズ (前の手順で推定) を使用してコンテナーを作成し、移行ワークロードがプロビジョニングされたスループットを完全に消費していることを確認すると便利です。

前の手順では、データサイズは約 60 TB と推定されていたため、データセット全体に対応するには、少なくとも 2.4 M RU のコンテナーが必要です。

移行速度を推定する:

移行ワークロードがプロビジョニング済みスループット全体を使用できると想定すると、プロビジョニング済みスループットで移行速度を推定できます。前の例を続けて、1 KB のドキュメントを Azure Cosmos DB API for NoSQL アカウントに書き込むには、5 つの RU が必要です。 240 万 RU で、1 秒間に 48 万ドキュメントを転送できます (480 MB/秒)。つまり、60 TB の完全な移行には 125,000 秒または約 34 時間かかります。

1 日以内に移行を完了したい場合は、プロビジョニング済みスループットを 500 万 RU に増やす必要があります。

インデックス作成をオフにする:

移行はできるだけ早く完了する必要があるため、取り込まれた各ドキュメントのインデックスの作成に費やされる時間と RU を最小限に抑えるのが推奨されます。 Azure Cosmos DB では、すべてのプロパティのインデックスが自動的に作成されます。選択したいくつかの用語へのインデックス作成を最小限に抑えるか、移行の過程で完全にオフにすることが価値があります。次に示すように indexingMode を none に変更することで、コンテナーのインデックス作成ポリシーをオフにすることができます。

  { 
        "indexingMode": "none" 
  }

移行が完了したら、インデックス作成を更新できます。

移行プロセス

前提条件が完了したら、次の手順でデータを移行できます。

まず、ソースから Azure Blob Storage にデータをインポートします。移行の速度を上げるには、個別のソースパーティション間で並列化すると便利です。移行を開始する前に、ソースデータセットを約 200 MB のサイズのファイルにパーティション分割する必要があります。
Bulk Executor ライブラリは、1 つのクライアント VM で 500,000 RU を使用するようにスケールアップできます。使用可能なスループットは 500 万 RU なので、Azure Cosmos DB データベースがあるのと同じリージョンに、10 台の Ubuntu 16.04 VM (Standard_D32_v3) をプロビジョニングする必要があります。移行ツールとその設定ファイルを使用してこれらの VM を準備する必要があります。
いずれかのクライアント仮想マシンでキュー手順を実行します。この手順では、ADLS コンテナーをスキャンし、ソースデータセットのパーティションファイルごとに進行状況追跡ドキュメントを作成する追跡コレクションを作成します。
次に、すべてのクライアント VM でインポート手順を実行します。各クライアントは、ソースパーティションの所有権を取得し、そのデータを Azure Cosmos DB に取り込むことができます。完了し、その状態が追跡コレクションで更新されると、クライアントは追跡コレクション内の次に使用可能なソースパーティションを照会できます。
このプロセスは、ソースパーティションのセット全体が取り込まれるまで続行されます。すべてのソースパーティションが処理されたら、同じ追跡コレクションに対してエラー修正モードでツールを再実行する必要があります。この手順は、エラーが原因で再処理する必要があるソースパーティションを識別するために必要です。
これらのエラーのいくつかは、ソースデータのドキュメントが正しくないことが原因の可能性があります。これらは、特定して修正する必要があります。次に、失敗したパーティションに対してインポート手順を再実行して、それらを再度取り込む必要があります。

移行が完了したら、Azure Cosmos DB のドキュメント数がソースデータベースのドキュメント数と同じであることを確認できます。この例では Azure Cosmos DB の合計サイズは 65 テラバイトになりました。移行後、インデックス作成を選択的に有効にし、RU をワークロードの操作に必要なレベルまで下げることが可能です。

次のステップ

.NET と Java で Bulk Executor ライブラリを使用するサンプルアプリケーションを試して、さらに詳しく学習します。
バルクエグゼキューターライブラリは Azure Cosmos DB Spark コネクタに統合されています。詳細については、Azure Cosmos DB Spark コネクタに関する記事を参照してください。
大規模な移行の詳細については、"一般的なアドバイザリ" の問題の種類と "大規模 (TB+) の移行" の問題サブタイプでサポートチケットを開いて、Azure Cosmos DB 製品チームにお問い合わせください。
Azure Cosmos DB への移行のための容量計画を実行しようとしていますか? 容量計画のために、既存のデータベースクラスターに関する情報を使用できます。
- 既存のデータベースクラスター内の仮想コアとサーバーの数のみがわかっている場合は、仮想コアまたは vCPU を使用した要求ユニットの見積もりに関するページを参照してください
- 現在のデータベースワークロードに対する通常の要求レートがわかっている場合は、Azure Cosmos DB Capacity Planner を使用した要求ユニットの見積もりに関するページを参照してください

フィードバック

このページはお役に立ちましたか?

Last updated on 2024-08-15