Confluent Platform 3.0がKafka Streamsによるリアルタイムデータ処理をサポート

Apache Kafkaメッセージングフレームワークの支援企業であるConfluentが提供するConfluent Platform 3.0メッセージングシステムでは，リアルタイムデータ処理にKafka Streamsをサポートしている。同社は先週，同オープンソースプラットフォームの最新版を一般提供開始すると発表した。Confluent Platformを使用することによって，大容量メッセージ処理にスケールアップ可能なリアルタイム/分散/フォールトトレラントメッセージングキューであるApache Kafkaを使った，スケーラブルなデータプラットフォーム構築が実現する。

Kafka Streamsはリアルタイムなデータ処理のためのライトウェイトなソリューションだ。不正行為やセキュリティの監視，IoT(Internet of Things, モノのインターネット)運用，マシン監視といったユースケースに対して，新たにKafkaを使用したネイティブなストリーム開発環境を提供する。開発者はこのライブラリを使うことで，Kafkaによる分散型のストリーム処理アプリケーションが構築できる。Kafkaがメッセージングとデータ転送を行い，そのデータをKafka Streamsが処理する形式だ。

Kafka Streamsはステートフルとステートレス両方の処理に加えて，フォールトトレラントな分散型データ処理もサポートする。専用のクラスタやメッセージ変換レイヤを用意したり，外部システムに機能を依存する必要はない。Kafka Streamsはメッセージのマイクロバッチとしてではなく，一度にひとつのイベントを処理する。データの到着遅延への対応や，アウトオブオーダデータのウィンドウニングも可能だ。

Confluent Platform 3.0のダウンロードに加えて，“Kafka Streams documentation”や“Quickstart Guide”といった新リリースのドキュメントもチェックアウトできる。

関連するニュースとして，Confuentmは先週，Kafkaクラスタを管理する商用プロダクトとしてConfluent Control Centerを発表した。Confluent Enterprise 3.0の一部として利用可能なConfluent Control Centerは，データエンジニアリングチームによるKafkaの最適化作業を支援するように設計されている。この管理ツールを使うことで，オペレータや運用チームは，トピックスやプロデューサ，コンシューマといったKafkaシステムのさまざまなコンポーネントを監視し，データパイプラインで何が起こっているのかを理解できるようになる。

Control Centerを使うことで，自社のデータ環境をメッセージレベルで調査して，メッセージのデリバリや想定されるボトルネックを理解すると同時に，自らのネイティブなKafka環境におけるエンドツーエンドのメッセージ配信状況を観察することも可能になる。またControl Center UIでは，新たなデータソースをクラスタに接続したり，自分たちのニーズに合うように新たなデータソースコネクタを設定することができる。

Control Centerについて詳しく知りたいのであれば，開催予定のウェビナについて確認しておくとよい。

InfoQは，ConfluentのJoseph Adler氏(プロダクトマネジメントおよびデータサイエンス担当のディレクタ)とMichael Noll氏(プロダクトマネージャ)にインタビューし，一連の製品発表について，それらが開発チームおよび運用チームをどのように支援するのかを聞いた。

InfoQ: 他のストリームデータ処理フレームワークと比較した場合，例えばStormやSpark Streaming，Apache Flinkと比べて，Kafka Streamsの特徴と言えるものは何ですか？

Joseph Adler & Michael Noll: ストリーム処理の開発者にとって，ストリーム処理フレームワークにはさまざまな選択肢がありますが，ほとんどの開発者が，ストリームデータパイプラインとしてKafkaをすでに使用しているのが実情です。Kafka StreamsはApache Kafkaという強固な技術的基盤の上に構築されているので，その拡張性や柔軟性，耐障害性など，多くの特徴を引き継いでいます。Kafka Streamsがストリーム処理の世界への障壁を低くすることで，多くの企業が，自らのビジネスに対するリアルタイム的な見識というメリットを得ることができるようになると，私たちは信じています。さらに，転送中データを暗号化するKafkaのセキュリティモデルを引き継いでいるので，金融などの業界にも適した選択肢です。

SparkやFlinkなどのフレームワークは，組織の中心にあるデータエンジニアリングチームが，ビッグデータやデータウェアハウスといった設備のパワーを活用する手段として利用することが多いため，主に“力仕事” – 何時間も掛かるような複雑な処理を行なうように設計されています。

これに対してKafka Streamsは，レスポンスタイム短縮のために処理速度を重視するような“高速アプリケーション”，あるいは“ストリームアプリケーション”に適しています。求められる出力は購入決定や状況に応じた提案，セキュリティ警告といったものです。このようなシステムの開発には，ビジネス要件の重視が求められます。

Kafka Streamsでは，既存のストリーム処理フレームワークのように，リアルタイム処理のニーズのために別のクラスタを用意したり，運用したりする必要はありません。リアルタイムデータ処理(不正検出やユーザアクティビティ追跡，艦隊の監視など)に従事する人たちの多くは，すでにデータプラットフォームのメッセージングバックボーンとしてKafkaを選択しています。ですから，まったく別のインフラストラクチャや技術を導入して，それを理解し調整し運用するよりも，Kafka Streamsを使ってすべてのデータをKafkaネイティブな環境で処理する方が，はるかに自然な選択です。

InfoQ: FlinkはKafka Streamsと同じように，マイクロバッチを使わずにストリームデータ処理を行なっていますが，それ以外にもFlinkの類似点，あるいは相違点はありますか？

