データボリュームの増大と組織内のデータベースシステムの急増が、ほぼリアルタイムでデータをストリーミングするアプリケーションに問題を発生させている。LinkedInデータインフラストラクチャチームのCelia Kung氏は、先週のQCon New York 2019 Conferenceで、プラグイン可能なソースとデスティネーションをサポートするマネージドデータストリーミングサービスであるBrooklinについて講演した。さまざまなソースとデスティネーションが、データストアあるいはメッセージングシステムとして使用可能になることで、柔軟性と拡張性を備えたソリューションが実現する。Brooklinは、LinkedInで開発されたストリームインフラストラクチャプラットフォームの一部である。
Brooklinは、複数のストリーミングソースからさまざまなデスティネーションにデータをストリーミングすることの可能な、Javaベースのマルチテナントデータ取得サービスである。メッセージングシステム(Kafka、EventHubs)、データベース(Oracle、MySQL)、あるいは他のデータストア(NFSなど)からデータをストリーミングし、Kafka、イベントハブ、HDFSなどのデスティネーションに公開することができる。ストリームは個別に設定し、動的にプロビジョンすることが可能だ。Brooklinはデータレプリケーション時に、ソースデータベースに対して"select * from table"のようなクエリを実行せず、MySQLデータベースのbinlogのようなソースデータベースログを使用する。セルフサービスのUIポータルがあり、さまざまなデータストリームの構成設定が可能である。メタデータの保存とノードの構成にはApache ZooKeeperを使用する。
このフレームワークの背景にある思想は、システム間のデータ移動を回避して、開発者がアプリケーションのデータ処理ロジックに集中できるようにすることだ。同社では過去3年間、CDC(change data caoture)などさまざまなユースケースを対象に、Brooklinフレームワークを実稼働環境で使用している。Kafkaインスタンス間でデータを複製するKafka MirrorMakerの代替として使用することも可能だ。
代表的なユースケースは、リアルタイムに近い応答を必要とする、ニアライン(nearline)アプリケーションである。Linkedinには、Live Search IndicesやNotificationsなど、このカテゴリに分類されるアプリケーションがいくつかある。
Kung氏は次に、データストリーミングでBrooklinを使用する2つの異なるシナリオについて説明した。最初のシナリオである変更データキャプチャ(change data capture)は、LinkedIn Webサイトでメンバが実施したライブアップデートのキャプチャである。Notifications Service、Search Indices Service、News Feed Serviceなど、複数のサービスが同じデータベースに接続し、同じデータセットを取得してWebサイトに更新を表示する。
続いて氏はストリーミングブリッジについて説明した。ストリーミングブリッジは、基本的にはクラウドサービスやクラスタ、あるいはデータセンタなど、異なる環境間でデータを移動するためのデータパイプである。ストリーミングブリッジを使用することで、例えばAWS上で動作しているKinesisインスタンスから、AzureクラウドプラットフォームにホストされているEvent Hubにデータを転送できる。AvroやJSONなど、さまざまなデータ形式の構成がサポートされている。暗号化または難読化のさまざまなポリシを適用することも可能だ。
氏はさらに、次のようなアプリケーションの使用例についても説明した。
- キャッシュ
- 検索インデックス
- ETLおよびデータウェアハウス
- マテリアライズドビューおよびレプリケーション
- 再分割(Repartitioning)
インスタンス間でKafkaデータをミラーリングする要件のために、LinkedInでは、Kafka MirrorMaker(KMM)をすべてBrooklinにリプレースした。各データセンタに複数あったKMMインスタンスも、データセンタ毎にひとつのBrooklinインスタンスに置き換えている。
LinkedIn Brooklinフレームワークは近い将来オープンソースとして公開される予定で、開発者コミュニティが組織で使用できるようになる、とKung氏は述べている。