AWS DataSyncとAzure File Sync 比較 ～共通点と相違点～

本年最後の記事です。
前回はAWS WorkSpacesとAzure Virtual Desktopをエンタープライズユーザ目線で、事前準備、構築、MFA実装の3つの観点から比較し、全10編にわたる連載形式になりました。
今回もAWSとAzureのサービス比較記事、AWS DataSync(以下、DataSync)とAzure File Sync(以下、File Sync)を比較します。
今回はファイルサーバをクラウド上に構築することを想定し、AWS WorkSpacesとAzure Virtual Desktopの時と同様、Active Directory環境が導入済みの環境とします。

DataSyncとFile Syncって何なの？

結構マニアックなサービスなので簡単に説明します。
どちらも各々のクラウド基盤上のPaaSのストレージサービスにオンプレミスのデータをアップロードするサービスです。
100TiB以上の大容量のデータであればAWS SnowballやAzure Databoxなどのサービス利用が考えられまし、数TiB程度、もう少し具体的には10TiB未満の容量であればVPNや専用線、暗号化したデータであればインターネット経由でRobocopyでデータコピーを行うことも考えられます。
この10TiBから100TiB間のデータ移行がなかなか悩ましく、かつ日々データ差分が出てくるファイルサーバやDBのようなサービスだと移行と切り替えが一苦労です。
そこでDataSyncやFile Syncというサービスを使い、オンプレミスのデータをクラウド上のPaaSストレージに同期を行いながら日次の差分を全て吸収し、完全なデータ移行を行うという趣旨のサービスです。
DBだと話がややこしくなるので、今回はファイルサーバを移行対象とした場合の移行ツールとして、どちらのサービスが優れているかを比較します。

DataSyncとFile Syncの共通点と相違点

DataSyncとFile Syncは一見するとよく似たデータ移行、データ同期のサービスなのですが、共通点と相違点をまとめました。
この共通点と相違点からそれぞれのサービスのユースケースが見えてきます。

DataSyncとFile Syncの共通点

まずは共通点から。
オンプレミスのデータをAWSやAzure上のストレージサービスに同期、アップロードを行う＝クラウドサービスにデータをLiftする
はい。
読んで字の如く。
サービスの趣旨の説明と同じですね。

DataSyncとFile Syncの相違点

次に相違点ですが、ここはマトリックスでまとめます。

項目	DataSync	File Sync
同期方向	オンプレミス<->AWS 双方向	オンプレミス<->Azure 双方向だが、頻度がそれぞれの方向で一致していない
同期頻度	最短で1分に1回の同期(cron形式で記述、しかし仕様上5分に1回程度を最低限とした方が良い。GUIでは1時間に1回が最短同期頻度)	オンプレミスの変更はAzure上に即時同期、Azure上の変更は最大で24時間かかってオンプレミスに同期(24時間の同期タイミングはユーザでは調整不可)
同期形式	オンプレミス側でデータが削除されてもクラウド上のデータは削除しないオプションがある	オンプレミス側にあるデータを正とし、オンプレミス側で変更のあったデータはクラウド上のデータも同様に変更し、オンプレミス側で削除されたデータはクラウド上でも削除する
課金※	AWSへの1GiBアップロードあたり0.0125USD	課金が1台のエージェントあたり月7.25USD

※課金の金額はDataSyncは東京リージョン、File Syncは東日本リージョンでの2022年12月31日時点のものです。
※ここでいう課金はDataSyncやFile Syncにかかる課金であり、データの保存にかかるS3やAmazon EFS、Azure Filesの従量課金は含まれていません。
それぞれの相違点から考えられるDataSyncの開発者が利用を想定している環境と、File Syncの開発者が利用を想定していると詳しく見ていきましょう。

DataSyncの利用想定環境

これは私見ですので鵜呑みにしないようにしてください。
実際に検証してみた所感です。
DataSyncの開発者の意図を直接聞き取った訳ではございません。

恐らくですが、DataSyncでさっさとAWS上にデータを全部移行し、極力早くAWS上にファイルサーバを構築しましょうという開発者の意図を感じました。
上述のDataSyncとFile Syncの相違点の課金の項目を見てもらっても分かる通り、長期利用してもあまりメリットは無く、ただただ課金がかかり続けます。
DataSyncは1GiBのアップロードにあたり0.0125USD、File Syncのサーバは1台当たり1か月で7.25USDでアップロードに際してデータ容量による従量課金は無いので、DataSyncとFile Syncとで価格の逆転が起こるファイル容量が割り出すと、580GiBになります。
毎月580GiB未満のデータアップロードが発生するのであればDataSyncの方が安くなり、毎月580GiB以上のデータアップロードが発生する場合はFile Syncの方が安くなります。
これは1度のみの初回同期だけでなく、データの変更差分が月次でどれだけあるかに依存します。
冒頭の説明の通り、移行対象のデータの総容量が10TiBから100TiBなので、(10TiB＋100TiB)÷2として平均を取り、55TiBとした場合、この総容量55TiBのうち何%が日時差分として変更されているかによって課金が決まってきます。
DataSyncとFile Syncの価格の逆転が起こる580GiBは55TiBからみれば何%に相当するかというと
580÷(55×1,024)=0.00102982･･･
となりますので、約1%に相当します。
ここで日時の変更差分についてAWSのサービス、Amazon EFS内に面白い記述がありますのでこれを引用します。
https://aws.amazon.com/jp/efs/pricing/
こちらのサイトに記述内容ですが、

