Amazon Web Services ブログ

AWS DataSync を使った Amazon S3 へのデータ同期

このブログは2021年8月24日に David DeLuca (Senior Storage Solution Architect)によって執筆された内容を日本語化した物です。原文はこちらを参照して下さい。

オンプレミスからクラウドへデータを移行する際には、スピード、効率、ネットワーク帯域、コストなど、考慮すべき要素が数多くあります。多くの企業が直面する共通の課題は、大量のデータをオンプレミスから Amazon S3 バケットにコピーする際の適切なユーティリティの選択です。

私はよく、お客様が無料のデータ転送ユーティリティーや AWS Snow Family デバイスを使って、データをS3に取り込むことから始めるケースを目にします。また、同じお客様が AWS DataSync を使用して継続的な増分変更をキャプチャすることもあります。

1つのツールを使用してデータを S3 に最初にコピーし、DataSync を使用して増分更新を適用するというこの種のシナリオでは、考慮すべきいくつかの疑問があります。別のデータ転送ユーティリティで書き込まれたファイルを含む S3 バケットにデータをコピーする場合、DataSync はどのように動作するのか？ DataSync は既存のファイルがオンプレミスのファイルと一致することを認識するのか？データの2つ目のコピーが S3 に作成されるのか、データを再送信する必要があるのか？等の疑問です。

追加の時間、コスト、および帯域幅の消費を避けるためには、DataSync が「変更された」データをどのように識別するかを正確に理解することが重要です。DataSync はオブジェクトメタデータを使用して増分的な変更を識別します。データが DataSync 以外のユーティリティーを使用して転送された場合、このメタデータは存在しません。この場合、DataSync は増分変更をS3に適切に転送するために追加の操作を行う必要があります。最初の転送にどのストレージクラスを使用したかによっては、予想外のコストが発生する可能性があります。

この記事では、オンプレミスのデータを S3 バケットにコピーすることについて、以下の3つの異なるシナリオを検討し、それぞれ独自の結果を得ることができるようにしました：

  1. DataSync を使用して最初のコピーとすべての増分変更を実行。
  2. DataSync を使用して、DataSync 以外のユーティリティで書き込まれた次のようなストレージクラスのデータを同期する。S3 Standard、S3 Intelligent-Tiering （Frequent Access または Infrequent Access tier）、S3 Standard-IA、または S3 One Zone-IA。
  3. DataSync を使用して、DataSync 以外のユーティリティで書き込まれた次のようなストレージクラスのデータを同期する。S3 Glacier、S3 Glacier Deep Archive、または S3 Intelligent-Tiering （Archive Access または Deep Archive Access 層）

各シナリオの詳細な結果を確認した後は、予期せぬ料金が発生することなく、効率的に Amazon S3 にデータを移行・同期するための DataSync の使用方法を決定出来ます。

ソリューション概要

DataSync は、オンプレミスのストレージシステムと AWS ストレージサービスの間でのデータ移動に加え、AWS ストレージサービス間でのデータ移動を簡素化、自動化、高速化するオンラインデータ転送サービスです。DataSync は、アクティブなデータセットの AWS への移行、オンプレミスのストレージ容量を空けるためのデータのアーカイブ、事業継続のための AWS へのデータのレプリケーション、分析や処理のためのクラウドへのデータ転送などに利用できます。

ここでは、DataSync がオンプレミスから AWS のストレージサービスへのデータ転送にどのように使用できるかを確認してみましょう。DataSync エージェントは、オンプレミスのストレージシステムからデータを読み書きするために使用される仮想マシン （VM） です。エージェントは AWS クラウドの DataSync サービスと通信し、AWS ストレージサービスへのデータの実際の読み書きを行います。

DataSync タスクは、データが転送されるロケーションのペアで構成されます。タスクを作成する際には、転送元と転送先の両方のロケーションを定義します。DataSync の設定に関する詳細な情報は、ユーザーガイドをご覧ください。

