AWS Snowballを真剣に考えてみる #なぜSnowballを使うのか？

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

# AWS Snowballの概略
AWS Snowballは、AWS Snowファミリーデバイス群からなっており様々なモデルが用意されている。今回は特に断りがなければSnowball Edge Storage Optimizedを指していると思ってもらいたい。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3288030/4b25ab1b-9bee-6a01-b6c3-53b85605a685.png)
写真：Snowball Edge筐体 参考：[AWS Snowball Edge デベロッパーガイド](https://docs.aws.amazon.com/ja_jp/snowball/latest/developer-guide/using-device.html)

## 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を利用する移行ユースケースとして思いつくのは下記になるだろう。
1. AWSへのネットワーク接続がない場合
2. AWSへのネットワーク接続はあるがネットワーク回線が細く移行スケジュールに間に合わない場合
    [AWS Snowball Edgeデベロッパーガイド](https://docs.aws.amazon.com/ja_jp/snowball/latest/developer-guide/whatisedge.html)には以下の記載がある。
>各 Snowball Edge デバイスは、インターネットよりも高速でデータを転送できます。この転送は、アプライアンス内のデータをリージョンのキャリアが配送することで行われます。

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

## 細いネットワーク vs AWS Snowball
ネットワーク回線が細く時間がかかるのでAWS Snowballを使う。よく語られるストーリーだ。ではその判断分岐点はどこだろうか。AWS Snowballはデータを格納し返送、ストレージへの格納に約一週間が目安とされている。
>Q: データの転送にはどのぐらい時間がかかりますか?
>データ転送速度は、ローカルネットワーク速度、ファイルサイズ、およびローカルサーバーのデータ読み込み速度を含む、さまざまな要因の影響を受けます。**Snowball Edge を使用して AWS に 80 TB のデータを転送するために必要なエンドツーエンド時間は約 1 週間です。** これには通常の配送時間と AWS データセンターでの処理時間が含まれます。
>[AWS Snowball のよくある質問](https://aws.amazon.com/jp/snowball/faqs/)

なお本来は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日にかかる**ということになる。
これは（超が付くほど）理想の上限値でありこれを上回ることはできない。

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

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

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

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

# AWS Snowballはデータ移行におけるSPOFなのか
[AWS Service Level Agreements (SLAs)](https://aws.amazon.com/legal/service-level-agreements/?nc1=h_ls&aws-sla-cards.sort-by=item.additionalFields.serviceNameLower&aws-sla-cards.sort-order=asc&awsf.tech-category-filter=*all)では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の代替手段を考えてみる」（予定）