このように20%がアクセス頻度の高い(日々のデータ更新差分)として料金計算の例としていますので、この20%を引用すると、
55TiB×20%=11TiBとなります。
日々のデータ変更差分が11TiBとなります。
めちゃくちゃ多いですね。
さすがにちょっと引いちゃいますが、AWSさん曰く業界で受け入れられている推定値とのことなので、これで再度料金を計算すると
11TiB×1,024×0.0125USD=140.8USD
となります。
DataSyncでは140.8USDが毎月かかります。
対してAzureは毎月7.25USDなので、AWSの方が19.4倍ほど高い金額がかかってしまいます。
さすがにAWSさん、ナンボ何でもここまで差額あるサービスで完全に競合するなんてことはあり得ないと思うので、
「DataSyncはデータ移行の過渡期のみに利用するサービスではないか？」
という考えに至った次第です。

もうちょっとこの計算式を引用して別の観点から見てみましょう。
DataSyncとFile Syncの価格の逆転が起こる580GiBを20％の日々の変更差分とするデータの総容量はいくらか？
という観点です。
求めたいデータの総容量をx(エックス)として計算すると
x(エックス)×20%=580GiB
ですので、
x(エックス)=580GiB÷20%=2,900GiB=2.83203125TiB≒2.8TiB
となりました。
日々の変更差分が20%であれば移行対象のデータの総容量が2.8TiB未満だとDataSync、2.8TiB以上だとFile Syncがそれぞれ有利ということになりますが、冒頭のDataSyncとFile Syncって何なの？で説明した想定容量の下限、10TiBを大幅に下回ってしまいます。
これでは前提と矛盾するので、そもそもDataSyncは移行ツールとしても割高なんじゃない？という結論が出てしまいました。
この料金の点からもやはりDataSyncは使い続けるものではなく、さっさとAWS上にデータを全部移行し、極力早くAWS上にファイルサーバを構築しましょうというサービスではないか？と思い致りました。
ダラダラとDataSyncでのデータ移行に時間がかかっていつまでも割高な料金をAWSに支払い続けるより、さっさと移行してAWS上にすべてのデータを移行を促す意図が良く伝わってきますので、ある意味料金が高いということは良いアピールなのかもしれません。
結論、DataSyncでさっさとAWS上にデータを全部移行し、極力早くAWS上にファイルサーバを構築しましょう、と考えました。

File Syncの利用想定環境

こちらはDataSyncと違い、1台のエージェントをインストールしたサーバあたり7.25USDしかコストがかかりません。
Azureへいくらデータを送っても、送信に対する課金はかかりません。
毎月定額です。
そしてこのFile Syncの「よく考えられているな！」と感心するのが、以下の構成図です。

ファイルサーバにFile Syncのエージェントをインストールすると、Azure Filesに自動でデータを送信してくれます。
しかも、ユーザはファイルサーバにアクセスすると、ファイルサーバにあるデータはそのまま開き、Azure Files上にアップロードされているデータは自動でファイルサーバ上にダウンロードされ、ユーザは何の操作も行うことなくファイルを開くことができます。
具体的には上図の青枠点線部分のデータはクライアントから見るとオンプレミスのファイルサーバ上にあるように見えますが、実際はAzure Files上の赤枠実線部分のようにクラウド上にのみ存在しており、オンプレミスのファイルサーバ上には実ファイルのデータは存在しません。
ファイル構造のメタデータとしてファイルサーバ上にデータがあるようになっているので、クライアントからオンプレミスのファイルサーバ上にデータがあるように見えるという仕組みです。
これはめちゃくちゃ凄い機能です。
Azure凄いですね！
先ほど引用で利用したAmazon EFSのアクセス頻度の高い(であろう20%の)データをストレージクラスEFS標準やEFS1ゾーンに、アクセス頻度の低い(であろう80%の)ファイルをストレージクラスEFS標準-IAやEFS1ゾーン-IAに自動で保存する機能があるようなのですが、この機能と同等の処理をオンプレミス-Azure間で行ってくれます。
この機能を
ティアリング (Tiering)
と言います。
めちゃくちゃ便利な機能で、ユーザのアクセスするファイルサーバはもはやキャッシュサーバとなり、アクセス頻度の高い、というか実際にアクセスしたファイルを日付順に直近のものからキャッシュサーバに置き、それ以外のアクセスの無いデータを自動で判定してAzure Filesに送ってくれます。
とても便利で賢い機能です。
このことから、File SyncはDataSyncと違いオンプレミスとAzure間での利用を継続することを、具体的にはオンプレミスのキャッシュサーバとAzure間でデータ同期をし続けることを想定したサービスだと言えます。
DataSyncとFile Sync、利用想定環境が大きく違うのでこのまま比較することにどこまで意味があるのか私も疑問ですが、そこは乗り掛かった舟ということで、Amazon WorkSpacesとAzure Virtual Desktopの比較と同じように、構築方法や動作確認なども行い引き続き比較を行っていきます。

本年はここまで。