(レポート) STG214: ニューローンチ！AWS Snowball Edge と AWS Snowmobile 入門 #reinvent

re:Invent 2016の「NEW LAUNCH! Introducing AWS Snowball Edge and AWS Snowmobile (STG214) 」の動画を聴講したのでレポートします。

• セッション動画: AWS re:Invent 2016: NEW LAUNCH! Introducing AWS Snowball Edge and AWS Snowmobile (STG214)
• セッションスライド: NEW LAUNCH! Introducing AWS Snowball Edge and AWS Snowmobile

画像はすべてセッションスライドからの引用です

スピーカー

• colin lazier - General Manager, Glacier & Snowball, Amazon Web Services
• Rich Ridolfo - Sr. Director, Operations & Infrastructure R&D, Philips
• Jay Littlepage - VP, Infrastructure & Operations, DigitalGlobe

レポート

このセッションで扱うこと

• 今年の re:Invent で発表された AWS Snowmobile と AWS Snowball Edge の製品概要
• Snowmobile を使った DigitalGlobe 社の画像データ移行事例
• Snowball Edge を使った Philips 社のヘルスケアプラットフォーム事例

Migrating large scale data is challenging

大量データをクラウド移行するのは非常にチャレンジング

ネットワーク越しにデータ転送した場合のスピードとコストを試算すると、実現可能ではないと判断されることがある インターネット転送は辛いので、輸送によるデータ移行を考えると、ロジスティックスとセキュリティが課題となる。

• Speed
• Cost
• Logistics
• Security

を解決するソリューションとして、昨年の re:invent 2015 で Snowball をリリースした。

AWS Snowball - petabyte scale data transport

• 8.5G に耐えるインパクトケース
• E-Ink の配送ラベル
• エンドツーエンドのデータ暗号化
• 50 TB 容量/10G ネットワーク転送

ストレージをそのまま配送できるような専用の筐体で覆い、タフな状況下でも利用できるようにした。 筐体は物流システムによりトラッキングされ、仮に盗まれても、データは暗号化されているため、データ流出は起きない。

これらの要件を満たしつつ、一人で運べるサイズ・重さに収まり、電源をさせば動作するように筐体を設計した。

How Snowball moves data into and out of AWS

Snowball のワークフロー

1. Snowball の配送先住所を指定してジョブを作成
2. Snowball を配送
3. Snowball に電源ケーブルを刺す
4. Snowball にデータコピー
5. Snowball を返送
6. S3 にデータコピー

Snowball to date

地球 100 周分 の距離を Snowball で配送した

過去一年で以下のような機能追加を行った

• 80TB Snowball(従来は 50TB のみ)
• ヘルスケア業界向けの HIPAA コンプライアンス
• リージョンの拡大
• Hadoop の HDFS からのコピー
• S3 API 互換のコピー

Challenges at extreme scale

Snowball が登場したおかげでデータセンターからの移行も feasible(実現可能) にはなったけれどど、まだまだ difficult(難しい)。

Snowball は TB から PB 規模のデータ移行に向いている。

10 PB, 100 PB, Exabyte 規模のデータを移行するとなると、ロジスティックスその他が途端に難しくなる。

• 80TB
• 100PB
• Exabyte

で壁がある。

100PB のデータを 10 個の Snowball で並列にデータ移行する場合を考える

• 1 Snowball あたり 100 PB / 10 = 10 PB = 10000 TB を移行する
• Snowball の最大サイズは 80 TB のため、10000 TB / 80 TB = 125 回のコピーが発生する。
• 1コピーあたりオンプレミスと AWS の配送・データコピーを含めて1週間かかるとすると、データ移行完了までに 125 週 = 約 2.5 年かかってしまう。

Snowball がなければ何十年もかかるはずのデータ移行が数年に短縮されたとも言えるが、現実的ではない。

移行期間中、何千もの Snowball がひっきりなしにオンプレミスを行き来し、データコピー作業も発生すると、さらに現実味が失せる

そうした課題を解決するために AWS Snowmobile が誕生した。

Snowmobile broad strokes

Snowball はデータ転送に特化した(purpose built)トラック

