伊藤忠テクノソリューションズ株式会社 (以下、CTC) の宮本です。

　従来は「クラウドにデータを置くこと」に懸念を持っていたお客さまも多かったわけですが、多くの導入実績や第三者機関のレポート等の公開により、これらの懸念はかなり払拭され、その次の段階として、具体的に「どのように安全にクラウドにデータを持っていくのか」を考える必要性が出てきました。本記事では、物理アプライアンスを使ったデータ移行サービスのAWS Snowball/Snowball Edgeの検証結果をレポートさせていただきます。

■ 目次
1．AWSへのデータ移行の方法
2．本検証の内容
3．Snowball/Snowball Edge利用手順の確認
4. 書き込み速度等性能（時間）の確認
5. メタ情報の移行の確認

1．AWSへのデータ移行の方法

　移行方法には様々な方法が考えられますが、いくつか代表的なパターンを記載します。

1-1. インターネット経由でのデータ移行

　この方法が一番シンプルですが、データ量が多い場合、アップロードに非常に時間が掛かることが考えられます。また、インターネット経由なので、通信の暗号化等の必要最低限のセキュリティの考慮は行うかと思いますが、そもそも社内のセキュリティポリシー等によりこのパターンは実施不可であるケースも多いのではないでしょうか。

1-2. 専用線 (Direct Connect) 経由でのデータ移行

　インターネットにデータを流したくない（流せない）場合、こちらの対応が考えられます。ただし、S3に対してアップロードを行いたい場合は、VPC Endpointを構成した上で、VPC内のEC2経由で通信するようにサーバを構成したりする必要があります。また、専用線がデータ移行専用のものでない場合は、他のサービストラフィックに影響を与えないように考慮する必要がありますが、Direct Connect側には帯域を制限する仕組みがないため、必要に応じて経路上のネットワーク機器やデータ移行のツール側等で考慮することになります。

1-3. 専用線 (CTC Cloud Connect) 経由でのデータ移行

　CTC Coud Connect はAWS、Microsoft Azure、Oracle Cloud、GCP等のパブリッククラウドとオンプレミスを、最短5営業日という速さで閉域接続します。CTC Cloud Connect の詳細は下記よりご覧いただけます。

1-4. AWS Snowball / Snowball Edge を利用したデータ移行

　専用の物理アプライアンスを用いた方式です。数10TB以上のデータを移行したい場合に適しています。Snowball/Snowball Edgeを取り寄せ、データを格納してAWSに送り返すと、AWS側で利用者のAWS環境にデータ移行してくれます。

　上記、１．２．のパターンとの違いとして理解しておきたいのが、「移行後にどこにデータが保存されるか」ということです。インターネットや専用線経由の場合は、S3にもEC2にも場合によってはRDSにも直接データを格納してしまえばよいですが、AWS Snowball/Snowball Edgeでは移行したデータは「S3」に格納されるため、その後必要に応じて利用者はS3からデータを取り出し適切な場所に移動させる必要があります。今回はこのパターンの検証となります。

2．本検証の内容

　今回の検証では以下の内容を確認しました。

• Snowball/Snowball Edge利用手順の確認
• 書き込み速度等性能（時間）の確認
• メタ情報の移行の確認

　一般的にデータ移行時に気になるポイントとして「性能（速度）」と「メタ情報（タイムスタンプやパーミッション）の移行」がどうなのか、という点があるかと思います。経験則として、ネットワーク経由でデータを移行する場合において、ハードウェアの性能よりもネットワーク環境やデータ種別・データ転送の方法に性能が左右されることが多く、今回は、方式ごとに典型的なスモールランダムファイルの転送と、一般的なサイズのファイルの転送においてどのような差異があるのかを確認しました。

　また、S3は「オブジェクトストレージ」であり、UNIXのパーミッションやWindowsの所有権情報でアクセス制御はされませんが、データ移行時の要件としてこれらを移行しなければならないケースもあるため、Snowball/Snowball Edge利用時にどこまでの考慮が可能なのかを確認しました。

