SDSで乗り切れ、データ爆発時代のストレージ運用

　「SDN（Software Defined Network）」の登場から数年、次の一手とばかりに広く唱えられ出したのが「SDx」。ITインフラにSoftware Definedという冠をかぶせ、SDS（後ろのSはストレージ）、SDC（Cはコンピューティング）、SDI（Iはインフラ全般）、SDDC（DCはデータセンター）、果てはSDE（EはEverything）という言葉まで生み出された。その中で、ツールが数々提供され、今最も注目されているのがSDSだ。

　SDSの仕組みを簡単に言えば、従来ストレージ専用装置に組み込まれていた管理・制御機能をハードウェアから切り離し、その機能をソフトウェアに移行して、物理的に分散したさまざまなストレージを単一の制御ポイント（ユーザーポータル、アプリケーション、オーケストレーションソフトウェアなど）から同一の方法で運用可能にすることだ。そのおおまかなイメージは図1のようになる。

図1　SDSのイメージ

コントロールプレーン

　ソフトウェアで実装、物理リソースを仮想化してプール化。ポリシーベースでアプリケーションと連携して自律運用が可能。

データプレーン

　ハードウェアで構成、データ格納と転送処理を担当する。ブロックアクセスとファイルアクセスを主とする製品と、オブジェクトアクセス（またはオブジェクトストレージベースでのブロック／ファイルアクセス）を行う製品とがある。

物理リソース

　ストレージ専用アプライアンス、スケールアウトNAS、コモディティサーバなど。

　これには、物理ストレージの「仮想化」が必要だ。つまり今まで「A社製の〇〇ストレージ」と呼ばれてきた物理ストレージ装置やサーバアタッチのHDDやSSD、PCIeFlash（サーバサイドフラッシュ）などのデータ格納・転送能力を「データプレーン」として集約し、「コントロールプレーン」では、例えば「低レイテンシ重視のストレージ」「スループット重視のストレージ」「性能より容量重視のストレージ」というように抽象化したストレージプールを作る。

ユーザー（あるいはアプリケーション、またはオーケストレーションソフトウェア）は、「性能Aランク、可用性Bランク（だが低コスト）のストレージを〇〇GB欲しい」と要求するだけで、SDSソフトウェアがサービスレベル別のストレージプールの中から、要求通りのリソースを自動的に選び出してあてがってくれる。このような仕組みがSDSだ。言い換えれば「ワークロードに従いSLAポリシーに基づいた自動リソースデリバリー」が行えるというわけである。

　肝心なのは、この時「ストレージベンダー名」「装置名」「データパス／プロトコル」などストレージごとに異なる属性はユーザーから見えず、知る必要もないところ。ユーザーはあてがわれたリソースを利用し、容量や性能などの要件が変われば、そのたびに同じような操作で最適リソースを手に入れられる。また必要なくなれば切り離して別用途に再利用することも簡単だ。

　これまで、適切なストレージリソースを調達するには設計や導入・テストを含めて数カ月かかる場合もあったが、SDSは物理リソースが足りていれば、かかる時間は数分程度。条件の変更にも迅速に対応できる。プログラマブルなAPIを利用して、全く人間が介在しない自動運用も可能になる。物理リソースの無駄を最小限にし、従来数年に一度は行われてきたシステム更改の際にかかる労力やコストを少なくすることも期待できる。

　このように言えば、よく似た特徴を持つストレージがピンとくるだろう。Amazon S3のようなクラウドストレージだ。実際、AmazonやGoogleなどの分散ストレージを活用した巨大データ活用成功モデルが、こうしたストレージ進化の方向を決めたといえるだろう。

　現状を大まかに言えば、S3のようなサービス志向、ポリシーベースのリソースデリバリーを人間の介在なしで行ってくれるソフトウェアが登場し、大企業ではプライベートクラウド構築のインフラとして、あるいはクラウドサービス事業者のサービスインフラとして、実装が始まってきたところだ。