• 1ジョブで 100 PB まで可能
• 45-foot コンテナーのデータトラック
• トラックは 68000ポンド≒34トン
• 最大 500 Gbps の速度で Snowball と通信

データ移行プロセスは Snowmobile と Snowball で似ている。

Snowmobile ではプロセスの最初にサイトサーベイを実施する点が大きく異なる。

サイトサーベイでは以下のようなことを行う

• 移行の概要の確認
• トラックの駐車場所
• 電源の確認
• セキュリティ対策

サイトサーベイのあとは

• トラックのディスパッチ
• データコピー
• トラックを AWS に戻す
• データをS3にコピー

と Snowball と同様のフローをたどる

DigitalGlobe の Snowball と Snowmobile 活用事例

このセクションは DigitalGlobe の Infrastructure & Operations VP である Jay Littlepage さんによる発表

DigitalGlobe の事業はリモートセンシング（人工衛星などによる写真販売提供）

Andy Jassy は前日のキーノートで実際にトラックを登場させて AWS Snowmobile を発表した。 "It's really happening. It's real."

DigitalGlobe 社による AWS Snowmobile の初事例の紹介。

AWS Snowmobile は DigitalGlobe 社にとってなぜ重要なのか?

Snowmobile と同じサイズのカメラで上空 400 マイルを軌道している衛生から撮影している。

上空から撮影した画像は撮影地点とマッピングすることもある

AP通信はスーパーマーケットで売られている魚介類の一部が奴隷船で収穫されたものであることを突き止めた

その解析に、DigitalGlobe 社の画像が活用された。

この ”Seafood from Slaves” により AP 通信は 2016 年の Pulitzer 賞を受賞

• AP Explore: Seafood from slaves | Associated Press
• AP wins Pulitzer Prize for 'Seafood from Slaves' investigation
• Fishermen Slaves: Human Trafficking and the Seafood We Eat

Dealing with "Data Boulders from Space"

世界をより詳細に画像化するにはストレージをたくさん消費する

例えば、DigitalGlobe 社の WorldView3 で撮影した画像は一枚で 12 GB 消費する。

毎日何千もの画像を撮影しているため、毎日 85TB の画像データを新規に保存している

"Seeing a Better World" for 16 years, with more sensors at higher resolution, adds up to a data management challenge.

過去16年間のデータ蓄積の結果、画像データの総量は 100 PB にもなった

毎年 10 PB の画像データが増える

• 費用と耐久性のトレードオフ
• 画像アクセスのしやすさ

を調整しつつデータ管理ぷたっとフォームを作成した

大多数の画像データはランニングコストのやすさからテープで管理されている

データはテープで保存されているにも関わらず、1時間以内にデータを取り出す事ができる

昨年は4,400万ファイルを操作した

Releases the images!

それなりに使いやすいシステムではあるが、顧客自身がこれらの画像データにアクセス出来るわけではない

クラウドの活用は new -> common -> expected と変わってきた

コンピュータリソースを使って画像からメタデータを抽出することが重要になってきたが実現できていなかった。

これらを解決するために AWS 上で GBDX(Global Geospatial Data Platform)というデータ管理プラットフォームを開発

過去16年に蓄積したすべての画像が管理されているわけではない上、オンプレでのデータの蓄積スピードがオンプレ→AWS(GBDX)のデータ移行スピードに勝っていた

How? Snowball!

• 昨年の re:invent で AWS Snowball が発表された。
• 最初は prank(悪ふざけ) と思った
• 画像アーカイブをすべて Snowball でデータ移行した

SpaceNet という商用の衛星画像データコーパスは機械学習目的で無料で提供されている。

• https://aws.amazon.com/public-datasets/spacenet/
• The SpaceNet Challenge | Seeing a better world™

First stage booster: push interesting data sets to AWS via Snowball

デジタルアーカイブとシステムを3ステップでAWSに移行した。

Step 1 : Snowball を使う

オンプレ環境でサービスは動かし続ける

裏で Snowball を使って AWS にデータをレプリケート

オンプレミスのデータは TB スケールではなく PB スケール。いつ終わるかわからない

Snowball から直接 Glacier Vault に保存させることはできない。Glacier への変換作業やストレージコストの増加が発生

