アイレット株式会社 cloudpack事業部 執行役員 後藤和貴

業務システムのクラウド移行は現実的なのか？ 〜事例から紐解くクラウド時代の失敗しないIT投資とは〜

アジェンダ

☁ cloudpackについて

☁ 企業のIT投資とクラウド利用の現状 ☁ クラウド移行事例3パターン

☁ まとめ:事例から導かれるクラウド移行の成功パターン

について

後藤 和貴@kaz_goto

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

後藤 和貴@kaz_goto

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

☁ cloudpack事業 執行役員 • エバンジェリスト • マーケティング担当（PR、ウェブ…）

☁ バックグラウンド • Oracle カスタマーサポート→開発 • ビジネス・アーキテクツ • テクニカルディレクター（フリーランス）

アイレット株式会社

設立

資本金

代表者

従業員数

事業内容 システム開発・保守 クラウドインテグレーション マネジドホスティング

2003年10月15日

7,000万円

齋藤 将平

134名（2016年6月現在）

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

コンシェルジュサービス

cloudpackビジネス

設計支援 コンサル

MSP 運用保守

システム 開発

24時間365日

定額課金/ 請求書払い

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

監視運用保守

企業 AWS

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

全世界で46社アジア地域5社

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

4 社 社超

プロジェクト超

6001200

6年間

6年間AWSのみで運用保守

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

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

セキュリティ ホワイトペーパー

☁ 国際・国内セキュリティ基準への取り組み

☁ ソフトウェア脆弱性情報に関する取り組み

☁ 業務ネットワークのセキュリティ ☁ 運用上のセキュリティ保持体制

120

クラウド 導入事例

※ 2016年6月時点

企業のIT投資とクラウド利用の現状

中期経営計画・IT投資のサイクル

3年 サイクル

5年 サイクル

IT投資（オンプレミス）

中期経営計画

市場の変化への追従課題❶

ビジネス転換への追従課題❷

経営計画に影響を与えたイノベーション

☁ iPhone 3G発売（わずか8年前）

☁ 新デバイス発表（1年に1度） • 6sまでに8回のモデルチェンジ

☁ 新OS発表（1年に1度） • 現在はiOS 9

働き方を大きく変えたスマートデバイス

経営計画に影響を与えたイノベーション

☁ 2006年にAWSスタート（今年で10年） ☁ 2011年に東京リージョン開設 ☁ ニーズに応じた722回の機能追加・改善 ☁ 過去10年で51回の値下げを実施 ☁ アクティブカスタマー100万超

クラウドの雄ーAmazon Web Services

3年 サイクル

IT投資（オンプレミス）

中期経営計画

市場の変化への追従課題❶

ビジネス転換への追従課題❷5年

サイクル

こんなスピード感で競争を優位に戦えますか？

3年 サイクル

IT投資（オンプレミス）

中期経営計画

市場の変化への追従課題❶

ビジネス転換への追従課題❷5年

サイクル

IT投資（クラウド）

1ヶ月 サイクル

市場・ニーズの変化・事業方針転換への スピーディな対応

クラウドへ移行することで得られる利点

☁ 経営が求める「俊敏さ」が手に入る • インフラ調達に圧倒的なスピード • 大量データを扱い、顧客ニーズを瞬時に高い精度で把握 • 『成長』の機会を逃さないIT投資 • 自社よりも高いセキュリティ基準と運用基準

☁ 運用保守コストの削減（人的リソース含む） ☁ 5年保守サイクルの脱却

CLOUD

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が落ちたときにも…

☁ 未知な領域が大きいので、クラウド経験値の高いパートナーと組む

別ロケーションでの復旧

☁ 災害時：シンガポールにほぼ自動的に環境構築 ☁ テンプレート（レシピ）から一発で再構築可能

Tokyo Region Singapore Region

CloudForma*on,

Template, Stack,

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

☁ 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. データ移行本番時 ➡ サーバー性能を一時的に上げて処理時間を短縮

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

ケンコーコム様 事例のポイント（2/2）

☁ 移行しただけで月額サーバー費用 600万円の削減 • 月額900万円→ 50台サーバーAWS移行→ 月額300万円へ

• オンプレ時は余裕を持ったリソース確保が前提→ クラウドへ移行→ 必要なときにリソース調達する方式に変更

☁ 稼働後に性能を下げてコスト削減 • 移行時の性能に余裕をもった設計を見直し

• 半数以上のサーバーで性能を再調整

☁ プロジェクト全体では約65%削減 • SAP移行の初期費用＋5年間の運用費用をオンプレミスと比較

【まとめ】 事例から導かれる

クラウド移行の成功パターン

クラウドの進化に 対応できる設計

Proof of Conceptを 入念に実施

既存のSIer＋ クラウド専門ベンダー

TCOを10年スパンで算出

クラウドならではの 移行方法

移行後もリソースの 最適化でコスト削減

失敗しないクラウド移行

☁ 検証/部分導入 → 全体移行が安全 • 導入成果の大きなズレを防ぐ

• クラウド的な文化に慣れる

☁ 業務別に達成したいゴールを定める • コスト/可用性/安全性など？

• 業務毎に上記の優先度を定めて、順次移行へ

• 既存SIer＋クラウドベンダーの協業体制が安心

☁ 長期スパンで変化に対応する覚悟を決める • 数年に一度のシステム更改 → いつでも変化に対応できる状態にする • クラウドは可用性・セキュリティ・コストどれをとっても効果が高い

• 数年おきに老朽化・更新が発生するオンプレミス環境はもはや不要

cloudpackホワイトペーパーAWS活用ノウハウを惜しみなく公開

セキュリティサーバーレス開発 （AWS Lambda）

サポートデスク（運用）専用線接続 （AWS Direct Connect）

cloudpackサイトで公開中 https://cloudpack.jp/whitepaper/

最後にお願い

☁ アンケートへのご協力をお願いします（ピンク色の紙） ☁ 抽選で5名様にAmazonギフト券5,000円をプレゼント

いたします