業務システムのクラウド移行は現実的なのか？ 〜事例から紐解くクラウド時代の失敗しないIT投資とは〜
317 Views
July 26, 16
スライド概要
2016.7.26に行われた日経産業新聞フォーラムにて、業務システムのクラウド移行が現実的かについて事例を元にエッセンスと失敗しない手法についてお話しました。
関連スライド
各ページのテキスト
業務システムのクラウド移行は現実的なのか？ 〜事例から紐解くクラウド時代の失敗しないIT投資とは〜 アイレット株式会社 cloudpack事業部 執行役員 後藤和貴
アジェンダ ☁ cloudpackについて ☁ 企業のIT投資とクラウド利用の現状 ☁ クラウド移行事例3パターン ☁ まとめ:事例から導かれるクラウド移行 の成功パターン
について
執行役員 / エバンジェリスト 後藤 和貴 @kaz_goto
☁ cloudpack事業 執行役員 • エバンジェリスト • マーケティング担当（PR、ウェブ…） ☁ バックグラウンド 執行役員 / エバンジェリスト 後藤 和貴 @kaz_goto • Oracle カスタマーサポート→開発 • ビジネス・アーキテクツ • テクニカルディレクター（フリーランス）
アイレット株式会社 設立 2003年10月15日 資本金 7,000万円 代表者 齋藤 将平 従業員数 134名（2016年6月現在） 事業内容 システム開発・保守 クラウドインテグレーション マネジドホスティング
AWSを活用しながら お客さまはビジネスに集中できる コンシェルジュサービス
cloudpackビジネス 設計支援 コンサル MSP 運用保守 システム 開発
24時間365日 監視運用保守 企業 定額課金/ 請求書払い Pマーク、ISMS、PCI DSS取得済みの運用体制 AWS
プレミアコンサルティングパートナー 全世界で46社 最上位パートナー Premier > Advanced > Standard > Registered アジア地域 5 社 cloudpackは4年連続認定
6年間AWSのみで運用保守 4社 6年間 600 1200 プロジェクト超 社超
認証・セキュリティの取り組み ＋セキュリティルーム ※写真はイメージです
セキュリティ ホワイトペーパー ☁ 国際・国内セキュリティ基準への 取り組み ☁ ソフトウェア脆弱性情報に関する 取り組み ☁ 業務ネットワークのセキュリティ ☁ 運用上のセキュリティ保持体制
クラウド 導入事例 120 ※ 2016年6月時点
企業のIT投資とクラウド利用の現状
中期経営計画・IT投資のサイクル 3年 サイクル 課題❶ 市場の変化への追従 中期経営計画 5年 サイクル IT投資（オンプレミス） 課題❷ ビジネス転換への追従
経営計画に影響を与えたイノベーション 働き方を大きく変えたスマートデバイス ☁ iPhone 3G発売（わずか8年前） ☁ 新デバイス発表（1年に1度） • 6sまでに8回のモデルチェンジ ☁ 新OS発表（1年に1度） • 現在はiOS 9
経営計画に影響を与えたイノベーション クラウドの雄ーAmazon Web Services ☁ 2006年にAWSスタート（今年で10年） ☁ 2011年に東京リージョン開設 ☁ ニーズに応じた722回の機能追加・改善 ☁ 過去10年で51回の値下げを実施 ☁ アクティブカスタマー100万超
3年 サイクル 課題❶ 市場の変化への追従 中期経営計画 5年 サイクル 課題❷ ビジネス転換への追従 IT投資（オンプレミス） こんなスピード感で競争を優位に戦えますか？
3年 サイクル 課題❶ 市場の変化への追従 中期経営計画 5年 サイクル 課題❷ ビジネス転換への追従 IT投資（オンプレミス） 1ヶ月 サイクル IT投資（クラウド） 市場・ニーズの変化・事業方針転換への スピーディな対応
クラウドへ移行することで得られる利点 ☁ 経営が求める「俊敏さ」が手に入る • インフラ調達に圧倒的なスピード CLOUD • 大量データを扱い、顧客ニーズを瞬時に高い精度で把握 • 『成長』の機会を逃さないIT投資 • 自社よりも高いセキュリティ基準と運用基準 ☁ 運用保守コストの削減（人的リソース含む） ☁ 5年保守サイクルの脱却
AWS Summit Tokyo 2016 Day 2基調講演より, https://aws.amazon.com/jp/summit2016-report/
AWS Summit Tokyo 2016 Day 2基調講演より, https://aws.amazon.com/jp/summit2016-report/
AWS Summit Tokyo 2016 Day 2基調講演より, https://aws.amazon.com/jp/summit2016-report/
AWS Summit Tokyo 2016 Day 2基調講演より, https://aws.amazon.com/jp/summit2016-report/
クラウド移行の事例 3パターン
徹底したPoCで クラウド移行 業務システムの 全面移行 SAPを含む 全システムのAWS移行
トヨタ様の課題・導入背景 ☁ トヨタ様 公式サイト11ドメイン • 月間1億PV、新車発表時3倍 • 開発/ステージング/本番セットで100台以上 ☁ クラウド移行の目的＝コスト削減 • 運用コスト/移行コストいずれも大きくせずに 実行したい ☁ 2010年秋にクラウドサービス調査 • 当初PaaSが最適と結論 • ただし100%要件を満たすクラウドはなかった • 2011年にAWSの東京リージョンが開設され 再検討の上、AWSに決定 出典 http://cloud.watch.impress.co.jp/docs/event/602472.html
トヨタ様の実施方法 ☁ PoC（Proof of Concept）を入念に行う • あらゆる選択肢に対して成果（コスト）を試算 • パブリック vs プライベート • IaaS vs PaaS • 変更なしでアプリ移行可能か • スケーラビリティ規模、などを考慮 ☁ ゴールの明確化 • 課題を「コスト」に一本化してブレない進め方にする
トヨタ様 事例のポイント ☁ 5年間でコスト削減 • 50.9%削減（計画）→ 64.3%削減（実績予定） ☁ クラウド動向は変化が早いため 早期採用リスクに対しプランBを用意 • プランB：あらゆる過程で複数の選択肢をもつ • 万が一、AWSが落ちたときにも… ☁ 未知な領域が大きいので、クラウド経験値の高い パートナーと組む
別ロケーションでの復旧 ☁ 災害時：シンガポールにほぼ自動的に環境構築 ☁ テンプレート（レシピ）から一発で再構築可能 CloudForma*on, Template, Tokyo Region Stack, Singapore Region
近畿大学様の課題・導入背景 ☁ 2014年に一部をAWS移行 • 教育系システムでクラウド移行を経験済 • メールなども他社のSaaSで運用中 ☁ 3年をかけてすべての業務システムをクラウドへ ☁ 可用性・セキュリティ・コストを重要視 • AWSはIaaSサービス提供者の中で、商用サービスの 導入実績が多く、運用機能も多く存在 • 1社で対応できるセキュリティと比べて安心で高機能な設計 • コストはオープンで見えやすく、フレキシブルなため 最適化しやすい
近畿大学様の実施方法 ☁ 初期構築：クラウドのメリットを活かす • 調達/設定/インストールのスピードが圧倒的に速い • 監視/運用の仕組みをクラウド専業のパートナーに任せて最適化 ☁ 運用手法：変わらず、しかし… • アプリレベルでは、オンプレ/クラウドでほぼ変更なし • トラブル時の対処手段は、AWSの方が圧倒的に多く解決がしやすい （例: ディスクの読み書き性能を上げる） • テスト/ステージング環境を自由に作って、いつでも捨てられる ☁ 体制変更：大きく変えずに • 業務の専門家としての既存SIerは変更しない • インフラ部分でクラウドの専門家に参画してもらう
近畿大学様 事例のポイント ☁ クラウド反対派はゼロ • 可用性とセキュリティはキチンと説明 • コストは10年間で比較 ☁ 業務要件は既存体制 • 業務システムをスムーズにクラウドへ 移行させるなら、既存SIerは必須 ☁ スペック変更が導入後も可能 • 移行前にサイジングはしっかりやっていたが、 変更が必要なときにはすぐ対応できる環境 23 出典 http://www.isit.or.jp/event/files/2015/11/f1b0d2a1c1244c6f540afc8ed4941630.pdf
ケンコーコム様の課題・導入背景 ☁ 2009年よりAWS試験導入 ☁ 2011年 東日本大震災がきっかけ ☁ 安定的な事業運営のために システムのクラウド化を計画 • 50台以上のサーバー群をクラウドへ • 本社機能の一部を福岡へ移転 出典 http://www.sbbit.jp/article/cont1/26061
ケンコーコム様の実施方法 ☁ 2011年 AWSへの移行を開始 • 自社ECサイト（PC/モバイル/スマホ） • モール上支店連携システム • 在庫管理システム • ドロップシップ販売管理システム ☁ 2012年 SAP ERP • 当時AWSがプラットフォーム認定されてなかったが 将来の二重投資を回避するために当初からAWS移行対象に
ケンコーコム様 事例のポイント（1/2） ☁ クラウドならではの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
ケンコーコム様 事例のポイント（2/2） ☁ 移行しただけで月額サーバー費用 600万円の削減 • 月額900万円→ 50台サーバーAWS移行→ 月額300万円へ • オンプレ時は余裕を持ったリソース確保が前提 → クラウドへ移行→ 必要なときにリソース調達する方式に変更 ☁ 稼働後に性能を下げてコスト削減 • 移行時の性能に余裕をもった設計を見直し • 半数以上のサーバーで性能を再調整 ☁ プロジェクト全体では約65%削減 • SAP移行の初期費用＋5年間の運用費用をオンプレミスと比較
【まとめ】 事例から導かれる クラウド移行の成功パターン
クラウドの進化に 対応できる設計 既存のSIer＋ クラウド専門ベンダー クラウドならではの 移行方法 Proof of Conceptを 入念に実施 TCOを10年 スパンで算出 移行後もリソースの 最適化でコスト削減
失敗しないクラウド移行 ☁ 検証/部分導入 → 全体移行が安全 • 導入成果の大きなズレを防ぐ • クラウド的な文化に慣れる ☁ 業務別に達成したいゴールを定める • コスト/可用性/安全性など？ • 業務毎に上記の優先度を定めて、順次移行へ • 既存SIer＋クラウドベンダーの協業体制が安心 ☁ 長期スパンで変化に対応する覚悟を決める • 数年に一度のシステム更改 → いつでも変化に対応できる状態にする • クラウドは可用性・セキュリティ・コストどれをとっても効果が高い • 数年おきに老朽化・更新が発生するオンプレミス環境はもはや不要
cloudpackホワイトペーパー AWS活用ノウハウを惜しみなく公開 セキュリティ サーバーレス開発 （AWS Lambda） サポートデスク（運用） 専用線接続 （AWS Direct Connect） cloudpackサイトで公開中 https://cloudpack.jp/whitepaper/
最後にお願い ☁ アンケートへのご協力をお願いします（ピンク色の紙） ☁ 抽選で5名様にAmazonギフト券5,000円をプレゼント いたします