AWS Snowball を使用して大量データをS3に移行（後編）

AWS Snowball とは

本エントリーは、2017年9月のSnowball前編の続きとなります。
随分と間が空いてしまいましたが、Snowballを扱う上での流れ、注意点を書いていきたいと思います。
前回は全体の流れの話をしたので、今回は具体的な使用方法や注意点についての話です。

Job作成

マネージメントコンソール上から Snowball の Job を作成します。

前編で書いた通り、Snowballは外付HDDというより、NASという感じです。 オンプレ環境のデータをSnowballに入れる場合、以下のような構成になります。

Snowball を同一ネットワーク上に配置してからのIPアドレスでのアクセスとなります。
同一ネットワーク上からであればどのサーバーのデータでも転送できますが、
ネットワーク的に遠い場所にあるサーバーとの通信は転送速度に影響するので、
Snowball はなるべく転送対象のサーバーの近くに配置した方が良いです。

事前準備

SnowballClient をダウンロードし、オンプレのサーバーにインストールします
オンプレサーバーからSnowballに転送するにあたり、処理時間を左右するのが、
内部ネットワークの速度と、SnowballClient をインストールしたサーバーのスペックです
SnowballClient をインストールするサーバーの最低推奨スペックはこちらです。

16コア推奨ですが、実際の案件では4コア8スレッドのCPUでも動作自体は確認しています（非推奨です）。

Snowball Client のテスト

Snowball本体が到着する前に実施できる性能テストとして、
Snowball Clientを使用した転送速度のテストがあります。
Snowball Clientがインストールされたサーバーを使った場合の転送の速度計算を実施します。
以下のコマンドでテストを行います

(Windowsの場合)

$ snowball test -r -t ＜テスト回数＞ ＜\\\転送元サーバー\転送元ディレクトリ＞

このテストであまりに遅い場合は、SnowballClientを入れるサーバーの性能を見直した方が良いです。
このテストで計測できる転送速度は、転送元サーバー → Snowball Client 、の転送速度なので、
Snowball Client → Snowball への転送速度は含まれない事に注意してください。

Snowball側 起動作業

Snowballをネットワークに結線する前にSnowball側の作業を実施します。
前面と背面のフタを開けます。
ハマりポイントとしては、フタの取っ手は下図のような構造になっており、
引っ張ってもびくともしません。
ボタンを押しながら真上に押し上げてください。

蓋にケーブルが巻き付けられていますが、この状態 を携帯などで写真に収めておくと、
返送時に巻き方に困らないのでおすすめです。

電源ケーブルを接続し、前面ディスプレイ上部の電源スイッチを投入します。
（正常に起動完了しない事が何度かありました。
電源ケーブルを一度抜き差しして、再試行すると正常に起動できたことがあります。）

準備完了となったら、タッチパネルの [Network] よりネットワークの設定を実施します。
ちなみにタッチパネルは感圧式ではないので、指で操作してください。狭いです。

ネットワークの設定が完了したら、ネットワーク回線をオンプレ環境に接続し、
SnowballClient側の作業を実施します。

SnowballClient側 起動作業

AWSのマネジメントコンソールからSnowballを選択し、作成したジョブを選択すると、
認証情報の項目から、マニフェストとアンロックコードがダウンロードできるようになっています。
これらを SnowballClient がインストールされているサーバーにダウンロードします。

ターミナルより以下のコマンドを実行し、Snowballを起動します
$ snowball start -i ＜SnowballのIP＞ -u ＜アンロックコード＞ -m ＜マニフェストファイルの場所＞

起動完了したら、使用済み容量、残容量、合計容量が表示されます。

オンプレからSnowballへの転送

SnowballClientがインストールされたサーバーより、以下のコマンドを実行してファイルをSnowballに転送します。
$ snowball cp ＜送信元＞ ＜送信先 バケット名/ディレクトリ＞

