仮想化専門コンサルタントが教える 「成功するエンタープライズ

クラウド環境構築のポイント」

日本仮想化技術株式会社 代表取締役社長兼CEO

宮原 徹 miyahara@VirtualTech.jp

代表略歴

•  本名：宮原 徹 •  1972年1月 神奈川県生まれ •  1994年3月 中央大学法学部法律学科卒業 •  1994年4月 日本オラクル株式会社入社

–  PCサーバ向けRDBMS製品マーケティングに従事 –  Linux版Oracle8の日本市場向け出荷に貢献

•  2000年3月 株式会社デジタルデザイン 東京支社長および株式会社アクアリウムコンピューター 代表取締役社長に就任 –  2000年6月 （株）デジタルデザイン、ナスダック・ジャパン上場

（4764） •  2001年1月 株式会社びぎねっと 設立 •  2006年12月 日本仮想化技術株式会社 設立 •  2008年10月 IPA「日本OSS貢献者賞」受賞 •  2009年10月 日中韓OSSアワード 「特別貢献賞」受賞

2

本日のアジェンダ

•  仮想化技術の現状 – ハイパーバイザー／ストレージ／ネットワーク

•  プライベートクラウドの課題 – 仮想化環境のサイロ化 – 継続的運用管理 – パブリッククラウドとの比較

•  エンタープライズクラウド構築の検討すべきポイント – OpenStackやその他の技術の評価

3

エンタープライズクラウドとは

•  企業のシステム基盤としてのクラウド環境 •  単なる仮想化環境ではなく、ITアーキテ

クチャの再構築を伴って、自動化、標準化を推し進めた次世代のシステム基盤

•  パブリックやオンプレミスといった形態にとらわれず、best-of-breedな環境を目指す取り組み

4

仮想化技術の現状

5

サーバ仮想化は普及段階に

•  ハードウェアの仮想化最適化 –  マルチコアCPU・大容量メモリ搭載

•  大規模なシステムほど仮想化に移行済み –  中小規模システムの仮想化移行フェーズに –  パブリッククラウドサービス利用も促進

•  仮想化の導入よりも運用管理に悩み –  性能不足・容量不足 –  障害対応・BCP対応

•  一層のランニングコスト削減要請 –  省電力サーバへの変更による電力コスト削減 –  高集約環境へのV2V移行による仮想インフラ再圧縮

6 V2V:Virtual to Virtual

ハイパーバイザーの最新動向

•  VMware vSphere 5.5の新機能 –  vSphere Flash Read Cache

•  SSD領域をReadキャッシュとして利用 –  vSphere AppHA

•  DB／Web監視と再起動 – 無償版ESXiのメモリ制限が無くなる（らしい）

•  ESXi 5.0では8GB、ESXi 5.1では32GB制限 •  Hyper-V 2012の登場

–  Windows Server 2012に搭載 – 機能面でvSphereを追従 –  Windows多用の場合、コスト面でメリット

7

ストレージの課題と注目技術

一層の大容量化 仮想ストレージ 重複排除

バックアップ／リカバリ D2Dバックアップ バックアップ統合

性能要求の高速化・多様化

SSD/NANDの採用 SANの高速化 分散ストレージ

BCP対策 遠隔複製機能 クラウドストレージ

8

ネットワークの課題と注目技術

通信量の増加 10Gイーサネット InfiniBand

仮想ネットワークの一元管理

分散仮想スイッチ OpenFlow ファブリック

BCP対策 高速WAN

モバイル 高速ワイアレス通信

9

プライベートクラウドの課題

10

プライベートクラウドの課題

•  仮想化環境のサイロ化による煩雑さ – 似て異なる仮想化環境の乱立 – 社内標準不在のVM増殖

•  継続的運用保守の困難さ – 硬直的なリソース追加 – 障害対応によるネガティブコスト

•  パブリッククラウドとの比較 –  「所有しない」経営の要請 –  apple-to-appleの比較になっているか？

11

仮想化環境のサイロ化

•  仮想化環境の乱立 – 業務システム毎、部門毎の仮想化環境構築と

P2V移行 – ネットワーク環境は既存構成を継続

