Kafkaに至る「ストリーム処理」の系譜と“クラウド時代の潮流”をたどる:ストリーム処理を基礎から理解する【後編】
センサーやアプリケーションから届く大量のデータをすぐに処理して活用したい――。それに応えるのが「ストリーム処理」だ。ストリーム処理の歴史を踏まえ、現状はどのような実装方法があるのかを解説する。
センサーやアプリケーションなどから継続的に送られてくるデータを、リアルタイムで処理、分析するのが「ストリーム処理」だ。例えば気象観測や金融取引、製造現場の監視など、特に即時の判断がものを言う分野で活用されている。このストリーム処理の発想自体は新しいものではない。
ストリーム処理の歴史
コンピュータの黎明(れいめい)期から、複数のセンサーから得られるデータをリアルタイムに処理・分析するための仕組みが模索されてきた。初期にはこのアプローチは「センサーフュージョン」と呼ばれており、異なる種類のセンサーデータを統合して意味のある情報を導き出すことが目的とされていた。
2000年代初頭、スタンフォード大学のデイビッド・ラックハム教授が、「CEP」(Complex Event Processing:複合イベント処理)という概念を提唱した。CEPは、複数のデータストリームをリアルタイムで相関させ、そこから有意なパターンやイベントを抽出する手法だ。イベントの発生タイミングを抽象化して扱う技術、イベントの階層管理、因果関係の把握などを基盤とするその考え方は「SOA」(Service-Oriented Architecture:サービス指向アーキテクチャ)や「ESB」(Enterprise Service Bus:エンタープライズサービスバス)といった企業向けアーキテクチャの発展にも大きく貢献した。
その後、クラウドサービスとオープンソース技術の進展により、分散メッセージング基盤「Apache Kafka」などを活用したPub/Sub(パブリッシュ/サブスクライブ)モデルによるイベントデータの処理が、従来よりも低コストで実現可能になった。この流れの中で、複雑なイベント処理をよりシンプルに扱えるストリーム処理フレームワークが続々と登場。CEPの枠組みを発展させた「ESP」(Event Stream Processing:イベントストリーム処理)や「DSP」(Data Stream Processing:データストリーム処理)といった概念も確立された。
現在では、クラウドネイティブなアプリケーション開発が主流となり、SOAやESB、CEPといった用語は次第に使われなくなってきている。その代わりに、マイクロサービスアーキテクチャやPub/Subサービス、そしてストリーム処理を中核としたシンプルでスケーラブルなインフラが台頭しており、リアルタイムデータ活用の主流技術として定着しつつある。
「ストリーム処理」を実現するツールとフレームワーク
併せて読みたいお薦め記事
連載:ストリーム処理を基礎から理解する
ストリーム処理の潮流
ストリーム処理の基本概念は数十年前から存在していたが、オープンソースのツールやクラウドサービス、メッセージング基盤の進化により、現在ではより簡単に実装できるようになっている。代表的なツールやフレームワークには、以下のようなものがある。
- Apache Spark Streaming
- 「Apache Spark Streaming」はストリーム処理とバッチ処理の両方に対応するフレームワークだ。Apache Kafkaや「Apache Flume」「Amazon Kinesis」などの複数のストリーミングデータのソースと連携してリアルタイムデータを処理できる。
- Apache Kafka
- Apache Kafkaは、複数のアプリケーション間でのデータ統合を簡素化する分散イベントストリーミングプラットフォーム。
- Apache Flink
- 「Apache Flink」は、リアルタイムかつ大規模なデータストリームを処理するための分散処理エンジンおよびフレームワーク。
- Apache Samza
- 「Apache Samza」は、複数のソースからの大量のリアルタイムデータを処理できる分散型ストリーム処理フレームワーク。データの状態(ステート)を保持しながら処理するステートフルアプリケーションの構築が可能。
- Apache Storm
- 「Apache Storm」は、無制限のストリームデータを処理するための分散型リアルタイム計算システム。オンライン機械学習や「ETL」(データの抽出、変換、ロード)処理に適する。
主要クラウドサービスベンダーも、ストリーム処理を簡素化するネイティブサービスを提供している。例えば、Amazon Kinesis、「Azure Stream Analytics」「Google Cloud Dataflow」などがある。
これらのフレームワークは、アプリケーションとデータストアを接続するパブリッシュ/サブスクライブサービスと組み合わせて用いられることが多い。
ストリーム処理のアーキテクチャ
ストリーム処理のアーキテクチャは、データの取り込み、処理、公開といった一連のデータ管理作業を安全かつ確実に実行するための基盤であり、これらの作業を簡素化する役割を担っている。用途や要件に応じて複数のアーキテクチャが存在し、それぞれ異なる手法でリアルタイムデータを処理する。
代表的なアーキテクチャには以下のようなものがある。
Lambdaアーキテクチャ
Lambdaアーキテクチャは、リアルタイムでのストリーム処理と、過去データを対象としたバッチ処理を組み合わせたハイブリッド型の構成だ。ストリーム処理は高速なデータアクセスや即時的なインサイトを提供し、バッチ処理は大量の履歴データに基づく集計や分析に適している。特にビッグデータ処理に向いたアーキテクチャとして知られる。
Lambdaアーキテクチャの主な構成要素は、データソース、バッチ層、スピード層、サービング層の4つ。バッチ層は不変(イミュータブル)かつ追記専用形式でマスターデータを保持し、処理の正確性と再現性を担保する。新たに到着するデータはまずキューに格納され、サービング層によってインデックス化される。スピード層はストリーム処理を通じて、データをリアルタイムにインデックス化し、ユーザーのクエリに即座に応答できるようにする。
Kappaアーキテクチャ
Kappaアーキテクチャは、主にメッセージングエンジン、ストリーム処理エンジン、分析用データベースで構成される。例えば、分散メッセージング基盤のApache Kafkaがデータの連続的な流れを受信し、それをストリーム処理エンジンがリアルタイムで分析可能な形式に変換。変換後のデータは分析用データベースに送られ、ユーザーはこのデータベースに対してクエリを実行して情報を取得する。
Kappaアーキテクチャの特徴は、ストリーム処理のみでバッチ処理を代替する点にある。全てのデータ処理がストリームベースで実行されるため、構成がシンプルになり、Lambdaアーキテクチャに比べて運用負荷も軽減される。リアルタイム分析に加え、過去のデータ分析にも対応可能で、1つの技術スタックで多様な分析要件に対応できる点が強みだ。
Copyright © ITmedia, Inc. All Rights Reserved.