アイレット株式会社

転換期を迎えるいま、 『オンプレミスからのマイグレーション』における勝利の方程式とは

AWS Summit Tokyo 2017

後藤 和貴fb.com/kaz.goto

@kaz_goto

執行役員 / エバンジェリスト

☁ アイレット株式会社 執行役員 • cloudpackエバンジェリスト • マーケティングコミュニケーション • デザインチーム、動画サービス開発

AWSを活用しながら お客さまはビジネスに集中できる

コンシェルジュサービス

24時間365日

定額課金/ 請求書払い

Pマーク、ISMS、PCI DSS、SOC2レポート取得済みの運用体制

監視運用保守

企業 AWS

プレミアコンサルティングパートナー

全世界で55社アジア地域7社

最上位パートナーcloudpackは5年連続認定Premier > Advanced > Standard > Registered

認証・セキュリティの取り組み

＋セキュリティルーム※写真はイメージです

120+

クラウド 導入事例

※ 2017年5月時点

マイグレーションニーズの高まり

出典：ITRhttps://japan.zdnet.com/article/35097600/

運用形態別ERPパッケージ市場規模推移と予測

ERP市場、2020年にクラウドが オンプレミスを追い抜く

出典：IDC Japanhttp://www.idcjapan.co.jp/Press/Current/20161207Apr.html

国内データセンターサービス市場 売上額予測、2015年～2020年

国内データセンター市場 クラウド型ホスティングの伸びが目立つ 2017年に従来型ホスティング追い抜く

これまでの移行方式

一般的な移行の進め方☁ 評価

• 既存システム調査

• 環境アセスメント

☁ 検証 • 移行方式選定

• 移行方法・ツールなど検証

☁ 移行 • 本番移行

• アプリケーション調整

こんな単純な話ではなく さまざまな課題がでてくる…

マイグレーションでの課題

1. 現行システムの調査 ・業務ドメイン調査 ( 業務要件 ) ・ライセンス ・ネットワーク ・サービス単位 ・システム連携 ・サーバー単位 　- OS 　- サービス 　- CPU / MEM / ディスク容量 　- 性能

2. AWS 制約確認 ・移行可能 OSバージョン ・利用可能 IP ・移行可能ライセンス ・システム要件　- クラスタ構成　- RAC構成　- ハードウェア依存システム ( IODrive 等 )

3. 環境アセスメント ( 事前影響評価 )

4. 移行対象サーバー・サービスの確定

5. 移行ツールの選定 ・VM Import / その他サードパーティ製品

6. 移行方針の確定 ・データ移行 ・ネットワーク移行 ・現行踏襲 / 新規作成・データ移行のみ ・並行稼動移行 / スイッチ移行　 (一定期間業務停止)

7. 要件定義 ・移行要件定義 ・システム毎要件定義 ・テスト要件定義 ・運用要件定義

8. 設計 ・AWS インフラ設計 ・移行設計（切り戻し可能な設計） ・サーバー設計 　- インスタンスタイプ 　- 性能 ・システムテスト設計 ・性能テスト設計 ・運用設計

9. AWS 実装 10. テスト 11. システム移行

形式としてのパターンはできているが…

情報システム部門視点

☁ ハードウェアの保守契約が切れるから、サーバーリプレイスかクラウド移行が必要

☁ ハードウェアの保守をしなくてもよくなくなる、可用性が高まる、DR環境も構築しやすい、などのメリットが得られるからAWSに移行したい

☁ 移行後に運用フローが大きく変わると、負荷も運用コストも上がるので、できれば大きな構成変更は避けたい

経営者視点

☁ 置き場所が変えるだけで、なぜそんなにコストがかかるのか？

☁ 可用性やパフォーマンスが向上しても利益には直結しないのに、なぜコストをかけて移行するのか？

☁ （DRで使う場合）災害対策の重要性は理解しているが、発生確率不明なものに高いコストはかけられない！

手順やスケジュールでの悩みも…