　実際には数年前からソフトウェアはあったが、パフォーマンスの問題であまり普及はしていなかった。近年ではPCIeFlash（サーバサイドフラッシュ）やオールフラッシュストレージのような高速デバイスの進歩によりパフォーマンスの問題が徐々に解消してきたため、あらためて注目されているわけだ。

　物理ストレージとして使われるのは主にREST APIで利用できるコモディティサーバ（IAサーバ）だが、従来型のストレージ専用装置側もAPIでSDSソフトウェアに対応するようになってきている。だが既存ストレージ専用装置の利用前提なのか、コモディティサーバの分散環境を前提にするのかで選ぶ製品構成は違ってくる。それが全部「SDS」とくくられるため、混乱しやすいかもしれない。

　ではもう少し具体的に、SDSがストレージに関する課題の何を解決するのかを整理してみよう。

増大するデータ量への対応

　大きな課題の1つは、増大する一方のデータ量への対応だ。モバイル、クラウド、ソーシャル、ビッグデータという、IDC（調査会社）が名付けた「第3のプラットフォーム」に加え、本格化を始めたIoTにより、データの増殖スピードに拍車が掛かっている。平成27年版「情報通信白書」によると2014年の国内企業の受信データは約14.5エクサバイト。これは2005年時点の約1.6エクサバイトに比較すると約9.3倍相当だ。その伸び率は将来拡大こそすれ鈍化する要素はない。世界規模で見ると2020年には44ゼタバイトに届くといわれるほどだ。

　既に起きているデータ爆発に企業システムがどう対応するかが将来の競争力を左右するのは自明。コスト最適にいかに多くのデータを集め、活用可能な形で保管できるかがストレージ領域では焦点になる。そのためには柔軟にスケール可能で、データ量に応じたコスト上昇が抑えられるストレージが必要。SDS導入によれば、クラウドサービスを利用せずとも自社で将来のデータ増大に備えられる可能性が高い。

構造化データの増加を上回る非構造化データの急増

　従来のDBシステムに馴染む構造化データも増加傾向だが、それに倍する勢いで非構造化データが急増している。また第3のプラットフォームの普及により、データ増殖ペースも一定ではなく、予測が困難だ。この傾向に対応するには、いつでもデータ量増加に追従してスケールでき、非構造化データ保管・利用に適したストレージが必要だ。

　構造化データを高速に処理するには、ストレージのブロック単位でアクセスする「ブロックストレージ」が適するが、データ長が一定でない非構造データでは、従来ファイルサーバやNASなどの、階層化されたディレクトリにファイルを整理する「ファイルストレージ」、大規模な分散ストレージ構築に向いた「オブジェクトストレージ」が使いやすい。だがそれぞれアクセス手法が違うため、ソフトウェアでその違いを吸収する必要がある。SDSはそうしたデータパスをも仮想化し、さまざまなインタフェースが利用できることを目標にしている。実際のSDS製品が全てのデータパスを備えているわけではないが、分散したコモディティサーバをブロック、ファイル、オブジェクトの各ストレージとして利用できるソフトウェアが登場しており、従来の構造化データの利用に加えて非構造化データの増大に備えることが可能になってきた。

表1　アクセス方式の3種類

コラム：オブジェクトストレージって何？

　ファイルシステムやRAIDを介さずに、アプリケーションからHTTP（REST）で、オブジェクト単位でソフトウェアを介して書き込むタイプのストレージ。オブジェクトとは、データ本体とそのヘッダ情報（メタデータ）のことで、オブジェクトストレージはオブジェクトにID（ハッシュ値などによるユニークなID）を付与して管理する。

　ボリューム設計などが不要で簡単に拡張可能、分散化にも適する。一方でデータ保護のためにはレプリケーションやイレージャーコーディングなどの冗長化・可用性対策を必要とする。主にクラウドサービスで非構造化データを大量に保管する目的で利用されている。オンラインストレージとして利用可能だが、ソフトウェアのオーバーヘッドが性能に影響するため、ニアラインストレージとしての活用が本命とする意見もある。

