ガートナー ジャパン
メインメニュー ホーム リサーチ コンサルティング ベンチマーク エグゼクティブ プログラム イベント 会社情報 メインメニュー
SAMPLE RESEARCH

サンプル・リサーチ

ソフトウェア・デファインド・データセンターの価値とは

インフラストラクチャ (INF) /INF-14-182
Research Note
D. Scott, D. Russell, J. Skorupa, P. Dawson,
N. MacDonald
掲載日:2015年4月14日/発行日:2014年12月10日

本リサーチ分析レポートのテーマに関心をお持ちの方は、2015年5月26(火)〜28日(木)に開催する 「ガートナー ITインフラストラクチャ & データセンター サミット 2015」のページを是非ご覧ください。(イベント終了後も開催実績としてご覧いただけます)


「SDx」は業界の新たな流行語となっている。本リサーチノートでは、ベンダーの「マーケテクチャ」をひと通り紹介し、ソフトウェア・デファインド・データセンターとその価値提案、および、ベンダーのハイプや製品を識別する手掛かりとして企業が利用できる主な特性を明らかにする。


要約


主要な所見

  • ソフトウェアで定義された何か(SDx)は、ソフトウェア・デファインド・アプリケーション・サービス(SDAS)とソフトウェア・デファインド・インフラストラクチャ(SDI)で構成される。ソフトウェア・デファインド・データセンター(SDDC)はSDIを構成する要素の1つであり、(市場ではなく)アーキテクチャの観点から捉えたアプローチである。
  • SDDCの主な価値は、データセンターおよびファシリティのインフラストラクチャをポリシー・ベースで自動化することにより、俊敏性が実現される点にある。
  • SDDCは成熟過程の初期段階にあり、今後5年間に大幅な変化を遂げる。
  • SDDCは、管理統制とサービスをハードウェア・インフラストラクチャから分離するため、インフラストラクチャの自動化や最適化といった、ソフトウェア・レイヤにおけるイノベーションを実現する可能性を秘めている。
  • SDDCは仮想化の範疇を超えるものであり、クラウド・サービス・インフラストラクチャの自動化に利用できる。ただし、自動化という成果を得る上では、SDDC以外の自動化アーキテクチャが利用される可能性もある。

推奨事項

  • タイプA(先進的)企業は、特に仮想化やクラウド・コンピューティングやアジャイルな方法論という観点から、またはデータセンターを新規構築する際に、SDDCの評価を実施する。タイプB(主流型)およびタイプC(追随型)企業は、市場が成熟期を迎えるまで2〜3年間は状況を見守り、その後で大規模な導入に着手する。
  • 自社のニーズに対応するために、俊敏性、運用効率、コスト抑制の面で自社にとって推進要因となる要素をSDDCソリューションの選定前に把握し、状況に即してSDDCを段階的に展開する。
  • SDDCソリューションの評価を進める際は、(APIやテクノロジなどへの)ベンダー・ロックインの有無を見極めるとともに、代替テクノロジに移行するための危機管理計画を策定する。
  • アーキテクチャ上では多数のSDDCベンダーのソリューションを運用せざるを得ない事態もあり得るため、IT部門は、上位のポリシー・フレームワークとの相互運用性と統合性に加え、既存のハードウェアのサポート状況も考慮してソリューションを評価する。
  • クラウド・サービスやアジャイルな方法論(DevOps)を導入する場合は、クラウド管理プラットフォーム(CMP)、リリース自動化ソリューション、SDDCソリューションのそれぞれが深いレベルで統合され、クラウド管理サービスのもたらす自動化以外にも価値提案が得られるよう確実を期する。


目次



図目次



分析

SDDCとは