オンプレミス環境 AWS環境

物理・仮想環境から多くのサーバー群を 最適に移行する方法がわからない

事前準備や移行作業に時間・手間が かかりすぎて計画通り進まない…

移行のたびに大量のデータが 転送され帯域を圧迫する

いかに適切な計画を立て、 かつ計画通りの時間とコストで移行できるかが鍵

クラウド全盛期のマイグレーション

検証環境利用→最適な本番移行

出典: エンタープライズAWS導入ガイド 第一版 http://aws.typepad.com/aws_ japan/2015/01/apn_partners_aws_guide.html

ケンコーコム様の課題・導入背景

☁ 2009年よりAWS試験導入 ☁ 2011年 東日本大震災がきっかけ ☁ 安定的な事業運営のために

システムのクラウド化を計画 • 50台以上のサーバー群をクラウドへ

• 本社機能の一部を福岡へ移転出典 http://www.sbbit.jp/article/cont1/26061

ケンコーコム様の実施方法

☁ 2011年 AWSへの移行を開始 • 自社ECサイト（PC/モバイル/スマホ）

• モール上支店連携システム

• 在庫管理システム • ドロップシップ販売管理システム

☁ 2012年 SAP ERP • 当時AWSがプラットフォーム認定されてなかったが

将来の二重投資を回避するために当初からAWS移行対象に

ケンコーコム様 事例のポイント

☁ クラウドならではのSAP環境移行方法 1. 開発環境構築後にサーバーをコピー

➡ 複数のテスト環境構築しテストを並列実行

2. サーバーを占有するデータ移行リハーサル ➡ テスト環境と別インスタンスを作成 ➡ 環境の準備で開発が滞るような状況を回避

3. データ移行本番時 ➡ サーバー性能を一時的に上げて処理時間を短縮

Copyright © 2013 Kenko.com All Rights Reserved. Confidential

� 稼動前はテスト、リハーサル、データ移行が重なる環境負荷が⾼い時期

実現化フェーズ テスト・移行フェーズ 稼働後支援フェーズ

1 2 3 4 5 6 7 8

設計 〜テスト

移行

結合テスト 総合テスト

ﾕｰｻﾞｰﾃｽﾄ

設計・開発・単体テスト

移行Ｔ１

移行Ｔ２

移行リハ

本番移行①

本番移行②

本番移行③

並行テスト

結合Ｔ仕様

テスト計画

総合Ｔ仕様

並行Ｔ仕様 ﾕｰｻﾞｰT仕様

性能・負荷テスト

障害テスト

システム運用テスト

テスト仕様

テスト仕様

テスト仕様

★GoingLiveCheck

移行設計・開発（SAP） 移行スケジュール詳細化

/移行手順書作成

移行設計・開発（周辺）

データクレンジング

AWSとオンプレミスとの対比 （参考）

15

総合テスト、移行と並行稼働テスト

業務に支障なく短時間で実施

出典『ケンコーコムを支えるECシステム/SAP ERPのAWSクラウド化』 http://d36cz9buwru1tt.cloudfront.net/jp/summit2013/documentation/awssummit2013_kenkocom.pdf

移行ツールの使用により 技術やスケジュールの不安を解消

オンプレミス環境 AWS環境

物理・仮想環境から多くのサーバー群を 最適に移行する方法がわからない

事前準備や移行作業に時間・手間が かかりすぎて計画通り進まない…

移行のたびに大量のデータが 転送され帯域を圧迫する

専用ツール導入により、業務単位の移行や 移行順番の制御などが可能に

エージェント導入＆Firewall設定のみ 移行作業はcloudpackが実施 スケジュール影響も最小化

初回移行時は全体、次回以降は差分のみ 転送して帯域圧迫を防ぐ

サーバー移行ツール

AWS Server Migration Service

AWS Server Migration Service☁ 概要

• VMware仮想マシンをAWSに移行可能

