HOME > ストレージ管理ソリューション部会 > Storage Magazine翻訳記事

コンポーザブル・インフラストラクチャーについて知っておくべきことすべて

コンポーザブル・インフラストラクチャーは、リソースを抽象化し、特定のアプリケーションに対応して、動的に構成や再構成ができるサービスにする。コンポーザブル・インフラストラクチャーが持つ多くの長所と、なぜこれが万人向けではないのかを学んでいこう。

Storage Magazine 2019年11月号より
Robert Sheldon

ハイパーコンバージド・インフラストラクチャー（HCI）の人気の高まりは、この仕組みに多くのメリットがあることの証左だ。しかし、HCIといえども短所はある。今、IT業界の多くの人たちが、これらの課題を解決する新世代のIT基盤に期待を寄せている。その一つが、コンポーザブル・インフラストラクチャーだ。この基盤は、オペレーションを円滑にし、潜在的にコストも削減しながら、ハイパーコンバージド・インフラストラクチャーよりも、柔軟で且つリソースを効率良く使うプラットフォームを提供する。

しかし、コンポーザブル・インフラストラクチャーも、HCIと同様に課題を抱えており、データセンターを更改しようとしているITチームは、何らかの結論を出す前に、コンポーザブル・インフラストラクチャーがどのように動き、コンバージド・システムやハイパーコンバージド・システムと何が違うのかを理解しておくべきだ。

コンポーザブル・インフラストラクチャーは、コンピュート、ストレージ、ネットワークを一個の統合されたセットとして提供するために、ソフトウェア定義のフレームワークを用意している。このインフラストラクチャーは、ハードウェアのコンポーネントをバラバラにし、それらを論理リソースプールに集め、クラウドプラットフォームと同じように、オンデマンドのサービスとして提供する。

IT業界の人々は、時々コンポーザブル・インフラストラクチャーをInfrastructure as Code（IaC）あるいはソフトウェア定義のインフラストラクチャー（SDI）と呼ぶことがある。しかし、この呼称はコンポーザブル・インフラストラクチャーの一面を捉えただけのものだ。コンポーザブル・インフラストラクチャーは、IaCの拡張版であり、且つSDIの一（いち）タイプと呼ぶほうがより正確だ。このインフラストラクチャーは、特定のタイプのワークロードに対応可能な流動的なリソースプールを提供するために、この両者の方式を統合しているからだ。

コンポーザブル・インフラストラクチャーは、物理サーバー、ストレージ、ネットワークのコンポーネントを抽象化し、それらを要求に応じて構成または再構成できる柔軟なサービスとして提供する。このインフラストラクチャーは、ベアメタル（訳注：ここではハイパーバイザ型仮想化方式および装置を指していると思われる）、コンテナ、仮想マシン上で稼働するアプリケーションに対応するだけの十分な柔軟性を持っている。インテリジェント・ソフトウェアは、コンポーネントを抽象化し、基盤を管理し、動的リソースの割り当てを行い、サービスを出来るだけ効率的に提供するために必要なオーケストレーションと自動化機能を備えている。

コンポーザブル・インフラストラクチャーの進化

従来型のデータセンターのアーキテクチャーでは、アプリケーションのホスティングと提供にマルチティアの戦略を採用するのが一般的だ。仮想化は、リソース使用の効率化と管理の円滑化に役立ったが、マルチティア方式は引き続き主流の座を占めている。

この戦略はアプリケーション・デリバリの方法が変わらないうちは有効だった。しかし、新しい技術の登場によって、より複雑なシステム、より高速なデプロイメント、より動的なワークフローが要求されるようになった。その結果、IT部門はオペレーションを単純化し、リソースをより良く使う方法を探さなければならないことになった。

Infrastructure as code

Infrastructure as code（IaC）はソフトウェアをベースとして、アプリケーションのホスティングと稼働が必要な基盤リソースの自動プロビジョニングと構成を行うためのアプリケーション・デリバリの手法である。IaCは、アプリケーションを実装する時の手動による割り込みの必要性を無くし、結果としてより迅速なデプロイメントと管理のオーバーヘッドの削減をもたらした。

開発者や管理者は、IaCに基盤定義ファイル（データセンターで、ITの処理を自動化するために使われる、プログラム・スクリプトと同じようなもの）をアプリケーションとともに組み込み、どのようにリソースを設定するかのインストラクションを与えている。この定義ファイルには、仮想サーバー、クラウド・インスタンス、ストレージ・リソース、データベース・システム、アプリケーション・パッケージ、テストツール、その他アプリケーション・デリバリをサポートするコンポーネントであればいくつでも、設定のインストラクションを書き加えることができる。