SDDCは、ITのインフラストラクチャとファシリティについて、管理およびサービス・エンジニアリングの任意選択を可能とするアーキテクチャ・アプローチである。自動化、ポリシー・ベース・オーケストレーション、再利用のレベルをそれぞれ引き上げることが可能なAPIを通じて提供されるサービスにより、物理インフラストラクチャの抽象化を実現するものであり、サービス指向アーキテクチャがアプリケーション・コンポーネントに対して果たす役割とよく似ている。SDDCの目的は、プロセスをポリシー・ベースで自動化してインフラストラクチャの俊敏性と処理速度を高めることにより、手作業による操作の割合が多い従来型のプロセスやスクリプトよりも大きなビジネス価値を生み出すことである。この取り組みには、インフラストラクチャの選定、セキュリティ、プロビジョニング、継続的なライフサイクル管理と最適化が含まれる。管理要件の減少と自動化の再利用性が高まるため、結果として運用コストの低減という利点も得られる。これらの過程で、SDDCは、分散環境全体にわたる構成設定、自動化、展開を推進するポリシーにより、プロプライエタリ・ハードウェア上で運用されているソフトウェア・サービスを上位レベルのソフトウェア・サービス・レイヤへ移行できるようにし(図1参照)、コモディティ・ハードウェアを含むリソース・プールの導入を通して、設備投資への支出を削減する可能性をもたらす。さらに、レガシー・ハードウェア資産の価値もSDDCによって増大する可能性がある。




図1. SDDCの概観



出典:ガートナー (2014年9月)





SDDCは、多くの場合、パブリック・クラウド・サービスの提供およびサービス・レベル合意(SLA)/サービス・レベル目標の達成を支える根幹部分となっており、アナリティクス、オーケストレーション、APIを通じて、自動化アクティビティおよびポリシー適用アクティビティの選択を可能にする。現在、SDDCを導入しているプライベート・クラウド・サービスはほとんど存在しないが、SDDCの成熟に伴って導入例が増加する。

成熟後も、SDDCは数多くの自動化アーキテクチャ実装の選択肢の1つであり、クラウド・コンピューティングおよび継続的なリリース自動化(DevOps)に不可欠なものになるわけではない。SDDCは、必須の存在というよりは、(基礎ハードウェアではなく)ソフトウェアにポリシー制御を配置することにより、エコシステムの機能に関していっそう大きなイノベーションを促進するためのソリューションを提供する。また、クラウド・ベースおよび従来のオンプレミスのサービス・アーキテクチャに対してSDDCを利用することもできる。さらに、SDDCは、インフラストラクチャの初期設定、構成設定、リソース・プールの自動化の実現に加え、インフラストラクチャの障害復旧やキャパシティ処理の自動化など、インフラストラクチャとオペレーションに関するプロセスの自動化にも重要な役割を果たしている。本質的に、SDDCの主な目標は、オンプレミスおよびハイブリッドのサービス提供に用いられるインフラストラクチャとファシリティの管理と最適化をさらに改善/効率化することである。別の言い方をすれば、インフラストラクチャ、ファシリティ、プロセスの自動化と管理において、パブリック・クラウド・プロバイダーの役割にいっそう近い存在にとなることである。

企業がSDDCベンダーのソリューション(備考1参照)の評価を進めるに当たって重要となるのは、SDDCによって置き換えられるテクノロジと共に、SDDCの導入に伴って既存テクノロジに加える必要のある変更の内容を把握することである。さらに、SDDCは自動化機能と最適化機能を提供するものではあるが、企業は、初期設定の状態でどのプロセスとサービスが自動化されるのか、また、自社でどのプロセスとサービスを構築する必要があるのかを評価しなければならない。初期設定のままで利用できる機能やコンテンツが存在する場合は、ソリューション全体について価値創出までの所要時間が短縮される。

SDDCはSDIの重要コンポーネントであり、SDIには、従来のITインフラストラクチャ(コンピューティング、ストレージ、ネットワーキングなど)に加え、センサ、デバイス、オペレーショナル・テクノロジを含めたデータセンター外のインフラストラクチャも含まれ、これらすべてについてSDxへの移行が進みつつある。SDASはSDIと情報をやりとりし、どちらも包括的用語である「SDx」に含まれる(図2参照)。本リサーチノートは、SDDCおよびその価値提案に主眼を置いている。SDASの詳細については、「デジタル・ビジネスのアプリケーション向けソフトウェア・デファインド・アーキテクチャ」APP-14-126、2014年12月5日付を参照されたい。




図2. SDxの階層構造


出典:ガートナー (2014年9月)





SDDCの価値提案


