© 2017, Amazon Web Services, Inc. or its Affiliates. All rights reserved.

アマゾンウェブサービスジャパン株式会社辻 義一・布目 拓也

サーバとデータのマイグレーション ソリューション

自己紹介

辻 義一

技術統括本部ソリューションアーキテクト

布目 拓也

技術統括本部ソリューションアーキテクト

Agenda

• マイグレーションのメリット

• マイグレーションのプロセス

• 仮想マシンコピーのためのサービス

AWS Server Migration Service 紹介

• 大規模データのクラウドへの移行

Amazon Snowball 紹介

マイグレーションのメリット

コストダウン

マイグレーションのメリット

グローバル対応全世界のリージョンを統一して利用可

イノベーションの加速オンプレミスでは難しい新領域への投資

ビッグデータ、IoT、 APIサービス…

アジリティ実需に合わせたオンデマンドな利用

ビジネスのニーズにあわせた素早い対応

セキュリティAWSの優れたセキュリティ環境の利用と

自社セキュリティポリシーの適用

マイグレーションのメリット

マイグレーションのプロセス

移行本番稼働

マイグレーションのプロセス

事前調査

トレーニング

PoC

AWS基本設計

移行プラン策定

フィードバック

移行本番稼働移行

本番稼働移行

本番稼働

事前調査

現状調査

• 全てのシステムについて洗い出し

⎼ H/Wスペック、リソースの使用状況

⎼ S/W構成、AWS上での動作可否、ライセンス条件

⎼ 可用性要件と現在の実現方式

⎼ システム間、社外連携などの有無

⎼ 運用・保守体制

⎼ リース期限、保守期限などのライフサイクル

など

システム移行

本稼働

システム移行

本稼働

システム移行

本稼働

移行本番稼働

事前調査

トレーニング

PoC

AWS基本設計

移行プラン策定

事前調査

TCO調査

• 現状のTCOとAWSに移行した場合のTCOを算出

• 適切な Apple to Apple で比較

⎼ RI の利用、現在不要なリソースは確保しないなどの工夫をした上でのコスト算出

⎼ セキュリティ対策のコスト

⎼ 4,5年ごとのリプレースのコスト

• 数値化できないコストや価値はリストにまとめる

どこまで詳細に事前調査すべきかはケースバイケース。

調査に時間やコストをかけすぎていないか見極めが大事。

AWS 基本設計

アカウント構成複数のAWSアカウントを併用することで分離を実現。分離するが連携するための機能もあり。

例）本番 / 開発、社内向け / 社外向け、部署ごと

ネットワーク構成

• AWS内のネットワーク構成

• 社内ネットワークとの接続

⎼ インターネットVPN / Direct Connect（専用線経由/WANサービス経由）

システム移行

本稼働

システム移行

本稼働

システム移行

本稼働

移行本番稼働

事前調査

トレーニング

PoC

AWS基本設計

移行プラン策定

AWS 基本設計

標準構成の定義

• クラウドデザインパターンの適用検討

• マネージドサービスの活用検討

セキュリティポリシー

AWSにあわせたポリシーの見直し

社内への提供フロー

課金管理・支払い方法

例）標準構成 – 外向けWebサイト

移行プラン策定

目標を明確化

移行で実現したい目標はコストだけではない。定量化して評価。

移行に際してどこまで手を加えるか

極力ストレート移行してから、クラウドネイティブに最適化が現実解。（Lift-and-Shift)

ストレート移行 クラウドに最適化

システム移行

本稼働

システム移行

本稼働

システム移行

本稼働

移行本番稼働

事前調査

トレーニング

PoC

AWS基本設計

移行プラン策定

移行プラン策定

移行スケジュールを策定

重要度、移行難易度、コスト効果に応じて移行対象を優先度付けして、移行スケジュールを策定。

アプリのバージョンアップ、再構築のタイミング、HWの保守切れなどのタイミングにあわせる事も考えられる。

システム 重要度移行

難易度コスト効果

移行優先度

A ◎ △ ◯ ◯

B △ ◎ ◎ ◎

C ◯ × × ×

・・・ ・・・ ・・・ ・・・ ・・・

移行

移行方式

「仮想マシンのコピー」で一括移行

「システム移行」と「データ移行」の2段階に分けて移行

システム移行

本稼働

システム移行

本稼働

システム移行

本稼働

移行本番稼働

事前調査

トレーニング

PoC

AWS基本設計

移行プラン策定

以下のような場合は2段階に分けて移行が望ましい

• データ量がかなり多い

• サービス停止期間を最小化したい

• 「仮想マシンのコピー」後に必要な変更作業が多い

移行

「仮想マシンのコピー」で一括移行の流れ

事前作業

1. 「仮想マシンのコピー」して、変更作業

2. 動作テスト

本番切替

1. 既存環境停止

2. 再度「仮想マシンのコピー」して、変更作業

3. 動作テスト

4. 切り替え2回目以降を差分のみにできるのは

