自動運転車の開発基盤では、なぜMapR（＝HPE Ezmeral Data Fabric）が採用されるのか？

[Masazumi_Koga]

今、自動車会社で最もホットな話題が、自動運転技術です。自動運転技術では、高度なAIが必要とされていますが、そのAIの「脳みそ」を作るには、ビッグデータの活用が鍵を握ります。国内外問わず、自動車会社では、AIの開発基盤にビッグデータ基盤ソフトウェアのMapR（新名称：HPE Ezmeral Data Fabric）が採用されています。なぜ自動車会社は、Ezmeral Data Fabric（MapR）を採用するのでしょうか？海外の自動車会社のMapR基盤では、1時間あたり８テラバイトのデータが収集されて、道路走行のシミュレーションが行われています。さらに、アプリケーションのデータの取り込みなども含めると、1日に約2ペタバイトのデータがEzmeral Data Fabric（MapR）に格納されています。

そのような、ペタバイト級のデータが増えるような基盤では、どのような分析基盤を必要とするのでしょうか？

C/C++で書き直した超高速なMapRファイルシステム

自動車会社のビッグデータ基盤で採用されている理由の１つは、MapRが持つ高速な分散ファイルシステムの提供です。分散ファイルシステムというと、HadoopのHDFS（Hadoop分散ファイルシステム）が有名ですが、HDFSは、Javaで作られています。このHDFSの最大の弱点は、Javaで動くため、非常にスピードが遅いという点です。一方、MapRファイルシステムは、HDFSの弱点を克服しています。なんと、C/C++で書き直しており、非常に高速なファイルシステムを提供しているのです。HadoopもMapRもどちらも分散ファイルシステムを提供しているので、同じでしょ？と思われたかもしれませんが、性能ベンチマークも公開されており、MapRが圧勝しています。

海外の自動車会社のMapRクラスタは、すでにノード数も560台を超え、MapRファイルシステムの容量も260ペタバイトになっています。もしファイルシステムの性能に問題があれば、それを補うために、さらに台数がかさみます。なので、高速な分散ファイルシステムのMapRが採用されているのです。

MapRは、高可用性NFSサーバにもなれる

海外の自動車会社の自動運転開発基盤におけるMapRクラスタでは、ペタバイト級のデータをいかに効率よく利用して、AI開発に活用できるかを常日頃考えています。その一つに、NFSの利用が挙げられます。Hadoopでは、あまり馴染みのないhadoopコマンドを使って分散ファイルシステムへのファイル操作を行うことが多いので、初心者にはとっつきにくいところがあります。一方、MapRは、NFSサーバになれるため、Linuxに慣れている人は、通常のNFSサーバにファイルをcpコマンドでコピーしたり、lsコマンドでファイルを閲覧できるのです。MapRで提供されるNFSサーバの機能は非常によくできていて、高可用性NFSを提供するため、NFSサービスを提供するMapRノードに障害が発生しても、自動的に別のMapRノードがNFSサービスを引き継いでくれます。

MapRは、IoT時代を見据えたデータストリーミングにも既に対応している！

国内外問わずMapRは、高可用性NFSが便利であるため、非常に多くの導入実績を誇りますが、それだけでなく、MapRは、データストリーミングの機能も提供しています。データストリーミングとは、誤解を恐れずに、簡単に言うと、IoT機器などから発生するセンサーデータなど、データサイズは小さいものの、その数が数十憶レベルの膨大な数に上るデータが絶え間なく流れ続けるような、いわゆる「データキューイングの仕組み、あるいは、そのデータの流れ」を指します。キューイングというと、ビリヤードの玉を突くキューやプリンターのデータをためておくキューが思い浮かびます。

キューは、ある機器から、ある機器への「絶え間ない情報の流れ」のようなものです。スーパーコンピュータの世界では、ユーザの並列計算プログラムをキューに入れてジョブという形で投入し、優先順位などを設けて効率よく処理します。また、前世紀の大型のメインフレームなどでも、ある部署から別の部署への情報伝達にキューを使ってデータを流し込むという形でデータ処理が行われていました。

近年は、ビッグデータとIoTの世界でも、キューが利用されており、そのキューを実現するのが、ストリーミングソフトウェアです。「でも、NFSサーバにコピーコマンドを使ってデータをコピーするのと何が違うの？」と思われたかもしれませんが、NFSサーバにコピーするのは、いわゆる、巨大なデータの一括コピーなどのバッチ処理です。NFSサーバへの巨大データのコピーなどのバッチ処理は、時々まとめて一括してコピーする処理なのに対し、ストリーミングは、リアルタイムにどんどん流れてくるサイズが小さいデータを膨大に取り込む処理です。当然、複数個所からデータが発生しますので、複数の発生源からのIoTデータやログデータなどを効率よくビッグデータ基盤に流し込まないといけません。そのようなときに、ストリーミングが利用されるのです。

自動車会社では、膨大な数の自動車からリアルタイムで発生するデータ基盤を想定しています。自動車1台あたりのデータも膨大になりますが、バッチ処理ではなく、将来の本番環境では、リアルタイムにずっと小さいサイズの膨大なデータが流れ続けるということを想定しているのです。だから、NFSでのバッチ処理以外に、ストリーミング処理が必要になることが想定されるのです。HPE Ezmeral Data Fabric（MapR）では、MapR Streamsとしてストリーミング機能が提供されており、負荷分散を自動で行うなどのエンタープライズレベルの要求答える機能が備わっています。そのため、自動車会社で利用されているMapR基盤では、この高可用性NFSによる業務継続＋利便性と、ストリーミングによる大規模IoTへの対応を見据えて、AI開発のデータ基盤としてMapRが採用されているわけです。

MapRが導入された超大規模IT基盤とAIを駆使して、自動運転車が全世界で広まる時代が到来しようとしています。自動運転だけでなく、ビッグデータ分析とAIの進化によって、人の動きや感情なども察知できる時代に突入してようとしています。MapRは、HPE Ezmeral Data Fabricという名前に変わりましたが、MapRで培った信頼と実績をHPEは引き継ぎます。

HPEは、2020年代に実現されるであろう高度に知能化されたIT社会の屋台骨をEzmeral Data Fabricで実現できると確信しています。

Masazumi Koga (Twitter: @masazumi_koga)