SDDCの主な価値提案としては、以下が挙げられる。

  • プロセスおよびサービスのデリバリ・コストを最適化しつつ、プロビジョニングおよび管理の俊敏性を高める。SDDCは、インフラストラクチャに対する文書化されたAPIアクセスを提供し、分散環境全体にわたって管理統制、オーケストレーション、自動化の強化を可能とすることで俊敏性の向上を実現する。
  • ハードウェア・デバイスに組み込まれていた機能を、よりモジュール化された、変更や更新が容易なソフトウェア・レイヤに移動することが可能になる。これにより、サプライヤーに加え、SDDCを導入する企業およびIT部門によるサービスのイノベーションが促進される。さらに、新たなSDDCサービスをレガシー・ハードウェアよりも上位のレイヤに配置する場合、SDDCによってレガシー・ハードウェア資産の価値が高まる可能性がある。
  • ハードウェアの過剰供給を削減する(一般にソフトウェアはハードウェアよりもプロビジョニングが容易かつ短期間で済み、また、SDDCは複数のサービスを実行できるハードウェア・リソースの共用プールを活用するものであるため)。SDDCでは、レガシー・ハードウェア展開にサービスが追加されるケースも存在する。
  • プロプライエタリ・ハードウェアの制御はハードウェア自体とは別の場所で実施されるため、コモディティ・ハードウェアの利用を一段と促進する(ただし、プロプライエタリ・ハードウェアに加えて異種コモディティがサポートされ、企業資産の保護が維持されることが理想である)。事実、特にストレージとネットワーキングにおいては、今日、プロプライエタリ・ハードウェアがもたらしている価値の多くはソリューション内部のソフトウェアから得られたものである。
  • 分散したインフラストラクチャ・デバイス全体にわたり、互いが連動するポリシー・ベースの構成とその適用の手段を提供することにより、プロビジョニングおよび変更の迅速化を実現しつつ、IT管理の必要性を低減する。
  • APIが一貫したものである場合か、またはSDDC制御プレーンによってマッピングされている場合、基盤ハードウェア・インフラストラクチャ上で運用されているサービスに影響を及ぼすことなく、当該のインフラストラクチャを置き換えることができる可能性がある。
  • 構成を制御するメカニズムがデバイス外部のソフトウェアに独立して存在していることから、アプリケーション・サービスを最も妥当な最適化済みのインフラストラクチャへとリアルタイムでバインドするなど、インフラストラクチャに関する新たなイノベーションを促進する。その結果、従来発生していた初期展開時のインフラストラクチャの過剰供給、資産や人的リソースの利用における非効率な部分を削減することが可能になる。ただし、これらのイノベーションについては、SDDCの本質ではなく、SDDCを生かしたインフラストラクチャ最適化機能と捉えることが重要である。ポリシー適用の役目を果たす機能がすべてSDDCとなるわけではなく、SDDCは、そうした機能を実現する基礎的かつ柔軟性に富んだ要素である。

SDDCの特性と分類

SDDCの主な特性および最小要件は、以下のとおりである。

  • 抽象化:物理実装のリソースを抽象化することにより、リソースとコンシューマーとの固定的な結び付きを解消する。抽象化では、インフラストラクチャ要素の論理モデルを定義する ことが可能になり、それらのモデルをプロビジョニングおよび再利用の際にインスタンス化できることから、標準化が実現する。
  • 計装化:モニタリング、パブリッシング、インテリジェントなアナリティクスに用いられる(物理および仮想の)インフラストラクチャを計装化する。
  • プログラマブル:文書化されたAPI(通常はRESTful API)を通じて、手作業による操作を必要としない自動プロビジョニング・サービスに加え、あらゆるITプロセスを実現する。
  • 自動化:APIを利用し、公開されている要素をスクリプトおよびその他の自動化ツールを用いて接続することにより、手作業による操作を伴うミドルウェアを可変要素から排除する。
  • ポリシー管理:分散したインフラストラクチャを事前定義ポリシーにより一元的に設定および再設定することにより、ビジネス・ニーズに対応できるようにする。
  • オーケストレーション:タスクの実行および最適化のためのポリシー管理と連携しながら、スクリプト・ベースの自動化という範疇を超え、コンピューティング、ネットワーク、ストレージ、ファシリティ、セキュリティの各リソース・ドメイン全体にわたってタスクの自動化を可能にする。

インフラストラクチャとこれを利用するアプリケーションとの最適化に向けたイノベーションは、上記の特性を組み合わせることにより、さらに促進される。一例を挙げると、SLAの条件値が一意的に定められている場合は、適切なインフラストラクチャを選定し、インフラストラクチャを動的に最適化することで資産の利用率が高まる。これらの機能は、単体製品として、またはCMPなどの機能スイートに組み込まれる形で市場に展開されている。