3．Snowball/Snowball Edge利用手順の確認

　まず、始めにAWSマネジメントコンソール側で「ジョブ」を作成した数日後、写真の通り、納品書と配送伝票だけが貼られた状態で機器が指定の場所に届きました。1台あたり20Kgくらいで持ち手がついているのでひとりでも運べます。SnowballとSnowball Edgeのジョブを同日に作成したら、同時に2台届きました。

図 1. AWSから届いた機器

　作業は、基本的にはAWSより公開されているユーザガイド/開発者ガイドをもとに実施していきました。

• AWS Snowball ユーザガイド（https://docs.aws.amazon.com/ja_jp/snowball/latest/ug/whatissnowball.html）
• AWS SnowballEdge 開発者ガイド（https://docs.aws.amazon.com/ja_jp/snowball/latest/developer-guide/whatisedge.html）

　詳細な手順自体は、当該ドキュメントを参照するのが確実だと思いますので、本ブログでは、ガイドでわかりにくかった部分を抜粋して説明します。

3-1. ファイル転送の方法

　SnowballとSnowball Edgeとでは、ファイル転送の手法と導入するモジュールが異なります。どのパターンで何をインストールしなければならないのかを以下に整理しました。

3-1-1. Snowballの場合

　今回の構成では、実際に転送したいデータはファイルサーバに配置し、クライアント経由でSnowballに転送しています。（クライアントからファイルサーバをNFS/CIFSマウントしました）
Snowballの場合、標準クライアント（Snowballクライアント）と、AWS CLIでの転送が可能です。AWS CLIで転送する場合、SnowballをS3に見立ててAPIで制御するためのS3 Adapterモジュールをクライアントにインストールする必要があります。これらツールの動作要件としてある程度のスペックが必要なので可能であればパソコンではなく、サーバで実施することを推奨します。

図 2．Snowballへのファイル転送イメージ

3-1-2. Snowball Edgeの場合

　今回の構成では、実際に転送したいデータはファイルサーバに配置し、クライアント経由でSnowball Edgeに転送しています。（クライアントからファイルサーバをNFS/CIFSマウントしました）

　Snowball Edgeの場合、AWS CLIとNFSマウント経由での転送が可能です。Snowball Edgeでは、S3 AdapterモジュールがSnowball Edge側にインストールされているため、S3 Adapterのモジュールをインストールする必要はありません。標準クライアントはSnowball Edgeのロックの解除やAWS CLI利用時の認証情報を取得するためにインストールする必要があります。これらツールの動作要件としてある程度のスペックが必要なので可能であればパソコンではなく、サーバで実施することを推奨します。

図 3．Snowball Edgeへのファイル転送イメージ

3-2. Snowball/Snowball Edgeにファイルを転送するための認証情報を取得

　こちらも両方を同時に使おうとするとややこしいので整理しました。専用のアクセスキーIDとシークレットアクセスキーを取得する必要があるのはSnowball Edgeのみです。

3-3. パッチ処理をさせながらの AWS CLI による転送

　AWS CLIを利用している場合において、細かいファイルを大量する際にバッチ処理で圧縮させながら転送することが可能です。また、オプション（--metadata snowball-auto-extract=true）を指定しておくことで、解凍された状態でS3に転送されます。（標準クライアントではバッチ処理が出来ません）

　オプション利用時の動作のポイントはSnowball/Snowball Edgeへの格納時は圧縮された状態となり、最終的にS3に保存されたときには展開された状態になるという点です。下図はSnowballでの実施イメージですが、Snowball Edgeでも同様の制御が可能です。

図 4.バッチ処理をさせながらの転送イメージ

4．書き込み速度等性能（時間）の確認

　極端なパターンですが、今回は、1KBファイルを1000,000個転送するパターン（以下、パターン①）と、1MBファイルを1,000個転送するパターン（以下、パターン②）での比較を行いました。

　ファイルはそれぞれランダムファイルを必要個数分ディレクトリ配下にフラットに生成しています。

　先で説明した標準インタフェース、AWS CLI、NFS経由、バッチ処理ありのAWS CLIのそれぞれで計測しています。

