移行とデータ転送

このレッスンでは、データ量と回線と期限という3つの材料から、回線で送るのか、装置で運ぶのか、置いたまま繋ぐのかを判断できるようになります。

まず要件文から

ある製造業の会社が、オンプレミスのファイルサーバーにある大量の設計データをAWSへ移したいと考えています。事業所と本社を結ぶ回線は業務でも使っており、移行のために占有はできません。工場の停止を伴う切り替えの日程が決まっていて、その日までに移し終える必要があります。移行後も、現場の端末からは今までどおりファイルサーバーとして見えてほしいとのことです。

ここには判断の材料が3つ入っています。データ量、使える回線、期限です。SAAの移行系の設問は、ほぼこの3つの組み合わせで答えが決まります。

回線か、装置か、の決め方

何テラバイトまでなら回線で送れる、という一律の閾値はありません。回線の帯域と、そのうち移行に回せる割合と、許された日数で決まるからです。判断の立て方は次のとおりです。

1. 移行に使える実効帯域を見積もる。業務で使っている回線なら、その一部しか使えません
2. データ量を実効帯域で割って、必要な日数を出す
3. 出た日数が期限に収まるなら回線、収まらないなら物理装置で運ぶ

日数が期限を超えたら Snow ファミリー、という順で考えます。設問には「回線は業務と共有」「移行期間は2週間」といった形で材料が必ず書かれているので、そこを拾います。逆に、帯域が十分あるのに Snow を選ぶ選択肢は、時間もコストも無駄になるので落とします。

選択肢の線引き

DataSync は、オンプレのNFSやSMBの共有と、S3・EFS・FSxとの間を高速に転送するマネージドサービスです。差分の検出、検証、スケジュール実行まで面倒を見るので、「一度だけでなく定期的に同期したい」「移行中も更新が続く」という要件では、自前のスクリプトやコマンドではなくDataSyncが答えになります。

Snow ファミリーは、AWSから届いた装置にデータを書き込んで送り返す方式です。回線の制約を時間の問題として扱えるのが利点で、拠点がへき地で回線が細い、という設問でも選ばれます。

置いたまま繋ぐという第3の答え

冒頭のシナリオの最後にある「移行後も、現場の端末からはファイルサーバーとして見えてほしい」という一文が、Storage Gateway の合図です。Storage Gateway は、オンプレ側に見慣れたインターフェースを残したまま、実体をAWSのストレージに置く仕組みです。用途ごとに種類が分かれます。

• S3 File Gateway — NFSやSMBの共有として見せて、実体をS3に置く
• FSx File Gateway — オンプレからFSxのファイル共有に低遅延でアクセスする
• Volume Gateway — iSCSIのブロックボリュームとして見せ、バックアップをAWSに置く
• Tape Gateway — 既存のバックアップソフトから仮想テープとして見せる

設問に「既存のバックアップソフトを変えずにテープ運用をやめたい」とあれば Tape Gateway、「アプリケーションを改修せずにファイルサーバーの容量問題を解消したい」とあれば S3 File Gateway です。

要件語から構成への対応

よくある引っ掛け

1つ目は、継続同期の要件に Snowball を当てる選択肢です。装置は1回運べば終わりなので、「移行後も差分を同期し続ける」という要件は満たせません。ここはDataSyncです。

2つ目は、移行だけを見て Storage Gateway を落とすことです。要件文に「オンプレの端末やアプリからは今までどおり見えること」と書かれていたら、全部を移し切る構成ではなく、Storage Gateway を残す構成が答えになります。移行系の設問は、移し先だけでなく移した後の見え方まで読みます。

• 判断の材料はデータ量と実効帯域と期限の3つです
• 必要日数が期限を超えたら Snow ファミリー、収まるなら回線です
• 継続的な同期が要件にあれば DataSync です
• 「今までどおり見えること」は Storage Gateway の合図です
• 一律の帯域の閾値を覚えるのではなく、割り算で判断します

まとめ