HadoopTimes

ストリーミングアーキテクチャ Apache Kafka とMapR Streams による新しい設計手法
最新動向

独自の分散ファイルシステムを核に“全方位”のデータ活用基盤を創る

企業が扱うデータの量も種類も爆発的に増える中で、さらにリアルタイム処理へのニーズも高まりを見せている。真のビジネス価値に昇華させるには、どのようなデータ活用基盤が求められるのか。この領域にフォーカスし、機能に磨きを掛けてきたプレーヤーの1社が米マップアール・テクノロジーズ(MapR Technologies)。日本法人でソリューションエンジニアを務める板垣輝広氏にマーケットの動向と戦略を伺った。

──企業におけるデータ活用は従前からの大きなテーマですが、とりわけ昨今の状況をどうとらえていますか?

かつてのデータ活用といえば基幹業務システムでとらえる売上実績など、いわゆるビジネスデータの活用が中心で、データウェアハウス(DHW)に代表されるようなRDB由来のテクノロジで大方のところは対処できていました。ところが企業がハンドリングできるデータの種類や量が様変わりして、いよいよもって活用レベルを抜本から上げなければならない時代が幕開けた。ここで活用基盤にも新機軸を求める動きが顕著になってきたととらえています。

もちろん、ある期間にどれだけの売上があったかという“過去”のデータを見ることも大事ですが、この瞬間に市場はどう動きがあるのか、顧客一人ひとりがどういう行動をしているのか……。カスタマー360という言葉が象徴するように全方位で“今”や“近未来”を捉える必要が出てきたのです。WebのアクセスログとかSNSでの口コミ情報とか、使えるものはとにかく使ってみようと、あの手この手が繰り広げられているのは多くが知るところ。静観していては競合がどんどん先に行ってしまいます。ビッグデータで言われる「Volume」や「Variety」が本当の意味でリアルになってきたとも言えるでしょう。

Hadoopの基本はバッチ処理

──データ活用基盤に対する要望も自ずと変わってきます。Apache HadoopはじめOSSコミュニティで開発される成果物への関心も一気に高まりました。

こうした変革期に注目を集めるようになった考え方として「データレイク」があります。まさにデータの湖。いくつもの川から様々なタイプのデータが流れ込んできて、一個所に膨大な量が漏れなく蓄えられる。必要に応じて、そこからデータを抽出して活用しようとのアプローチです。

写真1:マップアール・テクノロジーズの日本法人でソリューションエンジニアを務める板垣輝広氏

写真1:マップアール・テクノロジーズの日本法人でソリューションエンジニアを務める板垣輝広氏

データレイクを実装する急先鋒となったのが皆さんご存じのHadoop。もっとも、Hadoopって、基本はバッチ処理なんです。DWH時代にあったような、夜のうちにバッチでETL処理をして翌朝までにデータマートを更新するような使われ方が中心でした。データ量の増大に柔軟に応えるスケールアウト型のHadoopに置き換わったところでバッチはバッチ。アウトプットを活かすまでに、相応の時間がかかってしまう。ビッグデータの黎明期にはこれでもよかったんですが、さらにIoTなどが本格化するにつれて限界も見えてきました。

ビッグデータの3つめのキーワードとして「Velocity」が挙げられますが、これに関して残念ながらHadoopはミートしきれなかった。そこで出てきたのがApache Sparkです。蓄えられたデータを同じクラスタ上で分散並行処理するのはHadoopのMapReduceと同じですが、大きく異なる点は、いちいちディスクに書くんじゃなくてメモリーを巧く使って処理の融通性や高速性を担保しようという発想です。さらに、IoTの本格化に呼応するようにインプットの部分をどうにかしようということで、ストリーミング処理、別の言い方をすればメッセージング処理を司るものとしてKafkaが出てきたのも時代の必然ですね。