次の図は、私のテスト環境のアーキテクチャを示しています。ソースロケーションは、オンプレミスの Linux サーバーでホストされているネットワークファイルシステム （NFS） 共有のセットです。ターゲットロケーションは、バージョニングが有効な S3 バケットです。3つの DataSync タスクが設定されており、各シナリオごとに1つずつ、以下のタスクオプションを使用しています。

  • Verify data: Verify only the data transferred. このオプションは、転送元で転送されたファイルとメタデータのチェックサムを計算します。そして、このチェックサムを、転送終了時に宛先でそれらのファイルに対して計算されたチェックサムと比較します。
  • Transfer mode: Transfer only data that has changed. このモードでは、コピー元とコピー先で異なるデータやメタデータのみをコピーします。
  • Task logging: Log level: Log all transferred objects and files. タスクがコピーして整合性をチェックしたすべてのファイルやオブジェクトのログレコードが CloudWatch Logs に公開されます。

Synchronizing your data to Amazon S3 using AWS DataSync

DataSync の内部構造を深く理解するために、私は3つのツールを利用しています:

  • Amazon CloudWatch Logsは DataSync タスクのステップバイステップの実行をレビューするのに役立ちます。
  • S3 server access logsは、S3 バケットへのリクエストを詳細に記録したものです。
  • S3 consoleでは、S3 にコピーされたオブジェクトが表示されます。

Amazon S3の簡単な説明

このブログでは、S3 バケットへのデータ転送に焦点を当てていますので、関連するトピックを確認してみましょう。Amazon S3 は、業界トップクラスのスケーラビリティ、データ可用性、セキュリティ、パフォーマンスを提供するオブジェクトストレージサービスです。

S3 ストレージクラス

S3 では、様々なアクセスパターンに対応したストレージクラスが用意されています。

    • S3 Standard ：頻繁にアクセスするデータの汎用ストレージとして使用されます。
    • S3 Intelligent-Tiering ：アクセスパターンが不明または変化するデータのためのストレージクラスです。このストレージクラスは、データへのアクセスに応じて、4つのアクセス階層 （Frequent Access, Infrequent Access, Archive Access, and Deep Archive Access） 間でデータを自動的に遷移させます。
    • S3 Standard-Infrequent Access と S3 One Zone-Infrequent Access ：保存期間は長いがアクセス頻度の低いデータを対象としたストレージクラスです。
    • S3 Glacier と S3 Glacier Deep Archive ：非同期アクセスによるデータの長期アーカイブとデジタル保存のためのストレージクラスです。

DataSync では、任意の S3 ストレージクラスに直接書き込むことができます。

S3 メタデータ

Amazon S3 にファイルデータをコピーする際、DataSync は自動的に各ファイルを1対1の関係で単一の S3 オブジェクトとしてコピーし、ソースファイルの POSIX メタデータを Amazon S3 オブジェクトのメタデータとして保存します。DataSync タスクが　“transfer only data that has changed”　に設定されている場合、DataSync はファイルのメタデータと対応するオブジェクトの S3 メタデータを比較して、ファイルを転送する必要があるかどうかを判断します。次の図は、DataSync が書き込んだ S3 オブジェクトのメタデータの例です。

An example of S3 object metadata that was written by DataSync

S3 API オペレーション

S3 は REST API 規格をサポートしています。これにより、S3 のバケットやオブジェクトにプログラムでアクセスすることができます。このブログでは、以下のアクションを中心にご紹介します:

    • HeadObject: オブジェクトからオブジェクト自体は取得せず、メタデータのみを取得します。
    • PutObject: バケットにオブジェクトを追加します。
    • CopyObject: Amazon S3 にすでに保存されているオブジェクトのコピーを作成します。

S3 バージョニング

