410 Views
June 23, 17
スライド概要
2017.6.23に行われたインフォテリア、AWS、共同セミナーでの講演資料。Summitの内容にASTERIA WARP Coreの事例を加えています。
2017.6.23 『オンプレミスからのマイグレーション』における 勝利の方程式とは アイレット株式会社
☁ アイレット株式会社 執行役員 執行役員 / エバンジェリスト 後藤 和貴 fb.com/kaz.goto @kaz_goto • cloudpackエバンジェリスト • マーケティングコミュニケーション • デザインチーム、動画サービス開発
2003年10月15日 資本金 7,000万円 代表取締役社長 齋藤 将平 従業員数 184名 拠点 東京・大阪・名古屋 設立 システム開発事業 cloudpack事業 IoT開発事業
AWSを活用しながら お客さまはビジネスに集中できる コンシェルジュサービス
24時間365日 監視運用保守 企業 定額課金/ 請求書払い AWS Pマーク、ISMS、PCI DSS、SOC2レポート取得済みの運用体制
プレミアコンサルティングパートナー 全世界で55社 最上位パートナー Premier > Advanced > Standard > Registered アジア地域 7 社 cloudpackは5年連続認定
クラウド 導入事例 120+ ※ 2017年6月時点
マイグレーションニーズの高まり
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環境
いかに適切な計画を立て、 計画通りの時間とコストで移行できるかが鍵
クラウド全盛期のマイグレーション 〜サーバー to サーバー〜
検証環境利用→最適な本番移行 出典: エンタープライズ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仕様 結合テスト 総合テスト、移行と並行稼働テスト 総合T仕様 総合テスト 設計 〜テスト テスト計画 テスト仕様 並行T仕様 並行テスト ユーザーT仕様 ユーザーテスト 性能・負荷テスト テスト仕様 障害テスト テスト仕様 移行設計・開発(周辺) 移行 移行設計・開発(SAP) 移行スケジュール詳細化 /移行手順書作成 移 行 T 1 移 行 T 2 システム運用テスト 移 行 リ ハ 本 番 移 行 ① 本 番 移 行 ② 本 番 移 行 ③ データクレンジング 業務に支障なく短時間で実施 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/台。エージェン ト導入作業と中間サーバーの利用料金 がかかる。 サポート 諸費用
留意事項 ☁ 移行時のアプリケーション停止時間 • どの移行方法でも停止時間0で移行することはできない • 特にDBでは静止点を取るために停止が前提 ☁ 移行時間 • サーバースペックやネットワーク帯域等に依存するため、本番移行に 必要な時間は検証フェーズで計測及び検討必須 ☁ サービス対象範囲 • 各種ツールのサポートするOS・バージョンと前提条件が異なる • 移行後、アプリケーション、ミドルウェア、OSのパラメータ調整は別 途行う必要あり
クラウド全盛期のマイグレーション 〜データ、ファイル、etc〜
回線・データ伝送方法 ☁ 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
データ分析基盤構築サービス データ連携 BIツール DWH Amazon QuickSight Amazon Redshift インフラ構築・運用をcloudpackが提供
ASTERIA WARP SQHMDQQ ogc x N i d l RENPL s v .) fgc HBPNQNER WM LHBQ DQENPBD k eq HBPNQNER -VBD HBPNQNER G PD NHMR )BRHTD HPDBRNPW 1 NRDQ NLHMN JHMRNMD /NNF D uzo y 1 3) .6 k y NPJDP ) - 6P B D - NOS PJDRN /NNF D )M WRHBQ /NNF D )C NPCQ MQ M S NM P - 1 1 PD AD S P SL -) 2. H - mwd l r o . BDANNJ DPT)HP 0 x s uktg LHIHM Zwk o w ( r yfgc uy 6 k 0 1 ) n t mwd l be 0 1 ) 1 . . 0 3 ) ulx s )L XNM DCQGHER /NNF D 1 SPD R 6P B D R A QD HBPNQNER 3 DPTDP 1 W 3 NQRFPD 3 PH )XSPD 3 R A QD )L XNM WM LN )L XNM )SPNP HBPNQNER )BBDQQ .H D JDP NMFN 6) 6 HRRDP 3 e 3 . 1 - - )1 - h uy 1 1 / 1 - k fz 2 6 wj y )L XNM DA DPTHBDQ HBPNQNER )XSPD a k fz NSCM HF SDPW
Amazon RedshiftをDWHに活用 ☁ 特長 • データウェアハウス特化・高速DB • 列指向型(カラムナ) • ペタバイト級までスケールアウト • フルマネージドデータベース • PostgreSQL互換(各種ツール利用可能) Amazon Redshift • 最小 $0.314/時間〜スタート可能
ユースケース 施設への来店者の動線データ活用 ☁ 来店者のスマートフォンを使用 ☁ 施設内のスマートフォン接続情報を収集 ☁ 来店者の動線情報を分析 ☁ 33.8万台のスマートフォン(1ヶ月分) ☁ 3,500万件のログデータ(1ヶ月分) ☁ 10GB(1ヶ月分)※圧縮2GB
ASTERIA WARP Core→ Amazon Redshift Amazon Redshift
Amazon Redshift → BIツール Amazon QuickSight Amazon Redshift
Amazon Redshift → BIツール Amazon QuickSight Amazon Redshift
実際のシステム構成 お客様拠点 必要なデータの 収集 インフラ運用 各種業務システム • スケールアウト • システム監視 • バックアップ EC2 フロー作成 データ吐き出し データ取得 コピーコマンド 実行 管理者端末 Tableauや QuickSightなどの ツール 増え続ける データ Redshift運用 分析データ配信 分析者端末 S3 Redshift 読み込み・更新 分析・閲覧 • DBパフォーマンス • チューニング • テーブル分割
お客様事例
近畿大学様の課題・導入背景 ☁ 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パートナー 表
cloudpackのノウハウが網羅されたホワイトペーパー NEW