図3は、より広範なSDDCの分類基準を示している。SDDCは、SDASを頂点として個別の構成要素(コンピューティング、ストレージ、ネットワーク、ファシリティ)に分解されるものであり、SDDC APIを通じてインフラストラクチャ・サービスを要求する。セキュリティおよび管理は、アプリケーション、アプリケーション・サービス、インフラストラクチャにまたがる各ドメイン共通のサービスである。各構成要素は、それぞれに固有の制御プレーン(一連のAPI、ポリシー、オーケストレーションを提供)経由で(関連するソフトウェア・サービスを用いて)アクセスおよび管理される。論理ブループリントまたはポリシー・テンプレートのカタログにより(備考2参照)、特定のインフラストラクチャ構成を再利用することが可能となっている(OpenStack Compute [Nova] のフレーバーや、所定のSLAが保証された低遅延の高入出力処理に用いられるワークロード固有ストレージ・プロファイルなど)。ガートナーは、アプリケーションおよびインフラストラクチャを含め、ソフトウェアで定義される対象の包括的用語として「SDx」を用いている。




図3. SDxの分類



出典:ガートナー (2014年9月)




ベーシックSDDCおよびアドバンストSDDCの機能

図4は、従来、物理ハードウェアに組み込まれていたか、または物理ハードウェアに合わせて調整されていた機能を、サーバ上で実行される抽象ソフトウェアへと移行(例えば、ソフトウェア・デファインド・ストレージ[SDS]を利用)する上で、SDDCがどのような形で推進力となるかを示している。図の左側に、従来の物理ストレージ・アレイがどのような手法で重複排除サービスを実装しているかを示している。ベンダーの異なるストレージ・アレイは(あるいは同一ベンダーのアレイであっても)、機能がそれぞれ独自にサイロ化しており、APIを通じてアクセス可能なサービスがほとんど存在しない。APIを通じて機能にアクセスできる場合も、APIは同一ベンダー内での統一性がなく、特に複数のベンダー間ではまったく異なり、異種のデバイスやプロバイダーに対応するプログラマブルなインフラストラクチャとすることが不可能になっている。

SDDCによって、これらの差異が抽象化され、基礎の物理ハードウェア機能と通信するための共通のAPIセットが使用可能となることで、異種の物理環境全体にわたってポリシー・ベースのサービスとオーケストレーションが実現する。さらに、再利用と反復処理の活用を促進する論理モデル(プロファイル、パターン、ブループリントなど)を活用して、俊敏性と即応性が得られる。結果として、管理者と運用担当者による管理の効率を飛躍的に向上させることができる。

ただし、この実装はレガシー環境の管理性を改善することは可能であるものの、物理実装から論理サービス・レイヤへの機能の抽象化が十分ではないため、ガートナーは「ベーシックSDDC」と呼んでいる。図4右側の「アドバンストSDDC」実装は、一般にベンダー固有およびモデル固有となっている基盤ハードウェアから重複排除サービスを抽象化し、上位のサービス・レイヤへと移行した様子を示している。基盤ハードウェアは、その性質上、従来型とコモディティのいずれの場合もあり得るが、この形態では、プロプライエタリな機能を利用するのではなく、これまでに存在していなかった機能特性を新たに追加することもないため、従来の基礎インフラストラクチャをコモディティ化できるという効果がある。また、ソフトウェアによるストレージ・サービスへの移行とその実装を通じて、ハードウェア・ドメイン全体の可視性が向上することから、オペレーションおよびインフラストラクチャの効率が大幅に向上する効果も得られる。




図4. ベーシックからアドバンストまでのSDDCの遷移 (SDSを用いた一例)



出典:ガートナー (2014年9月)
* 表をクリックすると拡大表示します。