Adler & Noll: Kafka Streamは業界のこれまでの経験を学んでいます。その中には学術的なものも，あるいはApache Samzaなどオープンソースコミュニティのプロジェクトも含まれています。イベント時間と処理時間のセマンティクスを区別するための適切な時間モデルや，遅延到着データやアウトオブオーダデータの適切な処理といった重要な部分の類似は，この事実から説明することができます。こういった機能は，現実的なストリーム処理のユースケースでは必須なのです。

もうひとつの重要な違いは，Kafka Streamsが柔軟性，すなわち処理能力を動的に拡大ないし縮小できる機能を備えていることです。例えばKafka Streamsでは，マシンが１台あれば，そこでストリーム処理アプリケーションを実行してビジネスデータ処理を始めることができます。データ量が拡大して１台のマシンでは不十分になれば，マシンを追加して同じアプリケーションを起動するだけで - 運用中に，ダウンタイムなく - 処理が自動的に分散されます。

InfoQ: Kafka Streamsはウィンドウニングをサポートしていますが，この機能について詳しく説明して頂けますか。リアルタイムデータ処理ではどのようなメリットがあるのでしょう？

Adler & Noll: ウィンドウニングは，連続的なデータストリームを，もっと小さなチャンクに分割する役割をします。最も一般的なウィンドウニングは，例えば５分間隔で分析を実施する，というように，時間をベースにしています。ウィンドウニングは，不正検出(“この女性はこれまで，1時間に1回以上クレジットカードを使用したことがないが，この5分間に15トランザクションが記録されている – クレジットカードを盗難された可能性がある”)，あるいはトレンドニュース(“過去24時間にTwitterユーザが関心を持っているのは，米国大統領選挙，新しいApple MacBook，Justin Bieberの最新ビデオ”)など，多くのユースケースにおいて重要な機能です。

InfoQ: 時間ベースとセッションベースのウィンドウニングオプションはどのように違っていて，それぞれどのような場合に使うべきなのか，説明して頂くことはできますか？

Adler & Noll: 時間ベースのウィンドウニングはデータストリームを，例えば，5分間のデータに分割するものです。ストップウォッチを使うと思ってください。5分ごとに宣言するのです – “データの新しいウィンドウ！”と。ウィンドウニングが必要なユースケースはたくさんありますが，おそらくその大部分は時間をベースとするものでしょう。

これに対して，セッションベースのウィンドウニングは，関連イベントをいわゆるセッションにグループ分けする上で，ストップウォッチのように厳格なルール以上のものを使用します。アクティビティの期間がこれらのセッションだと考えてください。セッションベースのウィンドウニングを必要とする一般的なユースケースは，ユーザのインタラクションイベントを解析して，例えばFinancial Timesを読んでいるユーザ数や，Facebookで対話しているユーザ数を理解するような場合です。

InfoQ: Kafkaフレームワークのセキュリティサポートについて，メッセージやトピックへのアクセス制限，あるいはKafkaサーバ間の転送データの暗号化の面から説明をお願いできますか？

Adler & Noll: 認証機能としてKafkaでは，SASL/Kerberos，SASL/PLAIN，SSL/TLSをサポートしています。またアクセス管理では，トピック毎の参照/更新/管理アクセスをコントロールするACLを提供しています。これはユーザ毎にも，あるいは特定のIPに対しても設定することができます。

転送中のデータはSSL/TLSを使って暗号化されます。データプロデューサからKafkaブローカ(サーバ)，Kafkaブローカからデータコンシューマ，Kafkaクラスタ内で実行されるブローカ間の通信などは，すべて暗号化されています。

InfoQ: KafkaクラスタをDockerコンテナにデプロイすることはできますか？このインテグレーションに関するベストプラクティス，あるいは開発者用のオンラインリソースはあるのでしょうか？

Adler & Noll: DockerコンテナにKafkaクラスタを展開することは可能です。Confluentでは，Apache Kafkaを含むConfluent Platformを実行するための，試験的なDockerイメージを提供しています。これはつまり，DockerベースのKafkaセットアップを運用するユーザはまだ例外的で，一般的ではないということです。その原因のひとつとして，Dockerがまだ相対的に若いテクノロジであるため，十分に枯れていないということがあります。一方で，データアーキテクチャでのKafkaの役割はデータの保存と提供，すなわち“ステートフル”なサーバです。Dockerの哲学とベストプラクティスは，コンテナ内でこのようなステートフルなサービスを実行しない – ステートレスであることが望ましい – というものですから，このようなある意味直交する２つのアプローチをつなぐには，ある種の注意は必要になります。

InfoQ: Kafkaには今後，どのような新機能や拡張が用意されているのでしょうか？

Adler & Noll: 今後のリリースでApache Kafkaコミュニティは，運用の簡素化やデリバリ保証の強化に注力していく計画です。この中にはデータバランシングの改善やセキュリティ強化，Apache KafkaとしてのEOD(exactly-once delivery)サポートといったものも含まれています。Confluent Platformとしては，さらに多くのクライアントやコネクタを用意すると同時に，Confluent Control Centerによる監視機能や監視機能を拡充する予定です。また，Kafka 0.10を含んだKafka Streamsの最初のバージョンがリリースされたので，今後はコミュニティとConfluentが協力して機能を拡張していくつもりです。現在開発中の機能のひとつが，ストリーム処理アプリケーションを実装するためのSQLインターフェースです。これはKafka Streamsのユーザベースを拡張するだけでなく，ストリーム処理の認知度を高めるためにも含めたい機能の一例です。