ストリーム処理とは？ データのストリーミング処理を解説

ストリーム処理とは、イベントのついての情報を移動中に取得し、その場で処理する低遅延な方法です。情報は、その種類に関係なくほとんどがデータストリーム(イベントストリーム)で構成されています。ソーシャルメディアやWebトラフィックのクリックストリームデータ、工場の生産データなどの製造関連データ、株式市場や金融取引の詳細、病院の患者データ、機械学習システムのデータ、モノのインターネット(IoT)デバイスの状態などのIoT関連データは、企業に常にストリーミングされている情報の一部です。

アーキテクチャを見てみると、ストリーム処理では、データソース(プロデューサー)とそのデータのユーザー(コンシューマー)の間にデータ処理ソフトウェアを配置するフレームワークが採用されています。IT担当者はこのストリーム処理フレームワークを利用して、特定の目的を果たす新しいストリーミングアプリケーションの設計において、どのイベントストリームやデータフィードが重要で、そのデータをどのように活用するかを判断することができます。

ストリーム処理が最も役立つのは、データが絶えず生み出され、時間とともに変化し続ける中で分析を行わなければならないケースです。ストリーム処理は、データストリームに異常や外れ値がないかを監視し、何かがうまくいっていない場合にIT管理者にアラートを上げるためによく用いられます。たとえば、モノのインターネットでは、何百という工業用送風機のセンサーがその温度と回転速度をログデータベースに絶えず送信していることでしょう。ストリーム処理システムでは、送信中のこのストリーミングデータをデータベースへの格納前に取得できるため、送風機のいずれかに障害が発生し始めた場合は即座に管理者に警告できます。

Intel社では、ストリーム処理と機械学習ツールにより、セキュリティ運用やシステム健全性といった新しい領域にもビジネス価値を提供しています。

ストリーム処理が移動中の新しいデータをリアルタイムで分析するのに対し、バッチ処理は静的な情報を一定間隔で分析します。

バッチ処理では、過去に生成されてファイル内(SQLデータベースなど)に保持されたデータの精査、変換が行われ、レポートが作成されます。実行のタイミングは、アナリストが操作を行った時点です。処理される情報は、データ分析中にアクティブに変化または移動することがないため、一般に保存状態のデータ(data at rest)と呼ばれます。

一方、ストリーム処理では、移動中のデータ(data in motion)がリアルタイムで分析されます。静的なファイルに保存されているのとは対照的に、無限に流れるデータが、生成され次第その場で処理されるのです。その即時性のため、ストリーム処理はデバイスやサービスのその瞬間の状態をすばやく伝えます。

例として、工場の生産ラインやシステムを監視している多数のセンサーから生成されるログファイルにより定期的に更新されるデータベースを考えてみましょう。バッチ処理システムの場合は、データベースが頻繁にポーリングされ、センサーの総体的な状況や問題を示唆する可能性のある異常についてのレポートが一定間隔で作成されることでしょう。工場の運用アナリストや管理者にとって、その情報はレポートのタイムスタンプ時点のものであり、データベースが最後に更新された時点のものでしかありません。レポートの作成間隔が1時間であれば、レポートを手にしたときにはすでにデータが古く、使えないものである可能性もあります。

ストリーム処理システムではデータは移動中に取得、処理されるため、現場の担当者は工場の状況をリアルタイムで確認できます。機械に障害が発生したことを1時間経ってから知るのではなく、情報が即座に提供されるため、プロアクティブな対応が可能になります。

また、ストリーム処理はデータベース内に保存されているデータに依存しないため、ストレージを用意しなくても実装できます。ストリーム処理では、レイテンシーを低く抑えるために、データストリーム内の最も関連性の高い情報のみを選択して永続的に保存し、差しあたり関連性の低いデータは将来のサーチやセキュリティイベント、監査のために保存する方法がとられます。

ステートフルストリーム処理で扱うのは、(データの「ステート(状態)」で表される)過去のデータが新しいデータや将来のデータに影響するタイプの情報です。Webユーザーのセッションのロギングでは、ユーザーが開いた各リンクは前のリンク(ユーザーをそのページに導いたリンク)に依存します。ユーザーのデータフロー全体のストリーミング分析を行うには、ユーザーのセッション全体の状態を最初から最後まで考慮する必要があります。たとえば、クレジットカードトランザクションでは、通常、データストリームはステートフルです。トランザクションが完了し、不正検出機能によってトランザクションが正規であると証明されるまで、購入についての詳細な情報がメモリー内に保持されなくてはならないからです。

ステート情報は複数のストリームや分散したストリームにわたって同時に管理する必要があるため、ステートフルストリーム処理は著しく複雑になります。アクセスの多いWebサイトのユーザーをストリームプロセッサで監視している場合は、データ処理システムは一度に数千ものユーザーセッションのステートを監視しなければならないでしょう。そうなると、ネットワーク監視システムに必要なリソースが大幅に増え、ネットワーク監視のアルゴリズムの要件が増えたり、複雑になったりします。ステートフルストリーム処理アプリケーションがクラッシュした場合でも、ステート情報が失われないようなしくみを設計しておくことなどが必須となります。