ビジネスの俊敏性アップにリソース調達スピードがネックに

　ビジネス視点で見ると、ビジネス変化のスピードにリソース調達のスピードが追い付かなくなることが懸念される。ストレージ増強や変更が分単位で済むような俊敏なリソースデリバリーが求められる。またビジネスは拡大一方ではなく、縮退や廃止を迫られることもある。その際にもリソースが別用途に活用できる仕組みが必要だ。上述の特徴から、SDSはビジネス変化に迅速に適応する俊敏性をストレージにもたらす。

ITインフラコスト、運用管理コストの抑制

　ITリソースはできる限り合理的・効率的に利用し、無駄なリソースを所有しないことがコスト最適化のために肝心だ。特定システム運用の前提で導入されたハードウェアベースのストレージはストレージをサイロ化し、容量の無駄を引き起こしかねない弱みがあった。また拡張や縮退時にはデータの移行に多くの時間が費やされた。

　SDSではストレージノードやディスクを追加／削除すれば自動的にストレージプールにデータを自動的に再配置できる。コモディティサーバを利用するSDSなら、サーバを追加すればするほど容量を増強できるばかりでなく、性能も追加台数分リニアに上げることができる。また、物理ストレージを一部撤廃した場合でも、そのデータは自動的に他の物理ストレージに移動し、人手や時間をかけずにサービスを継続することが可能だ（図2、図3）。従来のRAIDディスクの障害復旧に必要だったリビルド時間も気にせずに済むだけでも、管理負担は軽くなるだろう。

図2　コモディティサーバのスケールアウト、縮退に伴うデータ再配置のイメージ（出典：EMC）

図3　サーバのスケールアウトに伴いパフォーマンスもリニアに向上　※100 IOPS、1TBのサーバを10台利用した場合と、さらに10台追加した場合の容量と性能の例（出典：EMC）

　またデータセンターにてラック単位で場所借りしている場合も、例えば1Uサイズのサーバをラックの空きスペースに積み込むことで料金を節約することもできそうだ。ストレージ専用アプライアンスを利用する場合には、数年後の必要容量を見越してあらかじめ隣接するラックを増設用に用意することがあるが、その無駄スペースをなくすことでコストセービングが可能になる。必ずしもラックが隣接していなくてもネットワークを介した接続ができるところも有利だ。

　さらにコモディティサーバの場合は、故障や老朽化によってリプレースする場合も、単純にサーバを置き換えるだけで済む。導入・移行はほとんど物理筐体を設置・設定する手間だけにできる。特にシステムを止めずに追加可能なことには注目すべきだろう。システム更改のタイミングでも、ストレージに関しては更改が不必要になることも考えられる（図4）。またコモディティサーバとして廉価なホワイトボックスや中古品でも、スペックと品質が水準をクリアしていれば利用できる。若干のリスクはあるが、コストと容量を重視する場合には選択肢の1つになりそうだ。

図4　ハードウェアの追加や削除に要する時間は大きく短縮（出典：CTC）

　また、既存ストレージ専用アプライアンスを利用する場合でも、マルチベンダー製品を統一的な手法で運用できることが運用管理負荷の低減につながるだろう。拠点をまたがるストレージ運用管理もやさしくなる。

　以上、今回はSDSの大まかなイメージと仕組み、利点について述べた。良いことづくめに見えたかもしれないが、SDSはまだ発展途上の技術である。上述したのは一種の理想論であり、具体的な製品ではまだ完全にマルチベンダー対応とは言い切れず、全てのストレージ製品へのアクセスや従来のハードウェアベースのストレージ機能（レプリケーションやバックアップ、スナップショットなど）が生かせる保証もない。さらに、どんな場合でもSDSを導入しさえすればコスト削減や運用管理負荷軽減につながるかといえば、答えはノーだ。まだまだSDSには注意すべきことも多い。