オプション -r をつける事で再帰的に転送します。
送信元は ネットワークパスでの記述になります。
Windowsなら
$ snowball cp -r \\192.168.10.10\okurudir\ s3://sunoubo-runi-okuru/okurudir/

といった感じです

コピーコマンドの構文についてはこちらを参照してください

他の SnowballClient コマンドはこちらを参照してください

流れとしては、
snowball cp でコピーして、
削除したい時は
snowball rm で削除して、
snowballの中身を見たい時は
snowball ls でリストして、
容量は
snowball status で確認して、
といった感じでサーバーからSnowballに転送します。

転送完了後の処理

間違いなくやっておいた方がいい処理として、
$ snowball -v validate

コマンドで、転送されたファイルの整合性を確認します。
エラーなどで正しく転送されなかったファイルは、Snowball -> S3 の工程で削除されます。
その危険を可能な限り無くすために、このコマンドで整合性の確認を実施する事を強く推奨します。
（割と時間がかかるので、余裕をもって実行してください）

全作業が終了したら、以下のコマンドでSnowballを止めます。
$ snowball stop

このコマンドはSnowball自体の電源を落とさないので、
コマンドが正常に流れたら、Snowballの電源ボタンを押して止めます。

また、返送時に以下の３つの条件を満たしていないと、返送してもインポートしてもらえず、データが消去されます。

• Snowballアプライアンスが侵害されていないこと
  • 前面背面のアクセスパネルを除き、Snowballが開かれていないこと（物理的に開封、変更、破壊されていない事）
• Snowballのフタが正しく閉まっていること
  • 前面背面のフタがカチッと音がするまで閉まっていること
• Snowballの E ink ディスプレイがちゃんと表示されること
  • データ転送が終わり、電源を切った後に返却ラベルが表示されていること

返送

返送はSnowballに同封されている（張り付いている）送り状を使って返送します。
手順も書いてあり、指定の配送業者を使って指定の場所に返送します。
送り先の住所は配送センターになっているので、
AWSのデータセンターの場所はわからないようになってます。
普通に業者に集荷を依頼して、普通に集荷してもらう感じです。

Snowball 返送後に確認する事

Snowball返送後は、マネジメントコンソールのSnowballジョブ画面で状況を確認します。
進捗バーを見ていればだいたいわかりますが、
実際にS3への転送が開始された時には全体の進捗バー以外に転送の進捗が%で表示されます。
進捗が100%になれば、S3への転送は完了です。

Snowball からEC2インスタンスへ

Snowballの扱い自体はそれほど難しいものではありません。
どちらかというと、全体の移行方針の方が重要です。

全体の流れとしてのコツには以下のようなものがあります。

• ファイル数を減らす
  • 無理をしてでもtarやzipで可能な限り一つのファイルにした方が、
    S3からインスタンスへ転送する時のパフォーマンスが上がります
• NTFS権限はSnowballには引き継げない
  • Windowsのファイルの場合は、事前に icacls などでNTFS権限を別ファイルとして吐きだし、
    転送後に適用する必要があります
  • icacls にはファイルパスの文字数制限が有ります。フォルダが深すぎて制限を超えるファイルがある場合は、代替手段が必要です。
• S3からサーバーへの転送は意外と時間がかかる
  • VPCエンドポイントを使っても、Snowballで運ぶような容量のファイルの転送には
    数日かかる事があります
  • 一時的にインスタンスタイプを上げて、S3APIの同時実行数を増やして並列で…のように
    転送しないとかなり時間がかかります
• WindowsのVSS領域は移行できません
• ファイルの整合性について
  • 小さいファイルが数千万などの条件だと、ファイルの整合性チェックは膨大な時間が必要となります。弊社はSparkの並列処理を用いて整合性チェック時間を短縮したという実績もあります

Snowballを使えばサクサクっとAWSへ移行できるように感じますが、
実際に使用してみると意外と時間がかかります。
使用するかしないかの判断が重要なポイントとなります。
Snowballを使用した移行をお考えの際は、ぜひ弊社へお問い合わせください。