|
I. リアルタイムストリームコンピューティング インターネットが世界にもたらした最大のインパクトは、その誕生以来、リアルタイムの情報交換を可能にし、あらゆる段階で効率を大幅に向上させたことです。リアルタイムの情報応答とインタラクションに対するこうした需要により、データベース（より正確にはリレーショナルデータベース）は、パーソナルオペレーティングシステムに次ぐ、ソフトウェア業界で最も急速に成長し、最も収益性の高い製品となっています。10年前、多くの銀行はリアルタイムの送金はおろか、リアルタイムの照会さえもできませんでした。しかし、データベースと高速ネットワークが状況を変えたのです。 インターネットのさらなる発展に伴い、ポータルベースの情報閲覧から検索ベースの情報検索、ソーシャルネットワーキングやインタラクションへと進化し、電子商取引、オンライン旅行、ライフスタイル製品がオンラインプロセスを日常生活に持ち込むにつれ、効率性への要求はリアルタイム性への要求を高めています。情報のインタラクションとコミュニケーションは、ポイントツーポイントから情報チェーン、さらには情報ネットワークへと進化しており、必然的に様々な次元にまたがるデータの相互参照が生じ、データ爆発は避けられなくなっています。そのため、リアルタイムフレームワークと大規模データストレージおよび計算の課題に対処するために、ストリーミング処理とNoSQL製品が登場しました。 7、8年前、カリフォルニア大学バークレー校やスタンフォード大学といった大学では、ストリーミングデータ処理の研究が始まっていました。しかし、金融業界やインターネットトラフィック監視といったビジネスシナリオへの重点が置かれていたこと、そして当時のインターネットデータ処理シナリオの限界などから、研究は主に従来のデータベース処理のストリーミングに焦点を当てており、ストリーミングフレームワークそのものの研究は少なかったのです。現在、こうした研究は徐々に衰退し、産業界はリアルタイムデータベースへと焦点を移しつつあります。 2010年にYahoo!がS4を、そして2011年にTwitterがStormをオープンソース化したことで、この状況は一変しました。以前は、リアルタイムアプリケーションを構築するインターネット開発者は、アプリケーションのロジックと計算だけでなく、リアルタイムのデータフロー、インタラクション、そして分散にも重点を置く必要がありました。しかし今では、状況は大きく変わりました。Stormを例に挙げると、開発者は堅牢で使いやすいリアルタイムストリーム処理フレームワークを迅速に構築できます。SQL、NoSQL、あるいはMapReduceコンピューティングプラットフォームと組み合わせることで、これまで想像もできなかった多くのリアルタイム製品を低コストで開発できます。例えば、Taobaoデータ部門のQuantum Hengdaoブランドのいくつかの製品は、リアルタイムストリーム処理プラットフォーム上に構築されています。 このチュートリアルはStormの基本的な入門書ですが、単なるStormのユーザーマニュアルにとどまらない、より幅広い内容となることを願っています。実際のデータ生成プロセスやアプリケーションアーキテクチャに関する私たちの経験をさらに深めていきます。最終的な目標は、リアルタイムストリーム処理フレームワークを活用したいと考えているすべての技術者の方々を支援し、同時に静かに世界を変えていくことです。 II. 嵐の特徴 Stormは、大規模なデータストリームを容易かつ確実に処理できるオープンソースの分散型リアルタイムコンピューティングシステムです。リアルタイム分析、オンライン機械学習、継続的なコンピューティング、分散RPC、ETLなど、多様なユースケースに対応しています。水平スケーリングをサポートし、高い耐障害性を備え、すべてのメッセージが確実に処理されるだけでなく、非常に高速です（小規模なクラスターでは、各ノードで毎秒数百万件のメッセージを処理できます）。Stormは導入と保守が容易で、さらに重要な点として、あらゆるプログラミング言語を使用してアプリケーションを開発できます。 Storm には次の特性があります。
ビッグデータ処理の分野では、Hadoop は間違いなく馴染み深い名前です。Google MapReduce をベースとした Hadoop は、開発者に map と reduce のプリミティブを提供し、並列バッチ処理プログラムを驚くほどシンプルかつエレガントに実現します。同様に、Storm もリアルタイムのビッグデータ計算のためのシンプルでエレガントなプリミティブを多数提供しており、並列リアルタイム処理タスクの開発の複雑さを大幅に軽減し、アプリケーションを迅速かつ効率的に開発するのに役立ちます。
Stormクラスターでは、トポロジを実際に実行する3つの主要なエンティティ、すなわちワーカープロセス、スレッド、タスクが存在します。Stormクラスター内の各マシンは複数のワーカープロセスを実行でき、各ワーカープロセスは複数のスレッドを生成でき、各スレッドは複数のタスクを実行できます。タスクは、実際にデータ処理を実行するエンティティです。私たちが開発するスパウトとボルトは、1つ以上のタスクとして実行されます。 したがって、計算タスクは複数のスレッド、プロセス、サーバー間で並列に実行され、柔軟な水平スケーリングがサポートされます。
Storm は、Spout によって送信されたすべてのメッセージが「完全に処理」されることを保証できます。これは、S4 などの他のリアルタイム システムとの直接的な違いです。 スパウトから送信されたメッセージは、その後数千ものメッセージの生成をトリガーする可能性があることに注意してください。これらのメッセージは、スパウトのメッセージをルートとするメッセージツリーとして視覚化されます。Stormはこのメッセージツリーの処理状況を追跡し、ツリー内のすべてのメッセージが処理された場合にのみ、スパウトのメッセージが「完全に処理された」とみなします。メッセージツリー内のいずれかのメッセージが処理に失敗した、または指定された時間内にメッセージツリー全体が「完全に処理」されなかった場合、スパウトのメッセージは再送信されます。 メモリ消費を最小限に抑えるため、Stormはメッセージツリー内のすべてのメッセージを追跡しません。その代わりに、メッセージツリー全体を処理するための特別な戦略を採用しています。メッセージツリー内のすべてのメッセージの一意のIDに対してXOR演算を実行し、その結果がゼロかどうかで、Spoutから送信されたメッセージが「完全に処理された」かどうかを判断します。これによりメモリ消費量が大幅に削減され、判断ロジックが簡素化されます。このメカニズムについては後ほど詳しく説明します。 このモードでは、送信されるメッセージごとにACK/Failが同期的に送信されるため、ネットワーク帯域幅が多少消費されます。信頼性の要件が高くない場合は、別の送信インターフェースを使用することでこのモードをオフにできます。 前述の通り、Stormは各メッセージが少なくとも1回は処理されることを保証します。しかし、コンピューティングシナリオによっては、各メッセージが1回だけ処理されることが厳密に要求される場合もあります。幸いなことに、Storm 0.7.0ではこの問題を解決するトランザクショントポロジが導入されました。これについては後ほど詳しく説明します。
メッセージ処理中に例外が発生した場合、Storm は問題のある処理ユニットを再スケジュールします。Storm は、処理ユニットが（明示的に強制終了しない限り）無期限に実行されることを保証します。 もちろん、処理ユニットが中間状態を保存している場合、処理ユニットが Storm によって再起動されると、アプリケーションは中間状態の回復を処理する必要があります。
JavaでSpoutとBoltを実装するだけでなく、Stormのいわゆる多言語プロトコルのおかげで、使い慣れたプログラミング言語を使ってこのタスクを実現できます。多言語プロトコルはStorm内の特別なプロトコルで、SpoutやBoltが標準入力と標準出力を使用してメッセージを渡すことを可能にし、単一行テキストまたは複数行のJSONエンコードされたメッセージとして送信します。 Stormの多言語プログラミングサポートは、主にShellBolt、ShellSpout、ShellProcessなどのクラスによって実現されています。これらのクラスは、IBoltおよびISpoutインターフェースに加え、JavaのProcessBuilderクラスを介してシェルがスクリプトやプログラムを実行できるようにするプロトコルを実装しています。 ご覧のとおり、この方法では処理中に各タプルの JSON エンコードとデコードが必要となり、スループットに大きな影響を与えます。
Stormには「ローカルモード」があり、これはStormクラスタのすべての機能をプロセス内でシミュレートします。ローカルモードでのトポロジの実行は、クラスタ上でのトポロジの実行と似ており、開発とテストに非常に役立ちます。
メッセージが迅速に処理されることを保証するために、基盤となるメッセージ キューとして ZeroMQ が使用されます。 |