IaCのインストラクションは、命令型または宣言型になる。命令型を使う場合は、インストラクションに、どのようにシステム・コンポーネントをプロビジョニングし構成するかを定義した特定のコマンドを入れなければならない。対照的に宣言型では、希望する最終的な状態を定義し、その状態に到達するために必要なステップは入れない。どちらの場合でも、目標となるのは、アプリケーションがデプロイされた時はいつでも同じ環境を得ることだ。

IaCデリバリを可能にするツールは、Ansible、Chef、Puppet、SaltStackなど多数ある。これらの多くが、命令型、宣言型両方のインストラクションをサポートしている。企業はまた、アプリケーションのプログラムに沿ってIaC定義ファイルをソースコントロールシステムの中でチェックできる。この方法によって、アプリケーションプログラムを管理するのと同じように、自社の基盤を管理できる。これにより、過去のバージョンに遡ることができ、重要な変更を見つけ出し、定義の比較や、他のオペレーションの実行も可能になる。

IaCのアプロ―チは、DevOpsアプリケーション・デリバリと相性がいい。なぜならばIaCは、開発者とテスターが自分が必要とする環境を構築できるからだ。その際、システム管理者に必要な基盤を供給してもらうのを待つ必要はない。これはまた、DevOpsチームが常に一定の環境で仕事ができることを保証し、さらに、アプリケーションプログラムに沿ってこの環境を試験することもできる。

コンバージド・インフラストラクチャー（CI）は、従来のインフラストラクチャーより素早く実装でき容易な管理が可能な、プリコンフィギュアされたハードウェアとソフトウェアのパッケージを提供するソリューションだった。CIアプライアンス内では、コンピュート、ストレージ、ネットワークのコンポーネントが物理的に統合されており、ハードウェアとソフトウェアは、特定のワークロード用に高度な最適化がなされていた。これによって、CIは適切な環境下では理想的なソリューションとなった。

残念ながらCIは、新たなアプリケーション技術の前では、過剰プロビジョニングや柔軟性の欠如など、従来型のデータセンターと同じ限界を多く示すことになった。

集約型システムの進化の次の段階は、ハイパーコンバージド・インフラストラクチャーの形でやってきた。このインフラストラクチャーでは、ハードウェア・セントリックのアーキテクチャーからソフトウェア定義のアプローチへの移行が行われた。当初はコンピュートとストレージが対象だったが、最終的にはネットワークもソフトウェア定義の対象となった。HCIは、コンポーネントをプラットフォームと緊密に統合することにより、拡張を容易にし、抽象化と自動化のレベルを深化させるのに多大な貢献をした。

HCIは、仮想デスクトップ基盤のような、特定のワークロードでは効果があることが証明されたが、HCIもまた従来のアーキテクチャーと同様、過剰プロビジョニングと柔軟性の欠如に苦しんだ。これが、コンポーザブル・インフラストラクチャーが登場するきっかけとなった。

コンポーザブル・プラットフォームは、HCIよりワークロードの変化にうまく対応でき、ベアメタル上でもアプリケーションを実行できる。これにより、アプリケーション・パフォーマンスに影響を与える、ハイパーバイザへの依存性をなくすことができた。同時に、コンポーザブル・インフラストラクチャーはコンテナとVMベースのワークロードへの対応が可能なため、他のコンバージド・システムより優れたアジリティを提供することにつながった。さらに、コンポーネント分離型のアーキテクチャーは、より良いリソース使用率とより円滑なオペレーションをもたらすとともに、より高く、より柔軟な拡張性も提供するものとなった。

コンポーザブル・インフラストラクチャーは特定のワークロード用にプリコンフィギュアされていないため、事前に設定要件を知らなくても様々なタイプのアプリケーションに対応出来る。リソースはサービスとして提供され且つアプリケーションから即座に使用可能なため、今日（こんにち）の変動するワークロード要求にも対応できる動的な基盤を提供している。コンポーザブル・インフラストラクチャーを動かしているインテリジェント・ソフトウェアは、これらのワークロードへの対応に必要なリソースのデプロイと管理を容易にする役割を果たしている。

さらに、HCIと違って、コンポーザブル・インフラストラクチャーはDASを使用するため、仮想のソフトウェア定義のストレージ・レイヤーやそのレイヤーによって生じるレイテンシを無くすことができる。ユーザーはまた、コンピュートとネットワークのリソースが相互に独自に拡張できるのとまったく同じように、ストレージをコンピュートとネットワークのリソースから独立して拡張することができる。ハードディスクについても、半導体ディスクは勿論、NVMeやPCIeのような業界標準もサポートされている。

ソフトウェア定義のインフラストラクチャー