新しいテクノロジスタックが次々と登場したことによってリアルタイム処理がぐっと身近になりつつも、かつてから慣れ親しんだバッチ処理のニーズが無くなるわけではなかった。企業は、とりわけビッグデータ活用に邁進する先駆的な企業は、また別の問題に直面することになりました。用途別のクラスターシステムを構築した結果、データレイクが混在するというのはその典型で、それらをまたがったクロス分析のためにテラバイト級のデータをネットワーク転送しようとしたら時間がかかってにっちもさっちもいかない。何のためにデータをまとめたんだっけ? という大元の議論に戻って頭を抱えるなんてことに繋がってしまいました。

すべての起点は柔軟で強固なファイルシステム

──そうした問題に切り込んできたのがマップアールという位置付けでしょうか。

おっしゃる通りです。どんな発想に立ったかというと、データを蓄積しているところ、つまり分散ファイルシステムの上に、テーブル、SQL、メッセージングなどビッグデータやIoTの時代におよそ必要となる機能を実装すればいいんじゃないかというものです。

当社が2009年に創業した際、エンタープライズ用途に耐えられるHadoopを標榜して、ランダムリードライトができるスケーラブルな独自のファイルシステムを完成させました。最初からどれだけ時代を見通していたかはさておき、このアーキテクチャが後々に様々な応用を利かせることにつながったのです。検索速度を上げたいとの想いでテーブルでの処理ができるようにNoSQLの機能を追加しましたし、“入り”のリアルタイム性を追求するためにメッセージキューの仕組みも機能として載せました。でもファイルシステムの仕組みはまったく変わっていないんです。

そのファイルシステムの特徴として「オールデータ、ワンプラットフォーム、エニークラウド」も挙げられますね。要はマップアールはどこで動かして頂いても構いませんとのメッセージです。技術的には、当社のファイルシステムはグローバルネームスペースになっていて、クラスターが複数あってもファイルシステムとしては1個に見せることができる。Azureの上だろうがAmazonの上だろうがオンプレにあろうが、それがマップアールファイルシステム上にあってネットワークさえつながっていれば、全部見えるんです。

このように、ベースとして柔軟で強固でありデータの信頼性を担保するファイルシステムをいち早く完成させたからこそユニークなソリューションに育ったと言えるでしょうか。要件の厳しい顧客に鍛えられながら、マーケットの変化に応じて機能強化を続けられてきたのは、当社にとってとてもラッキーなことです。

基本的に、器の大きさとしての制限はなくパフォーマンスボトルネックもありません。データ量あたりの単価を安くできるソフトウェアデファインドの仕組みを貫いており、しかもバイナリとしては1つです。顧客からすれば、必要な機能を選んでイネーブルにするだけで使える。ここに当社としてのこだわりがあり、だからこそ「コンバージドデータプラットフォーム」と言っているわけです(図1)。

図1:マップアール・テクノロジーズが次代のデータ活用基盤として訴求する「コンバージドデータプラットフォーム」の概要(出典:マップアール・テクノロジーズ)

図1:マップアール・テクノロジーズが次代のデータ活用基盤として訴求する「コンバージドデータプラットフォーム」の概要(出典:マップアール・テクノロジーズ)

マップアールと聞いて、Hadoopベンダーを想起する方もいらっしゃるかもしれません。確かに当社がライセンス収入を得た最初はHadoop製品でしたが、前述のように独自のファイルシステムを軸に周辺にどんどん機能を拡げていき、バージョン「4.1」をリリースしたタイミングで、コンバージドデータプラットフォームを謳うと同時にロゴからゾウ(Hadoopの象徴的シンボル)を外すに至ったのです。もはやHadoopベンダーではないと宣言したわけであり、大きな分岐点でもありました。

APIエコノミーでユーザー価値を究める

──各種のOSSコミュニティとの交流も活発です。その狙いや想いとは?

世の中に優れたテクノロジがあれば、競合となるものをわざわざ自社開発するようなことはせずにAPIを基軸にオープンスタンダードやデファクトスタンダードとうまく連携させるのが当社のポリシー。ファイルシステム周りを中心にコアな部分こそがっつりと独自開発していますが、それ以外はOSSの成果物などを積極的に使っています。変化が激しく複雑さも増ししているこの世の中、すべて自分達で完結できるものではなく、ロックオンの発想は顧客にとって百害あって一利無しですから。