• Snowball より大容量なデータ移行サービスが必要。
• Snowmobile を利用。
• Snowmobile は衛生写真からも識別出来る。

エクサバイトスケールに向かっていた DigitalGlobe 社にとってぴったりにソリューションだった。

Step 2:Snowmobile を使う

• Snowmobile で圧縮したデータを一括で移行。
• Glacier vault に直接アーカイブ化
• データは暗号化され、完全性もチェックされる。

データ移行とシステム移行が完了すれば、オンプレのデータ管理プラットフォームを引退させられる。

Lessons we are learning with Snowmobile

今後 Snowmobile を利用するユーザー向けの知見

This is not plug and play(yet)

• Snowmobile はオンプレミスにデータセンターをつなげたようなもの
• オンプレは NFS ベースで AWS 側は S3 ベース。
• 効率よく転送されるように、チューニングを頑張った。

Pre-planning and coordination is critical.

• データ量やデータの保存方法などデータの特性を十分に把握しておくこと。
• Snowmobile が届く前、サイトサーベイの実施前など、データ移行プロセスが動き出す前にしっかり事前調査を行うこと。

On orbit: Cloud-centric data management

• データ移行が来年完了すると、オブジェクトストレージを直接操作できるようになる。
• 移行が完了すれば、物理データセンターを破棄できるようになる。
• オンプレミスと同じようなデータライフサイクルを AWS 側のストレージにも設定できるようになる。

AWS 移行が完了すると、より詳細な画像分析を顧客やパートナーに提供出来るようになり、世界を大量の画像からより深く、より早く理解できるようになることにも繋がる。

Challenges at the Edge

• Snowball を開発した時、意識していた課題はデータの移動だった(data migration challenge)
• Snowball をリリース後、ユーザーの声に耳を傾けると、データ移行だけでなくデータを集める課題も多かった(data collection challenge)

データ収集では、移行すべき大量のデータがすでにあるわけではなく、生成されるデータの収集しデータ変換して移行する。

Snowball Edge broad strokes

データ収集は以下のようなワークフローが典型的

IoT のセンサーデータなどを想定している

• エミットされたデータをどこかに安全かつ耐久性高く保存
• データは Snowball の設置場所でも活用する
• リモート環境で集約したデータを AWS に移行する

このワークフローをエンドツーエンドで解決するために Snowball Edge を開発した。

Snowball Edge broad strokes

Snowball から Snowball Edge への変更点。

• 10Gbps の他に 25 Gbps, 40 Gbpsも追加
• データセンサーの引っ越しのように大量のデータを移行するケースにおいて、データの暗号化と転送を行う
• Snowball クライアントがデータ移行のボトルネックになっていた。
• 暗号化は Snowball Edge 側で行い、NFS と S3 API インターフェースを Snowball 側に用意した
• 複数の Snowball でクラスターを組めるようにした。耐久性が増し、一部の Snowball でストレージ障害が起きても、紛失しても、データロストしない。
• AWS Greengrass(オンプレミス版Lambda)連携により、データ収集時に、コンピューティング処理が可能

GE 風力発電の事例

• GE の風力発電はこのようなワークフローを採用
• センサーデータをクラスター化された Snowball に収集
• データ投入時には Greengrass が呼び出され、異常値検出やアラームの発火などを行う
• 月次、四半期毎に Snowball を AWS に送り、新しい Snowball と置き換える

収集したセンサーデータを異常値検出やより効率な風力発電運用に役立てる

Snowball Edge Key Features

Snowball Edge により、より耐久性高くデータ収集し、エッジ環境でのコンピューティングも可能になった

Philips の Snowball Edge 活用事例

このセクションは Philips 社の Operations & Infrastructure R&D でシニアディレクターを務めるRich Ridolfo さんによる発表

Philips の提供する HealSuite ソリューションの紹介と Snowball Edge の活用について

Philips の病院で

• リアルタイムのデータ収集
• プリプロセス
• 永久保存

をやっている。

静的なデータを AWS のストレージで管理することはすでにやっていた。

病院というオンプレミスで提供しているプラットフォームでもクラウドと連携させたかった。

ヘルスケア系は金融系のようなミッションクリティカルなシステムと同じく、様々なチャレンジがある