ソフトウェア定義のインフラストラクチャー（SDI）は、物理コンポーネントを管理及び抽象化し、それらをホステッド・アプリケーションに論理リソースとして提示するための、独立したソフトウェアレイヤーを使用するデータセンター環境である。SDI環境は、ソフトウェア定義のコンピュート、ソフトウェア定義のストレージ、ソフトウェア定義のネットワークなどの技術を、リソースをサービスとして提供するために使用する。

真のSDI環境では、ソフトウェアは全ての物理リソースを管理し、オペレーションを実行する際には、人間による割り込みをほとんど必要としない。SDIモデルは、高度な統合と自動化の達成を目標とし、より迅速なデプロイメント、簡易化された管理、より大きな柔軟性を目指している。SDIのソフトウェアレイヤーは、現在のアプリケーションの要求に基づいて、プロビジョニング、構成、管理のようなオペレーションを自動的に扱うことができる。SDIはまた、セキュリティや、バックアップやアーカイブを含むディザスタ・リカバリーに関連するオペレーションを実行することもできる。アプリケーション・パフォーマンスを最適化し、リソースの使用効率を最大化するオペレーションを実行するために、SDIの実装にはインテリジェント・ソフトウェアが必要だ。このソフトウェアは、状態を評価して適切なリソースのオーケストレーションを確保するために、常に基盤とワークロードをモニターしなければならない。

つい最近、AIや機械学習のような技術をSDIソフトウェアに組み込んで、オペレーションをさらに拡張する動きが出てきている。時（とき）として、AI定義によるインフラストラクチャーと呼ばれる取り組みである。

以下のいくつかの製品は、SDIを実装している。例えば、SUSE Managerは各種のハードウェアや、コンテナやクラウドプラットフォームを含む仮想環境にまたがるLinuxシステムを管理するために中央一元化されたツールを提供する。Nutanixは、Enterprise Cloudを提供している。このSDIソフトウェアは、Nutanix NXアプライアンス、他ベンダー製プリコンフィギュアド・アプライアンス、Lenovo ThinkAgile HX Seriesのようなサードパーティのサーバー上で稼働する。

メリットと課題

柔軟性はコンポーザブル・インフラストラクチャーの大きな長所の一つだ。ユーザーは、コンポーネントを独立的に拡張でき、変化するワークロードに対応する機能を目にすることになるだろう。後者は、常に統合と供給を必要とするDevOpsのプロジェクトをサポートする上で特に有用である。

コンポーザブル・インフラストラクチャーはまた、ITオペレーションを円滑にしつつハードウェアをより良く使うことにより、リソースの過剰プロビジョニング解消に役立つ。インテリジェントな管理レイヤーは、他のIT基盤で生じるデプロイメントや最適化のオーバーヘッドを除去する。これらは、特にワークロードが変化する時に生じるものだ。組み込まれている自動化やオーケストレーションは、手動の割り込みの必要性を減らし、多くの定型業務を無くすことによって、管理業務のオーバーヘッドを最小化するのに役立つ。IaCのように、コンポーザブル・インフラストラクチャーの長所を利用した手法によって、管理業務のオーバーヘッドをさらに減らすことができる。

これらの要素はすべて、基盤にかかるコストの節減に役立つものだ。企業はリソースをより迅速且つ効率的に割り当てられるので、アプリケーション・デリバリプロセスはより効率的になり、さらなる節約へとつながる。例えば、DevOpsチームの開発者とテスターはより迅速且つ簡単に自分たちの環境を構築でき、結果としてより効率的なアプリケーション・デリバリと全体の開発コスト低減が実現できる。

サービスをベースとしたモデルであるため、コンポーザブル・インフラストラクチャーはプライベート・クラウドやハイブリッドクラウドと相性が良い。また、AIや機械学習アプリケーションのような動的なリソース割り当てを要求するワークロードにも適している。

これらのメリットにもかかわらず、コンポーザブル・インフラストラクチャーにも課題がないわけではない。おそらくもっとも大きな課題は、これが比較的若い技術であるということだろう。ここ２、3年の間、堅実な進歩をしてきたとはいえ、コンポーザブル・インフラストラクチャーを動かすソフトウェアはまだ成長過程にある。特に、現行のプロセッサーの機能によって制限される、コンピュートとリソースの分離および構成を行うときにそれが露呈する。

さらに、コンポーザブル・インフラストラクチャーを規定する業界標準はまだ足りておらず、この基盤をデプロイする方法やコンポーザブル・インフラストラクチャーの定義さえベンダーまかせになっている。標準化の不足によって、この技術の潜在的な力は未だ引き出されないままだ。理論的には、コンポーザブル・インフラストラクチャーは複数の場所に存在する市販のハードウェアに対応できるはずなのだが、このような柔軟性が実現されるのは遠い将来という状況のため、ベンダー・ロックインの危険性が増加している。