AWS Server Migration Service

移行

システム移行 と データ移行 の2段階に分けて移行の流れ

事前作業

1. 「システム移行」作業

2. データの初期コピー

3. 動作テスト

本番切替

1. 既存環境停止

2. 差分データ同期

3. 動作テスト

4. 切り替え

Amazon Snowball

データ量が多い時は

AWS Database Migraion Service

データベースを差分同期するには

「 」 「 」

AWS Server Migration Service

Server Migration Service (SMS)

オンプレミスにある仮想マシンをAWS上にコピー

導入後の操作はAWSマネージメントコンソールやCLIから

ダウンタイムを最小化

作成されるS3やEBSスナップショットの料金のみで利用可

他のツールとの比較（VMware環境の場合）

VM Import(AWS CLI)

AWS Management Portal for vCenter (vCenterプラグイン)

Server Migration Service (SMS)

オンラインでのイメージ取得

△(クローンしてからエクスポートする事で無停止）

○(2016.9のバージョンより）

○

差分コピー × × ○

対応環境古いバージョンのESXやrawフォーマットなども

vCenter 5.1以降 ESXi 5.1以降vCenter 5.5以降

その他のメリット

VMware環境にインストール不要

EC2の管理をvCenterからも可能に

利用の流れ

オンプレミス環境

インターネット

ハイパーバイザー

VM

VM

VM

VM

VM

VM

VM

VM

AWSリージョン

VGW

IGWDirect Connect

SMS

①②③が12〜24時間ごとに繰り返される (最大 90日)

EC2

EC2を作成

③ AMIに変換

AMI

ServerMigrationConnector

VM

Connectorの導入

② スナップショットの差分を送信

① ハイパーバイザでのスナップショット

Step 2

Step 3

Step 4

SMSの要件対象仮想マシン

• Windows 32/64 bit OS (2003-2016 Server, 7, 8, 10)

• Linux 64 bit OS (RHEL/CentOS 5.1-, SUSE 11-, Ubuntu 12-)

• 推奨事前設定⎼ CD-ROMドライブの切断

⎼ アンチウイルスソフトの無効化

⎼ RDPなどの許可設定

動作環境

• VMware: vCnter 5.5以降, ESXi 5.1以降（Hyper-V は未サポート）

• インターネット接続（Proxy対応あり）

© 2015, Amazon Web Services, Inc. or its Affiliates. All rights reserved.

大規模データのクラウドへの移行

クラウドへのデータ移行のモチベーション

• ワークロード移行

• クラウドオフローディング

• ハイブリッド化

• データセンター移行

• アーカイビング

• BCP/DR

Cloud Data Migration

Direct ConnectSnow* data transport

family

3rd Party Connectors

TransferAcceleration

StorageGateway

Kinesis Firehose

AWSのストレージサービス

オブジェクト

Amazon GlacierAmazon S3

ブロック

Amazon EBS (persistent)

Amazon EC2 Instance Store

(ephemeral)

ファイル

Amazon EFS

AWSへのデータ移行とAWSサービス

AmazonS3

AWS Direct Connect S3 Transfer Acceleration Kinesis Firehose AWS Storage Gateway

AWS Snowball

Amazon EC2

Amazon EFS

Amazon Redshift

Amazon ES

AWS DMS

AmazonRDS

大量データ移行はS3を経由するのが一般的

クラウドへのデータ移行の課題

クラウドへのデータ移行における課題

• 基本はネットワーク経由

• 移行期間と回線帯域• 全ての帯域がデータ移行に利用できるとは限らない

• 一時的な回線増強が非現実的な場合もある

• データ容量が多ければ多いほど深刻な問題に

回線速度

占有率 1Gbps 500Mbps 300Mbps

25% 19 38 63

50% 9 19 32

75% 6 13 21

50TBのデータ転送にかかる日数

回線速度

占有率 1Gbps 500Mbps 300Mbps

25% 95 190 316

50% 47 95 158

75% 32 63 105

250TBのデータ転送にかかる日数

AWS Snowball

AWS Snow ファミリー

Snowball Snowball Edge Snowmobile

ペタバイトスケールのデータ移行

ハイブリッド/エッジワークロードのためのコンピュート&ストレージ

エクサバイトスケールのデータ移行

PRIVATE PREVIEW in TOKYO

AWS Snowball

「ハードウェアアプライアンス」を利用してオンプレミス−クラウド間の大量データ移行を高速化

• 80TBの容量をもつ物理アプライアンスを配送• オンプレミス−クラウド間の回線に依存しないデータ転送を実現

S3

Snowballの利用の流れ(Importの例)

コンソールでジョブの作成

届いたアプライアンスをネットワークへ接続

データをコピーして返送

データはS3に保管

(参考)50TBの転送にどれ位時間がかかるのか？

• ジョブのサブミット• 出荷までに1営業日

• 配送業者による配送• 翌々日配達

• (お客様による)Snowballの受け取り• データの転送• 配送業者による集荷

• 翌日 or 翌々日配達

• (AWS側での)Snowball の受け取り• AWS側のIngest開始に1営業日• SnowballからS3への転送は1日から2日

回線速度

占有率 1Gbps 500Mbps 300Mbps

25% 19 38 63

50% 9 19 32

75% 6 13 21

ネットワーク経由(再掲)

理想的なケースでは運搬も含めて1週間ー10日程度

Snowballを利用するケース

複数のSnowball アプライアンスを利用した並列転送も可能

AWS Snowballのユースケース

クラウドマイグレーション

災害対策 データセンター統廃合

コンテンツ配信

全社ファイルサーバのバックアップ全社員が利用する共有ファイルサーバ上のデータをクラウド環境へバックアップ

• 数百TB、1億超のファイルをS3へバックアップ

• 複数のSnowballを活用し、初期移行の転送期間を短縮

• 変更をトラッキングして更新差分を同期

• 低頻度アクセスストレージを活用し、コールドデータの保管コストを削減

Snowballお客様事例 サイバーエージェント様

共有ファイルサーバ

Amazon S3S3

Standard - IA

更新トラッキング

更新差分転送

ライフサイクル管理

Amazon SQS

差分更新ジョブ管理

初期移行

Snowballお客様事例 AOSデータ様

バックアップサービス拡張• 自社提供SaaSサービスの拡張オプションとしてSnowballの活用を検討中

• AOSBOX へネットワーク経由のバックアップ時間を短縮

• Snowball による安全なオフラインバックアップサービスを提供

Amazon Glacier

importAWS Snowball

利用者

Amazon

S3データ転送

AmazonS3

AOSBOXの利用にあたり、数TB〜以上のオフィスデータ、RAWデータ、動画データをネットワークなし＆セキュアに高速転送

http://www.aosbox.com/snowball/

Snowballお客様事例 レコチョク様

メディアコンテンツ移行・配信

Amazon S3の活用により、NAS・HDDで保管していた楽曲を安全且つ耐久性のある環境へ移行

• Snowballを利用して60TBの音源データを社内環境からインポート

• 約10日間で移行を完了

• インターネットを経由しないデータの移動

Amazon S3

自社特設環境 提供先

AWSSnowball

提供元

業務アプリケーション移行大量データを扱う複数の業務アプリケーションのクラウド移行にSnowballを活用

• コンテンツ配信、ログ解析システムをAWS上に移行

• オンプレミス環境から約60TBのデータをS3へ

• HDFSクライアントの利用により、中間データを生成せずに効率的に移行

• 接続先切り替えによりシームレスなシステム移行を実現

Snowballお客様事例 ドワンゴ様

HDFS

Amazon S3

データ移行

アプリケーション移行コンテンツ配信

Amazon EMR

ログ解析

Tokyo Region

創薬分子シミュレーション化合物とタンパク質における薬物ドッキング、スクリーニングシミュレーション

• 数千コアを時間課金で利用

• 50TBのRawデータをSnowballにてセキュアに転送

• クラスタ構築はAWS提供の CfnClusterで迅速に展開

• アプリケーションにmyPresto(※)を利用

Spot InstanceResearchers

AWS Direct Connect

Masterserver Auto Scalling group

Compute Fleet

AWSSnowball

S3

On-premise

Snowballお客様事例 エーザイ様

※ http://www.jbic.or.jp/enterprise/result/001.html

Snowball利用のポイント

ネットワーク移行とどちらが早いか？• データの特性・容量に依存(数十TB以上が検討範囲)

• 輸送・設置・撤去のリードタイムを考慮

データの移行先はS3

• 最終的な配置先、データ形式が異なる場合はその移動時間も考慮• イメージでコピーしてVM import

• S3からEBS/EFSへのデータコピー• AWS LambdaやFile Gatewayを活用

オフライン転送• 輸送中の更新差分は別途移行する必要がある

まとめ

まとめ

移行のためのソリューション

AWS Server Migration Service (SMS)→ 仮想マシン移行のダウンタウンを短縮

Amazon Snowball→ セキュアかつ迅速なクラウドへの移行が可能

AWS Database Migration Service→ TechTrack 1: 本日 18:20〜

シンプルなクロスプラットフォーム、最小のダウンタイムで実現するクラウド移行

AWS ソリューション Day 2017- Database Day~「クラウドへのデータベース移行」と「データレイクを軸としたビッグデータ活用」~

Database Dayとは？

ユーザー企業/パートナー/AWSによる導入事例や活用動向また技術情報をご紹介するIT部門（エンジニア・管理者など）向けのカンファレンス

開催日時・会場

• 2017年7月5日(水) 10:00~17:30 （9:30開場予定）

• 大崎ブライトコアホール（JR大崎駅より徒歩5分）

セッション

基調講演 と 2トラックのブレイクアウトセッション

トラック１：データベース移行 （事例セッションあり）

トラック２：データレイク（JAWSUG-BigData支部 事例セッションあり） URL

Thank you.