ヘルスケア固有の問題として生命の安全がある

HealthSuite とは?

HealthSuite は以下を行うヘルスケア向けのプラットフォーム

• compute
• storage
• analytics
• connectivity

IT システムと同じく

• 暗号化
• プライバシー
• コンセントマネージメント

といった要件があり、システムとしては大量データをストリーミングで保存し、あとで分析できるように永続化する。

Clinical Healthcare IT Challenges

• システムが止まると医療サービスが止まる。100％近い稼働率かフェイルモードでの動作を保証する
• X 線や MRI などのデータサイズが大きくなっても、処理時間はより短くなるようにする。3秒かかっていたものが1秒になるように改善しても人はすぐに慣れる。遅くなることは許されない。
• Connectivityが目下の課題。アメリカ国内に限定しても、回線のキャパシティや帯域の質はまちまち。

Connectivity

• ブロードバンドアクセスはアメリカではまだチャレンジ
• アメリカの10％の人はブロードバンドアクセスがない
• 39%の郊外に住んでいる人は低速のアクセスにも乏しい
• 病院はアメリカ各地にあるので同じチャレンジがある
• そのような環境下では、クラウドまで直接データ送信せず、オンプレでデータを集約する Snowball Edge がマッチする。

Desired Solution Characteristics

以下のような要求がある

• クラウドとのインターネット接続がなくても、認証、暗号、ロギングなどが可能
• オンプレミスとクラウドでコードベースが同じ(たとえば AWS Lambda と Snowball Edge で利用する Greengrassなど)
• オンプレとクラウドの間でエンドツーエンドでセキュア
• リダンダンシー
• 病院の統合、最新機器などにより、データ量が増えてもスケールする
• ファシリティや顧客によらず、統一的に管理出来る

IntelliSpace Console Critical Care

• ICU で患者のデータを様々なセンサーから収集する
• リアルタイムでデータをプロットする
• ルールエンジンにデータが常にフィードされる
• センサーデータをもとに患者の容態を即座に分析する

今日の ICU はこのようなシステムなしには成り立たない

冗長構成が組まれた高価なサーバーとして各 ICU で動作している

いきなりクラウドに持っていくのは敷居が高い。

クラウド移行した時に、通信障害などシステムがうまく動作しなかった時のインパクトが大きすぎる

Philips IntelliSpace Console Critical Care : HealthSuite + AWS Snowball Edge

http://image.slidesharecdn.com/stg214-161216172014/95/new-launch-introducing-aws-snowball-edge-and-aws-snowmobile-36-638.jpg

プロセス → コンピュート → 予測というパイプラインを Snowball Edge 上で構築した

• データをどうやって収集
• データをどのようにデータ処理向けに変換
• データの届くスピードで処理

これまでのところ、期待通りに動作している

• リアルタイムでデータ変換可能
• インターネット接続がなくても、動作する
• セキュア
• オンサイトの対応が不要

Snowball Edge : On-site hub for communication, data aggregation & pre-processing

将来について

• Snowball は ICU に限らず、病院におけるデータ収集のハブとなりうる
• ICU 以外にも画像などたくさんのデータが病院では生成されている
• これらのデータをその場でプリプロセスして活かしたい
• 病院で動いている各種サービスのデータはそれぞれのサービスに閉じて管理されている
• Snowball Edge に機能追加し、これらのデータ集約(データハブ)化をすすめたい

まとめ

本セッションは昨年発表された AWS Snowball に続く兄弟製品

• AWS Snowmobile
• AWS Snowball Edge

の利用事例の紹介です。

AWS Snowmobile が必要なほどの AWS データ移行案件に携わる可能性は非常に低いかと思います。

一方で、IoT や製造業などでインターネットにつなげることに抵抗がある業種で Snowball Edge は非常に有効に感じられました。

Snowball/Snowball Edge はオンプレミス環境での利用が一定期間を超えると、日々課金が発生しますが

• Snowball は $15/day
• Snowball Edge は $30/day

とリーズナブルです。

本セッションのユースケースにもあったように、オンプレミス環境でデータ収集ハブとして設置し、定期的に AWS に送り返すといった利用は、今後どんどん広まるのではないでしょうか。