Amazon S3 バージョニングは、あるオブジェクトの複数の世代を同じバケットに保持する手段です。S3 バージョニング機能を使用して、バケットに保存されているすべてのオブジェクトのすべてのバージョンを保存、取得、復元することができます。DataSync を使用して S3 バケットにデータを転送する際には、バージョニングの影響を慎重に考慮する必要があります。

    • DataSync をオンプレミスのストレージの継続的なバックアップに使用している場合、バージョン管理が望ましい場合があります。これにより、オブジェクトの現在のバージョンと以前のバージョンの両方を復元することができます。
    • DataSync を“移行ツール”として使用する場合は、バージョニングを無効にするとよいでしょう。以下のシナリオにあるように、既存のデータがあるバケットでは、S3 にデータのコピーが2つ保存されることになるシナリオがあります。

ウォークスルーシナリオ

シナリオ1： DataSync を使ってS3バケットへのデータの初期同期を行う。

このシナリオでは、オンプレミスの NFS 共有から空の S3 バケットにファイルを転送するデモを行います。このシナリオは、シナリオ2および3に関連した DataSync の動作を理解するためのベースラインを設定します。DataSync は最初の同期に使用されているため、S3 ストレージクラスは動作に影響しません。

  1. オンプレミスの NFS 共有には、2つのファイルが含まれています。”TestFile1″と “TestFile2″です。S3 バケットは空です。DataSync タスクを実行して、NFS ファイルをS3に転送します。このタスクが完了すると、以下のようになります。:
    • DataSync タスクの CloudWatch Logs では、2つのファイルが正常に転送され、データ整合性検証が完了している事を確認出来ます。:

CloudWatch Logs for the DataSync task confirm that the two files were successfully transferred and verified

S3 server access logs show that DataSync performed a “PUT” operation on two files

    • The S3 コンソール では、バケット内の2つのオブジェクトが表示されています:

Two objects in a bucket - synchronizing your data to Amazon S3 using AWS DataSync

  1. NFS 共有に2つのファイルを追加します（”TestFile3″と”TestFile4″）。2回目の DataSync タスクを実行します。タスクが完了すると、次のようになります。:
    • DataSync タスクの CloudWatch Logs では、2つの新しいファイルのみが転送され、データ整合性検証が完了している事を確認出来ます。:

CloudWatch Logs for the DataSync task show that only the two new files were transferred and verified

    • S3 サーバーのアクセスログを見ると、DataSync が以下の操作を行ったことがわかります。:
      • 既存のオブジェクトでは、オブジェクトのメタデータを読み取るために “HEAD” オペレーションが使用されました。メタデータはソースと同一であるため、DataSync は追加の操作を行う必要がありませんでした。
      • 2つの新しいファイルでは、”PUT” 操作が発生しました。

S3 server access logs show that DataSync performed the following operations on existing and new objects

    • S3 コンソールで、4つのオブジェクトが S3 バケットに転送されたことを確認します。それぞれのバージョンが1つだけであることに注意してください。:

The S3 console confirms that the four objects have been transferred to the S3 bucket. Note that there is only one version of each

  1. NFS 共有に新しいファイルを追加せず、3回目の DataSync タスクを実行します。タスクが完了すると、次のようになります。:
    • CloudWatch Logs では、ファイルが転送されていないことが確認できます。:

CloudWatch Logs show that no files were transferred (no new files were added)

    • S3 サーバーアクセスログを見ると、各オブジェクトに対して”HEAD”操作が発生しています。S3 のメタデータがソースと一致していたため、それ以上の操作は必要ありませんでした。

Since the S3 metadata matched the source, no further operations were required

シナリオ2： DataSync を使用して、ストレージクラスが Standard、S3 Intelligent-Tiering （Frequent または Infrequent Access tier）、S3 Standard-IA、または S3 One Zone-IA である既存の S3 データとデータを同期する。

最初のシナリオとは異なり、S3 バケットは空ではありません。S3 バケットには、オンプレミスのファイル共有にある2つのファイルと同じデータである2つのオブジェクトが含まれています。しかし、このファイルは DataSync 以外のユーティリティを使用して S3 にアップロードされたため、POSIX メタデータがありません。

  1. オンプレミスの NFS 共有には、2つのファイルが含まれています。”TestFile1″と “TestFile2″です。S3バケットには、同じデータのコピーが、ストレージクラス”Standard”で格納されています。

