はじめに

データ移行の観点で、AWSには他のクラウドにはない特徴的なサービスがある。AWS Snowballである。
AWSから送られてくるストレージ媒体にデータを格納し、AWSへ返送すればAWSクラウドストレージにデータが格納される（格納してくれる）。AWSサービスにおいて物理機材が利用者に見える数少ないサービスだ。
今回はこの AWS Snowballでのデータ移行についてちょっと真剣に考えてみた。

AWS Snowballの概略

AWS Snowballは、AWS Snowファミリーデバイス群からなっており様々なモデルが用意されている。今回は特に断りがなければSnowball Edge Storage Optimizedを指していると思ってもらいたい。

写真：Snowball Edge筐体参考：AWS Snowball Edge デベロッパーガイド

Snowball Edge Storage Optimized (データ転送用) の主な仕様

項目	仕様
HDDストレージ容量	80TB使用可能
ネットワーク接続	2x10Gbps–RJ45(1つ使用可能）/1x25Gbps-SFP28/1x100Gbps-QSFP28
重量	22.54kg
高さ	394mm
幅	265mm
長さ	718mm
温度範囲	0-45℃
電源	100-220V

サイズ感はタワー型のサーバのようなもので、これをネットワークに接続してデータをSnowballに格納する。
発送返送ともAWSマネジメントコンソールからの操作となり、利用者側で伝票を書くといった必要はない。

なぜAWS Snowballを使うのか？

通常AWSクラウドストレージへのデータを移行する場合、ネットワーク伝送を利用する。AWSもネットワークデータ移行サービスは豊富だ。そんな状況でAWS Snowballを利用する移行ユースケースとして思いつくのは下記になるだろう。

各 Snowball Edge デバイスは、インターネットよりも高速でデータを転送できます。この転送は、アプライアンス内のデータをリージョンのキャリアが配送することで行われます。

「1.」が前提になるならばSnowball以外の選択肢がない。「2.」をもう少し解像度をあげてみたい。

細いネットワーク vs AWS Snowball

ネットワーク回線が細く時間がかかるのでAWS Snowballを使う。よく語られるストーリーだ。ではその判断分岐点はどこだろうか。AWS Snowballはデータを格納し返送、ストレージへの格納に約一週間が目安とされている。

Q: データの転送にはどのぐらい時間がかかりますか?
データ転送速度は、ローカルネットワーク速度、ファイルサイズ、およびローカルサーバーのデータ読み込み速度を含む、さまざまな要因の影響を受けます。Snowball Edge を使用して AWS に 80 TB のデータを転送するために必要なエンドツーエンド時間は約 1 週間です。 これには通常の配送時間と AWS データセンターでの処理時間が含まれます。
AWS Snowball のよくある質問

なお本来はAWSから発送され手元に届くまでに同等の時間がかかるため、データ移行スケジュールの検討は注意が必要だ。

ネットワークとAWS Snowballでのデータ移行速度を比較するため、AWS Snowballでデータ伝送に要する時間を考えてみたい。移行するデータ容量は上述の「AWS Snowball のよくある質問」に記載されている80TBとしてみたい。

80TBのデータをネットワークで伝送した場合、以下の時間が必要である。なお、下記は伝送効率を考慮していない理想値であり、現実のデータ伝送は確実にこれより遅い。

回線帯域	計算	伝送時間
10Mbps	80TB×1024×1024÷(10Mbps÷8byte)=83,886,080MB÷1.25MBps	67,708,864秒=776日
100Mbps	10Mbps時の1/10	77.6日
1Gbps	10Mbps時の1/100	7.76日
10Gbps	10Mbps時の1/1000	0.776日

ネットワークの場合

AWS Snowballは運搬からデータ格納まで前述の通り1週間程度時間を見込む必要がある。運搬にかかる時間でありこの時間は利用者は何もできない。ネットワーク伝送であればその時間もデータを送り続けることができる。
上表の通り1Gbpsのネットワーク（回線）でデータを伝送した場合、理想値では7.76日で80TBのデータを伝送できる。

AWS Snowballの場合

AWS Snowballで80TBのデータを送る場合、まずはLANにSnowballを接続してデータを格納する必要がある。
AWSでシステムを移行するようなオンプレミスのLAN速度のボリュームゾーンは1Gbpsではないだろうか。（基幹部は10Gbps化されているシステムも多いとは思われるが…）
AWS Snowballへのデータ伝送で「仮にLAN同様の速度が出た場合」でも7.76日かかる。
そして、そこから1週間程度で運搬クラウドストレージへの格納が行われるので、7.76日＋1週間（=7日）となり合計14.76日、つまり1GbpsLANを使ってAWS Snowballで80TBのデータを移行する場合は最短約15日にかかるということになる。
これは（超が付くほど）理想の上限値でありこれを上回ることはできない。

AWS Snowballへの書き込み速度について、AWSドキュメント上には全く記載がないことは理解しておく必要がある

15日で80TBのデータを移行するならば、逆にネットワーク帯域はどの程度でよいだろうか。上記表の計算を流用するならば
83,886,080MB÷〇MBps=15日(=1,296,000秒）
〇≒65MBps=520Mbps、となる。つまり、80TBのデータをネットワークでAWSに伝送する場合は520Mbps以上のネットワーク伝送ができればネットワークの方が早いということになる。

上記計算はネットワーク帯域をフル活用できた場合であり、ベストエフォート回線やそもそもの伝送効率を加味しなければ実際の値は算出できない。帯域保証回線であったとしても、20-30%程度伝送能力は落ちると思った方がよい。

改めて、なぜAWS Snowballを使うのか？

繰り返しになるが、ネットワーク回線がなければSnowballを使うしかない。また、時間をかけてよいのであれば帯域が細かろうがネットワークで送り続ければよい。
それができないということはデータ移行スケジュールの制約、リミットがあるということになる。
何らかのデッドライン、閉め切り、マイルストンが設けられており、それを達成するにはAWS Snowballを使うしかないから使うのだ。しかし、ここからが今回の本題となるのだが「AWS SnowballにはSLAが設定されていない」のだ。

AWS Snowballはデータ移行におけるSPOFなのか

AWS Service Level Agreements (SLAs)では2024年5月現在AWS SnowballのSLAは記載されていない。何らかのデッドライン、マイルストン、期日/納期が設けられており、それを達成するにはAWS Snowballを使うしかないから使うにもかかわらず、それを達成する手段にはSLAがないのだ。
ただ、物理筐体を使って利用者とAWS間で輸送を伴うサービスなのでSLAが設定できないのも理解はできる。Snowballを配送する運送会社のトラックが故障するかもしれないし、事故に巻き込まれるかもしれない、雪で立ち往生も流行り（？）だ。また、AWS Snowballを利用していた利用者が一斉に返却遅延を起こしSnowballの在庫が枯渇するかもしれない（レンタルビデオ全盛時代を生きた人にはおなじみのはずだ）。

AWS Snowballを使わなければデータ移行とその先のビジネス目標が達成できないならば、Snowballに依存したデータ移行が必要であるならば、SnowballはSPOF（Single Point Of Failure,単一障害点)と言えるのではないだろうか。そのようなサービスに移行スケジュールを委ねていることは理解しておくべきである。

まとめ

AWSでのデータ移行手法としてAWS Snowballはとてもユニークで面白いサービスだと思う。しかし、述べてきたように頼らなければデータ移行が完遂できないのに信頼性で脆弱な面がある。替えがきかないならばSPOFとなってしまう。いかん、SPOFは極力排除しなければ…次にAWS Snowballの代替手段について考えてみたい。
⇒「AWS Snowballを真剣に考えてみる #Snowballの代替手段を考えてみる」（予定）