Apache Kafka が生まれた理由
今データを使って何かした方がいいと考えているお客様は多いのではないかと思います。Red Hat の金融セミナーでもこの手のお話があり、マネーソーの登壇者が以下の話をしていました。
義務化されるものがある一方で、オープンバンキングを実装するための様々なアプローチがあるのですが、一貫したテーマが一つあることに気付きました。〜略〜
今や誰もが同じデータへアクセスすることが可能で勘定系システムの中にある貴重なデータに基づいて活動できるのは私だけではありません。ではどうしたら差別化できるでしょうか。〜略〜 その答えとは次のようなものです。
データを使っていますぐ何かした方がよい。〜略〜 データに基づく活動が次の未開拓領域です。
データを活用する上で、非常に役にたつと思った資料があります。それは LinkedIn 社が Apache Kafka をなぜ作ったのかを詳細に説明しているレポートです。今回はこのレポートを詳しくみて行きたいと思います。
ETL を使っていたときの LinkedIn の課題
前提 : アクテビティデータ
Activity data is one of the newer ingredients in internet systems.
アクティビティデータは、インターネットシステムの新しい要素の一つです。
At LinkedIn this kind of data feeds into virtually all parts of our product. We show our users information about who has viewed their profile and searching for them; we train machine learning models against activity data to predict connections, match jobs, and optimize ad display; we show similar profiles, jobs, and companies based on click co-occurance to help aid content discovery; we also populate an activity-driven newsfeed of relevant occurrences in a user’s social network. Likewise, this data helps keep the web site running smoothly: streams of activity data form the basis of many of our security measures to prevent fraud and abuse as well as being the data source for various real-time site monitoring tools.
LinkedInでは、この種のデータは事実上、当社の製品のすべての部分にフィードされます。また、アクティビティデータに対して機械学習モデルをトレーニングして、コネクションの予測、求人のマッチング、広告表示の最適化を行います。また、クリックの共起率に基づいて類似したプロフィール、求人、企業を表示してコンテンツの発見を支援します。同様に、このデータはウェブサイトをスムーズに運営するのに役立ちます。アクティビティデータのストリームは、不正行為や不正使用を防止するための多くのセキュリティ対策の基礎を形成するだけでなく、さまざまなリアルタイムサイト監視ツールのデータソースにもなっています。
以前のシステム
LinkedIn 社は Apache Kafka を開発する前に 2 つのシステムを持っていました。
- ユーザーのアクティビティデータ(XML)を DWH へ格納するバッチ志向のシステム
- サーバーのメトリクスとロギングをハンドルするためのシステム(モニタリングシステムのみに使用)
このシステムには以下のような課題がありました。
- アクティビティデータとメトリクスは ETL によって遅延されて連携される(1時間ごと or 1日ごと)ためにリアルタイムで利用することができなかった。
- ビジネスメトリクス(ページビューの減少、サインアップ率の低下、その他の活動の低下など)とシステムメトリクス(パフォーマンスの低下、運用メトリクスなど)の相関関係をリアルタイムで把握することが困難だった。
- どちらのシステムもポイント・ツー・ポイントでデータのやりとりを行っており送信先は一つのみだったため、データを使いたいという要望があるシステムが多く生まれたがデータを活用できなかった。
- 新しいタイプのユーザーアクティビティを補足しようとしても XML と密結合が枷になってデータの追加が容易ではなく(スキーマの変更)、新しい活動を補足することが全くできなかった。
- クレンジングされたデータが DWH / Hadoop のみに制限されることで、データの利用者がバッチ志向のアプリケーションに制限された。
これらは顧客とのエンゲージメントをシステムで高めようとしている方々は将来的には課題になりえる問題なのではないかと思います。
LinkedIn のレポートの中には以下のような話も記載されています。
The traditional role of the data warehouse is to curate and maintain a cleansed, structured copy of all data. Access to clean, complete data is of the utmost importance to a data-centric company, however having the data warehouse be the sole location of the cleansed and structured data is problematic.
データウェアハウスの伝統的な役割は、すべてのデータのクレンジングされた構造化されたコピーを管理し、維持することです。データ中心の企業にとって、クリーンで完全なデータへのアクセスは最も重要ですが、データウェアハウスがクレンジングされ構造化されたデータの唯一の場所であることは問題です。
既存 MQ システムの利用
LinkedIn はすぐに Apache Kafka の開発をするという選択をしたわけではないようです。Apache Kafka を開発する前に既存の MQ システムで様々な試行をした結果、様々な問題に遭遇し、最終的に Apache Kafka の開発に至りました。
We put in place a simple in-memory relay as a stop-gap solution to support real-time product use-cases and began the development of the first version of Kafka.
Apache Kafka の開発
上記レポートの中では Kafka の特徴がいくつか説明されています。その中でも重要だと思うものをピックアップしてみました。
- Kafka は pub-sub システム
- メッセージを書き込む人(プロデューサー)はトピックの最後に追記する。(正確にはトピック内の特定のパーティションの最後)
- メッセージを読み込む人(コンシューマー)はトピックをどこまで読んだかを記憶しておき(オフセット)、読み込んでいないデータがきたら読み込む。
これにより、複数のコンシューマーが並列で Kafka に接続してパラレルで処理することが可能となる。従来の JMS などはブローカーがこの情報を管理していた。 - Kafka にはデータが永続化されるため、後から参加したコンシューマーが他のコンシューマーがすでに処理済みのデータを再度処理することができる。(データの送信先を複数分割することができるようになり、データパイプラインを構築することが可能になる)
より詳細に知りたい方は以下のリンクを参照ください。
課題の解決
従来発生していた LinkedIn の課題はどのように解決されたかみてみましょう。
Our configuration always sends live traffic to a local Kafka cluster and these live clusters are replicated to an aggregate cluster which contains a full view of all data for processing or loading into Hadoop.
私たちの構成では、常にライブトラフィックをローカルの Kafkaクラスタに送信し、これらのライブクラスタは、Hadoopへの処理やロードのためのすべてのデータの完全なビューを含むアグリゲートクラスタにレプリケートされています。
Data is also sent back from these applications and from Hadoop processing as new Kafka streams.
また、データはこれらのアプリケーションや Hadoop 処理から新しい Kafka ストリームとして送り返されます。
The “live data centers” are where the real-time application serving happens and the “offline data centers” house Hadoop and other offline analytical infrastructure.
“ライブデータセンター”はリアルタイムアプリケーションの提供が行われる場所であり、”オフラインデータセンター”は Hadoop やその他のオフライン分析インフラストラクチャを収容しています。
基本的には Kafka を導入することで、データのパイプラインを分岐したことが課題解決の大きな要素です。データを必要としているサービスにリアルタイムにデータを送る、これが Kafka の真骨頂になります。加えてサービスが必要とするワークロードに応じたデータソースを適用できます。例えば、データをより検索しやすくという要望があるサービスには elasticsearch、より高速性が求められるサービスにはインメモリデータグリッドのように用途に応じてデータソースを変えることができます。
- アクティビティデータとメトリクスは ETL によって遅延されて連携される(1時間ごと or 1日ごと)ためにリアルタイムで利用することができなかった。
→ ETL を Kafka に置き換えることでリアルタイム処理が可能になった。 - ビジネスメトリクス(ページビューの減少、サインアップ率の低下、その他の活動の低下など)とシステムメトリクス(パフォーマンスの低下、運用メトリクスなど)の相関関係をリアルタイムで把握することが困難だった。
→ ETL を Kafka に置き換えることでリアルタイム処理が可能になった。 - どちらのシステムもポイント・ツー・ポイントでデータのやりとりを行っており送信先は一つのみだったため、データを使いたいという要望があるシステムが多く生まれたがデータを活用できなかった。
→ ETL を Kafka に置き換えることでデータ送信先を分離できデータパイプラインを構築できるようになった。 - クレンジングされたデータが DWH / Hadoop のみに制限されることで、データの利用者がバッチ志向のアプリケーションに制限された。
→ ETL を Kafka に置き換えることでデータ送信先を分離できデータパイプラインを構築できるようになった。 - 新しいタイプのユーザーアクティビティを補足しようとしても XML と密結合が枷になってデータの追加が容易ではなく(スキーマの変更)、新しい活動を補足することが全くできなかった。
→ Kafka を用いることで疎結合なシステムを実現できるようになった。
クレンジングされたデータが DWH のみに限定されてしまうと使う人も限定されてしまうために、LinkedIn は Kafka を開発する際に以下のような構想をしていたようです。
We wanted to move as much of the structure and cleanliness “up-stream” into the real-time feed and allow batch systems to inherit this structure as one among many consumers.
私たちは、構造化されクレンジングされた「アップストリーム」をできるだけリアルタイムフィードに移行させ、多くの消費者の中の1つとしてバッチシステムがこの構造を受け継ぐようにしたいと考えていました。
This helps to scale the organizational problem of integrating all data by moving many problems off the central team that owns Hadoop or the data warehouse infrastructure and bringing it to the owner of the relevant data sources directly.
これにより、Hadoopやデータウェアハウスのインフラストラクチャを所有する中央チームから多くの問題を移し、関連するデータソースの所有者に直接持ち込むことで、すべてのデータを統合するという組織的な問題をスケーリングすることができます。
上記の記述からわかるようにクレンジングは”アップストリーム”で行われ(”ライブデータセンター” の Kafka クラスターの中)、”ライブデータセンター”においてはリアルタイムに使われているはずです。DWH にももちろんクレンジングされたデータは送信されますが、それはあくまでパイプラインの一つという位置付けです。DWH はあくまでオフライン処理用で様々なサービスがリアルタイムにデータアクセスにくる場所ではありません。
いかがでしたでしょうか。Apache Kafka が作られた理由がよく理解できたのではないでしょうか。
最後に
いろいろなお客様からの要望をお伺いしていると、ETL と Apache Kafka を同時に利用するという LinkedIn が Kafka の開発に至った理由と相反した理由でお使いになられるケースもよく見受けられます。
Kafka をただのメッセージングミドルウェアと思っている方もいまだに多く、LinkedIn や Netflix(下記リンク) のようにデータパイプラインを構築するためのツールであることを認識されている方はまだ少ないように思います。この機会に LinkedIn がなぜ Apache Kafka を開発したのかを読んでみると面白いかもしれません。
また、Red Hat では AI/ML のリファレンスアーキテクチャーを OpenShift 上に展開できるOpen Data Hub というプロジェクトを展開しています。Open Data Hub Operator をインストールすると Strimzi Operator (Kafka on Kubernetes の Operator)がインストールされるようになっています。
Red Hat OpenShift Commons Gathering で披露した肺炎の画像診断もこの Open Data Hub を利用しています。ぜひ動かしてみてください。