on-premises NFS share contains two files - 'TestFile1' and 'TestFile2' - The S3 bucket contains copies of the same data, in the Standard storage class

  1. NFS 共有に2つのファイルを追加します（”TestFile3″と”TestFile4″）。最初の DataSync タスクを実行します。完了すると、次のようになります。:
    • CloudWatch Logs によると、新しいファイルだけが転送されていますが、4つのファイルすべてについて、整合性検証が行われています。:

CloudWatch Logs indicate that only the new files were transferred, but all four were verified

    • S3 サーバーアクセスログに興味深いパターンが見られます。:
      • 既存の2つのファイルに対して、DataSync は以下の操作を行いました。:
        • オブジェクトのメタデータを読み取るための”HEAD”操作です。これらのオブジェクトは、DataSync 以外の方法でS3に転送されたため、POSIXメタデータがありません。
        • “REST.GET.OBJECT”オペレーションは、チェックサムを計算するためにオブジェクトを読み込み、このオブジェクトがソースファイルと一致するかどうかを検証します。
        • “REST.COPY.OBJECT”により、POSIXメタデータを含む新しいオブジェクトが作成されました。これは基本的にオブジェクトの”インプレースコピー”であり、データがワイヤ上で再送信されることはありませんでした。
      • 2つの新しいファイルに対しては”PUT”操作が行われました。

For the two new files, a 'PUT' operation occurred, with several operations performed on the two existing files

    • S3 コンソールで、以前に送信したファイルには2つのバージョンがあり、新しいファイルには1つのバージョンしかないことが確認出来ます。:

The S3 console shows that there are two versions of the previously transmitted files, and only one version of the new files

  1. NFS 共有に新しいファイルを追加せず、2回目の DataSync タスクを実行します。タスクが完了すると、次のようになります。:
    • CloudWatch Logs では、ファイルが転送されていないことが確認できます。:

CloudWatch Logs show that no files were transferred

    • S3 サーバーアクセスログを見ると、各オブジェクトに対して”HEAD”操作のみが発生しています。S3 のメタデータがソースと一致していたため、それ以上の操作は必要ありませんでした。

Only a 'HEAD' operation occurred on each object. Since the S3 metadata matched the source, no further operations were required

シナリオ3： DataSync を使用して、ストレージクラスが Amazon S3 Glacier、S3 Glacier Deep Archive、またはS3 Intelligent-Tiering （Archive または Deep Archive層） である既存の S3 データとデータを同期する。

これはシナリオ2と似ていますが、S3 バケットは空ではありません。S3 バケットには、オンプレミスのファイル共有にある2つのファイルと同じデータである2つのオブジェクトが含まれています。このファイルは DataSync 以外のユーティリティを使用して S3 にアップロードされたため、POSIX メタデータを持っていません。しかし、前のシナリオとは異なり、このオブジェクトは長期的なアーカイブを目的としたストレージクラスに存在します。

  1. オンプレミスの NFS 共有には、2つのファイルが含まれています。”TestFile1″と “TestFile2″です。S3 バケットには、Amazon S3 Glacier ストレージクラスに同じデータのコピーが含まれています。

on-premises NFS share contains two files- 'TestFile1' and 'TestFile2' - The S3 bucket contains copies of the same data, in the Amazon S3 Glacier

  1. NFS 共有に2つのファイルを追加します（”TestFile3″と”TestFile4″）。最初の DataSync タスクを実行します。タスクが完了すると、次のようになります。:
    • CloudWatch Logs によると、既存のファイルと新しいファイルの両方が転送され、整合性検証されています。:

