転換期を迎えるいま、 『オンプレミスからのマイグレーション』における勝利の方程式とは - AWS Summit Tokyo 2017
>100 Views
June 13, 17
スライド概要
AWS Summit Tokyo 2017で講演した資料。
関連スライド
各ページのテキスト
AWS Summit Tokyo 2017 転換期を迎えるいま、 『オンプレミスからのマイグレーション』における勝利の方程式とは アイレット株式会社
☁ アイレット株式会社 執行役員 執行役員 / エバンジェリスト 後藤 和貴 fb.com/kaz.goto @kaz_goto • cloudpackエバンジェリスト • マーケティングコミュニケーション • デザインチーム、動画サービス開発
AWSを活用しながら お客さまはビジネスに集中できる コンシェルジュサービス
24時間365日 監視運用保守 企業 定額課金/ 請求書払い AWS Pマーク、ISMS、PCI DSS、SOC2レポート取得済みの運用体制
プレミアコンサルティングパートナー 全世界で55社 最上位パートナー Premier > Advanced > Standard > Registered アジア地域 7 社 cloudpackは5年連続認定
認証・セキュリティの取り組み ＋セキュリティルーム ※写真はイメージです
クラウド 導入事例 120+ ※ 2017年5月時点
マイグレーションニーズの高まり
ERP市場、2020年にクラウドが オンプレミスを追い抜く 国内データセンター市場 クラウド型ホスティングの伸びが目立つ 2017年に従来型ホスティング追い抜く 運用形態別ERPパッケージ市場規模推移と予測 国内データセンターサービス市場 売上額予測、2015年～2020年 出典：ITR https://japan.zdnet.com/article/35097600/ 出典：IDC Japan http://www.idcjapan.co.jp/Press/Current/20161207Apr.html
これまでの移行方式
一般的な移行の進め方 ☁ 評価 • 既存システム調査 • 環境アセスメント ☁ 検証 • 移行方式選定 • 移行方法・ツールなど検証 ☁ 移行 • 本番移行 • アプリケーション調整
こんな単純な話ではなく さまざまな課題がでてくる…
マイグレーションでの課題
形式としてのパターンはできているが… 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. データ移行本番時 ➡ サーバー性能を一時的に上げて処理時間を短縮
AWSとオンプレミスとの対比 （参考） 稼動前はテスト、リハーサル、データ移行が重なる環境負荷が⾼い時期 実現化フェーズ 1 2 テスト・移行フェーズ 3 4 5 6 稼働後支援フェー ズ 7 8 ★GoingLiveCheck 設計・開発・単体テスト 結合Ｔ仕様 結合テスト 総合テスト、移行と並行稼働テスト 総合Ｔ仕様 総合テスト 設計 〜テスト テスト計画 テスト仕様 並行Ｔ仕様 並行テスト ﾕｰｻﾞｰT仕様 ﾕｰｻﾞｰﾃｽﾄ 性能・負荷テスト テスト仕様 障害テスト テスト仕様 移行設計・開発（周辺） 移行 移行設計・開発（SAP） 移行スケジュール詳細化 /移行手順書作成 移 行 Ｔ １ 移 行 Ｔ ２ システム運用テスト 移 行 リ ハ 本 番 移 行 ① 本 番 移 行 ② 本 番 移 行 ③ データクレンジング 業務に支障なく短時間で実施 Copyright © 2013 Kenko.com All Rights Reserved. Confidential 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構成例 M C M AWS SMS Connector IA E M I2 tcp443 AMI VMware vCenter
CloudEndure ☁ 概要 • SaaSでの提供 • 物理/仮想サーバーをAWSに移行可能 • 移行対象サーバーにエージェントをインストールし管理コンソールから移行操作 • 移行後EC2インスタンスが直接起動 ☁ 移行作業の流れ • 移行対象サーバーへエージェントインストールおよびファイアウォール設定変更 • 管理コンソールにて移行パラメータ設定 • 管理コンソールから移行テストおよびアプリケーション動作テスト実施 • 本番移行実施 • 必要に応じて差分同期されたEC2インスタンスを起動
CloudEndure構成例 中間 サーバー
Racemi DynaCenter ☁ 概要 • 物理/仮想サーバーをAWSに移行可能 • 移行対象サーバーにエージェントをインストールし、管理コンソールから操作 • 移行後EC2インスタンスが直接起動 ☁ 移行作業の流れ 1. 移行対象サーバーへエージェントインストールおよびファイアウォール設定 変更 2. 管理コンソールにて移行パラメータ設定 3. 管理コンソールから移行実施 4. 各種アプリケーション動作テスト 5. 必要に応じて差分同期実施
Racemi DynaCenter構成例 2 tcp443 VPC D C 2 P N tcp443 2 2 DAV depot (Racemi ) R DC E Racemi V VPC
ツール比較 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） AWSの 目利き （ 適切なゴール設定 •優先度 •移行計画 業務に精通した SIベンダー（既存） AWSに精通した ベンダー
まとめ：マイグレーションの勝利の方程式 ☁ クラウドらしい環境準備方法を導入 • 必要なときのみ検証環境を準備 • 移行時のみサイジングなども可能 ☁ 移行に最適なツール・移行方式を選択する • 移行元環境、セキュリティ設定、コスト ☁ 業務レイヤーとインフラ担当の協業体制 • 業務・サーバー群毎に達成したいゴールを定める • 優先度を定めて、順次移行へ
移行支援サービス migrationpack
発 表 オンプレミスからAWSへの環境移行する際に存在する、インフラ構成の合理 性、既存アプリケーションの動作、運用手順・障害対策など、様々な検討事項 をcloudpackが強力にサポートします。さらに不要になったハードウェア買い取 りまでも行い、無駄なコストの排除も実現。 日 31 5月 cloudpackがお客様のオンプレミス環境の AWS移行をサポート
発 日 31 5月 migrationpackサービス 表
発 日 30 5月 AWS移行を成功に導くcloudpackパートナー 表