ガートナーは、SDS、SDC、SDF、ソフトウェア・デファインド・セキュリティ(SDSec)がベーシックとアドバンストの両方の機能特性を備えるものへと発展しつつあることを確認したが、SDNについては様相が異なる。定義され実装されるべき最初のSDDCコンポーネント・アーキテクチャであるSDNの場合、SDNと呼ばれるためには、高度な実装が必須となる (「Ending the Confusion About Software-Defined Networking: A Taxonomy」参照)。なぜなら、ハードウェア・レイヤから独立したソフトウェアを通じてネットワーキングのイノベーションを実現し、プロプライエタリな機能を物理ネットワーキング・デバイス自体から排除することを目的として、大学コミュニティがSDNを考案したからである。このため、物理デバイスおよびそれらに組み込まれている機能に関して、管理と自動化を改善するための代替アプローチを導入することで極めて大きな価値を得られる可能性がある場合も、ガートナーはそれらの実装をSDNとして分類していない。しかし、SDNと比較して成熟度が低いコンピューティング、ストレージ、セキュリティというSDDCのそのほかの領域においては、ベンダーの初期投資は、新たなサービス機能を導入しつつ、レガシー物理デバイスの自動化タスクとオーケストレーション管理タスクへの組み入れを可能とするポリシー・ベースのオーケストレーションによる複雑性緩和を重視する傾向にある。

図5は、SDDCのサービスおよび集約された統合インフラストラクチャ管理サービスの概念を示している。これらはコンポーネント制御プレーンよりも上位に配置され、付加的な管理機能と最適化機能を備える。サービスでは、ある特定のコンポーネントを処理の対象とすることも、多数のコンポーネントを対象とすることもできる。例えば、統合インフラストラクチャ・システムには、一般的に、コンピューティング、ストレージ、ネットワーキング、セキュリティを含む論理パターンまたはテンプレートが用意されており、分散環境に対してポリシー・ベースの集約的なプロビジョニングを実施できる。結果として、集約型の管理/制御サービスは、基盤コンポーネントのサービスおよびAPIと連携するものであるか、または深く統合されていなければならない。例えば、集約型サービスは、サービスをプロビジョニングする際に自社内外の適切なデータセンターを選択することを可能とし、また、リカバリ・ポイント目標 (RPO) とリカバリ・タイム目標 (RTO)のSLAに基づくことで、基盤となるインフラストラクチャとファシリティ・アーキテクチャに対するディザスタ・リカバリ(DR)SLAを最適化する、複数サイトにわたる回復力に関する適切なメカニズム選択を可能にする。さらに、SDDCベンダー各社がそれぞれ自社固有の制御ポイントを利用し、自社固有の強みを生かしてSDDCに取り組んでいるため、大多数のIT部門は、構築したSDDCアーキテクチャで多数のベンダーのソリューションを必要とする。

多くの企業は、CMPおよびクラウド・サービス・ブローカ(CSB)を利用してプライベート、ハイブリッド、パブリックの各クラウド・サービスの導入を進めている。これらのツールは、エンド・ツー・エンド・サービスの(関連ポリシーを伴う)設計パターンまたはブループリント、つまりポリシー(キャパシティ、遅延、コストなど)に基づいた適切なデータセンターとリソース・プールに設定される設計パターンまたはブループリントを可能とする。これらのツールの多くは、基礎となるSDDCコンポーネントの実行用パターンまたは実行用テンプレートへと統合される(別の方法として、これらのコンポーネント設計パターンをCMP論理モデルまたはブループリントにおいて直接作成するケースも数多く存在する)。重要な概念として、ポリシーおよびオーケストレーションは、その性質上、連携型であり階層構造となっている。新たなクラウド・サービスは、CMPで設計が開始される一方、基盤コンポーネントのオーケストレーションおよびポリシーと統合することで実行される。

この一例であるOpenStack(オープンソースのCMP)は、リソース定義用のHeatテンプレートを備えているものの、リソースのプロビジョニングについては、コンピューティング、ストレージ、ネットワーク、およびセキュリティの各コンポーネントを操作するAPIを通じて実行する。別の例を挙げると、上位レベルのCMPでは、クラウド用に最適化されたサービス・ブループリントを定義し(すべての論理アプリケーションとクラウド・サービスのインフラストラクチャ・コンポーネントを定義)、プライベートまたはパブリックのIaaS(サービスとしてのインフラストラクチャ)サービスを1つ以上利用して、個別のインフラストラクチャ・リソース・プールへとプロビジョニングする場合がある。このCMPは、サービスをモニタリングし、自身の集約型ポリシーおよびオーケストレーション制御レイヤを通じて、インフラストラクチャをスケールアップ/スケールアウトすることによりキャパシティの拡張を実行する。




図5. コンポーネント間の関係および依存関係



出典:ガートナー (2014年9月)




SDDCはどのような点で仮想化と異なるのか

