SDSの使いどころはココだ、ユースケースと選び方、6つのポイント：IT導入完全ガイド（2/5 ページ）

　もともと現在のようなSDS進展の発端がコモディティサーバを活用したスケールアウト容易な、いわばAmazon S3のようなデータサービスへの関心の高まりだったこともあり、分散するコモディティサーバを仮想化して1つのストレージに見せる手法がすなわち「SDS」だという認識も広がっている（図1）。むしろこの方が現在のところ一般的な理解なのかもしれない。

図1　Software Defined Orchestrationと、分散コモディティサーバを利用する「SDS」（出典：レッドハット）

　実際、現在SDSに関心を寄せる企業の多くは、コモディティサーバを活用して低コストにデータ増大に備えたいという動機を持つ場合が多いようだ。特にストレージノードとなるサーバが廉価で、追加もリプレースもサービスを止めずに迅速に行えることが注目される理由になっている。

　この方式の場合、各サーバ上のソフトウェアが内蔵ストレージの管理機能を担い、分散したノードの連携も同ソフトウェアが行う。レプリケーションやスナップショットなどの冗長化やデータ保護機能などもソフトウェアの機能として備えている。

　基本的にはオブジェクトストレージを形成し、データがどのように分散していても、またサーバ間を移動していても、オブジェクトIDは一意なので矛盾がおきることはない。アクセスはシンプルなREST APIを利用でき、インターネット経由でのアクセスにも好適だ。パフォーマンスは専用アプライアンスよりも低いため、更新頻度は比較的低いが大量・大容量を必要とするアプリケーション（例えば画像や映像、分析系など）により適性がある。一方で高速トランザクション処理には難がありそうだ。

　ただし、性能の問題はハードウェア側（CPUなどのデバイス）の進歩により常に変わる。その進化の恩恵をサービスを止めることなく、継続的にタイムリーにストレージに組み込んでいけるところも、ハードウェアベースのストレージ専用製品とは異なる特長だ。

　レッドハットでは、ストレージを従来型の「データ容器」としての存在ではなく、IAサーバのコンピューティング能力を最大限に活用した「ストレージ＋コンピューティング」こそが本来のSDSの持つ可能性だと考えている。

　これを表現するキーワードとして「ストレージング」という言葉も生み出している。実際、ストレージベンダーがこれまで行ってきたストレージの進化を、今後はソフトウェアベンダーやオープンソースコミュニティー、あるいはSIerが担うことも可能になるはずだ。

　なおアクセス方式としてはRESTばかりでなく、ファイルアクセスやブロックアクセスも可能にした製品がある。例えばEMC ScaleIOはブロックストレージをコモディティサーバ上に構築できる。オープンソース製品のGlusterは分散ファイルシステムを構築する。

　同じくオープンソースのCephはオブジェクト／ファイル／ブロックアクセスの全部をサポートしている。VMware vSANは独特で、同社の仮想環境vSphere専用でvCenter Serverに管理を一元化、アクセス方式は独自APIなのでvSphere以外からのアクセスはできない。