Upcoming SlideShare
仮想化専門コンサルタントが教える「成功するエンタープライズクラウド環境構のポイント」
- 1. 仮想化専門コンサルタントが教える 「成功するエンタープライズ クラウド環境構築のポイント」 日本仮想化技術株式会社 代表取締役社長兼CEO 宮原 徹 miyahara@VirtualTech.jp
- 2. 代表略歴 • 本名：宮原 徹 • 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
- 3. 本日のアジェンダ • 仮想化技術の現状 – ハイパーバイザー／ストレージ／ネットワーク • プライベートクラウドの課題 – 仮想化環境のサイロ化 – 継続的運用管理 – パブリッククラウドとの比較 • エンタープライズクラウド構築の検討すべ きポイント – OpenStackやその他の技術の評価 3
- 4. エンタープライズクラウドとは • 企業のシステム基盤としてのクラウド環境 • 単なる仮想化環境ではなく、ITアーキテ クチャの再構築を伴って、自動化、標準 化を推し進めた次世代のシステム基盤 • パブリックやオンプレミスといった形態に とらわれず、best-of-breedな環境を目指 す取り組み 4
- 5. 仮想化技術の現状 5
- 6. サーバ仮想化は普及段階に • ハードウェアの仮想化最適化 – マルチコアCPU・大容量メモリ搭載 • 大規模なシステムほど仮想化に移行済み – 中小規模システムの仮想化移行フェーズに – パブリッククラウドサービス利用も促進 • 仮想化の導入よりも運用管理に悩み – 性能不足・容量不足 – 障害対応・BCP対応 • 一層のランニングコスト削減要請 – 省電力サーバへの変更による電力コスト削減 – 高集約環境へのV2V移行による仮想インフラ再圧縮 6V2V:Virtual to Virtual
- 7. ハイパーバイザーの最新動向 • 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
- 8. ストレージの課題と注目技術 一層の大容量化 仮想ストレージ 重複排除 バックアップ／リカバリ D2Dバックアップ バックアップ統合 性能要求の高速化・多 様化 SSD/NANDの採用 SANの高速化 分散ストレージ BCP対策 遠隔複製機能 クラウドストレージ 8
- 9. ネットワークの課題と注目技術 通信量の増加 10Gイーサネット InfiniBand 仮想ネットワークの一元 管理 分散仮想スイッチ OpenFlow ファブリック BCP対策 高速WAN モバイル 高速ワイアレス通信 9
- 10. プライベートクラウドの課題 10
- 11. プライベートクラウドの課題 • 仮想化環境のサイロ化による煩雑さ – 似て異なる仮想化環境の乱立 – 社内標準不在のVM増殖 • 継続的運用保守の困難さ – 硬直的なリソース追加 – 障害対応によるネガティブコスト • パブリッククラウドとの比較 – 「所有しない」経営の要請 – apple-to-appleの比較になっているか？ 11
- 12. 仮想化環境のサイロ化 • 仮想化環境の乱立 – 業務システム毎、部門毎の仮想化環境構築と P2V移行 – ネットワーク環境は既存構成を継続 • 標準の不在 – 導入時期毎に異なるサーバー、ストレージ – 標準化されていないミドルウェア – 統合されていない運用管理 12
- 13. 継続的運用保守の課題 • 継続的なリソース管理 – ストレージ不足の頻発 – 弾力的なリソース追加が必要 • 不規則に発生する障害対応 – ディスク障害、電源障害の頻発 – 問題切り分けから解決までの期間の長期化 • 慢性的な運用管理担当者の不足・不在 – 業務まで理解したアウトソース先の確保？ – 運用管理コストが真っ先にカットされる 13
- 14. パブリッククラウドとの比較 • 要件の再確認 – 適切なapple-to-appleの比較のために • パブリッククラウドのセキュリティや継続 性に対する不信感・不安感の評価 – SLAではなく、万が一の場合の責任の所在 – リスクアセスメントの実施 • 適切なコスト比較 – キャッシュアウト抑制について経営的側面か らの確認 14
- 15. 参考）リスクアセスメントの実施 • リスクアセスメント＝リスク分析＋リスク評価 • リスク分析＝リスク因子（脅威と脆弱性）の 特定＋リスク算定 – 脅威：システム又は組織に危害を与える事故の 潜在的原因 – 脆弱性：脅威によって影響を受ける内在する弱さ – リスク：ある脅威が脆弱性を利用して損害を与 える可能性 15 http://www.ipa.go.jp/security/manager/protect/pdca/risk_ass.html
- 16. パブリッククラウドのメリット • 短期の利用 – 「持たない」ことによるメリット • 迅速な配備 – セルフサービスポータル • 大量のリソース要求 – ネットワークトラフィックに注意 • 物理的な分散 – BCPの一手段として 16
- 17. パブリッククラウドの落とし穴 • 従量課金 – ネットワーク課金 による「パケ死に」の可能性 • 決済方法 – 「固定課金」では取られすぎの可能性も • 設計 – 性能が読めない – ネットワーク設計の制約 • 運用管理 – すべてをアウトソースできるわけではない 17
- 18. プライベートクラウドのコスト • 半年、一年先を見越したサイジングが必要 – 必然的な結果として過剰な初期投資 • 導入資産の陳腐化が速い – 資産償却が資産価値下落に追いつかない 18
- 19. とあるコスト試算の一例 19 期間 費 用 プライベート パブリック
- 20. ユーザー視点でのクラウド資産 • 参考：「IFRSではクラウドをどう会計処理 する？」 – http://techtarget.itmedia.co.jp/tt/news/1111/17/ news05.html • SaaSを利用している場合には資産計上不要 • IasS/PaaS上に構築したアプリケーションな どは無形ソフトウェア資産として計上 • 資産帰属先によって計上方法が異なるの で留意 20
- 21. IFRSとクラウドのかかわり（引用） 21 出典：http://image.itmedia.co.jp/l/st/tt/news/1111/17/l_tm_ifrs67076_01.png
- 22. プライベートとパブリックの比較 プライベート パブリック 初期導入構成 事前にキャパシティを見込ん だサイジング スモールスタート可能 初期導入コスト 資産として初期投資が必要 初期投資を抑制できる 資産コスト 資産として計上、償却が必要 （リースを除く） 資産計上不要部分があり、費 用として計上可能 運用管理形態 自社運用ないしマネージド サービス マネージドサービス 運用管理コスト 費用として計上 費用として計上 トータルコスト 短期的にはキャッシュアウト が必要だが、長期保有でメ リット 短期的なキャッシュアウトを 抑制できるが、長期的にはコ スト増 22
- 23. エンタープライズクラウド構築の 検討すべきポイント 23
- 24. エンタープライズクラウドの意義 • 仮想化基盤の統合 • 運用管理の自動化 • システム標準化 • セルフサービス 24 ITアーキテクチャの再構築
- 25. 準備フェーズ • 現行IT資産の棚卸し – 優良資産と不良資産の仕分け – 基盤統合の青写真を描く • コスト構造の明確化 – 省ける無駄の抽出 – 基盤統合や自動化によるコスト削減 • ビジネスに貢献するIT基盤の定義 – システム要件だけでなくビジネス要件も 25
- 26. 仮想化基盤の統合 • マルチハイパーバイザーの検討 – 既存環境と新規環境の切り分け – ゆるやかにV2V移行 • パブリッククラウドの有効活用 – 現状、パブリックとプライベートの間の頻繁な行 き来は現実的ではない？ – 目的別による使い分け • 統合管理システムの構築 – 垂直統合型システム導入の検討 – ハードウェアに限らないシステム全体に対しての best-of-breedの追求 26
- 27. 運用管理の自動化 • オーケストレーションの重要性が高まる – VM、OS、アプリケーション、ネットワーク、ストレ ージなどを一括配備（プロビジョニング） – 俊敏性の確保 • 手作業の排除 – 自動化できるものは自動化する – 1回きりの作業でも極力自動化？ • サービスカタログの構築 – 単なるIaaS提供・利用ではなく、サービスという 観点でのITインフラ構築 – 業務とサービスの対応関係を重視 27
- 28. システムの標準化 • 俊敏性や保守性を考慮すれば標準化は避 けて通れないプロセス – でも、なかなか着手できない、定着しない • プロジェクト毎の特殊性をどこまで排除／ 許容するのか – システムの硬直性を生み出さないか – 逆に不都合をもたらさないか • 仮想マシンの標準テンプレート作成、修正 のプロセスの標準化から – 継続的にオーケストレーション、サービスカタロ グへと発展させる 28
- 29. セルフサービス • 運用管理の効率化とシステム乱立のト レードオフを考慮 – 運用管理をどこまでユーザー側に任せるか – 中央集権型か、ユーザー自治型かの選択 – 乱立を抑制するためコストの明確化が必要 • 課金システムとの連動 – 自社・グループ企業内でも利用料課金 – 利用状況監視の粒度は？ 29
- 30. OpenStackの評価 • 大規模プロビジョニングツールとして有効 • OpenStackのみでエンタープライズクラウ ド環境をまかなうことはできない – ネットワーク：Neutron経由でOpenFlowなど 各種ネットワーク技術との連携が必要 – 監視：日本で人気はZabbix連携？課金系は Ceilometerが使い物になってくれば – 自動化：Chefが注目されているが、今後は Heatが使われるようになっていく？ 30
- 31. ネットワーク • 基盤統合することによりネットワーク接続性 の重要性は高まる – 自動化による確実なネットワーク設定 – ネットワーク分離の要不要とオーバーレイネット ワーク等の検討 • 大括りでのSDNやNFVは短期的には検討 対象には入らない？ – 直接のターゲットはDCや通信事業者 – BCP/DR実現のために必要？ – DC・通信事業者が提供するサービスを（透過 的に）利用する可能性があるぐらい？ 31
- 32. ストレージ • 従来の仮想化統合と変わらないが、目的別 に複数用意する可能性を検討 – SSD・NANDを活用した高速ストレージ – HDDを使用した大容量ストレージ – 分散型ストレージやオブジェクトストレージの活用 – オーケストレーションとの連動 • 大容量化に伴うバックアップ／リカバリ時間 増大にどう対処するか – 動作継続性の観点からリカバリを行う時間が無 い場合も – ストレージ複製技術・CDPなどの活用 32 CDP:Continuous data protection
- 33. 今後進展するXaaS化 • 仮想化、自動化、標準化の流れの先に あるのは各種コンポーネントのXaaS化 – DBaaSやLBaaSなど • 専用ハードからハードウェアアプライア ンス、仮想アプライアンスへの流れ – ex)OpenFlow対応スイッチ – ストレージもSDS(Software-Defined Storage)に • GlusterやCeph、Swiftなどに注目 33
- 34. まとめ • エンタープライズクラウド環境構築とはIT アーキテクチャの再構築である • 仮想化から自動化、標準化への流れ • ハイブリッドクラウド構築や垂直統合型 システム導入の検討は一つの試金石と なるか？ 34
- 35. 今後の活動 • OpenStackおよびBaremetal OpenStack導入検 討のためのプログラム実施 – 動作デモ – テクニカルディスカッション – 導入ハンズオン など • 各種検討・検証成果の公開 • 外部機能開発と成果物のOSS化 35 お気軽にご依頼ください
- 36. お問い合わせ先 「OpenStackについて、どこに相談すればいいの？」 まずは我々にご相談ください http://VirtualTech.jp/ sales@VirtualTech.jp 050-7571-0584 36
Login to see the comments