DataSyncAgentをHyper-V上で使ってみる（step2/2）

はじめに

こんにちは、株式会社エーピーコミュニケーションズクラウド事業部の松尾です。
今回はDataSyncAgentをHyper-V上で動かし、S3へデータ転送をしてみます。Hyper-Vは物理PC上で動作させます。
前回の記事でファイルサーバ用EC2とHyper-Vの構築まで完了しました。今回はこの続きとしてHyper-VでのS3への転送を検証していきます。

ゴール

本記事でお伝えすることは次の内容です。

Hyper-VのDataSyncAgent設定
DataSyncでのデータ転送設定

S3の作成

データ転送先となるS3を作成しておきます。

DataSyncAgentの設定

マネコンからDataSyncの設定を行っていきます。まずはロケーションで「送信元ロケーション」と「送信先ロケーション」を作成します。

「送信元ロケーション」として、作成したファイルサーバの情報を設定していきます。今回はWIndowsのファイルサーバ機能の為、プロトコルはSMBを選択、エージェントは作成したエージェントを選択、SMBサーバーにはファイルサーバのIPアドレスを入力します。このIPアドレスはエージェントから到達出来る必要があります。共有名には共有フォルダとしたパスを設定します。

ユーザーとパスワードは、エージェントが共有フォルダにアクセスする際に使うパラメータを設定します。ドメイン名があればオプションで入力しておきます。

続いて、「送信先ロケーション」も作成していきます。
バケットを選択し、IAMロールは新規作成したものを設定しました。

送信元と送信先のロケーションが作成された状態です。

続いて、「タスク」を設定していきます。

送信元なのでSMBとして設定したロケーションを選択。

送信先はS3として設定したロケーション。

送信元データオプションでは、一旦「特定のフォルダ」を選択し、フォルダ名に「/test/*」としておきます。本番データの転送前に一部のテストフォルダのみを対象にすることで想定通りの転送動作ができていることを確認することを想定しています。

転送オプションでは、転送対象のデータを全量か変更分か、データ整合性チェックの対象などを設定できます。今回はデフォルト値のままとしていきます。

スケジュールは、毎時0時とします。スケジュールなしにすることも可能です。

タスクレポートとロギングは今回は無しとします。

レビュー画面では内容を確認し問題なければ、タスクを作成します。ちなみに、ロケーションを除くパラメータは作成後でも編集可能に見えました。

タスクが作成されました。スケジュール設定した時間まで待ってみます。

DataSyncでのデータ転送

スケジュール設定した時刻なるとステータスが実行中に遷移しています。動いている様子。

その後失敗していました。メッセージを見るとAgentからSMBサーバへ到達出来ていないとのこと。原因はプライベートIPでSMBサーバを指定してしまったからだと思われます。今回はインターネット経由でSMBサーバへ到達させるのでグローバルIPにする必要がありました。グローバルIPに修正していきます。

ロケーションは編集出来ないので再作成する必要があります。

タスクもロケーションは編集できないため、再作成する必要があります。

「jmatsuo-fromsmb-to-s3-seconda」として、グローバルIPで再作成したロケーションを送信元をするタスクを再作成しました。

手動でデータ転送を開始してみます。

履歴を見ると成功しています。S3バケットも見てみましょう。

S3バケットでは想定したフォルダ（testフォルダ配下のみ）が転送された状態になっています。.aws-datasync-metadataは自動で付与される隠しファイルのようです。

docs.aws.amazon.com

転送対象フォルダを全てに変更しデータ転送されることをみていきます。

/testフォルダを除くファイル（aaa.txt,bbb.txt）が転送されています。

次にファイルの内容が更新された場合、更新内容がS3側に反映されることを確認していきます。

DataSyncを手動で開始し、実行完了後のS3上のbbb.txtファイルを見ていきます。

更新後の内容が反映されていました。想定通りの動作です。

まとめ

Hyper-VでのDataSync動作を検証してみました。EC2と比較しても特に違いはなく、転送動作にも違いはありませんでした。異なる点としては、EC2ではインスタンスタイプが決まっているので考慮不要ですが、Hyper-Vの場合は自前で必要要件を満たすマシンを用意する必要がある点があります。今回はCPU要件でエラーになっていたのですが、結果的にはデータ転送を行うことができました。ファイル数やフォルダ数が多くなる本番環境などでは要求スペックを満たしたマシンを用意することが必要かと思います。
また、今回検証した構成はDataSyncAgentとSMBサーバ間がインターネット経由の構成でしたが、”ネットワーク的に遠い”この構成はAWSとしては非推奨の構成です。送信元のSMBサーバに出来る限り近い場所にDataSyncAgentを配置することが推奨されている点には注意下さい。
検証してみて、送信元と送信先データの整合性チェックが透過的に行える点がDataSyncの一番のメリットだと思っています。自前で実装するとハッシュ値の管理などが必要ですがよしなに行ってくれる点はマネージドサービスの良い点です。他にもスケジュール設定機能や差分の同期機能も継続的なデータ転送を行いたい状況には大きなメリットとなるでしょう。