•  標準の不在 – 導入時期毎に異なるサーバー、ストレージ – 標準化されていないミドルウェア – 統合されていない運用管理

12

継続的運用保守の課題

•  継続的なリソース管理 – ストレージ不足の頻発 – 弾力的なリソース追加が必要

•  不規則に発生する障害対応 – ディスク障害、電源障害の頻発 – 問題切り分けから解決までの期間の長期化

•  慢性的な運用管理担当者の不足・不在 – 業務まで理解したアウトソース先の確保？ – 運用管理コストが真っ先にカットされる

13

パブリッククラウドとの比較

•  要件の再確認 – 適切なapple-to-appleの比較のために

•  パブリッククラウドのセキュリティや継続性に対する不信感・不安感の評価 – SLAではなく、万が一の場合の責任の所在 – リスクアセスメントの実施

•  適切なコスト比較 – キャッシュアウト抑制について経営的側面か

らの確認

14

参考）リスクアセスメントの実施

•  リスクアセスメント＝リスク分析＋リスク評価 •  リスク分析＝リスク因子（脅威と脆弱性）の

特定＋リスク算定 – 脅威：システム又は組織に危害を与える事故の

潜在的原因 – 脆弱性：脅威によって影響を受ける内在する弱さ –  リスク：ある脅威が脆弱性を利用して損害を与

える可能性

15

http://www.ipa.go.jp/security/manager/protect/pdca/risk_ass.html

パブリッククラウドのメリット

•  短期の利用 –  「持たない」ことによるメリット

•  迅速な配備 – セルフサービスポータル

•  大量のリソース要求 – ネットワークトラフィックに注意

•  物理的な分散 – BCPの一手段として

16

パブリッククラウドの落とし穴

•  従量課金 – ネットワーク課金 による「パケ死に」の可能性

•  決済方法 –  「固定課金」では取られすぎの可能性も

•  設計 – 性能が読めない – ネットワーク設計の制約

•  運用管理 – すべてをアウトソースできるわけではない

17

プライベートクラウドのコスト

•  半年、一年先を見越したサイジングが必要 – 必然的な結果として過剰な初期投資

•  導入資産の陳腐化が速い – 資産償却が資産価値下落に追いつかない

18

とあるコスト試算の一例

19

期間

費 用

プライベート パブリック

ユーザー視点でのクラウド資産

•  参考：「IFRSではクラウドをどう会計処理する？」 –  http://techtarget.itmedia.co.jp/tt/news/1111/17/

news05.html •  SaaSを利用している場合には資産計上不要 •  IasS/PaaS上に構築したアプリケーションな

どは無形ソフトウェア資産として計上 •  資産帰属先によって計上方法が異なるの

で留意 20

IFRSとクラウドのかかわり（引用）

21

出典：http://image.itmedia.co.jp/l/st/tt/news/1111/17/l_tm_ifrs67076_01.png

プライベートとパブリックの比較

プライベート パブリック

初期導入構成 事前にキャパシティを見込んだサイジング

スモールスタート可能

初期導入コスト 資産として初期投資が必要 初期投資を抑制できる

資産コスト 資産として計上、償却が必要（リースを除く）

資産計上不要部分があり、費用として計上可能

運用管理形態 自社運用ないしマネージドサービス

マネージドサービス

運用管理コスト 費用として計上 費用として計上

トータルコスト 短期的にはキャッシュアウトが必要だが、長期保有でメリット

短期的なキャッシュアウトを抑制できるが、長期的にはコスト増

22

エンタープライズクラウド構築の検討すべきポイント

23

エンタープライズクラウドの意義

•  仮想化基盤の統合 •  運用管理の自動化 •  システム標準化 •  セルフサービス

24

ITアーキテクチャの再構築

準備フェーズ

•  現行IT資産の棚卸し – 優良資産と不良資産の仕分け – 基盤統合の青写真を描く

•  コスト構造の明確化 – 省ける無駄の抽出 – 基盤統合や自動化によるコスト削減

•  ビジネスに貢献するIT基盤の定義

– システム要件だけでなくビジネス要件も

25

仮想化基盤の統合

•  マルチハイパーバイザーの検討 – 既存環境と新規環境の切り分け – ゆるやかにV2V移行

