「NetAppビッグデータソリューションNetApp Open Solution for Hadoop の全貌」
NetApp Tech OnTap NetApp Logo NetApp Logo
NetApp Tech OnTap
     
「進化を遂げた
NetAppビッグデータソリューションfor MapR」
シェアする NetAppオフィシャルFacebook

ソリューション概要

こんにちは。前回に引き続いて今回は具体的な中身についてご紹介していきます。以下再掲します。

  • Hadoop ディストリビューションに 「MapR」を採用し、よりエンタープライズ向けへ
  • NetApp Eシリーズに最新モデルのE5500を採用し更なるハイパフォーマンス対応
  • Cisco UCSサーバとEシリーズのみで構成されるビルディングブロックでシンプルスケールアウト

HadoopディストリビューションMapRの採用

進化を遂げたNetAppビッグデータソリューションでは、Hadoopディストリビューションにエンタープライズ・グレードのMapRを採用しています。MapRには画期的な多くのイノベーションが盛り込まれていますが、ここで注目したいポイントは高い信頼性・運用性と既存データを有効に活用できる、NFSアクセスを可能としている点です。

以前のNetApp Solution for Hadoop では、NameNodeを保護するためにサーバの冗長化、またそのメタデータを保護するために高信頼性であるNetApp FASストレージを適用していました。進化した本ソリューションでは、この点が非常にシンプルになっています。

図2: HDFS ビルディングブロック

実データだけでなくメタデータを各ノードに分散して持たせることにより、サーバ・ストレージの分のコスト削減をしつつ、多くのメリットを教授することができるようになっています。この辺りの設定などはそれほど意識して作業する必要はなく、インストール・初期セットアップ時に自動で分散配置およびHA構成されるようになっており、導入・運用面でも容易さが特徴です。

もう一つのダイレクトなNFSアクセスですが、通常のHadoopでデータを活用させる際に対象データをHDFSに保存する操作が必要になります。ここでHDFS特有なお作法を意識する必要が有るため、一般には面倒があります。MapRが開発したMapR FSは多くのAPIを利用できます。その中で大量なデータを流し込むのに使いやすいのは やはりNFSでしょう。シンプルにMapR FSのデータ格納領域をNFSエクスポートし、クライアントは慣れ親しんだPOSIX準拠でNFSマウントしデータ保存することができます。

図2: HDFS ビルディングブロック

出典:「MapRを選ぶ理由」より
http://jp.mapr.com/why-hadoop/why-mapr/architecture-matters

データ活用・分析等の前段階であるデータ投入に関して無駄な労力や時間を掛ける必要がなくなりました。

NetApp Eシリーズ E5500を採用し更なるハイパフォーマンス対応

前回の構成では、Eシリーズのコントローラとしては、E2600またはE5400というものでした。今回採用したE5500は下記のように性能が上がっています。

図2: HDFS ビルディングブロック

特にHadoopの主なワークロードとして扱われるシーケンシャルアクセスの性能アップは目の見張るものがあります。MapRはランダムアクセスも得意としており、このE5500はランダムアクセス性能としても前モデルよりもアップしています。

ビルディングブロックでシンプルスケールアウト

今回、本ソリューションをリリースするにあたり下記のような構成で検証を行っています。

図2: HDFS ビルディングブロック

何も難しいところはなく、サーバとしてCisco UCS を4式、NetApp E5560を1式使った構成の動作確認です。ここでのポイントはこの形を基本の「ビルディングブロック」としてスケールアウトさせていく事が可能になるということです。ただし、データの活用方法やその後の要求具合によっては、CPUリソースのみであったり容量リソースのみ増強したいケースも出てくるかもしれません。その場合に柔軟な対応が可能です。1つのE5500は8つまでSASのインタフェースをもっているため最大8サーバを直結できCPUリソースのみ増強できます。また、E5500はNL SASを搭載した場合は360本(外付けのシェルフを+5)までサポートされています。よって容量のみでもビルディングブロックに追加できます。なお、コントローラのIO帯域性能も含めて考えると120本(外付けシェルフは+1)までスケールさせることができます。

図2: HDFS ビルディングブロック


図2: HDFS ビルディングブロック

CPUのマルチコア化が進んでいる昨今、多くの場合は容量追加が先に要求される事になるでしょう。そういった場合、特に4Uのラックスペースで高密度に大容量を格納できるEシリーズはエンタープライズのお客様には都合の良いものといえます。

ビッグデータへのアプローチ

ここからは自分の言葉で本ソリューションからビッグデータ、ここではデータ活用までのアプローチを伝えます。大きく2つです。「ためる」と「ETLオフロード」です。