　なお、環境の都合上ネットワークは1Gbで構成しており、クライアントはLinuxです。

　いきなりですが、結果を記載します。まずは、パターン①の計測結果から、

　スモールランダムファイルのrsyncに時間が掛かるのは当たり前なので、一般的な話としてやめたほうがよい、という話ですが、バッチ処理ありのAWS CLIでの処理が非常に優秀であることが分かりました。何分？とか何秒？とかはあくまでも今回の結果であり、実際の移行時の速度の参考にはしないでください。

　なお、SnowballのAWS CLIがコマンド異常終了で失敗してしまいましたが、今回は、かなり極端なパターンでの計測でしたので、通常の利用であれば問題ないです。

　また、今回は計測していませんが、単純にクライアント台数を増やして多重で実行することで大きく所要時間は短縮できるでしょう。

　続いてパターン②です。

　こちらはどのパターンも特別ボトルネック等もなく、順調に転送が可能でした。同じAWS CLIでの転送時は、SnowballよりSnowball Edgeのほうが高速でしたが、これは、Snowballはクライアントマシンにて暗号化処理を行うのに対して、Snowball Edge側はSnowball Edgeにて暗号化処理を行うためではないかと推測されます。

　Snowball EdgeでAWS CLIと比較してNFSマウントで時間が掛かりましたが、これは単純にrsyncコマンドによる前後処理とTCP IPのオーバヘッドによる差分と推測されます。

　こちらも、何分？とか何秒？とかはあくまでも今回の結果であり、実際の移行時の速度の参考にはしないでください。

　余計に時間がかかるだけならNFSマウントって意味ないんじゃ？と思われるかもしれませんが、この方式でしか出来ないことを、「５．メタ情報の移行の確認」にて説明します。

5．メタ情報の移行の確認

　こちらも結論だけ書きますが、NFSマウント経由で移行したファイルに対しては、S3に保存される際にオブジェクトにメタデータが保存され、Storage Gateway経由でNFSマウントすることで、メタデータを参照することが出来ます。（簡単に書きましたが、結構面倒です。）

　実際にS3に移行されたメタデータについては、下図を参照してください。

　ただし、現在の仕様ではSnowball Edgeに書き込んだ段階ですべてのファイルがuid/gidが65534に変更されてしまいます。（こちらはサービス改善リクエストを出しました）

　タイムスタンプは移行できるため、現状では、この部分の移行が必須となる場合のみの検討となるでしょうか。

　ちなみにですが、本仕様に関連して、rsyncやcpコマンドでパーミッションコピーが出来ないことがわかりました。
　（よく使うrsync –a や　cp – p が使えません。また、rsyncでは、--inplaceオプションが必要でした）

図 5．SnowballからS3に移行された後のメタデータの移行状態

　いろいろ書きましたが、最初からtarでパーミッションを保持して固められたファイルであれば、標準クライアントやAWS CLIで転送した後にサーバにダウンロードして解凍すればよいので、そのほうが遥かに単純です。（一旦Snowball/Snowball Edgeを経由している時点で、直接ソースとデスティネーションを、そのままオンラインで同期しているわけではないので）

６．最後に

　本記事では、Snowball/Snowball Edgeを利用したデータ移行の検証を行いました。数10TBを超えるデータを転送する必要があり、かつ、インターネットやDirect Connectの転送速度に制限がある場合は、初回転送は、Snowball/Snowball Edgeで行い、差分同期・最終同期を、Direct Connect経由でオンプレミスと接続しrsync等を使って実施する、などの方法が現実的かと思います。

　Snowball/Snowball Edgeの機器の仕様等については本ブログではあまり触れませんでしたが、AWSのページにまとめられていますので、そちらを参照ください。

• AWS Snowballの仕様（https://docs.aws.amazon.com/ja_jp/snowball/latest/ug/specifications.html）
• AWS Snowball Edgeの仕様（https://docs.aws.amazon.com/ja_jp/snowball/latest/developer-guide/specifications.html）