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

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

Mike Matchett
Storage Magazine 2015年9月号より

(前編からの続き)

今日(こんにち)のHadoopエコシステム(YARN、MR、Sparkなどなど)の幅広い人気とユーザー数の増加をみれば、誰しもパラダイムが変わったことを理解するだろう。Hadoop分散ファイルシステム（HDFS : Hadoop Distributed File System）はもともと、計算処理も提供するスケールアウト・クラスターを稼動させるために設計された。巧みな並列処理アルゴリズムとそれを支えるジョブスケジューラーが、各ノードに対して各自が保存しているデータのかたまり（訳註：大容量データをぶつ切りしたもの。チャンクと呼ばれる）を解析するタスクを送る。規模の増大に対応するためにノードを追加することによって、容量は増大するがパフォーマンスは相対的に一定を保つ。

Hadoopはコモディティサーバー上で稼動するように設計されたスケールアウト・プラットフォームなので、HDFSはおおまかにいえば、ビッグデータ向けに設計されたソフトウェア定義のストレージの仲間である。とはいえ、単純に組み上げただけのHadoopは、複数のタイプのデータの同時処理、QoSを分ける必要のある複数のユーザーや処理作業、複数の段階のストレージで処理されるデータフローなどにおいて、いくつかの課題を抱えている。単一のHadoopクラスター内では、容量とパフォーマンスを別々に拡張するのは一般的にはかなり難しい。さらに、Hadoopネイティブの製品はエンタープライズデータ管理の要件に対してはまだ発展途上であり、HortonworksやClouderaなどのHadoopベンダーが何とかそのギャップを埋めるべく頑張っている状況だ。

エンタープライズネットワークが日々高速化している現在、ユーザーの環境によっては、スケールアウト・ストレージシステムを、別系統のスケールアウト・プロセッシングシステムとネットワークで密につなぐのは、なかなか良いアイデアだ。ストレージとプロセッサーを集約したシステムの替わりに、基盤ドメインをゆるやかに結合させておくことで、既存のデータ管理プラットフォームを維持し、複数プロトコルによるデータ共有のアクセスパターンにも対応できるのだ。

既存のエンタープライズストレージを試用する前に、大規模データ解析に対する以下の要求事項を考慮して頂きたい。処理量が同程度のたくさんのクライアント間で、一元化されたデータを共有するために設計された従来のストレージプラットフォームは、膨大な数の異なる小さなファイルを提供できるのか？あるいは、数は少ないが巨大なサイズのファイルを、たくさんの解析アプリケーションに同時に提供できるのか？一例としてHDFSは、長時間の連続読み込みを伴う、巨大なデータストリームを必要とする解析をサポートできるように設計されている。これが従来のNASであれば、小さなファイルのリード・ライトに対応するために、ホットデータのティアリングやキャッシングで頑張っていたかも知れないところだ。

解析用大規模ストレージを管理する

以下に注意すべきポイントをあげる：

1．キャパシティプランニング
大量のデータと一見すると無限のように思われるスケールアウト・インフラストラクチャーのバランスをとるのは、結構大変なことだ。キャパシティは、容量不足の状況を作らないようにしながら、コストの最適化のために、常々注意を払い、計画を立てていく必要がある。

2．クラスター
どのような種類のIT基盤のクラスターでも、数百、時として数千のノードに増加するので、効果的なクラスター管理が重要になってくる。パッチ作業、プロビジョニング、その他のタスクは世界水準の高度な技術がなければ、維持管理していくのは困難になる。

3．ビッグデータ・ワークフロー
真に効果的なストレージシステムを設計しているのであれば、データの発生から消滅までのライフサイクルを理解したうえで、データについて考えてもらいたい。ソースから結果、結果からコンテンツ配信および消費（これを繰り返す）がデータのライフサイクルである。

