膨大なデータを「溜める」「処理する」ため、システム開発の現場ではこれまでHadoopに代表される並列分散処理で切り開いてきました。例えば、Hadoopを利用することで、「6時間かかっていた処理が5分になった」「26日かかっていた処理が20分になった」などという当時ではセンセーショナルな事例を多数見られた方もいらっしゃるかと思います。そういった事例に牽引され、Hadoopはすぐに“大量データの蓄積や膨大な件数のバッチ処理を、現実的な処理時間で実現可能とする、並列分散処理技術のデファクトスタンダード”になりました。企業が並列分散処理技術を扱う際のハードルを下げたHadoop（MapReduce）（※2）でしたが、それでもそのまま使うには高度な知識が必要でした。そのため、開発生産性を高めるためのエコシステムが数多く登場し、次第にMapReduceアプリケーションを直接開発しなくても、多くの人が並列分散処理を扱えるようになっていきました。

しかしながらそもそも、Hadoopは大きなデータの塊単位で処理することを中心としており、データ・レコード1件1件を低レイテンシ（※3）で処理するような用途には向いていないという本質的な課題もありました。この課題を解決するために、データ・レコードを高頻度で挿入し活用するデータ処理に向いたHBaseが登場したり、時々刻々と生じるデータ（ストリームデータ）を処理する分散ストリーム処理基盤として、Apache Storm、Apache Kafkaが登場したりしました。これにより、膨大なストリームデータをリアルタイムに活用することが可能となり、私たちはエンドユーザに対し、データに基づく素早いアクションを取れるようになりました。

図1：様々なOSSの登場

大規模データを扱うためのプロダクトが多数登場したことにより、以下のようなニーズに合わせた処理基盤を構築することができるようになりました。

• 大量データを溜められる、バッチ処理できる
• 高スループット、低レイテンシでレコード単位の入出力ができる
• 大量・多数の細かなデータ（ストリームデータ）を受け止められる
• 前処理済みのデータに対して分析向けアドホッククエリが実行できる

しかし、特定ニーズに応えるために特化した仕組みが多々見受けられるものの、単一技術だけで全てのニーズを満たすことは難しく、実際のシステムは様々なトレードオフ（スケーラビリティ、ACID準拠、低レイテンシ、高スループット、シーケンシャルアクセスとランダムアクセスの両立、低いコスト、など）を考慮しながら、複数の技術を組み合わせることも少なくありません。

図2：様々なトレードオフの例

システム構成が複雑化する中、市場が成熟して期待も大きくなってくるに連れ、「大量で件数の多いデータを書き込み」つつ、「直近データに対してSQLを使い柔軟に分析したい」といった要望が出てくるようになりました。しかも、蓄積のための仕組みはスケーラブルで、膨大な量のデータを抱えても現実的な費用で扱いきれること、というような要件が重なると、前述のようなトレードオフがある、これまでの技術のただの組合せでは実現が難しいチャレンジだと言えます。

図3：バッチ処理とストリーム処理の混在アーキテクチャ

これまでストレージレイヤソフトウェアに求められてきたことは、

• スケーラビリティ…データ蓄積量や処理量に応じてリソースを拡張しやすいこと
• 使い勝手…ユーザが利用しやすいインターフェースであること
• リーズナブル…特殊なHWを使わず、コモディティなHWを並べて実現できること
• 耐障害性…サーバが故障してもデータを失わないこと

といったことですが、昨今はこれらに加え、ストリーム処理の普及や多様な分析要求を意識した「リアルタイム分析」しやすいことが求められてきています。

ユースケースとしては、

• バッチ、ストリームからの入力データを大量に蓄積する
• 蓄積したデータを用いた機械学習を行ってモデルを作成しておく
• 直近のアクティビティ（ストリーム）や過去履歴（バッチ）をもとに、リアルタイムな顧客の傾向を分析・可視化する
• 問合せや対応履歴をもとに有益な情報をエンドユーザにpush通知する

といったすべてを満たすようなものが考えられます。従来のアーキテクチャでは、バッチ処理アーキテクチャだとリアルタイム性が失われ、逆にストリーム処理アーキテクチャだと過去データの扱い・アドホックな分析が困難になってきます。

そこで近年登場してきたのが、Apache Kudu、Apache Hudi、Delta Lakeなどのリアルタイム分析に利用可能なOSSストレージレイヤソフトウェアです。これらのソフトウェアは、Hadoopが苦手としていたリアルタイムなデータを利用した分析処理に対応しており、またHBaseよりも列指向（データを列方向に扱いやすくすること）を前提とする仕組みとなっており、よりデータ分析を意識した仕組みと考えられます。これらのソフトウェアは、前述した各トレードオフのバランスをとる方向で、リアルタイム分析を実現し、市場のニーズに応えています。

図4：ストレージレイヤソフトウェアを用いたバッチ処理とストリーム処理の両立

表1：代表的なOSSストレージレイヤソフトウェア

本稿では、近年出てきた顧客のニーズ「大量のデータを蓄積しつつ、リアルタイムにアドホックな分析を行いたい」という、これまでの技術では実現が難しく、またシステム構成が非常に複雑になってしまうユースケースに対応する、ストレージレイヤソフトウェアを紹介しました。紹介したストレージレイヤソフトウェアを使わない場合でも、バッチ処理とストリーム処理を組み合わせたラムダアーキテクチャ（※4）などによる実現もありますが、「異なるアーキテクチャ上のアプリケーションで同一の動作をさせる難しさ」があります。それに比べると、ストレージレイヤソフトウェアは分析者へのユーザビリティを確保しており、多くの方がデータを活用して利益を享受することができる「データ民主化」を実現するものだと考えます。

ストレージレイヤソフトウェアは、前述したとおりプロダクトによって特徴が異なり、選定をすること、効率的に使うにはまだまだ専門性が必要な状況です。これまで我々が培ってきた、過去Apache Hadoop/Spark/Kafkaなどの大量データ処理の知見や、幅広くOSSを扱ってきた強みを活かし、さらなる調査・研究を続けていきます。本稿で述べたようなニーズをお持ちでしたら、ぜひご相談ください。

著者：福久 琢也、田中 信行、土橋 昌