•  パブリッククラウドの有効活用 – 現状、パブリックとプライベートの間の頻繁な行

き来は現実的ではない？ – 目的別による使い分け

•  統合管理システムの構築 – 垂直統合型システム導入の検討 – ハードウェアに限らないシステム全体に対しての

best-of-breedの追求 26

運用管理の自動化

•  オーケストレーションの重要性が高まる –  VM、OS、アプリケーション、ネットワーク、ストレ

ージなどを一括配備（プロビジョニング） – 俊敏性の確保

•  手作業の排除 – 自動化できるものは自動化する –  1回きりの作業でも極力自動化？

•  サービスカタログの構築 – 単なるIaaS提供・利用ではなく、サービスという

観点でのITインフラ構築 – 業務とサービスの対応関係を重視

27

システムの標準化

•  俊敏性や保守性を考慮すれば標準化は避けて通れないプロセス – でも、なかなか着手できない、定着しない

•  プロジェクト毎の特殊性をどこまで排除／許容するのか – システムの硬直性を生み出さないか – 逆に不都合をもたらさないか

•  仮想マシンの標準テンプレート作成、修正のプロセスの標準化から – 継続的にオーケストレーション、サービスカタロ

グへと発展させる

28

セルフサービス

•  運用管理の効率化とシステム乱立のトレードオフを考慮 – 運用管理をどこまでユーザー側に任せるか – 中央集権型か、ユーザー自治型かの選択 – 乱立を抑制するためコストの明確化が必要

•  課金システムとの連動 – 自社・グループ企業内でも利用料課金

– 利用状況監視の粒度は？

29

OpenStackの評価

•  大規模プロビジョニングツールとして有効 •  OpenStackのみでエンタープライズクラウ

ド環境をまかなうことはできない – ネットワーク：Neutron経由でOpenFlowなど

各種ネットワーク技術との連携が必要 – 監視：日本で人気はZabbix連携？課金系は

Ceilometerが使い物になってくれば – 自動化：Chefが注目されているが、今後は

Heatが使われるようになっていく？

30

ネットワーク

•  基盤統合することによりネットワーク接続性の重要性は高まる – 自動化による確実なネットワーク設定 – ネットワーク分離の要不要とオーバーレイネット

ワーク等の検討 •  大括りでのSDNやNFVは短期的には検討

対象には入らない？ – 直接のターゲットはDCや通信事業者 –  BCP/DR実現のために必要？ –  DC・通信事業者が提供するサービスを（透過

的に）利用する可能性があるぐらい？

31

ストレージ

•  従来の仮想化統合と変わらないが、目的別に複数用意する可能性を検討 –  SSD・NANDを活用した高速ストレージ –  HDDを使用した大容量ストレージ – 分散型ストレージやオブジェクトストレージの活用 – オーケストレーションとの連動

•  大容量化に伴うバックアップ／リカバリ時間増大にどう対処するか – 動作継続性の観点からリカバリを行う時間が無

い場合も – ストレージ複製技術・CDPなどの活用

32 CDP:Continuous data protection

今後進展するXaaS化

•  仮想化、自動化、標準化の流れの先にあるのは各種コンポーネントのXaaS化 – DBaaSやLBaaSなど

•  専用ハードからハードウェアアプライアンス、仮想アプライアンスへの流れ –  ex)OpenFlow対応スイッチ – ストレージもSDS(Software-Defined Storage)に

•  GlusterやCeph、Swiftなどに注目

33

まとめ

•  エンタープライズクラウド環境構築とはITアーキテクチャの再構築である

•  仮想化から自動化、標準化への流れ •  ハイブリッドクラウド構築や垂直統合型

システム導入の検討は一つの試金石となるか？

34

今後の活動

•  OpenStackおよびBaremetal OpenStack導入検討のためのプログラム実施 –  動作デモ –  テクニカルディスカッション –  導入ハンズオン など

•  各種検討・検証成果の公開 •  外部機能開発と成果物のOSS化

35

お気軽にご依頼ください

お問い合わせ先

「OpenStackについて、どこに相談すればいいの？」

まずは我々にご相談ください

http://VirtualTech.jp/ sales@VirtualTech.jp

050-7571-0584 36