あらゆる抽象化は、仮想化を内包している。仮想化は、SDDC(およびSDx)の必須かつ根本的な要素である。ただし、(ハードウェア内に限らず)ソフトウェア内のリソース・コンポーネントに対するアクセスおよび制御を標準化し、APIを通じたプログラマビリティ、オーケストレーション、およびポリシーの利用可能範囲を強化するという観点から捉えると、SDDCは仮想化の範疇を超えるものとなる。この結果、インフラストラクチャを(理想としては標準的な手法により)自由に操作できるほか、アプリケーションについてはセットアップ、構成設定、テスト、展開、継続的管理を、ライフサイクル全体を通じて完全に自動化できる。この特性は、アジャイルな継続的デリバリ・モデル(DevOps)で構築されているアプリケーションの場合、特に顕著になる。標準のSDDCソフトウェア・レイヤを利用することで、(APIが共通であるか、互いにマッピングされているため)アプリケーション自体に及ぼされる影響を最小限または皆無としつつ、基盤ハードウェア・インフラストラクチャを置き換えることができる。

ただし、置き換えによるメリットを得る上では、最低限の共通基準となっているAPIを使用した場合、SDDCの利便性が制限される可能性があるため、十分な注意を払わなければならない。さらに、ベンダーは共通APIではない拡張されたAPIや機能を積極的に追加することでイノベーションを進めるが、そのイノベーションの対価として、ベンダー・ロックインが拡大し、代替ベンダーへの移行が困難になる。


SDDCはどのような点でクラウド・コンピューティングと異なるのか

SDDCとクラウド・コンピューティングの類似点の1つは、両者とも抽象インフラストラクチャ上に構築されるアーキテクチャを表現していることである。ただし、クラウド・サービス・アーキテクチャは、顧客またはコンシューマーにセルフサービスの形で利用されることを目的として、クラウド・サービス・アーキテクト(または所有者)により構築される。SDDCは、選択可能なインフラストラクチャおよびデータセンター・アーキテクチャを表現するものであり、基礎となっているインフラストラクチャの自動化、制御、インテリジェンスを通じて、インフラストラクチャの俊敏性(および潜在的なモビリティ)を実現する。したがって、SDDCはクラウド・サービスのプロビジョニングと自動化を実現する際に利用されることもあるが、それらを実現する上で必須のものではない。

クラウド・サービスの構築では、プログラマビリティに加え、ポリシーやオーケストレーションをはじめとするSDDCのほかの特性が必要となることから、SDDCとCMPは互いに緊密に連携している。CMPには、自社内外の適切なデータセンターに配置されている適切なリソース・プールへのプロビジョニングなど、適切なインフラストラクチャのプロビジョニングをポリシーに基づいて自動的に調整するためのSDDC機能がサービス最適化レイヤに組み込まれている。例えばCMPは、ネットワーク・プロビジョニング用に自身が備えている独自機能 (IPアドレッシング、ファイアウォール、ロード・バランシングなど) を利用する場合もあれば、ネットワーク・ポリシー適用およびプロビジョニングのためのサードパーティSDN機能に統合される場合もある。

OpenStackは、仮想コンピューティング、ストレージ、ネットワーキング、DBMS、アイデンティティ管理に用いられるオープン・ソース・ベースのCMPであり、クラウド・サービスのオーケストレーションや自動化に利用できるオープン・ソースAPIを備えたSDDCが組み込まれている。仮想インフラストラクチャのベンダーは、要求されたAPIの機能を実現するためのドライバまたはプラグインを作成する。CMPのベンダーは、すべての環境(開発、テスト、ステージング、本稼働、DRなど)にわたり、完全なエンド・ツー・エンドでのサービス全体のプロビジョニング、オーケストレーション、管理に用いられるアプリケーションまたはサービス・コンテキストを追加することにより、OpenStack(およびそのほかのクラウド・リソース)に付加価値を提供する。また、ベンダーのプラグインは、完全にレイヤ化されたCMP製品を通じてではなく構成部品の形で、いっそう高度な機能をOpenStackに直接提供できる。例えば(内外のプロバイダーまたはリソース・プールへの)ポリシー・ベースの配置、動的なインフラストラクチャ最適化、パフォーマンス診断といった機能をプラグインによって追加できる。