CloudWatch Logs indicate that both the existing files and new files were transferred and verified

    • S3 サーバーアクセスログには、事前のテストとは異なるパターンが見られます。:
      • 既存の2つのファイルに対して、DataSync は以下の操作を行いました。:
        • オブジェクトのメタデータを読み取るための”HEAD”操作です。これらのオブジェクトは、DataSync 以外の方法で S3 に転送されたため、POSIX メタデータがありません。
        • オブジェクトは Archive ストレージクラスにあるため、DataSync はオブジェクトを読み込んでチェックサムを計算する”GET”オペレーションを実行できません。そのため、”PUT”オペレーションを使用して、ファイルの新しいコピーを作成する必要がありました。
      • 2つの新しいファイルに対しては”PUT”操作が行われました。

For the two new files, a 'PUT' operation occurred (2)

    • S3 コンソールで、以前に送信したファイルには2つのバージョンがあり、新しいファイルには1つのバージョンしかないことが確認出来ます。:

The S3 console shows that there are two versions of the previously transmitted files, and only one version of the new files (1)

  1. NFS 共有に新しいファイルを追加せず、2回目の DataSync タスクを実行します。タスクが完了すると、次のようになります。:
    • CloudWatch Logs では、ファイルが転送されていないことが確認できます。:

CloudWatch Logs show that no files were transferred (2)

    • S3 サーバーアクセスログを見ると、各オブジェクトに対して”HEAD”操作のみが行われています。S3 のメタデータがソースと一致していたため、それ以上の操作は必要ありませんでした。なお、オブジェクトがアーカイブストレージクラスに存在していても、S3 のメタデータは読み取ることが出来るのが重要な点です。

Only a “HEAD” operation occurred on each object. Since the S3 metadata matched the source, no further operations were required

まとめ

このブログでは、AWS DataSync が空の S3 バケットにデータをコピーする際に、既存のデータがある S3 バケットと比較して、どのように動作するかを深堀りしてみました。以下が得られた知見です。:

シナリオ1では、DataSync はオンプレミスから空の S3 バケットへの最初のコピーを実行しました。DataSync は、ファイルと必要なメタデータをワンステップで書き込むことができました。これは非常に効率的なプロセスであり、ネットワークの帯域幅を有効に活用し、時間を節約でき、全体的なコストを削減できる可能性があります。最も重要なのは、どの Amazon S3 ストレージクラスでも動作するという利点があることです。

シナリオ2は、S3 ストレージクラスが Standard、S3 Intelligent-Tiering (Frequent or Infrequent Access tier)、S3 Standard-IA、S3 One Zone-IA のいずれかである場合で、過去に転送した S3 データとのデータ同期を行いました。データを有線で再送信する必要はありませんでしたが、各 S3 オブジェクトの新しいコピーが作成されました。この方法でも、帯域幅の効率化は図れますが、GET と COPY の操作に追加の S3 リクエスト料金が発生します。

シナリオ3は、S3 ストレージクラスが Amazon S3 Glacier、S3 Glacier Deep Archive、S3 Intelligent-Tiering（Archive または Deep Archive 層）のいずれかである場合で、過去に転送した S3 データとの同期を行いました。この方法では、各ファイルを有線で再送信する必要がありました。これは、S3 リクエストの追加料金、帯域幅の使用量の増加、および時間の増加につながるため、最も効率の悪い方法です。

S3 のストレージクラスに関わらず、バケットで S3 のバージョニングが有効になっている場合、過去に転送された S3 データと同期すると、各オブジェクトの重複コピーが作成されます。この結果、シナリオ2と3の両方で示されているように、S3 ストレージの追加コストが発生します。

データの継続的な同期に DataSync を使用しているのであれば、S3 への最初の転送は可能な限り DataSync で行うことをお勧めします。ただし、DataSync 以外の手段で S3 にデータをコピーした場合は、ストレージクラスが Amazon S3 Glacier、S3 Glacier Deep Archive、S3 Intelligent-Tiering （Archive または Deep Archive tier） でないことを確認してください。また、そのバケットの S3 Versioning が現在有効になっている場合は、それを停止することをお勧めします。

AWS DataSync と Amazon S3 についてお読みいただきありがとうございます。