このソリューションは何よりもデータ活用基盤を作る上でNFSの口を持っていることが第一のポイントです。「NFSであれば、NetAppならFASシリーズ、Data ONTAP / clustered Data ONTAP を使えばよいのじゃないか」と声が聞こえそうですが、それでは適切でない理由があります。データためる箱としても分析基盤としても、Eシリーズの方に分があるのです。まず、シーケンシャルアクセスにおいてはFASシリーズはこれほどの性能が出せません。またデータがどんどん増えてきた場合、高密度なEシリーズはFASよりもラックペースを節約できます。結果、金額コストもかかりません。そして、NFS部分でいうと実はApache Hadoop を含め他のディストリビューションもNFSのインタフェースそのものは出すことはできます。しかしながら、そのバックとなるHDFSの仕様や、エンタープライズという観点で、導入・運用・性能・信頼性の多くの面で劣ります。これまでのNFSを普通に利用してきた方々からすると、それは扱いづらいと感じることもあるでしょう。ですが、MapRはファイルシステムも改良した上でNFSを提供しています。そのためこれまで利用していたNFSのまんま、他のアプリケーション、データベースからのデータ共有が非常に楽に行えます。

ここから何がえいるかというと、ビッグデータ、「データ活用」をはじめようとした人達はまず「データをためる」という事からすぐに着手きるようになるのです。「どんなデータがいい?」「何をしたらよいか?」「どう分析しようか?」「何がみつけられるか?」「ちゃんと効果がでるのか?」当然これらをしっかり考えて計画していくことも大事でありますが、そうしている間にも先にはじめている競合他社との差が開いてしまいます。このソリューションは時間を無駄にしません。必要なデータ全部入れてしまえばいいのです。乱暴な言い方ですが、そういうアプローチもありだとおもってます。データ活用のための人・段取りなどがまだであれば、ためながら準備していけばいいのです。ちょこっとでもデータ分析経験をしていくと、結局いろいろなデータを掛けあわせたりしていくもので、データはあればあるほどいいのです。様々な角度で分析、推測することができ早く気付きを得て対策をねり、アクションにつなげることができるでしょう。

図2: HDFS ビルディングブロック

構造化されたものもされていないものもためる

もう一つの「ETLオフロード」です。そもそもETL自体ピンときていない方のために軽く解説からしますと、ETLとはExtract(抽出)Transform(変換・加工)Load(データのロード)です。既存でDWH(データウェアハウス)をご利用されているお客様にはおなじみでしょう。「データ」というはそのままでは活用する事はできないことがほとんどで、必要な部分だけ抜き出したり、アプリケーションや分析ツールにわかりやすいように加工したり変換したり、ノイズ(不要な部分、またはそう定義したもの)が混じっていたら除いたりしてから利用します。これまでは、これらの処理を含めてDWHが役割を担っていました。考えていただければわかりますが、活用対象からはずれるデータもそこにかなり溜まっていることになるわけです。DWHにデータ(不要なものも含め)がたまり圧迫されるようになれば、次々に買い足すというような事となり、かなり高額となり且つもったいない状況であることがおわかりになるでしょう。DWHにはもっとインテリジェントな役割のみに注力してもらい、データためて、ふるいにかける部分は外出ししてしまいましょう、というのが「ETLオフロード」です。これを本ソリューションが担うことで、全体的にコストを抑えることにも且つ効率のよいデータ活用、アナリティクスフローとでもいいましょうか、そのような素敵な基盤ができあがることでしょう。

図2: HDFS ビルディングブロック

終わりに

前回と今回で2回に渡り新しいネットアップのビッグデータソリューションをご紹介しましたがいかがでしたでしょうか。正直、ありそうでなかったソリューションの形ではないかとおもいます。エンタープライズグレードを求めるのであれば、本ソリューションは最適ではないかと自負しております。

最後に気になるコストのところかとおもいますが、本ソリューションは金額面でも新しい試みで提供しています。一般的にサーバのみで構成されるHadoopクラスタと比べても引けを取らないレベルでのご提供となっています。詳しくは弊社担当営業までお問い合わせください。

皆様の今そこにあるデータが活かされ、新たな活躍場が広がる事を期待しています。

参考

NetApp Eシリーズ製品比較

http://www.netapp.com/jp/products/storage-systems/e5400/e5400-product-comparison.aspx

MapRを選ぶ理由

http://jp.mapr.com/why-hadoop/why-mapr/architecture-matters

MapRアーキテクチャ概要

http://www.slideshare.net/MapR_Japan/map-r-architecture20131112ja


倉持健史(くらもちたけし)

倉持健史(くらもちたけし)
システム技術本部 システムズエンジニア
NetApp




東京電機大学情報科学科卒、UNIX 系 SIer、Linux HA クラスタソフトウェアメーカを経て 2011 年 9 月パートナー SE として入社
Soution SE 社内外の技術支援を中心に活動、clustered Data ONTAP はもとより、BigData関連他、Flash技術、
IaaS Platform(OpenStack)等担当
1978 年 8 月 22 日 東京生まれ
基本はインドアだが登山も好き、TEKKEN はポールでゴリ押し
関連情報
関連情報
【進化を遂げたNetApp ビッグデータソリューション for MapR】
関連情報
Go further, faster TRUSTe
お問い合わせ   |   購入方法   |   フィードバック   |   採用情報  |   登録   |   プライバシーポリシー   |   © 2014 NetApp