Amazon Web Services ブログ

AWS DMSを用いたパーティション化されたデータのAmazon S3への並列ロード時間の改善

この記事は、Perform parallel load for partitioned data into Amazon S3 using AWS DMS を翻訳したものです。

AWS Database Migration Service (AWS DMS) を使用すると、SQL、NoSQL、テキストベースのターゲット間でデータを移行できます。Amazon Simple Storage Service (Amazon S3)を使用すると、データレイク、クラウドネイティブアプリケーション、モバイルアプリなど、さまざまなユースケースで、あらゆる量のデータを保存、保護することができます。この投稿では、AWS DMS v3.4.6 以降で利用可能なパーティション化されたソースの並列ロードを使用し、Amazon Relational Database Service (Amazon RDS) for MySQLからAmazon S3にデータを移行する際のロード時間を改善する方法を示します。パーティション化されたデータの並列ロードと同じ仕組みが、他のリレーショナルデータベースソースエンジンにも適用できます。

パーティション化されたテーブル

テーブルのパーティション化とは、データベースのテーブルを複数のファイルシステム上に分散させる仕組みです。テーブルのパーティション化は、データベース・エンジンによってさまざまなバリエーションがあるため、この記事では深く掘り下げませんが、テーブルのパーティション化の利点を知っておくことをお勧めします。

パーティションは、テーブル内のデータに対して条件を定義し、データをどのパーティションに所属させるかを決定することができます。たとえば、eコマースの注文テーブルを例に考えてみましょう。注文日の月と年でパーティションを設定すると、2022年1月に購入されたすべての注文はあるパーティションに存在し、2022年2月の注文はすべて別のパーティションに格納されることになります。2022年2月の注文データを(適切な述語を使用して) クエリする場合、範囲外のパーティションからのデータを除外できるため、より最適化されたクエリになる可能性があります。同様に、2022年1月のデータが不要になり、アーカイブされている場合、データを削除するより、パーティションを削除する方が、はるかに簡単で処理時間も短い操作であり、他のパーティションに格納されている他の月のデータに影響を及ぼすことはありません。

パーティション化されたデータの並列ロード

AWS DMSでは、Amazon S3をターゲットとして、サポートされるデータベースエンジンをソースとして使用する場合、移行タスク内でパーティション化されたデータの並列フルロードを設定することができます。フルロード中、データは並列スレッドを使用してターゲットに移行され、ソースデータベースオブジェクトのパーティションにマッピングされたサブフォルダーに格納されます。並列ロードのルールは3つのタイプがあります。ソースオブジェクトにパーティションが定義されている場合、partitions-auto と partitions-list を使用して、ソースのメタデータからロードするパーティションを自動的に特定することができます。パーティションがないオブジェクトで、データを範囲または境界で定義できる場合(たとえば、日付/時間の値を使用)、partitions-range を使用してロードするセグメントを指定できます。partitions-rangeの使用に関する詳細については、AWS Database Migration Service が並列フルロードと新しいLOB移行メカニズムのサポートによって移行速度を向上を参照してください。

パーティション化されたデータの並列ロード パフォーマンステスト

さまざまなテーブルを、適切なパーティションタイプと値でパーティション分割をすることができますが、通常、大量のデータを含む大きなテーブルが最も効果的です。この記事では、MySQL Employeesサンプルデータベースをソースとして使用し、salaries テーブルにRANGEパーティショニングを使用します。MySQL 5.7パーティショニングタイプの詳細については、パーティショニングタイプを参照してください。

salaries テーブルにデータが追加され、総行数は3億6400万行強、テーブルサイズは25GB強となりました。このデータベースは、Amazon RDSのt3.largeインスタンスで実行しています。データ移行を行うために、AWS DMS を使用して、t3.mediumレプリケーションインスタンスがプロビジョニングします。ソースの MySQL データベースに接続するためのソースエンドポイントを作成し、Amazon S3 のターゲットバケットに接続するためのターゲットエンドポイントが作成します。AWS DMS レプリケーションインスタンスの設定とレプリケーションタスクの詳細については、『AWS DMS ユーザーガイド』を参照してください。

この演習では、AWS DMSのフルロードタスクを4回に分けて実行します。最初の2つのタスクは、比較的パワーのないハードウェアで実行されます。1つ目はベースラインを確立するために並列ロードなしで実行し、2つ目はパフォーマンスを比較するために、並列ロードを有効にして実行します。次の2つのタスクは、設定自体と使用するハードウェアの両方の影響を調査するために、最初は並列ロードなしで実行し、次に並列ロードありで、比較的パワーのあるハードウェアで実行します。