前のセクションで説明したようにステートフルストリーム処理がデータ全体の状態(ステート)を考慮するのに対し、ステートレスストリーム処理ではステートを考慮しません。

ステートフルストリーム処理環境では、過去のイベントに関する情報が現在のイベントの分析の一環として使用されます。たとえば、産業機械の計測温度は、集計し、経時的に検証して、何らかの傾向が生じた場合に特定できるようにすることで有用度が増します。

一方、ステートレスストリーム処理では、データはそのまま分析され、ステート(前の情報)は考慮されません。周辺温度をリアルタイムに把握したいだけで、温度の変化について考えなくてよい場合は、ステートレスなストリーム処理システムで十分です。しかし、温度の経時的な変化に基づいて将来の温度を予測するには、ステートフルなストリーム処理システムが必要になります。

ステートフルストリーム処理は、コーディング、運用、拡張のいずれにおいてもはるかに複雑です。管理対象のストリームが増え、一つひとつのストリームが生成するデータ量が増すにつれて、ステートフルストリーム処理システムは複雑になり、より多くのリソースを必要とするようになります。しかし、ステートフルストリーム処理はステートレスストリーム処理よりもはるかに有用なインサイトをもたらすため、昨今では圧倒的に多く採用されるようになっています。

ストリーム処理フレームワークとは、ストリーミング入力を受信して処理するデータフローパイプラインを提供し、有用な分析をリアルタイムで実行する、エンドツーエンドの処理システムです。どのフレームワークも、ストリーム処理ソフトウェアや、データストリーミングに対応したイベントストリーム処理ソフトウェア(後述)の開発を容易にするように設計されています。ストリーム処理フレームワークを導入すれば、開発者は既存のツールライブラリから関数をすばやくインクルードでき、ゼロからストリーム処理システム全体を開発せずに済みます。

組織固有の環境やユースケースに応じて使用できるさまざまなフレームワークがあり、そのうちのいくつかの市販フレームワークとオープンソースフレームワークは、実際に企業に導入されています。特殊用途向けのさまざまなストリーム処理フレームワークも開発されていますが、傾向としては、汎用的なストリーム処理フレームワークが強い支持を集めています。

ストリーム処理フレームワークの役割は、採用しているストリーム処理エンジンにかかわらず、データのパイプラインを入力として受け取り、そのデータを処理して、結果を出力キュー(一般にシンクと呼ばれます)に送ることです。また、ストリーム処理フレームワークには、データのやり取り方法や分割方法、データの状態の管理方法、エラーの管理と制御方法などを定めた独自のプログラミングモデル(処理システム)も含まれています。

ストリーム処理フレームワークが分析の基盤となるのに対し、ストリーム処理ソフトウェア(ストリーム処理アプリケーション)は、フレームワークの上に構築され、実際の分析を実行します。ストリーム処理フレームワークを利用すると、さまざまなストリーミングアプリケーションをコーディングする手間や時間を省けます。

ストリーム処理ソフトウェアの一般的なユースケースには、次のようなものがあります。

• データの収集(複数のクラウドの統合、ストリーム形式およびメッセージ形式のビジネスデータなど)
• 組織全体での配信(データの分散やデータドリフトの監視と検出など)
• ストリーム内の異常の検出
• ストリーム内での集約
• ストリーム内での加工やルールに基づく検出
• データコンプライアンス
• 金銭目的の不正行為の検出：犯罪行為のリアルタイムでの特定
• システムの監視：サーバーハードウェア、ネットワーク、アプリケーション、産業機器のリアルタイムでの分析と予測的メンテナンスの実現
• アルゴリズムによる高速な証券取引
• サプライチェーンの監視と管理
• ネットワーク侵入検知
• マーケティング、広告キャンペーンの分析：顧客の行動をリアルタイムで追跡
• 車両通行の監視と軽減

ビッグデータ環境でのストリーム処理は基本的には他の環境と同じように機能しますが、ビッグデータのストリーム処理には他にはないメリットがあります。たとえば、ストリーム処理ではデータストア全体にアクセスせずにデータ分析を実行できます。ビッグデータの場合、当然ながら、非構造化データが格納された膨大な数のデータベースを扱うことになるため、巨大なデータストアをバッチ処理すると極めて低速になることが少なくありません。ストリーム処理を利用すれば、この問題を回避し、通常はわずか数ミリ秒でビッグデータからインサイトをリアルタイムで生成できます。また、この種のデータは常に変化しているため、バッチ処理では、ビッグデータストアの状態が完全であることは決してありません。バッチ処理が開始された直後から、ベースのデータが変化し続けるため、どのようなバッチレポートも完了した時点ですでに古いものになっています。ストリーム処理は、こうした状況をはじめ、複雑なイベント処理の問題をスマートに解決します。

