パブリッククラウド導入の実践ノウハウ
•
27 recomendaciones•6,905 vistas
http://libra.netcommerce.co.jp/ 上記URLよりロイヤリティ・フリーのパワーポイントをダウンロードできます。
Recomendados
Recomendados
Más contenido relacionado
La actualidad más candente
La actualidad más candente (20)
Destacado
Destacado (17)
Similar a パブリッククラウド導入の実践ノウハウ
Similar a パブリッククラウド導入の実践ノウハウ (20)
Más de Masanori Saito
Más de Masanori Saito (20)
Último
Último (9)
パブリッククラウド導入の実践ノウハウ
- 5. 「自家発電モデル」から「発電所モデル」へ 5 工場内・発電設備 v 設備の運用・管理・保守は自前 v 需要変動に柔軟性なし 電力供給が不安定 自前で発電設備を所有 工場内・設備 電 力 電力会社・発電所 大規模な発電設備 低料金で安定供給を実現 v 設備の運用・管理・保守から解放 v 需要変動に柔軟に対応 工場内・設備 送電網 データセンター 大規模なシステム資源 低料金で安定供給を実現 v 設備の運用・管理・保守から解放 v 需要変動に柔軟に対応 システム・ユーザー デ タ インターネット
- 8. システム資源のECサイト 見積書 契約書 調達手配 導入作業 メーカー ベンダー サイジング 調 達 費 用 数週間から数ヶ月 数ヶ月から数年を想定 現物資産またはリース資産 従来の方法 セルフ･サービス・ポータル l 調達・構成変更 l サービスレベル設定 l 運用設定 l ・・・ 数分から数十分 直近のみ・必要に応じて増減 経費・従量課金／定額課金 クラウド オンライン･リアルタイム
- 10. v 徹底した標準化 v ⼤量購⼊ v 負荷の平準化 v APIの充実・整備 v セルフサービス化 v 機能のメニュー化 クラウド・コンピューティングのビジネス・モデル 10 クラウド・コンピューティング オンデマンド 従量課⾦ ⾃動化・⾃律化 システム資源 の共同購買 サービス化 低コスト 俊敏性 スケーラビリティ SDI (Software Defined Infrastructure)
- 13. クラウドの定義／サービス・モデル (Service Model) アプリケーション ミドルウェア オペレーティング システム ハードウェア PaaS Platform as a Service IaaS Infrastructure as a Service Software as a Service SaaS Salesfoce.com Google Apps Office 365 Windows Azure Force.com Google App En Amazon EC2 IIJ GIO Cloud Google Storage アプリケーション エンドユーザー ミドルウェア アプリケーション 開発者 仮想マシン システム アーキテクト
- 14. ふたつのタイプのIaaS （日本の個別事情） 運⽤管理 v 構築（作成） v 起動/シャットダウン v バックアップ v 仮想マシンの複製 v リソースの変更や監視 v 運⽤サービス設定など システム資源 v プロセッサー v メモリー v ストレージ v デスクトップ v ネットワーク v データセンター設備など サービス事業者 標準化されたシステム構成、運 ⽤管理メニューを提供。調達・ 運⽤管理の⾃動化を徹底。 ユーザー セルフサービス・ポータルを 使って⾃社要員で必要な管理・ 設定を⾏う。 サービス事業者 ユーザーの個別の要望に応じて、 サービス事業者がシステムの構 築、運⽤設計を実施。それに応 じた運⽤サービスを提供する。 割安。継続的なサービスや機能 の拡充、コスト低減などを享受 できる。 割⾼。サービスや機能は固定化 または変更に⼿間はかかる。継 続的なコスト低減は難しい。 セルフサービス型 IaaS フルサービス型 IaaS AWS,SoftLayer,cloudnなど 国内SI事業者に多い NISTの定義に該当
- 15. ハイブリッド・クラウド 複数企業共⽤ パブリック・クラウド クラウドの定義／配置モデル (Deployment Model) プライベート・クラウド 個別企業専⽤ 個別･少数企業 不特定・複数企業／個⼈ LAN LAN インターネット 特定企業占有 ホステッド プライベート・クラウド LAN 専⽤回線・VPN LAN
- 16. ホステッド・プライベートクラウド 16 プライベート・クラウド ホステッド プライベート・クラウド オンプレミス プライベート・クラウド デディケイテッド プライベート・クラウド コミュニティ プライベート・クラウド ユーザー企業に システム資源を 占有・割り当て パブリック・クラウド ユーザー企業・⾃社構内 データセンタ・占有借⽤施設内 クラウド・サービス事業者 ⾃社専⽤ クラウド環境 予め⽤意された 標準仕様を組合せ ユーザー企業毎に 個別仕様で クラウドを提供 ユーザー企業の資産 クラウド・サービス事業者の資産 運⽤管理責任は⾃社 運⽤管理責任は事業者 運⽤管理責任は事業者 リースまたは減価償却 サブスクリプション サブスクリプション+初期費⽤ l OpenStack（OSS） l Microsoft Azure Stack l Vmware vSphere など l AWS Virtual Private Cloud l Microsoft Virtual Network l IBM Blumix Dedicated など l NTT Bizホスティング l NSSOL absonne l CTC CUVICmc2 など
- 17. ハイブリッド・クラウド 同⼀のアーキテクチャー リソース Ａ リソース Ｂ リソース Ｃ パブリック・クラウド プライベート・クラウド クラウド基盤 仮想資源 セルフサービス・ポータル リソース Ａ リソース Ｂ リソース Ｃ ユーザー・ビュー パブリックと プライベートが ひとつの リソース プール 標準化の主導権争い
- 18. ハイブリッド・クラウド 18 Cloud Stack AWS OpenStack Cloud Stack vmware vCloud Air vmware vCloud Suites Azure Azure Stack Google Cloud Platform なし Cloud Foundry Google App Engine Elastic Beans Talk Lambda など IBM Bluemix BlueMIx Dedicated 互換API OpenStack Cloud Foundry IBM Bluemix Local プライベート・クラウド パブリック・クラウド PaaS IaaS PaaS IaaS SQL Server Visual Studio .Net など
- 19. ハイブリッド・クラウドとマルチ・クラウド 19 クラウド管理プラットフォーム Prime Cloud Controller (SCSK) / RightScale (RightScale) / vRealize Suite (Vmware) など オンプレミス（自社構内） データセンタ（自社設備） データセンタ（他社設備） コロケーション／ホスティング パブリック・クラウド パブリック・クラウド バーチャル プライベート クラウド ハイブリッド・クラウド マルチ・クラウド インターネット／ＶＰＮ／専用線 (SDN : Software-Defined Network) 個別専用システム ハイブリッド・クラウド マルチクラウド
- 21. 仮想化統合基盤とクラウド(IaaS)との違い 仮想化 運 ⽤ 管 理 調 達 インフラに関わるシステム資源を ソフトウェアの定義・設定により調達、構成変更 調達機能と 運⽤管理機能の 連携と⾃動化 個別対応 ⾃動化/⼈的作業 個別対応 ⾃動化/⼈的作業 システム資源の利⽤効率向上 ⼈的作業の負担軽減 調達・変更の俊敏性と⽣産性向上 仮想化基盤 クラウド(IaaS)基盤
- 22. PaaS
- 23. ASPからSaaSへ、ホスティングからIaaSへ オンプレミス アプリケーション ミドルウェア OS/ハードウェア サービスプロバイダ ASP Application Service Provider ネットワーク上のサー バーにパッケージソフトを 搭載してネットワーク越し に提供 Hosting/Housing データセンターの サーバーを ネットワーク越しに提供 クラウド SaaS IaaS SaaS Software as a Service (1999〜) マルチテナント対応アプリ ケーションを「サービス」と して提供し、従量課金 PaaS (2007〜) IaaS (2006〜) サービスとして 提供従量課金
- 24. データセンター データセンター ASPとSaaSの違い – マルチテナント サーバー サーバー サーバー アプリ アプリ アプリ サーバー サーバー 仮想化 顧客 顧客 顧客 アプリ アプリ アプリ データセンター サーバー アプリケーション 顧客 顧客 顧客 パッケージをそのまま使用 複数企業での共有を前提とした設計 データの分離、セキュリティに配慮 メンテナンスコストが低い リソースの利用効率が高い または マルチテナントDB ASP SaaS
- 26. ガバナンスが効かないという都市伝説 パブリック・クラウドは、 ガバナンスが担保できないので使えない！ ガバナンスを担保するとは、 命令や指⽰などなくても、普段通りの業務をこなしていれば、業務や経営 の⽬的が達成されるビジネスプロセスを構築し、それを運⽤すること。 本当にそうでしょうか？ ということは？ 許容⽔準 達成基準 施策 v ⼀元管理され利⽤状況を計測でき、利⽤ログを把握できる。 v 必要な時に必要な機能／性能／資源を調達・利⽤できる。 v 管理の対象が少なく、管理負担が少ない。 クラウドで できること
- 27. クラウドで実現するガバナンス 27 ガバナンスを担保するためには・・・ 効率 利便性 コスト リスク ガバナンス Governance 状 況 が ⾒ え る 状 況 が 調 整 ・ 変 更 で き る v ⼀元管理され、利⽤状況を計測でき、利⽤ログを把握できる。 v 必要な時に必要な機能／性能／資源をプロビジョニングできる。 v 管理の対象を減らすことができる。 クラウドで できること
- 28. セキュリティが心配という都市伝説 セキュリティが心配なので使えない？！ ネットワーク・パフォーマンスが不安定なので使えない？！ 既存システムからの移行に手間がかかるので使えない？！ vセキュリティ専門部隊が、データセンターやネットワークなど物理インフラを24時間365日対応 vSOC2、FIPS 140-2、ISO 27001、ITAR、PCIDSSなど第三者機関による認証を通し情報を開示 v金融機関に於いて情報セキュリティ対策の指針となっている「FISC 安全対策基準」に準拠 vインターネットで接続する以外に、専用線で接続も可能。 v自社のプライベート・ネットワークとL2接続 v固定的な専用領域を提供しリソースを安定供給（バーチャル・プライベート・クラウド） v主要なOS、ミドルウェア、ビジネス・アプリケーションをクラウドに持ち込み可能 vVM Ware、Hyper-V、KVMなど複数の仮想化基盤サポート、自社内仮想化基盤をそのまま移行可能 v基幹業務移管の事例も拡大 高度な災害強度の データセンター 高いコストパフォーマンス グローバルでフラットな アーキテクチャー
- 30. パブリック・クラウド適用のリスク 30 管理主体の違い 事業者によるシステム設計と運営管理 ü 投資の内容や優先順位の判断 ü セキュリティやサービスレベルの維持などの統制活動 ü 障害や情報漏えいなどのインシデント発⽣時の情報連携 ü インシデントに関する情報開⽰範囲や原因究明作業に対するユー ザー関与に制約 ü インシデントの全体像や根本原因の特定が不⼗分な恐れ ü ⾃社のシステム環境の移植性の問題 ü サービス終了時にデータの引き継ぎに制約が⽣じる恐れ ü サービス品質に対して実施するリスク管理の有効性について、 ユーザーが期待するレベルまで実施されていない、また、実施さ れていても情報開⽰の制約でユーザーが確認できない恐れ 情報開⽰の限界 ü セキュリティ管理ルールの⼗分性や運営実態について、情報開⽰ 範囲に制約 ü 契約で合意した内容の履⾏状況に関してユーザー側の確認が撮り にくい ü ベンダーの情報開⽰情報と⾃社のセキュリティポリシーなどとの 整合性を⼗分の確認が困難 機能やサービス内容の制約 個別カスタマイズの制約 ü ユーザー固有のカスタマイズが実現できないため業務影響の⾒極 めや対策について検討が必要 サービスに関する意思決定権 ü 事業戦略の変更や破綻などにより、⼀⽅的にサービスの終了や変 更、また、サポート停⽌により、ユーザーの業務継続や顧客への サービス提供に影響を及ぼす恐れ サービスの多様化・グローバル化 データの所在 ü データセンター設置国の法令への遵守 ü 海外の現地規制当局の強制執⾏などによるデータ閲覧やデータ収 集、通信傍受により業務継続に⽀障、情報漏えいの恐れが ベンダーのグローバル化 ü 本社拠点（各種意思決定機能）を海外に置くベンダーも多く、 サービス内容や提供価格、契約条件などの調整がスピード感を もって推進できない恐れ ü ベンダーの本社が海外にあることで、係争時の管轄裁判所が海 外となり、海外の係争への対応が必要となる恐れ ü インシデント発⽣時に時差や⾔語の問題から、ベンダー、ユー ザー間のコミュニケーションに⽀障をきたす恐れ 役割分担や責任範囲の多様化 責任や役割の固定化 ü ユーザーの個別要求事項を前提とした諸条件の調整が困難 ü ⾃社のニーズをふまえた「融通」が利きにくく、ユーザー側で追 加の対応⼿続きやリソース⼿配などが必要となる恐れ ü マルチベンダーで⼀つのITサービスを実現する場合情報連携に混 乱や⽀障をきたす恐れ 導⼊に伴うハードルの低下 簡単迅速なサービス導⼊ ü ユーザー部⾨が⾃社のセキュリティポリシーやシステム化⽅針な どへの影響確認を⼗分に実施せずに単独で導⼊してしまい、全社 的なシステム統制に影響を及ぼす恐れ http://japan.zdnet.com/article/35063430/
- 31. クラウド・サービス事業者のポジショニング 2015 31 ハイブリッド・クラウド パブリック・クラウド 開 発 者 志 向 エ ン タ プ ラ イ ズ 志 向 Digital Ocean Google Cloud Platform Amazon Web Services Microsoft Windows Azure IBM SoftLayer Vmware vCloud Air ü DC拠点の拡大 ü サービスの拡充 ü ベアメタル ü BlueMix ü 業界・業務プロファイル ü Bluemix Dedicated ü 10GBバックボーン ü Power Systems,Z Systems ü BlueMix Local ü Vmware コネクター ü SAP提携 ü 上位レイヤサービス拡充 ü パートナー・ビジネスの拡充 ü エコシステム・ソリューション・パターン ü 上位レイヤサービス拡充 ü Office365 ü OSSへの対応拡充 ü .NetのOSS化 ü 上位レイヤーサービス拡充 ü パートナー・ビジネスの拡充 ü EVO Rail ü サービスの拡充 ü vCenterの機能拡充 ü Windows Server 2012 R2
- 32. v 通信インフラ/DCのシームレス提供 v グローバル拠点展開（9カ国11拠点） v APAC最大のDC敷地面積 v ネットワーク転送量無料（IN/OUT） v 数千人規模の直販力 v 回線ユーザーへのアップセル機会 v NTTグループの国内プレゼンスとシナジー v 企業基幹系システムの豊富な導入実績 v クラウド・マイグレーション・チームの存在 v ポジショニングの異なる２つのサービス NTTコミュニケーションズ vAWSに次ぐ２位 vAWSを上回る成長率 vオンプレミス（Windows Server）との連携 v既存パートナーとの強力なエコシステム vAWSの価格破壊に追従 v国内データセンターからの提供 vIoTやビッグテータ、機械学習などの新領域拡充 vスタートアップ企業や開発者からの支持拡大 v優秀な人材の流入 vOffice365の事業拡大 Microsoft v国内外のエンタープライズ顧客基盤と営業力 vクラウドへの大規模投資（10億ドル以上） v豊富な導入実績（世界2万社以上） vベアメタル・サーバーの提供 v海外拠点との10GBバックボーン接続 vPaaS（BlueMix）のサービス機能の充実と拡充 v人工知能（Watson）との連携 v業界業務プロファイルの展開 v国内データセンターからの提供 vp Systemsやz Systemsの機能提供 クラウド・サービス事業者の強みと機会 32 林雅之氏の資料を元に作成 http://cloud.watch.impress.co.jp/docs/new s/20150218_688718.html v圧倒的市場リーダー v開発者を志向したサービス機能の充実と拡充 v価格競争の急先鋒 vソリューション・アーキテクトなどの人材充実 v国内40を越えるコミュニティ v国内数万社規模の導入実績 v200社前後のパートナー vスタートアップ企業からの熱烈な支持 v企業の基幹業務への採用拡大 v国内データセンターからの提供 Amazon Web Services IBM
- 33. 33 ITインフラと仮想化
- 34. 仮想化とは
- 35. 仮想 virtual 表⾯または名⽬上はそうでないが 事実上の/実質上の/実際の 本来の意味 「仮想化」の本当の意味 本来の意味 仮想化 Virtualization 物理的実態とは異なるが、 実質的機能を実現する仕組み ⽇本語での語感 ü虚像の〜 ü実態のない〜 It was a virtual promise. （約束ではないが）実際には約束も同然だった。 He was the virtual leader of the movement. 彼はその運動の事実上の指導者だった。
- 36. 物理資源・物理機械 サーバーの仮想化 ストレージの仮想化 Java仮想マシン データベースの仮想化 パーティショニング 分 割 アグリゲーション 集 約 エミュレーション 模 倣 仮想化 (Virtualization) ひとつの物理資源を 複数の仮想資源に分割 複数の物理資源を ひとつの仮想資源に分割 ある物理資源を 異なる資源に見せかける 仮想化の3つのタイプ
- 38. タイムシェアリング “⾒かけ上” 同時使⽤できる コンピューター（物理資源） 個別の資源 個別の資源 個別の資源 個別のOS 個別のOS 個別のOS “⾒かけ上” 別々の資源として 使⽤できる 仮想化の誕生(2) コンピューターを共同利用する技術 仮想化ソフトウェア ハイパーバイザ (hypervisor)
- 39. 仮想化からSDIへ
- 40. SDI（Software-Defined Infrastructure） 40 仮想化（Virtualization） ファイヤウォール 負荷分散装置 ルーター ファイヤウォール スイッチ 負荷分散装置 ルーター ネットワーク 物理的なシステム資源（リソース・プール） 組織・企業 組織・企業 組織・企業 組織・企業 柔軟に！ 即座に！ 簡単に！ 物理的なシステム資源全体を、ソフトウェアの設定で、調達・構成変更できる仕組み
- 41. ITインフラを支える仮想化 ストレージCPU メモリ OS アプリケーション サーバー ファイヤウォール スイッチ 負荷分散装置 ルーター ストレージCPU メモリ OS アプリケーション サーバー ストレージCPU メモリ OS アプリケーション サーバー ネットワーク 物理的なシステム資源 ストレージCPU メモリ サーバー ファイヤウォール スイッチ 負荷分散装置 ルーター ストレージCPU メモリ サーバー ストレージCPU メモリ サーバー ネットワーク 仮想化（Virtualization） 仮想システム 仮想システム 仮想システム 物理的なシステム資源のまとまり ＝ リソース・プール
- 42. 自 律 化 仮想マシン、ミド ルウェア、アプリ ケーションの稼働 状況を監視し、運 用パターンに沿っ て設定を調整する 監 視 監 視コントローラー セルフ･サービス ポータル 仮想リソース ミドルウェア アプリケーション 操作 操作 運用管理者運用パターン 自 動 化 APIを介し、コン トローラーやセル フポータルの操作 に従って、プロビ ジョニングを行う ü ハード・ソフト構成の管理 ü システムの稼働監視 ü アラートから異常の兆候を検知 ü 異常の原因を解析 ü 解決策の選定 ü 解決策適用による影響範囲を確認 ü 設定の変更やリソースの追加で対応 運用 パターン 仮想化・自動化・自律化の関係 プロビジョニング 仮想化ソフト 仮想化ソフト 仮想化ソフト 仮 想 化 物理リソースを管 理し、ソフトウェ アによる定義に 従って仮想リソー スを提供する リソース プール オーケストレーター 操作 操作 操作 API
- 43. 自 律 化 監 視 監 視コントローラー セルフ･サービス ポータル 仮想リソース ミドルウェア アプリケーション 操作 操作 運用管理者運用パターン 自 動 化 仮想化・自動化・自律化の関係 プロビジョニング 仮想化ソフト 仮想化ソフト 仮想化ソフト 仮 想 化 リソース プール オーケストレーター 操作 操作 操作 API IaaS PaaS SaaS クラウドOS
- 45. Infrastructure as Code（１） 45 環境構築⼿順書 ① AをBする。 ② CをDにする。 ③ FをGにする。 ・・・ +#!/bin/sh+yum install -y httpd httpd- devel php php- mbstring php-pdo php-mysql mysql- インフラ設定インフラ構築⼿順作成 環境構築⼿順書 1 ① AをBする。 ② CをDにする。 ③ FをZにする。 ・・・ 環境構築⼿順書 2 ① AをBXする。 ② CをDYにする。 ③ FをZにする。 ・・・ 環境構築⼿順書 3 ① AをBXする。 ② CをDYにする。 ③ FをGZにする。 ・・・ +#!/bin/sh+yum install -y httpd httpd- devel php php- mbstring php-pdo php-mysql mysql- ü ⼿作業で作業ミスが⼼配 ü 変更を繰り返すと管理が⼤変 ü 実際の環境と履歴が⼀致しない ü 対象が増えると管理しきれない ü 設定に⼿間がかかる ü テスト・確認が複雑
- 46. Infrastructure as Code（２） 46 変更履歴 ① XXXXXXXXX ② XXXXXXXXX ③ XXXXXXXXX ・・・ クラウド個別システム × × システム資源が物理的に固定さ れるので、インフラ構築はその 制約の下で⾏われる。 物理サーバーを構成変更しなが ら使い続ける。 システム資源が仮想化されるの で、インフラ構築に物理的な制 約をうけることはない。 仮想サーバーの追加・破棄を頻 繁に繰り返すことができる。 変更履歴を管理 動作している状態を管理 再現性を⾼める Immutable Infrastructure構成は変化し続ける
- 47. Infractracture as Code（３） 47 仮想マシン 仮想マシン 仮想マシン Orchestration: 複数サーバーの管理を⾃動化 Configration: OSやミドルウェアの設定を⾃動化 Bootstrapping: OSの起動を⾃動化 OS OS OS Virturization: 仮想マシンの構築・起動 ミドルウェア アプリケーション OSや仮想化ソフトウェアのインストール／設定作業を⾃動化 データベースサーバ／Webサーバ／監視エージェントなどのミドル ウエアのインストールやバージョン管理、OSやミドルウエアの設定 ファイルや、OSのファイアウォール機能などの設定などを⾃動化 複数台のサーバ群を監視し、新しいサーバをシステムに登録したり、 障害のノードをシステムから取り除いたり、サーバへのアプリケー ションのデプロイをサポート KickStart
- 49. パブリック・クラウドへ移行すればコストを削減できるか？ 49 現行システム（オンプレミス）の構成や運用をそのままに移行しても コスト削減は難しい l サーバー台数 Ø サーバー台数が多いとシステムが複雑になり、構築・インテグレーション費用が増加する Ø 販売代理店（SI事業者など）に任せると台数に応じて販売マージンや手数料が必要となる Ø 管理対象のサーバー台数が多いと保守・サポート費用が増加する l サーバー稼働時間 Ø 使わないサーバー・インスタンスが停止されずに動いている Ø 割引が効くはずの年額一括にしたが、全てを使われずに無駄な費用を払ってしまう Ø 常時稼働が前提のオンプレミスと同じ運用方法で料金が嵩んでしまう l サービス・レベル Ø パックアップ Ø 冗長化構成 Ø その他、サポートオプションの契約 l データ転送コスト Ø ダウンロードデータ転送（外部へのデータ持ちだし） Ø 外部ネットワーク回線費用（閉域網、国際回線等） l 社員人件費 Ø 運用管理などに関わる社員の人件費はクラウドに機能が移管してもそのまま残存 SI事業者によっては、サーバー台数 を増やそうとする場合がある！
- 51. クラウドサービスのコスト構造 51 サーバー ストレージ データ転送 内部ネットワーク 外部ネットワーク 能⼒×時間 容量／⽉ 転送量（GB） ダウンロード 定額／⽉ 転送量 ポート速度100Mビット秒 オプション機能 FW、LBなど オプション単位 インスタンスの能⼒に よって料⾦は異なる。 外部へのデータ転送量 に応じて課⾦される。 サービスによって異な る。 セグメント数、外部 ネットワークとの接続 に伴うデータ転送量に 応じて課⾦される。 専⽤線などの閉域網、 海外DCとの国際回線の 費⽤などが必要となる。 サービスによっては標 準機能として提供され る場合もある。 ü 冗⻑化構成を減らす ü 変動／固定を動的に組合せる ü 必要なインスタンスのみ稼働させる ü 運⽤を⾃動化する ü ベンダーを通さず直接契約にする ü データ・ライフサイクルを⾒直し ホット/コールドデータを分けて保管 ü 容量無制限のファイルサーバーと組 み合わせる アクセス速度に応じて サービス・料⾦が異な る。 ü アプリケーション設計の⾒直し ü 同⼀セグメント内での転送 ü 運⽤⽅法の⾒直し ü セグメント内で完結するような設計 ü 国際回線を多⽤する場合は回線料⾦ が組み込まれたサービスを選定 ü 不要なオプションは設定しない オ ン プ レ ミ ス を そ の ま ま に 移 ⾏ せ ず 構 成 ・ 運 ⽤ を 再 設 計
- 52. 料金の削減のポイント（１） 52 必 要 能 ⼒ 調達するサーバー能⼒ 必 要 能 ⼒ 調達するサーバー能⼒ 運⽤⾃動化ツールの活⽤ よく似た運⽤パターン・グループ に集約しインスタンスを削減
- 53. 移管の考え方 53 IaaS PaaS SaaS オンプレミス・システム 1. コスト 5年間のTCO 2. BCP 遠隔多重化構成など 3. バックアップ／アーカイブ 電⼦メール、業務データなど 4. ユーザー利便性 応答時間、グローバル対応など 5. ガバナンス ⾒える化、管理機能など そのまま移⾏すれば ü オンプレミスよりもコストが嵩む ü 運⽤管理負担が増える ü 機能⾯で利⽤部⾨のニーズに応えられない ü サービスレベルが低下する ü セキュリティが担保できない Ø 上記、組合せの最適解を考える Ø クラウド前提のアーキテクチャーに⾒直す Ø 情報システム部⾨の役割を再構築する
- 54. 移管に関する考慮事項 54 システム・アーキテクチャー変更にともなう üスループットやレスポンスなどの影響度 分析やリスク検証 ü投資を正当化するため、オンプレミスと の⽐較における投資対効果の明確化 ü⾮機能要件の⾒直し セキュリティポリシーや個⼈情報保護⽅針との適合性や システム監査への対応要件を満たすかどうかなど ü 運⽤⽅法の変更 ü パブリッククラウドの提供機能やセ キュリティポリシーなどの評価 既存業務システム （オンプレミス） パブリッククラウドへの移管 仮想サーバーの パブリッククラウドへの移管 パブリッククラウドでの 新規システム構築 海外システムのクラウド化 ü 越境データ規制 ü 個⼈情報保護規定 ü 犯罪捜査権 など
- 56. システムデザイン勘所 56 Design for Failure 障害発⽣を前提とし、 障害が発⽣しても問題なく運⽤できるような設計を⾏うこと システム機器ではなくサービスとしての健全性を保つこと ü 全体の可⽤性の担保が最重要 ü SPOF（Single Point of Failur：単⼀障害点）を作らない構成 多様な監視⽅法を組み⼊れること ü 外からの監視：反応があるか、ないか ü 内からの監視：受けられるか、受けられないか ü サービスからの報告：サービス⾃⾝の健全性の主張 データを収拾し、閲覧する体制を作る ü いつでも、増やせる、削除できる仕組みとする ü データを集積し、利⽤状況を分析する ü 分析結果を踏まえてブラッシュアップを継続する ⾃動化する ü いつ起きるか分からないことへの対応を⾃動化で対処する ü 検知、報告、対応までの⾃動化を⽬指す 監視 ログ 収集 通知 復旧 改善 分析
- 57. 実演
- 58. シナリオ１：クラウドで仮想サーバーを調達 58 Google Cloud Platformで仮想の発注 → リソース変更 Ø AWS、Azure、Google Cloud Platform、SoftLayerの中で最も最速で仮想マシンが ⽴ち上がると評判（※）のGoogle Cloud Platformで仮想マシンを発注してみます。 ※現時点のものです。使⽤者が増えたり、サービスの改定で変わります。 動画デモ
- 59. シナリオ２：クラウドでベアメタルサーバーを調達 59 SoftLayerでベアメタの発注→仮想に変換→リソースの変更 Ø AWS、Azure、Google Cloud Platform、SoftLayerの中で、唯⼀、物理サーバー （ベアメタルサーバー）を提供しているSoftLayerでベアメタルサーバーを発注して みます。 Ø ベアメタルサーバーのイメージテンプレートから、仮想マシンを作成する（使⽤する シチュエーションの例） ü ベアメタルで作ったけど、テスト⽤に同じ構成で仮想マシンを作っておきたい。 ü ベアメタルで構築したが、リソースをそんなに作っていないので仮想マシンに置き換えたい 動画デモ
- 60. シナリオ３：クラウドでリモートデスクトップを作成 60 AzureでRemoteAppの発注 Ø RemoteAppとは？ はリモート デスクトップ サービス経由で、リモートサーバーの 上のアプリを、あたかもローカルで実⾏しているかのようにみせる技術です。 Ø RemoteApp プログラムは、ローカルのアプリケーションと同様に表⽰されますが、 プログラムはリモートサーバー上で稼動しています。 動画デモ
- 63. 実践のステップ 63 検討 調達 構築 運⽤ 1. 試算するコストの漏 れ抜けに注意 2. 利⽤の繁忙期、閑散 期を意識してサイジ ング 3. ⾃前で構築すべきか どうかを⾒極める 4. ライセンスはクラウ ド対応かどうかを確 認 1. 費⽤の⽀払⽅法 2. ベンダー選定 1. 各種⼿続きのリード タイム 2. クラウドのオーダー 3. パフォーマンス 4. 監視 5. 権限設定 6. セキュリティ 7. そのほか 1. 費⽤の⽀払⽅法 2. ベンダー選定
- 64. 検討
- 65. 検討時の考慮事項 ü 試算するコストの漏れ抜けに注意 ü 利⽤の繁忙期、閑散期を意識してサイジング ü ⾃前で構築すべきかどうかを⾒極める ü ライセンスはクラウド対応かどうかを確認 65
- 66. 検討１：目に見えないコストにも注意する 66 オンプレでのサーバー更改があり、オンプレのサーバー費⽤の⾒積が 1500万円なんですが、クラウドにしたらいくらですか？ クラウドは安いというイメージ「Amazon EC2」が0.02ドル〜/h ⽬に⾒えない費⽤も含まれている。これらを含めて、⽐較しないと同条件 での⽐較にはならない。普段は意識しない、既存の⾃社データセンターや サーバールームの維持費とランニングコストも含め⽐較する必要がある。 サーバー（HW）費⽤、サーバー保守費、電源・空調費⽤、場所代、ハイパーバイザーの冗⻑化、 LiveMigration機能、SnapShot機能、Storage領域の3冗⻑、24h365dでインフラ環境の保守要員 常駐費⽤など ※クラウドプロバイダーによって、条件は異なる よくやってしまう⽐較 オンプレのサーバー（HW）費⽤ vs クラウド費⽤（オンプレと同台数＆同スペック） 〇 オンプレのサーバー（HW）費⽤ ローエンドモデルのPCサーバー:¥100,000／台 → ¥15,000,000/150台 〇 クラウド費⽤（オンプレと同台数＆同スペック） ローエンド程度のスペックのインスタンス → ¥26,360,640/150インスタンス/年 ※ $1,464.48/インスタンス＝¥175,738/インスタンス（1ドル＝120円）
- 67. 検討２：サーバーの使用率や利用時期を洗い出す 67 オンプレミスと同じ使い⽅をしようとすると、コストを下げられない？ クラウドは必要な時に必要な分だけ⽤意できる。その特性を活かすことで、コスト削 減ができる。 Ø ひと⽉しか使わない → ひと⽉だけ使う 年間で12分の1にコスト削減 Ø 使⽤率が低い → 超ロースペックで発注 オンプレと同スペックなら$0.16/h→超ロースペックなら$0.02/h 年間で8分の1にコスト削減 Ø ⼀定の時期だけスペックが必要 → 通常時はロースペック、必要な時だけスペックを増やす 年間で？分の１にコスト削減 既に所有しているシステムは構成を変えることはできない。追加するにも時間も⼿間もかかり、 ⼀旦資産となったら使い切らなくてはならない。
- 68. 検討３：各サーバー（システム）の利用シーンを洗い出す 68 オンプレミスと同じ使い⽅をしようとすると、コストを下げられない？ 各サーバー（システム）の利⽤シーンの洗い出しを⾏って、以下を検討する。 ØSaaS → PaaS → IaaSの順で検討する ü ファイルサーバー代替として、SaaSのBOXやDropbox、PriveDrive（国産）な どのオンラインストレージを使うことも可能。SaaSであれば、すぐに使え、構 築⼯数が削減できる。 ü Active Directoryもサービスが使えるのでIaaSで作る必要はない（Azureのみ） Ø接続はポータビリティを求めるか？セキュアな通信を求めるか？ ü CRMやカタログなど外出先から簡単にアクセスして使いたいシステムの場合は、 インターネット経由（VPNや端末認証）で利⽤できる環境にする。 ü ⼈事データなど社内から安全に通信したいシステムの場合は、お客様環境とクラ ウドサービスの間に専⽤ネットワーク回線をひいてセキュア通信環境にする。 Azure ： ExpressRoute AWS ： Direct Connect SoftLayer ： DirectLink 通常データ ： BOXやPrimeDirve等のインターネット経由で利⽤できるサービス 機密データ ： IaaSでファイルサーバーを構築、専⽤ネットワーク回線で接続
- 69. 検討４：移行対象を見極める（１） 69 全てをパブリッククラウドに移⾏すべきだろうか？ ソフトウェアライセンスが仮想サーバーに適合できているか？ → Oracle製品の場合、AWS、Azureに関してはCPUライセンスを認めている http://www.oracle.com/jp/store/cloud-lic-170290-ja.pdf 適合できていない場合は、代替案の検討 ü 適合しているソフトウェアに変更が可能か？（変更に伴って発⽣する費⽤を考慮） ü SoftLayer等、物理サーバーが利⽤できるクラウドにするか？ ü オンプレ環境に残すか？
- 70. 検討４：移行対象を見極める（２） 70 全てをパブリッククラウドに移⾏すべきだろうか？ MACアドレスと紐づくアプリケーションは無いか（例：CAD製品）？ → MACアドレスなどのハードウェアの固有の情報は維持し続けることは出来ないこ とが多いので要注意 例）Azureの場合 仮想マシンの MAC アドレスは、いくつかの原因で変化する可能性があります。VM を停⽌ (割り当て解除) 状態にする場合や、仮想マシンのサイズを変更する場合、ま たはホスト サーバーのサービス修復や計画済みのメンテナンスを実施する場合は、 MAC アドレスは維持されません。 https://msdn.microsoft.com/ja-jp/library/azure/dn133803.aspx 例）AWSの場合 可能。 http://aws.typepad.com/aws_japan/2011/12/new-elastic-network- interfaces-in-the-virtual-private-cloud.html
- 71. シナリオ４：クラウドでDB/HAサーバーを構築 71 AWSのPaaS：Amazon RDS for Oracle Ø AWSのPaaSを使って、OracleのHA構成をあっという間に構築します。 動画デモ
- 72. 補足）Databaseのクラウドへの移行考慮点 72 PaaS→IaaSの順で検討 PaaSを選択する場合、業務に適しているかを確認 Azure SQL Database Ø ポイントインタイム リストアで、データベースを 35 ⽇間分遡って以前の状態に戻すことができる （Editionにより遡れる⽇数が異なる） Ø データベースをホストしているデータ センターで障害が発⽣した場合は、別のリージョンにあるデータ ベース レプリカにフェールオーバーことができる Ø レプリカを使⽤して、アップグレードまたは異なる地域への再配置を⾏うことができる Ø 最新のプログラムにアップデートされる。 Ø 制限事項について確認する ü Windows 認証はサポートされない ü TCP/IP 接続のみが許可 ü 分散トランザクション (複数のリソースに影響するトランザクション) をサポートしていない など ü 詳細は以下のURLを参照 https://azure.microsoft.com/ja-jp/documentation/articles /sql-database-general-limitations/ https://azure.microsoft.com/ja-jp/documentation/articles /sql-database-performance-guidance /#service- tier-capabilities-and-limits https://azure.microsoft.com/ja-jp/documentation/articles /sql-database-resource-limits / https://azure.microsoft.com/ja-jp/documentation/articles /sql-database-security-guidelines / データ量を確認 データ元がオンプレミス環境にあり、データ量が⼤量の場合、クラウド環境へデータをアップロードしなく てはならないが、それがボトルネックになる可能性があり 通信量の確認 アップロード、ダウンロードなどの通信で費⽤が発⽣する（各クラウドベンダーで費⽤の掛かり⽅が異な る）ので、DBのアップロード、ダウンロードの量も含めて検討する
- 73. 補足）クラウドの利用料金を下げる（１） 73 スモールスタートで始める クラウドは必要な分スペックが増やせるので、最初から⼗分なリソースを割り当てるのではなく、リソー スの利⽤状況を⾒ながら増やす。 ※オンプレの時の感覚が抜けず、リソースを多めに割りあてる場合がよくある。 マルチクラウドにする AWSで運⽤したが、しばらく運⽤しているとネットワーク通信量が⼤変なことに。通信量の多いサービス をネットワーク通信費を固定できるクラウドへ移⾏して、コスト削減を実現。 使わない時は課⾦されないように⼯夫する Ø 使わない時は停⽌して、使う時のみ起動する。AWSの場合は停⽌（インスタンスは課⾦されないが、 EBSは課⾦される）。 http://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/Stop_Start.html Ø Azureの場合は停⽌＆割当解除 http://blogs.msdn.com/b/dsazurejp/archive/2015/01/09/azure-virtual-machine-billing- architecture.aspx Ø SoftLayerは削除（サーバー停⽌しても費⽤がとられるので、テンプレート化しておいてサーバ削除） Storageの選択はデータの⽤途別 各クラウド業者でStorage種類を複数提供しているので、データに適したストレージを選択する ü AWSの場合 スタンダードストレージ標準／低頻度アクセスストレージ／Glacier ストレージ ü GCPの場合 Standard Storage／Durable Reduced Availability（DRA）Storage／Nearline Storage
- 74. 補足）クラウドの利用料金を下げる（２） 74 CDNサービスの活⽤ Webサイトで静的コンテンツへのアクセスが多い場合、インスタンスのスケールアウトをするより、オブ ジェクトストレージ＋CDNサービスを活⽤することで費⽤が下がる。また、CDNは全世界にあるキャッ シュサーバから配信がされるためWebサイトの⾼速化も期待できる。 ü AWSの場合 S3 + CloudFront ü SoftLayerの場合 ObjectStroge+CDNサービス ü Azureの場合 BLOBストレージ+Azure CDN リザーブドインスタンスの活⽤ Ø AWSでは⻑期(1年 or 3年)利⽤をコミットすることで最⼤ 75%オフで利⽤。費⽤削減だけでなくキャ パシティ予約ができる(予約分のインスタンスを起動できる保証)メリットもある。 Ø Microsoft Azureでは、Enterprise Agreementという先払い式で価格表が変化する⽀払い形態がある。 これは全てのリリースに適⽤される。 プリエンプティブルVMの活⽤ GCPでは連続稼働保証がなく、クラウド側の都合によっていつでも停⽌させられるプリエンプティブルVM がある。プリエンプティブルVMは連続稼働保証がない点を除けば、性能や可⽤性などは通常のVMと同じ。 最⼤70%安くなる。 国内のリージョンを変えて費⽤を抑える Azureは東⽇本リージョンと⻄⽇本リージョンでは時間あたりの料⾦が異なる。例えば、A7インスタンス (Windows)の場合(⽉額従量料⾦は、連続使⽤ 744 時間として⾒積もり) Ø 東⽇本は〜 ¥106,284/⽉ Ø ⻄⽇本は〜 ¥ 94,146/⽉
- 75. 検討時の考慮事項 – まとめ ü 試算するコストの漏れ抜けに注意 – データセンター費⽤、電気代、空調費など チェックリストを活⽤して漏れ抜け防⽌ ü 利⽤の繁忙期、閑散期を意識してサイジング – 閑散期に縮退できるシステムは積極的に検討し、 クラウドの利点を活⽤ ü ⾃前で構築すべきかどうかを⾒極める – SaaS, PaaSを活⽤して管理コスト削減 ü ライセンスはクラウド対応かどうかを確認 – 移⾏できない場合あり。事前の調査が重要 75
- 76. 調達
- 78. 契約方法 78 ü クレジットカードで申込むとすぐに環境が使えるようになるので、SIer の作業開始の前⽇に登録を⾏った。しかし、何故かクレジットカードの 審査が通らないという。同カードは、別件で正常に使えているのに。 ü クラウドベンダーとの英語でのやりとりで、なかなか進展せず、SIerに アカウント情報を渡さないといけないのにもう間に合わない。 ü 夜中にリモートで申込みして、会社にかかってきた確認の電話に出れな かった など クラウド環境にサーバーを構築する前にやるべきこと → クラウドサービスに申し込んで、アカウントを取得する」 準備するもの ü 会社のクレジットカード情報 ü 電話で英語対応可能な⼈（SoftLayerの場合） 確認すること ü 会社はクレジットカードでの⽀払いが問題ないか？ ü ドル請求は対応可能か？（Azureは円も対応） ü 電話での確認／問合せに英語で対応できる⼈がいる？（SoftLayerの場合） → 上記が⼀つでもNGな場合は、「請求代⾏サービス」を利⽤する。 ü 請求書の円払い、⽉末締めで処理したい場合は、このサービスで対応してくれる。
- 79. ベンダー選定 79 ü A社と詰めていた内容をB社に伝えて相⾒積もりをお願いした。B社 の⽅が⼤幅に安いのでB社に発注。 ü B社構築後、A社と合意していた内容までやっていないことが、納品 後に発覚。 ü B社に確認したところ、それは別⾒積とのこと。実は、トータルでA 社の⽅が安かった。 何を基準にベンダーを選定すれば良いのか Ø 検討の段階から⽀援してくれるか？ Ø クラウド環境の構築経験があるか？ ü 4⼤クラウドのいずれかの経験があれば、他のクラウドもほとんど対応可能。 ü 実績がないSIerに依頼する時は、SIerの事前調査費⽤（お勉強費⽤）やリス ク費⽤までのせられないように気を付ける。 ü ⼿間ではあるが、3社くらいに相⾒積もりをとって判断する。 ※（クラウドに限った話ではないが）相⾒積もりの場合、⾒積の範囲が異なる場合があるので 要注意。作業詳細をもらい、作業内容を⽐較する。
- 80. ベンダー選定（参考） 80 A社 ： 600万円 B社 ： 490万円 ファイルサーバー移⾏作業⼀式 Ø Active Directory導⼊ Ø ファイルサーバー単純移⾏ （ディレクトリ構成は現状維持） Ø ⽤途別にファイルサーバーを分割 Ø バックアップサーバー導⼊ Ø 共有フォルダのボリュームシャド ウコピー機能導⼊ Ø WSUSサーバー移⾏ （グループポリシーによる⾃動設定） Ø ディレクトリ構成の再設計 Ø 変更後の構成へのデータ移⾏ （フォルダ移動） ファイルサーバー移⾏作業⼀式 実は、以下の2項⽬は対象外 後から 追加依頼したら ＋240万円 Ø ディレクトリ構成の再設計 Ø 変更後の構成へのデータ移⾏ （フォルダ移動） 合計： 710万円
- 81. 調達時の検討事項 – まとめ ü費⽤の⽀払⽅法 – 会社のクレジットカードが利⽤可能か – クレジットカードの登録は余裕をもって – 英語の対応がある可能性あり – 請求代⾏サービスの検討 üベンダー選定 – SOW（statement/Scope of work / 作業範 囲記述書）をしっかり – 合⾒積の場合は提案レベルの差に注意 81
- 82. 調達時の検討事項 SOW(Statement/Scope of Work)の例 82 作業内容 担当 期間 基本設計 A社 詳細設計 A社 クラウドのオーダー ⾃社（担当：XXさん） ネットワーク設定 ロードバランサー/ファイアーウォール VPN B社 B社 OS設定 OS ミドルウェア/アプリケーション A社 C社 ストレージ設定/データベース設定 A社 バックアップ A社 システムテスト A社/⾃社
- 83. 構築
- 84. 構築時の注意事項 ü 各種⼿続きのリードタイム ü クラウドのオーダー ü パフォーマンス ü 監視 ü 権限設定 ü セキュリティ ü そのほか 84
- 85. 早めの社内申請や付帯手続き 85 ü T担当者「本社のIT部⾨が管理（または外部へ委託）していて、今⽇ 申請したんですが、数⽇かかります。」 ü SIer「切替作業できませんよ。」 ※DNS設定実施⽇が⽉2回の固定という会社もある。 今までの感覚でやっていると構築作業に間に合わない オンプレでは発注してからハードウェアが届く間の2週間〜1ヶ⽉という期間が、クラ ウドになると0⽇になる。 Ø DNSの切替 ü DNS申請に関して事前に把握しておく p DNSの管理者 p 申請⽅法 p 申請から実施までの⽇数 Ø SSL証明書 ü SSL証明書は事前に検討＆購⼊準備をしておく p SSL証明書の価格は提供元によって違うので、⽐較して選定しておくのがお勧め。 p クラウドベンダーでSSL証明書を有償オプションで提供しているところもあるが、 安くはない。 SIer「サーバーに設定するのでSSL証明書の情報ください。」 IT担当者「あー、これから買います。ちなみに今はいくらくらいで買え ますか？どこで買うのがお勧めですか？」 SIer「https設定＆接続確認作業は後⽇で・・・」 ※検討＆購⼊申請に数⽇かかる会社もある。
- 89. 監視設計 89 監視機能はクラウドサービスが提供する標準監視だけで⼤丈夫？ クラウドサービスに標準監視はついているが・・・ クラウドサービスの標準監視 Ø 標準でPING監視などついているが、品質がよくないクラウドベンダーもあるため 通知がしっかりと機能するか確認する Ø 重要なシステムには個別で監視システムを検討する ※クラウドサービス標準監視以外の拡張した監視はインターネット経由でないと監視ができない ※従来のデータセンター内部の専⽤ネットワークからの監視は対応していない Ø DirectLinkなどで専⽤回線経由での監視を検討する。その際、監視ベンダーへも回 線をひく必要ある。
- 91. セキュリティを考慮 91 とんでもない請求額が来たので、確認したら通信料がすごいことに。 → サーバーを乗っ取られて、⼤量の通信が発⽣していた。 クラウド環境はパブリックからアクセスできて便利だが・・・ アクセス制御 Ø インスタンスオーダー後、アクセス制御は個別設定する必要がある。 Ø SoftLayerはフルオープン、その他のクラウドも22番が空いているのでアクセス元 制御をかける必要あり。 Ø 多くのパブリッククラウドでは、課⾦が⼀定額以上に達したらメール通知する機能 ある為、設定をしておくと安⼼。 Ø SoftLayerでは、アタックされた費⽤は請求されない様にする保険（$5）を設定す ることが可能。 テスト⽤なのであまりセキュリティを気にせず、アクセス元制御をかけ ていなかった。 → 「DNS Amp Attack」の踏み台にされてしまい、攻撃を受けて いる会社からクレームが来てしまった。
- 93. 構築時の注意事項 – まとめ ü各種⼿続きのリードタイム – 社内外ともに、⼿続きに時間を要するものがある。 事前に確認、余裕をもって対応 üクラウドのオーダー – オーダー後すぐに利⽤できないサービスもあり。 事前に確認 – オーダー内容と構成が異なる可能性あり。事前調 整が必要なものもある üパフォーマンス – 達成すべきパフォーマンス要件を満たせない場合 は占有型の検討を 93
- 94. 構築時の注意事項 – まとめ ü監視 – 死活監視、リソース監視を意識しよう。死活監視 はクラウド側で標準提供のものもある – サービスによっては独⾃に監視を構築 ü権限設定 – 誤操作防⽌ üセキュリティ – クラウドはインターネットに接続されていること を意識し、適切に対策しよう üそのほか – クラウド標準のインターフェイスは変わる可能性 あり 94
- 96. 運⽤
- 97. 早めの社内申請や付帯手続き 97 ハイパーバイザーの脆弱性対応で、再起動祭り。SoftLayerは、データ センターごとに再起動がかかる。 各クラウドに合わせた冗⻑構成を検討 クラウド環境はハイパーバイザーが冗⻑化されているなど、なるべく停⽌しない作り になっているが、100％とまらないわけではない Ø SoftLayerの場合 ：データセンターをわける Ø Azureの場合 ：可⽤性セットというグループ化をすることで、サーバーが同 時に落ちない様に設定可能、更にBCP対策が必要な場合は、更にリージョンを分け ることも可能 Ø AWSの場合 ：複数のAZにインスタンスを設置する Ø GCPの場合 ：複数のAZにインスタンスを設置する ネットワークのメンテナンスで、⼀時的にサーバー使⽤停⽌になった。
- 98. 運用に関する補足事項 停⽌のたびにIPが変更される → 固定IPアドレスのサービスが提供されているので、別途購⼊する。 開発の⽅にテストサーバーを次々建てられて、とんでもない⾦額になる → サーバーを建てられるアカウント権限を制限する 不要になったテストサーバー削除のためにインスタンスは消したけど、付随するサー ビスの消し忘れで余計な課⾦が発⽣（Storage、Public IP） → オーケストレーションツールを⼊れる → 教育の徹底
- 100. 100 計画書・企画書作りの勘所
- 101. クラウドを利用する目的 101 投資コスト（CapEX）の削減 運⽤コスト（OpEX）の削減 ベストミックスの実現 コスト削減から競争⼒の強化へ l 保有（資産化）から利⽤（サービス化） l 変更に伴うリスク回避 l 利⽤サービスの選別 l ⾃動化の促進 l 標準化・共通化（プラットフォーム化） l ハイブリットクラウド l マルチクラウド l サービス間の連携 l 守りのITから攻めのITへ l テクノロジーを活かした事業の差別化 ⾃社で所有することの限界 Ø ガバナンスとセキュリティ Ø 災害対応（Disaster Recovery） Ø グローバル展開 l 利⽤状況の徹底した⾒える化 l 少ない投資コストでの災害対応 l フラットなグローバルサービス
- 102. クラウドのメリットを経営層にどう伝えるか 102 ⾃社で所有することの限界 Ø ガバナンスとセキュリティ Ø 災害対応（Disaster Recovery） Ø グローバル展開 l 利⽤状況の徹底した⾒える化 Ø システム利⽤の状況やリスクを把握しやすい Ø 必要な対策を事実に基づいて⾏える Ø ⾼度なセキュリティ認証に対応している（⾼度なスキル・⾼額なコスト） l 少ない投資コストでの災害対応 Ø ⾼度な災害対応を施した施設にて運⽤ Ø 複数の独⽴したアベイラビリティゾーン Ø 国内外の分散レプリケーション可能、しかもアップロードコストは不要 l フラットなグローバルサービス Ø 世界中にデータセンター Ø 世界中で同⼀のアーキテクチャ Ø マルチクラウド化によりさらなるリスク分散
- 103. クラウドのメリットを経営層にどう伝えるか 103 投資コスト（CapEX）の削減 l 保有（資産化）から利⽤（サービス化） Ø 初期投資が抑制される Ø 資産を経費化できる l 変更に伴うリスク回避 Ø 使⽤量に応じた従量課⾦ Ø アプリケーション機能の変更や負荷の変動に柔軟に追従できる
- 104. クラウドのメリットを経営層にどう伝えるか 104 運⽤コスト（OpEX）の削減 l 利⽤サービスの選別 Ø 低コストのデータセンターで運⽤されるためコスト削減が⾏いやすい Ø 最適なサービスを選択し組み合わせることができる ü ⽬的や予算などの条件 ü 利⽤スキルの習熟度 ü サービス・レベル l ⾃動化の促進 Ø 広範な⾃動化ツールを利⽤できる ü 運⽤監視 ü 構成管理 ü 変更管理など l 標準化・共通化（プラットフォーム化） Ø 運⽤管理や開発・実⾏環境の運⽤コストが削減できる Ø システムの調達・構築や変更のコストが削減できる Ø PaaSを活⽤することで開発や保守のコストが削減できる
- 105. クラウドのメリットを経営層にどう伝えるか 105 ベストミックスの実現 l ハイブリットクラウド Ø プライベートクラウド ü コンプライアンス ü レイテンシー ü 運⽤管理の⾃由度など Ø パブリッククラウド ü コスト ü サービス機能 ü グローバル対応 など l マルチクラウド Ø サービス機能やコストなどの特性に応じた使い分け l サービス間の連携 Ø EBS（Enterprise Service Bus）による疎結合 Ø セルフサービスポータルや統合管理ツール（オーケストレーター）
- 106. クラウドのメリットを経営層にどう伝えるか 106 コスト削減から競争⼒の強化へ l 守りのITから攻めのITへ Ø 最新のテクノロジーを活かした事業の差別化ができる Ø グローバル展開が容易に、迅速にできる Ø 構築や保守のスピードが早く、ビジネス環境の変化に即応できる l テクノロジーを活かした事業の差別化 Ø 新しいサービスモデルを構築できる Ø 最新のテクノロジーがクラウドから提供される
- 107. 予算はどう変わるのか 107 データセンター or ⾃社のサーバールーム 「資産」から「経費」への転換 l プログラム・ライセンス（経費） l プログラム・サポート（経費） l 運⽤管理/派遣（経費） l システム開発（資産） l ハードウェア資産（資産） l サブスクリプション（経費） l システム開発（資産） l マネージド・サービス（経費） 経費は⼯夫と改善で 継続的に削減可能
- 108. クラウド時代の情報システム人材の活かし方 108 戦略・企画 業務分析 システム設計 アプリケーション開発 インフラ プラットフォーム構築 保守 運⽤管理 ヘルプデスク 現場サポート 戦略・企画 業務分析 システム設計 アプリケーション開発 「攻めのIT活⽤」拡⼤ インフラ・プラットフォーム構築 保守 運⽤管理 ヘルプデスク 現場サポート Ø 情報システム部⾨の機能と役割を再定義 Ø 経営企画や業務戦略スタッフとの⼈材交流 Ø 業務部⾨との⼈材交流 Ø アジャイル開発 Ø ⾼速開発ツールやPaaSの活⽤ Ø SaaSの活⽤ Ø シチズン・デベロッパーの育成 Ø ホステッド・プライベートクラウド Ø ⾃動化 Ø DevOps Ø ⾼速開発ツールやPaaSの活⽤ Ø SaaSの活⽤ システム・アーキテクト ビジネス・アーキテクト ビジネス価値を明らかにし、最適なビジネス・プロセ ス描き、それを実現するシステムをデザインする。 テクノロジーやサービスに精通し、それらを⽬利きで き、最適なシステムをデザインする。
- 109. 情報収集のための 参考情報
- 110. Amazon Web Services(ＡＷＳ) ■JAWS-UG（AWS User Group Japan） http://jaws-ug.jp/ ■AWSクラウドデザインパターン http://aws.clouddesignpattern.org/index.php/%E3%83%A1%E3%82%A4%E 3%83%B3%E3%83%9A%E3%83%BC%E3%82%B8 ■Amazon Web Services ブログ http://aws.typepad.com/aws_japan/
- 112. Microsoft Azure ■Microsoft Virtual Academy（Microsoft Azure） http://www.microsoftvirtualacademy.com/product-training/product- windows-azure-jp ■Microsoft社主催 Azureセミナー https://azure.microsoft.com/ja-jp/community/events/ ■Azure⾃習書 https://www.microsoft.com/ja-jp/server-cloud/azure/Try/self-learning.aspx ■Microsoft Azure サポート チーム サイト http://blogs.msdn.com/b/dsazurejp/
- 113. Google Cloud Platform ■Google Cloud Platform Japan Blog http://googlecloudplatform-japan.blogspot.jp/ ■GCP JP(@googlecloud_jp)Twitter https://twitter.com/googlecloud_jp ■apps-gcp http://www.apps-gcp.com/ ■無料説明会 http://google-training.jp/cloud-platform/briefings ■無料ハンズオン http://www.cloud-ace.jp/event/
- 114. お問い合わせ 114 クリエーションライン株式会社 http://www.creationline.com/ info@creationline.com ネットコマース株式会社 http://www.netcommerce.co.jp/ saito@netcommerce.co.jp l 情報システム部門の戦略策定支援 l ITベンダーの事業戦略策定支援 l テクノロジーや営業スキル育成研修 など l クラウドインテグレーション l クラウドプラットフォームの構築 l OSS等を活かしたシステム開発 など