ただし、クラウド・コンピューティングが焦点としているのは、クラウド・サービスの設計、プロビジョニング、最適化である。SDDCは、この範疇を超えて非クラウド・サービスの周辺を自動化し、クラウド・サービスの対象とならない範囲(インフラストラクチャ、オペレーション、データセンターのプロセスなど)も対象とする。例えば、(コンシューマーの観点からの)クラウド・サービスの自動化は、(管理者の観点からの)クラウド・インフラストラクチャの自動化には及ばない。SDDCは、物理インフラストラクチャのこうした自動化および最適化に向けたプログラマビリティを実現するものであり、ベンダーへの通知および内外のインシデント管理/応答プロセスとの統合を含め、リソース・プールへの新たなキャパシティの統合やインフラストラクチャの障害修復プロセスなど、プロセスの自動化を可能にする。実際には、SDDCは、エンタプライズ・データセンターと比較して大幅に少ない人的リソースでパブリック・クラウド・プロバイダーがインフラストラクチャを大幅に拡大/縮小することを(プロセスおよびインフラストラクチャの自動化と組み合わせて)可能にするための基盤である。


SDDCはすべてのインフラストラクチャ・ソフトウェアおよびハードウェアの市場を吸収するのか

それはあり得ない。ソフトウェアおよびハードウェアのインフラストラクチャが備えている機能は、文書化された(オープンおよびプロプライエタリの)APIを通じてアクセス可能となることが見込まれるものの、バックアップ/リカバリ・ソフトウェア、インフラストラクチャ監視ソフトウェア、セキュリティ暗号化といった既知のソフトウェア機能すべてがSDDCへと再分類されるわけではない。ただし、SDN(例えば、VMware NSXやJuniper Networks Contrail)やSDS(例えば、Atlantis Computing ILIO USXやEMC ViPR)といった分散している一連のインフラストラクチャ・デバイス全体にわたりポリシーを設定し適用するためのポリシー・フレームワークは、SDDCとして分類されることもあり得る。


市場におけるハイプおよび実情

図6は、SDxのテクノロジ・プロファイルを2014年のガートナーのハイプ・サイクル曲線上に表したものであるが(「Hype Cycle for Virtualization, 2014」参照)、SDxは成熟過程の初期段階にある。SDDCの主な原動力は、自動化およびポリシー適用を通じた俊敏性であり、結果として、複数のドメインにわたるオーケストレーションが可能になる。また、SDDCは、(アジャイルな方法論およびDevOpsを利用した)頻繁なリリースが発生するサービスを含め、プライベートおよびハイブリッドのクラウド・サービスを実装する際に検討されることが多い。既存のサービスに後付けするよりも、オーケストレーションを用いるSDDC APIおよびポリシーを利用して新しいサービスを構築する方が容易かつコスト効率に優れるため、SDDCは、(新たなサービスの構築場所、または既存サービスの搭載場所や拡張場所である)新たな環境において段階的に実装されるようになる。

SDDCのもう1つのユースケースは、インフラストラクチャとオペレーションの効率向上に向けてさらに的を絞ったものである。具体的には、サーバ、ストレージ、ネットワークの各担当チーム内またはチーム間でSDDCを利用することにより、管理プロセスと反復的タスクを自動化し、設定エラーを削減し、サービス・デリバリの速度を改善し、人件費を削減することができる。例えば、一部のSDSソリューションは、1つのAPIで複数ベンダーのストレージ・デバイスと通信するためのAPI変換レイヤを提供することにより、管理タスクの自動化とオーケストレーションに伴って生じる複雑さを緩和し、複数のデバイスにわたるストレージ・サービスを開始できるようにしている。




図6. SDx関連テクノロジのハイプ・サイクル:2014年



出典:ガートナー (2014年9月)
* 表をクリックすると拡大表示します。




コンポーネントの観点からは、ネットワークおよびセキュリティは依然としてSDxの初期段階にあるものの、比較的成熟している。SDNコントローラは勢いを増しつつあり(「Mainstream Organizations Should Prepare for SDN Now」参照)、サービスを上位とするネットワーク機能の仮想化(例えば、ソフトウェアによるロード・バランシングやファイアウォールのサービスに用いられるもの)は急速に開発が進んでいる。市場のすべてのSDNソリューションについて同様の方法でアーキテクチャが構築または実装されているわけではなく、一部はSDNソリューションの体裁をとった自動化ソリューションである。(SDNではない)自動化ソリューションを利用して企業の目標を達成できる場合もあるが、マイナス面として、イノベーションをもたらすがデバイス上に存在しない新たな機能を利用するには、組み込まれているソフトウェアかまたは(新たなソフトウェアをロールアウトするだけでなく)ハードウェアを更新する必要が生じるケースもある。さらに、組み込まれているソフトウェアをコントロールするベンダーは、AppleがiOSに対するコントロールを生かしてほかのブラウザ・ベンダーとの競合を抑制している事例のように、イノベーションのペースと方向性を意のままに管理できる。