例えばSparkを採用し、その中でSpark SQLだけでは足りない機能があればDrillとの連携をコミュニティと一緒にやっていく。そうした活動の繰り返しです。SPSSやSASなどと連携したいというニーズもあるでしょう。その場合は、我々の基盤からデータセットを提供できるように協業などの道筋を拓いていくのです。当社がフォーカスするのは、あくまでプラットフォームのレイヤーです。

最新リリースは「6.1」で、顧客ニーズや市場動向に照らせば、バッチ処理のみならずリアルタイム処理もインタラクティブな処理も含めて、主要な機能はほぼカバーできているようにも思います。耐障害性を保ちつつストレージの効率性を向上するものとして、イレージャコーディング(Erasure Coding)にも対応しました。この先は、データ活用高度化や耐障害性向上に資する機能の強化などに力を注ぐことになりそうですね。例えば、蓄えたデータの可視化、もっと広義にはデータエンジニアリングを支援するようなもので、OSSでいえばZeppelinのようなものを拡充しなければなりません。そのほか、コンテナ技術のDockerとのインテグレーションや、機械学習との融合とかも進みます。

DWHオフローディングなど現実的ステップで日本企業を支援

──日本市場では、どんな業種や業界がターゲットになりますか?

この手のデータ活用基盤に真っ先に食指を伸ばしたのは、ビジネスの主戦場をネット上に置く企業や、膨大なデータをすでに持っている通信系企業だったのですが、2年ほど前から製造や金融、小売など一般のエンタープライズ企業からの問い合わせが目立つようになってきました。

例えば製造業だと、ラインやプロセスの責任者を中心に自分たちがハンドリングしているデータをしっかり活用しているんだけど、隣の部隊にはうまくフィードバックできていないという実状がまだあったりするんですよ。部分的には最適化されていても、横串を刺してみるとまだまだ改善の余地が残されているんですね。ここにメスを入れたいという声が上がっています。

そのためには製造装置などのセンサーデータをもっと活かす施策が必要です。過日も、とある企業さんをお訪ねしたんですが、生産ラインから取得し得るセンサーデータを積算してみたら年間で1900億レコードに達することが分かって、とても驚いていました。うまく蓄積して活用できる環境を整えれば改革のヒントが見つかるはずであり、そこに気づいた企業が今、こぞってアクションを起こし始めています。

当社としては業界や業種を問わず、データ活用に課題を抱えて解決の糸口を探している企業に全方位で応えていきます。ワールドワイドで様々な実績やユースケースを積み上げていますから、それらも大いに参考になるはずです。

実際のプロジェクトでは、“現実解”も意識します。すでに何らかのDHWをお持ちの場合、そのシステムのライフサイクルを考慮しなければなりませんし、社内で培った運用スキルを無下にすることもできません。いきなり全部を変えるのは難しいものです。既存システムを残しつつ、新しい要件に対応するものをマップアール上に用意して徐々にシフトさせていく。つまりはオフローディングによって、理想像にソフトランディングさせていくのです。そのノウハウ提供も含めて、日本企業のお役に立ちたいと思います。


本コンテンツはIT Leadersに掲載された記事を転載しています。

導入事例:株式会社シーエーシー

導入事例:株式会社シーエーシー
株式会社シーエーシー様は、1966 年に国内初の独立系ソフトウェア専門企業として創業し、コンサルティング、アプリケーション開発から運用に至るまで、幅広いサービスを提供しています。

同社が提供する、年金管理パッケージ・サービス「Micmari(みくまり)」では、機密性の高い個人データを管理するプラットフォームとして、信頼性の高い商用ディストリビューションを選ぶ必要があり最終的にMapRソリューションを採用いたしました。

こちらの資料では、株式会社シーエーシー様がどのような経緯でMapRを採用し、MapRを導入後課題をどのように改善したのかをお話いただきました。

ぜひご覧ください。

無料ダウンロードはこちら