一見、成熟した領域であるかのように思える企業ITインフラの世界でも継続的なイノベーションが見られる。ハードウェア価格性能比のたゆまない向上は当然のこととして、TCO（総合保有コスト）の観点から重要な運用管理コスト、設置スペース、消費電力の削減に向けたイノベーションも継続的に登場している。
最近におけるそのようなイノベーションの例が、ハイパーコンバージド・インフラストラクチャ（以下、HCI）だ。バズワード的な響きがあるが、ITインフラ関連テクノロジーのメガトレンドに沿い、上記のようなTCO面の課題を解決するための地に足が付いたソリューションである。破壊的イノベーションとまでは言えないが、重要な持続的イノベーションのひとつと言えるだろう。
ハイパーコンバージド・インフラストラクチャとは何か？
「コンバージド」（converged）とは日本語で訳せば「集約された」という意味である。HCIは「超集約型基盤」と訳すことができよう。HCI登場前にも、コンバージド・インフラストラクチャという言葉があった。これは、コンピューティング・サーバー、ストレージ、そして、（多くの場合に）ネットワークというハードウェア構成要素と関連ソフトウェア（主に仮想化と運用管理）をすべてひとつのベンダーが事前にパッケージ化し、動作検証した形態で提供するハードウェア製品を指す言葉だった。
コンバージド・インフラストラクチャの採用により、ユーザーにとっては、サーバー・ハードウェアの導入には付き物の設置作業や検証作業の負荷を軽減でき、保守運用時のコンタクト先を一本化できるというメリットが生まれた。
HCIでもこの特性は引き継がれているが、ストレージの構成という点でコンバージド・インフラストラクチャと相違する。これは、単なるパッケージング手法の違いというのではなく、テクノロジー的に大きな相違点だ。
HCIでは独立した外部ディスクサブシステムという考え方がなく、コンピューティング・サーバーのローカ ル・ストレージが全面的に活用されている（図１）。
図 1：HCIでは独立した外部ディスクサブシステムという考え方がなく、
コンピューティング・サーバーのローカ ル・ストレージが全面的に活用されている
このHCIの設計思想は、ディスクをコンピューティング・サーバーとは分離したストレージサブシステムとして扱い、I/O性能やデータ管理機能を最適化していくという、ここ数10年間に継続してきた企業ITインフラにおけるトレンドの逆を行くものだ。HCIに「破壊的」要素があるとするならば、この点と言えるだろう。
そもそも、なぜ外部ストレージが一般的になっていたのだろうか。最大の理由はローカル・ストレージはデータの共用がしにくく、データのサイロ化（データが特定サーバーに従属してしまい、結果的に特定のアプリケーション以外では利用しにくくなること）やデータの重複を招きがちという問題があった点だ。また、ストレージ容量のサーバー間での融通が利かないという問題もあった。
たとえば、特定のサーバーのローカル・ストレージの容量が切迫しており、他のサーバーのローカル・ストレージの容量に余裕がある場合でもその容量を活用することができず、結局ストレージ容量が足りないサーバーにストレージ・ドライブを追加せざるを得ないという状況である。これにより、ストレージ容量の無駄が発生し、ストレージ容量の利用率がきわめて低い（典型的には30%以下）という問題も生じた。
しかし、仮想化テクノロジーによってこれらの問題は解決可能になった。他のサーバーのローカル・ストレージ上のデータであっても、あたかも共用ディスク上にデータがあるかのようにアクセスできる。そして、サーバー間のストレージ容量の割り振りも自由に行なうことができる。つまり、HCIでストレージがコンピューティング・サーバーに従属してしているのは、あくまでもハードウェア構造上の視点であり、ソフトウェアによる仮想化を介してしまえば、この点は問題ではなくなる。
ソフトウェア定義型ストレージ（Software-Defined Storage）という言葉に表わされるように、ストレージ構成がソフトウェアにより決定されるという世界だ。ローカル・ストレージに障害が起きた際の再構成やVMインスタンスの別サーバーへの移動も、ストレージ管理ソフトウェアによりユーザーからは透過的に対応できる。また、外部ストレージ・サブシステムでは常識のRAID、重複排除、圧縮等の機能もサーバー上で稼働するソフトウェア階層で実現される。
Google等の大規模サーバファームで使用されている自社製サーバーも多くの場合、同様の設計思想になっていると推定される。つまり、CPUとストレージを搭載した同一のハードウェア・コンポーネント（マザーボード）をきわめて多数使用することで高い性能を発揮しているということだ。
アプリケーションプログラムにとってハードウェアがどう見えるかは、その上で稼働するソフトウェアサブシステム次第である。ハードウェア・コンポーネントを追加すれば、処理能力を増強できるし、ハードウェア・コンポーネントが故障した場合には単純に置き換えればよい（実際には、即座に置き換える必要はなく、放っておいて定期的に交換すればよい）。一般企業においてGoogleのような超大規模システムを運用することはないだろうが、考え方は同様である。