同様に、大多数のCMPはSDDCを配置することなくロールアウトされ、代替的な手段を利用して自動化とポリシーに関する要件に対応しているが、時間の経過に伴って成熟が進むにつれ、SDDCコンポーネント・ソリューションとの統合がいっそう進む。CMPでは、統合インフラストラクチャ・システムのSDDC APIとの統合が既に進められており、基礎となっている利用可能な集約型コンピューティング、ストレージ、ネットワーキングの機能と通信するための標準的な手段が提供されている。しかし、各ベンダーの統合インフラストラクチャ・システムが提供する一連のAPIはそれぞれ異なるものである。このためCMPのAPI抽象化レイヤは、複雑性とインフラストラクチャ・ベンダーの変更に伴って生じる影響を軽減する上で有用となるが、その代償としてCMPベンダーへのロックインが拡大する。

あらゆる自動化ソリューションと同様に、SDDCは、適切なビジネス成果を目指して適切な領域に適用する場合、破壊と変革を促すものとなり得る。しかし企業は、SDDCテクノロジのハイプとSDDCテクノロジが初期段階にあることを認識し、慎重かつ入念に評価を進めなければならない。企業のタイプに応じたコメントを以下に示す。

  • インフラストラクチャおよびアーキテクチャに関して強力なスキルを擁するタイプAの企業は、主として仮想化やクラウド・コンピューティングおよびアジャイルな方法論という観点から、またはデータセンターを新規構築するケースの多くにおいて既に、SDDCの評価を進めている。
  • タイプBおよびCの企業は、市場が成熟期を迎えるまで2〜3年間は状況を見守り、その後、大規模な導入に着手する。ただし、特にクラウド専用またはクラウド向けに最適化されたサービスの開発を進めている場合や、アジャイルな方法論を採用する場合、またはデジタル・ビジネス・イニシアティブに着手する場合は、理解度と利点の評価を目的としてパイロット実装かまたは小規模の実装を検討する。


推奨リサーチ

  • 「クラウド・コンピューティングのハイプ・サイクル:2014年」(INF-14-181、2014年12月10日付)
  • 「Hype Cycle for Virtualization, 2014」
  • 「Ending the Confusion About Software-Defined Networking: A Taxonomy」
  • 「How to Derive ROI for Integrated Systems」

備考1

SDDCベンダー

従来型データセンター・インフラストラクチャのすべてのベンダーが、SDDC指向のさまざまなソリューションの提供を進めており、各社は中心的な強みを強調している。いずれも、あらゆる領域のすべての条件を満たす完成されたSDDCソリューションではなくそのための標準もないため、大多数は相互運用性がない。結果として、購入企業は慎重を期する必要がある。

以下は、SDC、SDS、SDN、SDF、およびSDSecのソリューションを提供しているベンダーの例である。

  • SDC:Cisco、Docker、HP、Red Hat、VMware
  • SDS:Atlantis Computing、EMC、Nexenta、VMware
  • SDN:HP、Juniper Networks、Nuage Networks、VMware
  • SDF:Emerson、IO、Nlyte Software、Schneider Electric
  • SDSec:CloudPassage、Illumio、vArmour、VMware

備考2

論理ブループリントまたはポリシー・テンプレートのカタログ

各SDDCドメインおよび上位サービスには、再利用可能なパターン、すなわちブループリントという概念が取り入れられている。これは、プロビジョニングの際に、これらのパターンによって特定の(例えば、ストレージ、コンピューティング、ネットワーキング、セキュリティの)論理構成を識別することができ、物理環境または仮想環境へと極めて迅速にインスタンス化できるという考え方である。



(監訳:田崎 堅志)


APP: INF-14-182 (G00262841)
※本レポートの無断転載を禁じます。


←INDEXに戻る

 

gartner.com
TOP OF PAGE
Copyright