最初の例では、データベース移行タスクを使用して、並列ロードを利用せずに、ソースの salaries テーブルからターゲットのS3バケットにデータをロードしています。このタスクは、「フルロード時のコミット率」をデフォルトの1万行から5万行に変更した以外は、すべてデフォルトの設定で構成されています。

以下の画像は、AWSコンソールによるフルロードチューニングの設定です。

次の画像は、並列ロードなしのDMSタスクの出力を示しており、19分7秒で完了しています。

次に、同じリソースを使用してこのプロセスを繰り返しますが、データベース移行タスクは、パーティション化されたデータに対して、並列ロードを利用するように変更しています。以下のJSONは、ソース上のデータを指定するAWS DMS タスクマッピングのタスク構成を記述しています。

{
    "rules": [
        {
            "rule-type": "selection",
            "rule-id": "373834480",
            "rule-name": "373834480",
            "object-locator": {
                "schema-name": "employees_partitioned",
                "table-name": "salaries"
            },
            "rule-action": "include",
            "filters": []
        },
        {
            "rule-type": "table-settings",
            "rule-id": "2",
            "rule-name": "2",
            "object-locator": {
                "schema-name": "employees_partitioned",
                "table-name": "salaries"
            },
            "parallel-load": {
                "type": "partitions-auto"
            }
        }
    ]
}

次の画像は、並列ロードありのDMSタスクの出力を示しており、17分29秒で終了しています。

並列ロードを有効にした場合、タスクの実行時間は8.5%短縮されました。次のスクリーンショットは、AWS DMS レプリケーションインスタンスの平均CPU使用率とネットワーク受信スループットの増加と、RDS DBインスタンスの平均CPU使用率も増加したことを示すAmazon CloudWatch メトリクスです。

次のCloudWatch メトリクスは、AWS DMS インスタンスのCPU 使用率を示しています。

次のCloudWatchメトリクスは、AWS DMS インスタンスのネットワーク受信スループットを示しています。

次のCloudWatchメトリクスは、RDS DBインスタンスのCPU使用率を示しています。

選択したハードウェアの影響、および並列ロードを使用する際の考慮事項を理解するために、より強力なインスタンスを使用して同じテストを繰り返します。RDS DBインスタンスはr5.8xlarge、AWS DMSレプリケーションインスタンスはc5.12xlargeに変更しました。

新しいハードウェアで最初の例を繰り返し実行したところ、並列ロードなしで、タスクは6分37秒で完了しました。ハードウェアの能力が向上したことで、最初のテストに対するロード時間が約65%短縮されています。

次の画像は、並列ロードなしのDMSタスクの出力を示しています。

最後に、2番目の例を繰り返して、並列ロード機能を利用します。このタスクは3分36秒で完了し、同等のハードウェアで実行した前回のタスクと比較して、ロード時間が約45%短縮されました。

次の画像は、並列ロードありのDMSタスクの出力を示しています。

次のCloudWatchメトリクスは、並列ロードを有効にした場合、AWS DMS レプリケーションインスタンスのネットワーク送信スループットとCPU使用率が向上し、ソースRDS DBインスタンスへの接続数も増加していることが確認できます。

以下のCloudWatchメトリクスは、AWS DMS インスタンスでのネットワーク送信スループットを示しています。

以下のCloudWatchメトリクスは、AWS DMS インスタンスのCPU使用率を示しています。

次のCloudWatchメトリクスは、RDS DB インスタンス上のデータベース接続を示します。

以下の表は、結果をまとめたものです。

AWS DMS Instance Amazon RDS Instance Parallel Load? Runtime
t3.medium t3.large No 19 mins 7 secs
t3.medium t3.large Yes 17 mins 29 secs
c5.12xlarge r5.8xlarge No 6 mins 37 secs
c5.12xlarge r5.8xlarge Yes 3 mins 36 secs

結論

この投稿では、AWS DMS バージョン 3.4.6 でパーティション化されたデータに対して並列ロードを使用して、Amazon S3 へのデータ移行時間を改善する方法を示しました。また、選択したハードウェアがパフォーマンスにどのような影響を与えるか、比較的強力なハードウェアでより多くの改善を実現することを確認しました。本番環境へ移行する際には、設定や機能を変更したり有効にしたりする前に、別の環境で十分なテストや概念実証の評価を行うことをお勧めします。

パーティション化されたデータに対する並列ロードの使用についての詳細は、ドキュメントを参照してください。

免責事項:この投稿で行われたテストは実際のパフォーマンステストではないため、お客様自身のワークロードは異なる可能性があります。

翻訳はソリューションアーキテクトの関藤 寛喜が担当しました。原文はこちらです。