また、コンポーザブル・インフラストラクチャーのシステムは、HCIより複雑だ。そのため、デプロイメントや保守は簡単ではない。結果として、この基盤のために技術力の高い管理者を置かなくてはならなくなり、コスト節約の幾分かはそこで相殺される。先行投資がいきなり跳ね上がることも起こりうる。また、業界標準がないために、ベンダー独自の機器にロックインされてしまうと、コンポーザブル・インフラストラクチャーをシステムに加えるのは高くつくかも知れない。

コンポーザブル・インフラストラクチャーの要はレイヤー構造

コンポーザブル・インフラストラクチャーは、3つの基本レイヤー、物理リソース、コンポージング・ソフトウェア、管理APIによって作られている。下図は、コンポーザブル・インフラストラクチャーを提供するためにこれらのコンポーネントが、どのように連携しているかを概念的にまとめたものだ。物理レイヤーにはコンポーザブル・インフラストラクチャーの基礎となる、コンピュート、ストレージ、ネットワークのリソースが入っている。

コンポージング・ソフトウェアは、物理コンポーネントを抽象化し、API経由でアクセスできるように、これらを論理リソースプールにまとめる。このソフトウェアは、プログラム可能且つ構成可能で、自己修正機能を持っている。このソフトウェアは、特定のアプリケーションの要件を満たすのに必要な論理リソースを自動的に構成することができる。また、特定のユースケース用に、事前定義された設定を提供するテンプレートの使用をサポートしている。コンポージング・ソフトウェアの内容はベンダーにより様々あり、機能の詳細や実装される方式もまた様々なバリエーションがある。

管理APIは、コンポーザブル・インフラストラクチャーのリソースへのアクセスを円滑にする重要な役割を担っている。一つのAPIが、サーチ、インベントリ、プロビジョニング、更新、診断など幅広いオペレーションを実行する。開発者は、このAPIを使ってプログラムで基盤を制御でき、管理者はこのAPIを使って当該環境のあらゆる箇所を操作できる。例えばこのAPIによって、IaCベースのアプリケーションがオンデマンドで基盤を構成することができ、またDevOpsチームが自動的にプロビジョニングされたリソースに既存のアプリケーション・デリバリツールを使うこともできる。

導入の検討と様々な製品ベンダー

自社のデータセンターにコンポーザブル・インフラストラクチャーを検討しているITチームは、きちんと調査を済ませておかなくてはならない。ベンダーごとに製品は相当異なり、業界は急速に進化している最中だからだ。

Hewlett Packard Enterprise（HPE）は、2015年にこの技術の取り組みを始めて以来、この潮流の最先端に位置してきた。Synergyベースのプラットフォームのリリース以降、HPEは絶えず自社のコンポーザブル・インフラストラクチャー製品の機能を改良・拡張してきた。例えば、HPEは現在、コンポーザブル・インフラストラクチャーをProLiant DLラックサーバー及びSynergyマシン上に提供している。さらにHPEは、Composable Cloudと呼ばれるハイブリッドクラウドを導入した。これは、プライベートクラウド・プラットフォーム上でコンポーザブル・インフラストラクチャーの構築を可能にするものだ。

この市場のコンポーザブル・インフラストラクチャーのプレイヤーはHPEだけではない。Dell EMCは、PowerEdge MX上で稼働するコンポーザブル・インフラストラクチャーを提供している。Dellによれば、このプラットフォームは、kinetic infrastructure（真のコンポーザブル・インフラストラクチャーという意味を表すDell EMCの造語）と定義されるタイプの最初の製品である。 Liqidも、Intel Optane SSD上に構築されたコンポーザブル・インフラストラクチャー製品をいくつか販売している。さらにDriveScaleは、コンポーザブル・インフラストラクチャー構築用にハードウェア・インディペンデントなプラットフォームを提供しており、またIntelは、コンポーザブル・インフラストラクチャーを独自の形式でデプロイするために、Rack Scale Designリファレンス・アーキテクチャーを提供している。

ここに挙げた製品及びその他の製品が示すことは、コンポーザブル・インフラストラクチャーの解釈が製品の数と同じくらい存在するということだ。その結果、ITの意思決定者は、個々のコンポーザブル・インフラストラクチャーを評価し、それぞれを比較し、その上で特定のニーズと予算に最もあうものを判断しなければならない。

そうは言っても、コンポーザブル・インフラストラクチャーの方式はまだ市場に登場したばかりだということを認識すべきである。全ての企業がこの技術からメリットを受けるとは限らない。もし受けたとしても、正しい製品を選択するのはたやすいことではない。適切な環境下においては、コンポーザブル・インフラストラクチャーは、相当なメリットを実現する可能性があるが、そこまで到達するには相当の時間と努力が必要になる。

Robert Sheldonは、技術コンサルタント兼フリーの技術ライター。
Emailアドレスは、contact@rhsheldon.com