クラウド&データセンター完全ガイド：特集
「ハイパーコンバージド」か「コンバージド」か――ITインフラ選びの着眼点（前編）
デジタル変革期のITインフラ［戦略と選択］（Part 2）
2018年1月12日 06:00
弊社刊「クラウド＆データセンター完全ガイド 2018年冬号」から記事を抜粋してお届けします。「クラウド＆データセンター完全ガイド」は、国内唯一のクラウド／データセンター専門誌です。クラウドサービスやデータセンターの選定・利用に携わる読者に向けて、有用な情報をタイムリーに発信しています。
発売：2017年12月21日
定価：本体2000円＋税
ITインフラ市場でハイパーコンバージドインフラ製品が登場してから数年が経過した。ユーザー企業の間では登場当初の警戒感が薄れ、注目度はちょうどピーク期にさしかかっている状況だ。ここでは、ハイパーコンバージドインフラとコンバージドインフラを中心に、ITインフラ選定に際して着眼すべきポイントを確認していく。 text：渡邉利和
ハイパーコンバージドとコンバージドの境界
サーバーやストレージの選定を行おうとして調べる際、ハイパーコンバージドインフラ（Hyper Converged Infrastructure：HCI）の名前をよく耳目にするようになった。だが、何をもって“ハイパー”なのかは広く周知されているとは言いがたい。定義にこだわってもあまり意味はないが、以前からあるコンバージドインフラ（Converged Infrastructure：CI）との境界が曖昧になりつつあるのも確かである。
CIの場合は、システムを構成する各コンポーネントは、単体のサーバー、ストレージ、スイッチなどのネットワーク機器だ。それらがシステムラックに収まり、設定が完了した状態で出荷される。よって、稼働状態にあるシステムを見ただけではCIなのか単に各コンポーネントがラックに収まっているだけなのかの違いは分からない。ラックへの格納作業をシステムインテグレーター（SIer）が行ったのか、製造元のベンダーが行ったのかの違いととらえる考えもあろう。これも必ずしも間違った見方ではない。一目瞭然で判別できるような、目に見える機器構成上の違いがあるわけではないからだ。
一方、HCIの場合は、ストレージが独立したコンポーネントからサーバー内蔵に変わる。そのため、Webサーバーのように、多台数のサーバーだけでラックを埋めているような見た目になる。ハイパーコンバージドでは、SDS（Software Defined Storage）技術を活用し、サーバー内蔵のHDDやSSD/フラッシュメモリが仮想的にまとめてストレージプールを構成する。ここがCIとHCIの明らかな違いということになる（図1）。
だが、先に述べたように、製品の進化過程でこの表面的な差が曖昧になる動きも出ている。例えば、最新のHCI製品に、ストレージベンダーのネットアップ（NetApp）が2017年11月に国内提供を開始した「NetApp HCI」がある（写真1）。同製品は、1つのシャーシに4個のコンピューティングノードまたはストレージノードが収まるかたちで構成される。ユーザーが購入可能な最小構成は2台のシャーシとなっている（図2）。
NetApp HCIが採用したこのフォームファクターは、HCIとしていったん統合されたコンポーネントを再びシャーシ内でサーバーとストレージに分離したようにも見える。したがって、見た目からの単純な分類は意味をなさないわけだ。
こうした設計が現れた背景には、初期のHCIで弱点とされた部分を解消する工夫がある。HCIのメリットを損なうことなく弱点を解消するためにはどうすればよいか、ベンダー各社の工夫が始まっている段階だ。
SDDCを具現化したHCI
HCIがITインフラ市場で本格的に普及していく過程で立役者となったのがニュータニックス（Nutanix）だ。同社のHCI製品は、外観としてはラックマウントサーバーで、自社ロゴをあしらった外装が施されているが、中身はx86のコモディティサーバーそのものであり、ハードウェア面で独自性を出そうとはしていない。
ニュータニックスのSDS「分散ストレージファブリック」および仮想化システムの統合管理インタフェース「Nutanix Controller VM」といったソフトウェアが中核であり、同社自身、HCIを「データセンター／ITインフラの運用を簡素化するためのターンキー・ソフトウェアデファインドソリューション」であると説明している。同社の取り組みから、HCIとは、SDDC（Software Defined Data Center）のコンセプトを実現するためのソフトウェアであるという側面もうかがえる（図3）。
ニュータニックスのHCI製品の場合、システム構成は基本的にラックマウントサーバーを積み上げていくかたちだ。このサーバーにはサーバー仮想化基盤やSDS、運用管理ソフトウェアなどが組み込まれており、サーバー台数を増やすことで、システム規模を段階的に拡張していける。構成についてあれこれ複雑な検討をすることなく、単純に数を増やすだけというシンプルさがユーザーの支持を集めているようだ。
運用管理のシンプルさの反面、リソース効率に無駄も
ストレージ部分に注目すれば、上述のニュータニックスの取り組みと同様のことが以前から行われてきた。ストレージベンダーがハードウェアアプライアンスとして提供するストレージ製品でも、ユニットを追加するだけでリニアに拡張できるタイプの製品は以前から販売されている。ストレージソフトウェア製品でも、コモディティサーバーを分散型ストレージとして管理し、柔軟な拡張性を売りにする製品もすでに存在する。
HCIは、この分散型ストレージの中に、ワークロードを処理するためのプロセッサやメモリといったコンピュートリソースを内蔵した、いわば主客転倒のシステム設計だとも言える。ユーザーにとってのメリットは前述のとおりシンプルさだが、逆に、システムの目標性能を柔軟にコントロールすることが難しくなる面がデメリットになる。
ハードウェアモジュールをストレージ内蔵サーバーに統一するHCIの手法は、コンピュート／ストレージ双方のリソース要求が同じようなペースで高まっていく場合、本来のシンプルさのメリットを享受できる。だが、そうでなくなると拡張効率で大きな無駄が生じることになる。
例えば、現状のシステム構成でコンピュートの処理能力に不足はないが、ストレージ容量だけが逼迫してきたというよくあるケースを想定してみよう。このときHCIなら、両リソースをセットで増強するしか選択肢はない。また、導入後の拡張にかぎらず、システム導入当初の両リソースのバランスがHCIの構成にマッチしていない場合もあるだろう。
この問題に対処すべく、HCIベンダーはコンピュート／ストレージ共に何段階かのバリエーションを用意することで多少のバランス調整は行えるような配慮を行っている。だが、個々のユーザーのワークロードの特性によっては調整可能範囲を逸脱することもありえる。もちろん、多少のアンバランスであれば、運用管理のシンプル化のメリットがデメリットを上回ると判断して許容する場合もあろう。
NetApp HCIについては、このリソースのアンバランスの調整幅をできるかぎり多く取ることを狙った設計と見ることができる。ただし、コンピューティングノードとストレージノードを分け、任意の比率でシャーシに搭載できるようにした結果、ユーザー側で両リソースの構成比率について考えなくてはならず、シンプルさのメリットは一歩後退せざるをえない。
なお、NetApp HCIでは、標準の運用管理ソフトウェアによって精細なQoS（Quality of Service）管理が可能になっている点も特徴として強調されている。複数のワークロードが混在するITインフラの場合、適切なQoS管理がないと、重要度の高いアプリケーションの処理が遅延するなどの問題につながる。これを避けるため、そうしたアプリケーションに対しては専用のITインフラを用意する手法が一般的だ。もちろん、そのやり方だと、サイロ化されたITインフラが複数並列する状況を招くというデメリットが発生する。ゆえに、QoS機能の良しあしはHCI製品選びでは重要な着眼点になってくる。
事前構成済みであることの価値
CIが出現した際、事前構成済みのメリットが各社からアピールされた。これを単なるセット販売、もしくはコンポーネントの組み合わせの相性問題の解決といったニュアンスで受け止めたユーザーも少なからず存在するようだ。しかしながら、運用管理負担の軽減を考えるうえで、この事前構成済みの価値は決して小さなものではない。もちろん、CIの発展系と位置づけられるHCIにも同じことが言える。
組み合わせ問題の検証機会は、システム構築時の一度だけというわけではない。セキュリティリスクへの対策や各種の機能強化など、システム運用中に個々のコンポーネントがバラバラのタイミングでアップデートされるため、厳密に言えば、組み合わせ問題の原因となるような不整合はシステム運用期間を通して繰り返し発生する可能性があるのだ。
従来のシステムでは、安定稼働を保証するためのユーザー側の対策として“塩漬け”というやり方を選択することも多い。塩漬けシステムと言えば、メインフレームなど今となっては更新が困難でそのまま使い続けざるをえない、といったネガティブな印象があるが、一方でシステム運用管理のノウハウとして、「問題なく動いているシステムには触るな」といった心得が語り継がれているのも事実だ。これは日本特有の習慣というわけでもないようで、英語でも「If it ain't broke, don't fi x it」（壊れていないなら直すな）といったことわざがあるので、事情は国や地域を問わないのだろう。
もちろん、むやみやたらに余計な変更を行わないという意味なら特段問題になる話ではないが、現実には変更を加えないことが絶対的なルールのように扱われてしまい、ベンダー側から提供されるアップデートや改修プログラムも一切受け入れず、導入時点の状態のまま運用期間が終了するまでまったく変更せずに使い続けようとする例もあると聞く。
大規模なミッションクリティカルシステムでは、システムダウンの影響は莫大な額の損失として計上される結果につながる。そのため、必要なアップデートだとしても適用に慎重になるのは無理からぬことだ。しかし、一切変更せずに運用を継続できる時代はもう終わりつつあるという状況は認識しておきたい。