• VMware vCenter環境毎にAWS Server Migration Service Connectorをインストールし、AWS コンソールから移行操作

• 移行後はAMIが作成される

☁ 移行作業の流れ 1. VMware vCenter環境にAWS Server Migration Service Connectorをインストール

2. AWSコンソールにて移行パラメータ設定

3. AWSコンソールから移行ジョブスケジュール及び実行

4. 作成されたAMIからEC2インスタンスを作成

5. 各種アプリケーション動作テスト

AWS Server Migration Service構成例

��������VMware vCenter

IA E I2 M

M C M

AMI

AWS SMS Connector

tcp443

CloudEndure☁ 概要

• SaaSでの提供

• 物理/仮想サーバーをAWSに移行可能 • 移行対象サーバーにエージェントをインストールし管理コンソールから移行操作

• 移行後EC2インスタンスが直接起動

☁ 移行作業の流れ • 移行対象サーバーへエージェントインストールおよびファイアウォール設定変更 • 管理コンソールにて移行パラメータ設定

• 管理コンソールから移行テストおよびアプリケーション動作テスト実施 • 本番移行実施

• 必要に応じて差分同期されたEC2インスタンスを起動

CloudEndure構成例

�����中間

サーバー

Racemi DynaCenter☁ 概要

• 物理/仮想サーバーをAWSに移行可能

• 移行対象サーバーにエージェントをインストールし、管理コンソールから操作

• 移行後EC2インスタンスが直接起動

☁ 移行作業の流れ 1. 移行対象サーバーへエージェントインストールおよびファイアウォール設定

変更

2. 管理コンソールにて移行パラメータ設定

3. 管理コンソールから移行実施

4. 各種アプリケーション動作テスト

5. 必要に応じて差分同期実施

Racemi DynaCenter構成例

Racemi���VPC��DC�

��VPC

2

2

D CP

R VE

DAV depot(Racemi��� �)

N2 2

tcp443

tcp443

ツール比較Server Migration Service Racemi DynaCenter CloudEndure

概要

サーバーのイメージを作成しAMIとして移行する。VM Import/Exportの拡張版としての位置付け。操作は管理コンソールから実施。

サーバーのイメージを作成し、それを基に直接EC2を作成する。操作は管理サーバーのWebコンソールから実施。

サーバーのイメージを作成しそれを中間サーバーのEBSに配置する。対象EBSのスナップショットを作成してそれからEC2を作成する。操作は管理サーバーのWebコンソールから実施。

適した用途 サーバー移行、簡易型DR サーバー移行、DRサイトとの永続的な同期

サーバー移行、簡易型DR

移行容易性

◎ 移行対象環境に管理用仮想アプライアンスを導入すればエージェントレスで移行可能。作業は簡単。

◎ 移行対象サーバーにエージェント導入して移行する。作業は簡単。

◎ 移行対象サーバーにエージェント導入して移行する。作業は簡単。

東京リージョン 使用可否

◎ 東京リージョンはサポート対象。いくつか未サポートのリージョンあり。

◎ 東京リージョンはサポート対象。いくつか未サポートのリージョンあり。

◎ リージョンに制約なし

サポート

◎ AWSサポートを利用可能。日本語対応。

△ 8-17 EST（22-7am JST(サマータイム時: 21-6am JST)）日本語対応なし。メールベース。特別対応は別途費用。

△ 8-17 EST&EET（22-7am, 15-24 JST(サマータイム時: 21-6am , 14-23 JST)）日本語対応なし。メールベース。特別対応は別途費用。

諸費用

○ S3、EBSスナップショットの使用料がかかる。作業費は管理用仮想アプライアンスの導入が大半。

◎ 移行対象サーバーへのエージェント導入費用が大半。ツール利用料は$299/台。利用条件あり。

○ サービス利用料は$400/台。エージェント導入作業と中間サーバーの利用料金がかかる。

留意事項☁ 移行時のアプリケーション停止時間

• どの移行方法でも停止時間０で移行することはできない