4．データ保護
規模が大きくなるとデータを損失や破損から守り、起こりうる災害から復旧することは、ますます重要になる。大規模なデータストレージを対象とした、スナップショット、レプリケーション、バックアップ、DRなどのソリューションを探してもらいたい。

未来図：コンバージドデータレーク

全体的に見て、未来はコンバージド（およびハイパーコンバージド）製品が担っているようだ。進化を続けるHadoopアーキテクチャーは一例に過ぎない。コンテナテクノロジーの登場とともに、従来のストレージアレイが既存ストレージを改造せず、ネイティブでどのようにして大量のデータを使うアプリケーションにサービスを提供できるようになるか、という話もちらほら聞かれるようになった。

ITコンバージェンス（集約化）は様々なレベルで起こっている。より複雑で難しいことを要求してくるアプリケーションに対応するために以下のような動きもある。
ひとつは、ストレージと計算処理（およびネットワーク・サービス）の統合、ふたつ目は、異なるデータのタイプの混在（非構造型ドキュメントを扱うトランザクション型レコードやマシンデータ・リポジトリとの組み合わせなど）である。

ひとつの会社に関連するあらゆるデータをキャプチャーし、保持し、一括管理するために、まずデータをHadoopクラスターに格納するという、エンタープライズ・ビッグデータレーク構想を、多くのベンダーが推し進めている。マスターレポジトリーから取り出されたデータは、ビッグデータ解析アプリケーションや社内の様々な部署のユーザーが直接共有データとして使えるようになる。
とは言うものの、データレーク構想の最も厄介な問題は、ガバナンスとセキュリティである。構造型データベースでさえも、ひとつのデータを正確に追跡し、見つけ出すのは難しいが、巨大な非構造型データの湖での追跡の難しさとは比べ物にならない。どのような条件のデータ解析シナリオにも対応して、有益な情報を提供することも大事だが、クレジットカード番号のようなデータは見つけ出しかつマスクすることが、コンプライアンスの観点から重要である。

さらには、常に変化するデータレークに様々な方法でアクセスが行われているが、誰がどのデータにアクセスできるかを、どのようにコントロールするか？さらには誰がそのデータにアクセスしたのかをどのように追跡するのか？ユーザーは、データクオリティの観点から、どのデータが最新で、どこから来たのか、そのデータのどこが法的に有効とされているかを知りたいと思うだろう。

ふたたびクラウドの未来へ

われわれは、以前であればHPC（ハイ・パフォーマンス・コンピューティング）と考えられていたような環境が、いまや大規模データ解析処理に対応するために企業のデータセンターに参入してきたことを目にしている。その例として、PanasasのPanFS、Lustre社製品をベースとしたアレイ(DDN EXAscalerなど)や IBMの GPFS が入った IBM Spectrum Scaleなどが挙げられる。
さらには、パブリック・クラウドストレージと超高速解析エンジンの連携も行われている（AWS S3やAmazon Elastic MapReduceなど）。今日(こんにち)多くのクラウドのセキュリティ体制は、一部のエンタープライズ・データセンターよりよほどきちんとしており、クラウド・オプションは殆どのコンプライアンスに対応している。

クラウドを使う際の障害として考えられている問題点のひとつが、クラウドへのデータ移行の費用と時間である。しかし、実際には多くのアプリケーションにとって、殆どのデータはクラウドに一度だけ移行すればよいのであって、（クラウド内でデータが生成されない限り）それ以降、移行が必要なデータの増加量は十分管理可能である。もちろん、クラウドデータ・ストレージのコストは常時累積されていくが、それは予算化すればよい話だ。

ソフトウェア定義、スケールアウト・ストレージ、コンバージド・インフラストラクチャー（ストレージと計算処理）、仮想化、コンテナとクラウドによる取り組みなど、企業はいまやどんな困難なデータ解析要求がやってこようとも、それに対応する、コスト効率がよく、拡張性に富んだストレージを構築するための装備は十分整っている。(完)

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