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

データ解析用アーキテクチャー：最新ビッグデータ・ストレージ(前編)

Mike Matchett
Storage Magazine 2015年9月号より

ビッグデータ解析はストレージシステムに新たな要求を突きつけ、往々にしてストレージ構造の一新や改造が必要となる。

他企業との競争によるものか、社内からの圧力によるものかを問わず、最近はCIO、CDO（チーフ・データ・オフィサー）、さらにはCEOまでもが自社のデータから更なる価値、更なる洞察、更なる情報を搾り出すことに大きな関心を寄せている。彼らには、価値ある資産に化けるかもしれないデータを仕舞い込んだり、無視したり、捨てたりする余裕はもはやないのだ。文字通り受け取れば、この状況は何も考えずに「価値を堀り出すために、ただ全部のデータを分析すればよい」ように見える。しかし、お分かりのように、たとえそれがビッグデータよりもはるかに小さいデータであっても、データを保持すれば確実に費用がかかる。大量のデータを大規模に処理するのには困難が伴う。さらに、全てのデータをいつでもプライマリ・ストレージで処理できるとは限らない。

これまでは、法令順守の履歴調査や業務プロセスを最適化するための戦略的洞察や情報のソースなどのような、何らかの企業価値がない限り、データの保持を正当化するのは難しかった。今日、この考え方は変わりつつあり、これはビッグデータ解析アプリケーションに負うところが大きい。下位のビッグデータは嵩張るばかりで直近の価値はほとんど望めないが、いつか見出される絶大な価値を秘めているかも知れない。だからこそ、あなたの会社ではそれを保持しようとする。いったんデータを失えば、それ以降の機会が失われるからだ。

ビッグデータ錬金術

とはいえ、全てのデータから価値を引き出すためにIT部門は、ますます巨大になるデータを保存するだけでなく、複数の方法でデータを処理し解析できるシステムを設計しなければならない。何年もの間、これに対する標準的なアプローチは、限定された構造型・トランザクション型データを BI (ビジネス・インテリジェンス)ワークフローを提供するためにデータウェアハウス（および関連するシステム）に蓄積し、コンプライアンスや特定のサーチやリコールのために、古いデータやファイルベースのデータはアーカイブする、というものだった。かくして我々は長きに亘り、構造型クエリベースの解析用には高価なスケールアップ・パフォーマンス志向のプラットフォームを使ってきた。その一方で、法的期限がくるまでの履歴やコンプライアンスデータの長期保存用には、容量効率の良い大容量コンテンツ保存装置を使うのが一般的だった。どちらも導入し効果的に運用するには複雑かつ高価な代物だ。

しかも、前述の制限だらけの二つのパターンによるアプローチでは、その潜在的な価値を取りこぼすことが多く発生してしまう。もちろん、市場では革新的な技術が出揃ったので、より大きな規模と高速で行う動的解析の価格が下がっただけでなく、手付かずで眠っていたデータへのアクセスの溝も埋めることができるようになった。アーカイブのアーキテクチャーが、キャプチャーしたコールドデータをもっと「活動的に」役立てるように、ネイティブなサーチ型解析機能の組み込みを始めたのもその一例だ。
今日、何世代にも亘るパフォーマンスと拡張性の改良によって、以前は死にかけたデータの廃棄場と考えられていたところが、Webスケールのオブジェクトストレージ（AWS S3など）へと進化している。

同様に新興のHadoopエコシステムは、HPCに触発されたスケールアウトのパラレルプロセッシングシステムを安価なハードウェアで構築可能にし、一般の企業がコスト効率よく、ハイパフォーマンスのデータ解析を大規模なシステムで行えるようになった。ユーザーが初めてビッグデータを扱うとき、Hadoopは、生の詳細データの置き場として、また高度に構築されたBI/DWアーキテクチャー用に大規模のELT（抽出(extract)、流し込み（load）、変換（transform））/ ETL (extract, transform, load)のホストとして恰好のシステムを提供してくれる。それだけではない。成長を続けるHadoopエコシステムはさらに、構造化率が低く、容量が大きく、データ増加速度が速いデータストリームから価値を探し出す機能を世に出した。今日、複合型HadoopおよびHadoopコンバージド・プロセッシング製品（例えば、HadoopとVerticaを統合したHP HAVEnなど）は構造化解析用スーパーパワーと非構造化解析用のスーパーパワーを密に結合し、経営に焦点を絞った（即ち、リアルタイム業務の中での）ビッグデータ解析用アプリケーションの実行を可能にした。

実際、われわれは常に拡大するストレージと常に拡大するデータ処理を組み合わせた、集約型の（即ち、使い勝手の良い）ITアーキテクチャーの真新しくワクワクする事例を目にしているのだ。企業が巨大な規模で有効なデータ解析を行う環境はかつてないほど良くなっているが、ストレージの選択肢が多すぎて途方に暮れてしまう。購入可能な選択肢の中のベストとは何かを理解するのは、きわめて難しいことかもしれない。

ビッグデータ・ストレージ成功への鍵

データの大規模保存と解析に取り組むとき、以下のことを検討してもらいたい：

・ストレージ（計算機、メモリー、などなど）が常に安価になっている一方で、解析用データの設置面積は増え続けそれにつれてコストも上昇している。予算を組むとき、データ転送と移行費用、（最終的にデータを消去する費用をも含む）データの寿命期間中に発生する作業、その他運用管理要因（例えばストレージ管理の運用コスト）などを全て計算に入れなければならない。

・規模が大きくなると、データ保護、ビジネス継続、可用性、セキュリティの確保が難しくなる。小さなカゴに大量の卵を山積みにすれば、膨大な脆弱ポイントを作り出すことになる。

・これまでデータ解析の需要の多くがバッチ主体の処理と合致していたのに対して、このごろは解析のアウトプットがリアルタイムで適用され、動的業務プロセスの結果に影響を与えるケースが増えている。（例としては、目の前にいる潜在顧客や得意客のニーズの解析などがあげられる）この高速オペレーショナル・インテリジェンス（訳注：リアルタイムにデータ解析を行い、現場の意思決定を支援するシステム）には、よく練られたビッグデータワークフローが必要だ。この処理は複数のシステムを横断する可能性が高く、おそらくは、慎重に検討された量のフラッシュキャッシュまたはインメモリー処理が必要になるだろうからだ

解析用大規模データストレージ

ではビッグデータを保存し、解析して企業にとって有益なものとするには何が必要なのだろうか？言うまでもなく、ほとんどの人が最初に取り組まなければならないことは、データをこれまでよりも大きな規模で扱うことだ。よくとられるアプローチは、容量増加の必要にあわせてストレージのノードを追加できるスケールアウト設計を利用することだ。スケールアウト製品は、データ増加のスピードにあわせてほぼ直線的なパフォーマンスの伸びを見せる。容量のためのノード追加がIOPS向上のためのノード追加を意味するのだ。レイテンシ改善のために半導体ストレージを積んだノードを追加できるアーキテクチャーもあり、ストレージプール拡張のためには大容量のノードを追加できるアーキテクチャーもある。

これら大規模解析システムの新世代について、2番目に気づくことは、分析処理がストレージ基盤と統合されつつある、ということだ。解析用データを別のストレージシステムに保存すれば、当然リモートI/Oパフォーマンスという「税金」を払うことになる。ビッグデータと処理負荷の高い分析の組み合わせだとこの税金は、完全に障碍とまではいえないかも知れないが、相当な負担になる可能性がある。(後編に続く)

Mike MatchettはTanejaグループのシニア・アナリスト兼コンサルタント。