バッチ処理がビッグデータ環境で有用なケースもあります。たとえば、長期的な視点に立った、詳しいインサイトが必要な場合などです。そうしたインサイトは、データストア全体を包括的に分析することによってのみ得られます。ただし、タイムリーな分析を迅速に実行する必要がある場合は、ストリーム処理の方が適しています。

Pulsarは、パブリッシュ-サブスクライブ型の分散メッセージングシステムです。Pulsarには、パブリッシュやエンドツーエンドのレイテンシーが非常に低い、メッセージの配信が保証される、データロスがゼロ、階層化ストレージを使ってデータを永続的に保存できるといった特徴があります。

Pulsarは、Yahooファイナンス、Yahooメール、Flickrといった重要なアプリケーションのメッセージングプラットフォームとして、2013年にYahooで開発されました。2016年にApache Foundationに追加されると、またたく間にトップレベルのプロジェクトとなり、その活発なコミュニティーへの参加者は増え続けています。

Kafkaなどの従来のメッセージングシステムは、データの処理とデータの保存を同じノードで行うアプローチをとってきました。このモノリシックな設計は、ローカルディスクからデータを取得できるため、パフォーマンス面で一定のメリットがありますが、拡張性や復元性の点ではデメリットとなっています。

Pulsar Functionsの基盤となっているプログラミングモデルは非常に単純です。Pulsar Functionsは、1つ以上の入力トピックからメッセージを受け取ります。メッセージがトピックにパブリッシュされるたびに、関数コードが実行されます。トリガーされた関数コードは、受信メッセージに対して処理ロジックを実行し、出力内容を出力トピックに書き込みます。あるPulsar Functionの出力トピックを別のPulsar Functionの入力トピックにすることができるため、Pulsar Functionsの有向非巡回グラフ(DAG)を効率的に作成できます。

Pulsar Functionsは、1つ以上のPulsarトピックからメッセージをコンシュームし、ユーザーが記述した関数(処理ロジック)を各受信メッセージに適用して、結果を1つ以上のPulsarトピックにパブリッシュする、軽量なコンピューティングプロセスです。

Pulsar Functionsの基盤となっているプログラミングモデルは非常に単純です。Pulsar Functionsは、1つ以上の入力トピックからメッセージを受け取ります。メッセージがトピックにパブリッシュされるたびに、関数コードが実行されます。トリガーされた関数コードは、受信メッセージに対して処理ロジックを実行し、出力内容を出力トピックに書き込みます。あるPulsar Functionの出力トピックを別のPulsar Functionの入力トピックにすることができるため、Pulsar Functionsの有向非巡回グラフ(DAG)を効率的に作成できます。

ストリーム処理は、通常、利用できるストリーム処理フレームワークを検討することから始まります。検討にあたっては、組織固有の環境への適合性や、さまざまなユースケースにどれだけ対応できるかに重点を置くことをおすすめします。フレームワークにはオープンソースと市販のものがありますが、自社でどの程度のサポートが必要かに基づいて検討する必要があるでしょう。

評価に際して確認しておきたい代表的なポイントを以下に挙げます。

• バッチ処理とストリーム処理の両方の機能を備えたデータ処理フレームワークが必要か。
• 検討中のフレームワークは、社員がすでに習得しているプログラミング言語をサポートしているか。
• フレームワーク全体を容易に拡張できるか、組織の拡大に合わせてクラスタリングできるか。
• ステートフルストリーム処理がサポートされているか、またステート管理の実装方法は拡張性に優れているか。
• どのようなフォールトトレランスアプローチが採用されているか、障害やクラッシュの際の復旧能力はどうか。
• 開発プラットフォームとして使いやすいか。フレームワークで使用するコードを開発者がすばやく習得して積極的に記述できるか。
• データソースを問わないシステムか。対応しているクラウドサービスプロバイダーはあるか。
• 使用できるシステム監視ツールとネットワーク監視ツールはどれか。
• メンテナンスや開発が頻繁に行われているか。バグは速やかに修正されるか。

ストリーム処理は、データベースなどのデータストアに直接クエリーを実行せずに情報を分析できる、これまでにない新しい方法をもたらします。この新たな方法は、過去のデータを分析する古い方法から脱して、ストリーミングアプリケーションで分析をリアルタイムで実行するといった、データ分析のパワフルな可能性を拓きます。ストリーム処理は、その性質上、ほぼ瞬時に実行できるため、大規模データベースに対して実行したレポートの結果を長々と待つ必要はなくなります。

つまり、データストリームの規模が大きく複雑であるほど、ストリーム処理からメリットを得られる可能性は高くなります。とは言え、ストリーム処理システムは、工場のセンサーからのデータやクレジットカードトランザクションのフロー、その他ありとあらゆるストリーミングデータについて、リアルタイムで分析する必要があるどのような企業にもメリットをもたらします。