APC 技術ブログ

株式会社エーピーコミュニケーションズの技術ブログです。

株式会社 エーピーコミュニケーションズの技術ブログです。

DataSyncの転送パフォーマンスを検証する

目次

はじめに

こんにちは、株式会社エーピーコミュニケーションズ クラウド事業部の松尾です。
データ移行サービスのDataSync、これまで動作検証は何度か実施してきていますが、パフォーマンスの観点ではまだ未検証です。今回はDataSyncのパフォーマンス、具体的には大容量データの転送時、DataSyncの設定によってどのくらい速度が違うのか、を検証していきたいと思います!

ゴール

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

  • DataSyncでの大容量データ転送の設定
  • 設定の違いによる転送速度結果

前提

本検証はJP Contents HUBのAWS DataSync を利用した Amazon S3 への移行ハンズオン に沿った内容となっています。DataSyncとNFSサーバ、S3の構築は完了した状態から検証を始めていきます。

各種リソースは作成済の状態から開始

テスト転送

本番データの移行前に想定通りに転送が行われることを確認していきます。具体的には、本番データの一部データを2つのAgentを使ってS3へ転送出来ることを確認します。

移行先リージョンのDataSyncでタスクを作成していきます。

送信元ロケーション

送信先ロケーション

除外動作もテストするため2つ設定します。

タスク設定1/2

タスク設定2/2

作成したタスクステータスが利用可能になったら「デフォルトから開始する」で転送を開始します。

テスト転送結果の検証

タスクが完了後、S3のバケットで除外設定が効いているか確認してみます。 なんと、除外したはずのindex.htmlが転送されていました。

設定を間違えたと思い、タスク設定画面を見てみますがindex.htmlの末尾にスペースがあるようなないような。。?判断できないですね。

GUIでは判断できなかったのでCLIで取得した情報から判断してみます。 CloudShellで

aws datasync describe-task-execution --region <リージョン> --task-execution-arn <タスク実行ARN>

を実行すると、以下応答が返りました。

index.htmlの末尾に半角スペースが入っていたことが確認出来ました。これが原因ですね。。

では、スッキリしたところで本来の検証続きです。 コマンドで取得した結果から実行時間の内訳を確認することが出来ます。 準備段階、転送段階、検証段階の実績で、それぞれ、PrepareDuration、TransferDuration、VerifyDurationの値です。 単位はミリ秒なので、この結果からは 準備段階に1.8秒、転送段階に15.3秒、検証段階に0.5秒という情報が読み取れます。

フル転送

テスト転送が成功したので次はフル転送に移っていきます。 まずはNFSサーバのファイルシステムごとにAgent1とAgent2それぞれに転送タスクを振り分けていきます。図のようにFS1とFS2の転送はAgent1、FS3の転送はAgent2に設定したタスクを作成していきます。

タスクが3つ作成された状態です。それぞれのタスクで送信元のマウントパスが異なっていることが分かります。

タスク1(Copy FS1)、タスク2(Copy FS2)、タスク3(Copy FS3)の順に開始した直後のステータスです。 タスク1とタスク2は同じAgent1であるため、タスク2のステータスがキューに入った状態であることが分かります。タスク3はAgent2で独立しているのですぐに実行中に遷移しました。 全タスクが終了するまで待ちます。

ちなみに、進捗がほぼリアルタイムで可視化されるのは安心感がありますね。

上から順にタスク3、タスク2、タスク1となり、それぞれ20GBの転送に14分、10GBの転送に5分、10GBの転送に9分、といった結果でした。
タスク1とタスク2の合計時間とタスク3の合計時間は、それぞれ14分7秒、14分33秒と、ほぼ同じに収まっていることが分かります。1回だけの計測なので参考程度ですが。

差分転送

fs2のファイルを変更していきます。 1つの新しいファイル、1つの変更されたファイルが変更箇所です。

変更を加えた状態でタスクを実行、タスクの完了後、CloudShellからタスク詳細を確認してみます。 今度は準備段階(PrepareDuretion)に55秒かかっていることが分かります。初回は10秒なので約6倍の時間がかかっています。

fs2の2回目準備時間は55秒

fs2の初回準備時間は10秒

この時間を短縮していきたいと思います。

差分転送時間の短縮

方針は、タスク実行時に転送対象をfs2全体ではなく一部のディレクトリを指定することで、スキャン対象ファイル数を減らし、スキャンに係る時間を短縮することを狙っていきます。
まずは、再度fs2へファイル変更を加えます。

次に、タスク2の実行時に「オプションを上書きして開始」を選択し、特定のフォルダ(ここではファイルの変更があるフォルダ)を指定してタスクを開始していきます。

ファイルを変更したdir0001ディレクトリ配下を指定

タスク実行後、要した準備時間をみると、1.8秒と2回目の55秒と比べて約53秒短縮されていました。
2回目ではfs2全てがスキャン対象で約500,000ファイルに対して、3回目はfs2/d0001/dir0001/配下を指定したため約500ファイルが対象となったことによる違いです。この結果から、変更箇所が分かっている場合には時間短縮に有効であることが分かりました。

fs2の3回目準備時間は1.8秒

まとめ

ハンズオンをなぞる形でDataSyncの検証をしました。 転送元ファイルシステムごとにAgentを分ける(=タスクを分ける)のは、タスクごとに進捗やログの確認もしやすいので切り分けもしやすい構成になっていました。時間の短縮という観点ではAgentが複数でも単体でも同じ程度の時間になりましたが、1回の計測だったので参考程度の情報です。
差分転送では、CLIを使うことでGUIでは表示されない準備段階・転送段階・検証段階という情報を確認することが出来ました。今まではGUIのみで操作してきたので新しい発見でした。また、DataSyncのタスクオプションを指定することで変更内容に応じた適切な設定も理解しました。実案件では初回転送後に差分が発生することは多いので、状況に応じて適切な設定を使い分けていきたいと思います!

おわりに

私達クラウド事業部はAWSなどのクラウド技術を活用したSI/SESのご支援をしております。

www.ap-com.co.jp

また、一緒に働いていただける仲間も募集中です! ご興味持っていただけましたらぜひお声がけください。

www.ap-com.co.jp