• 特にDBでは静止点を取るために停止が前提

☁ 移行時間 • サーバースペックやネットワーク帯域等に依存するため、本番移行に

必要な時間は検証フェーズで計測及び検討必須

☁ サービス対象範囲 • 各種ツールのサポートするOS・バージョンと前提条件が異なる

• 移行後、アプリケーション、ミドルウェア、OSのパラメータ調整は別途行う必要あり

その他の要素

回線・データ伝送方法

☁ AWS Direct Connect • 例: クラウドゲートウェイアプリパッケージ

☁ インターネットVPN ☁ その他

• Amazon S3 Transfer Acceleration

• AWS Snowball

• AWS Snowmobile

その他の移行ツール

☁ データベース移行 • AWS Database Migration Service

• Attunity

• Infoteria ASTERIA WARP

☁ ファイル移行 • AWS Storage Gateway

• Amazon EFS

お客様事例

近畿大学様の課題・導入背景

☁ 2014年に一部をAWS移行 • 教育系システムでクラウド移行を経験済

• メールなども他社のSaaSで運用中

☁ 3年をかけてすべての業務システムをクラウドへ ☁ 可用性・セキュリティ・コストを重要視

• AWSはIaaSサービス提供者の中で、商用サービスの導入実績が多く、運用機能も多く存在

• 1社で対応できるセキュリティと比べて安心で高機能な設計

• コストはオープンで見えやすく、フレキシブルなため最適化しやすい

近畿大学様の実施方法

☁ 初期構築：クラウドのメリットを活かす • 調達/設定/インストールのスピードが圧倒的に速い

• 監視/運用の仕組みをクラウド専業のパートナーに任せて最適化

☁ 運用手法：変わらず、しかし… • アプリレベルでは、オンプレ/クラウドでほぼ変更なし

• トラブル時の対処手段は、AWSの方が圧倒的に多く解決がしやすい（例: ディスクの読み書き性能を上げる）

• テスト/ステージング環境を自由に作って、いつでも捨てられる

☁ 体制変更：大きく変えずに • 業務の専門家としての既存SIerは変更しない

• インフラ部分でクラウドの専門家に参画してもらう

近畿大学様 事例のポイント

☁ クラウド反対派はゼロ • 可用性とセキュリティはキチンと説明

• コストは10年間で比較

☁ 業務要件は既存体制 • 業務システムをスムーズにクラウドへ

移行させるなら、既存SIerは必須＝協業

☁ スペック変更が導入後も可能 • 移行前にサイジングはしっかりやっていたが、

変更が必要なときにはすぐ対応できる環境 23

出典 http://www.isit.or.jp/event/files/2015/11/f1b0d2a1c1244c6f540afc8ed4941630.pdf

マイグレーションの勝利の方程式

Migration = A x（B + C）

適切なゴール設定 •優先度 •移行計画

業務に精通した SIベンダー（既存）

AWSに精通した ベンダー（ （

AWSの 目利き

まとめ：マイグレーションの勝利の方程式

☁ クラウドらしい環境準備方法を導入 • 必要なときのみ検証環境を準備 • 移行時のみサイジングなども可能

☁ 移行に最適なツール・移行方式を選択する • 移行元環境、セキュリティ設定、コスト

☁ 業務レイヤーとインフラ担当の協業体制 • 業務・サーバー群毎に達成したいゴールを定める • 優先度を定めて、順次移行へ

移行支援サービスmigrationpack

cloudpackがお客様のオンプレミス環境の AWS移行をサポート

オンプレミスからAWSへの環境移行する際に存在する、インフラ構成の合理性、既存アプリケーションの動作、運用手順・障害対策など、様々な検討事項をcloudpackが強力にサポートします。さらに不要になったハードウェア買い取りまでも行い、無駄なコストの排除も実現。

5月31日発表

migrationpackサービス5月31日発表

AWS移行を成功に導くcloudpackパートナー5月30日発表