0. 本投稿について
LinkedInのKafkaについて書かれた論文を読んだので、概要だけ記録する。
論文リンク
http://sites.computer.org/debull/A12june/pipeline.pdf
1. Introduction
- LinkedInでは、コネクション予測、ジョブのマッチング、表示する広告の最適化をユーザーの行動履歴から機械学習を利用してモデリングしている。
- ユーザーのソーシャルネットワークに関連のあるニュースフィードをactivity drivenに投稿している
1.1 Previous Systems
- 行動履歴データをデータウェアハウス(DWH)にInsertするバッチ指向のシステムとサーバのメトリクスとロギングを処理するシステム（監視システムにのみ利用）の２つのシステムを構築していた。
- どちらもpoint to point でデータのやり取りを行い、送信先は１つに決まっていた。
- ユーザの行動履歴はログファイル（xml形式）に収集してETLサーバにバッチで送信する。
- ETLサーバがログファイルのメッセージをパースして、RDBとHadoopにインポートする。
- 問題点
- リアルタイム性に欠ける。（ファイルに出力されたものをパースしてインポートするので、ファイルローテーションの時間分ラグが出てしまう。）
- 送信先は一つしかサポートしない
- アプリケーションが直接xmlのメッセージを出力するので、予期しないスキーマの変更があった場合に対応できない
1.2 Struggles with real-time infrastructure
システムをよりリアルタイム化するために、様々な方法を試した。
秒間2,3000のメッセージをさばくことができ、LinkedInの他サービスでも稼働実績があったのでActiveMQを利用してプロトタイプを作成しテストしてみた。その結果、以下の問題があった。
- メモリにキューとして保持できるデータ量を超えるとその時点で性能が著しく低下する。（ランダムIOが多いため。）
- Consumerプロセス（データを取得するクライアント）自身がバランスをとっているので、与えられたキューにConsumerプロセスがないという事象が発生した。(管理できないので、Consumerからbrokerへの割当をstaticにしたくなかった。)
- ActiveMQ自体のバグで(brokerのhung up、コネクションリーク、アウトオブメモリー等）
これらが、既存のプロダクトではなくpipeline infrastractureを自社開発しようというモチベーションになった。
2. Pipeline Infrastructure
2.1 Conceptual Overview of Kafka
- 抽象化したバイト配列としてメッセージをモデリングする。
- Producerはあるフィードの全てのメッセージを持つtopicにメッセージを送る。
- それぞれのtopicはKafkaのbrokerのクラスターに分散され、brokerはそれぞれのtopicごとのパーティションを持つ。
- パーティションはメッセージが書かれた順番に並ぶ。
- システムの動作は以下２つ
- topicの値に新規メッセージをappend
- 特定のメッセージidから始まるパーティションからメッセージをfetch
- 全てのtopicは複数のsubscriberから読み取り可能、かつ、とても小さなoverheadでsubscriberを追加可能
- 稼働中にグループにノードを追加可能でstaticなconfigurationなしに自動リバランスする。
- Zookeeperを利用してグループのハートビートやconsumerへpartitionの割当を行う。 ※この辺りの説明は結構複雑だったので、一旦放置。
- 多少のデータロスは許容できるものに利用している。高可用性を提供する試みとして、それぞれの機能(producer,broker,consumer)ごとにロスや遅延を発見するためのデータを計測している。
2.2 Kafka Usage at LinkedIn
- Kafkaは１日あたり１００億を超えるメッセージの書き込みを処理する。
- 高トラフィックの時間帯は秒間172,000メッセージを扱う。
- totalで40のconsumerがありtopicをconsumeしている（8個はreplicationやモニタリングツール用で、それ以外はユーザーやその他機能から書き込まれるアプリケーション）
- ユーザー行動履歴データとシステムログをあわせて367topicをサポートしている。
- 最大で一つのtopicが１日92GB追加される。小さなものは数KB
- メッセージデータは７日間保持され、データがconsumeされたかどうかに関わらず経過した時点でgarbageとして収集される。
- Consumerはこのポリシーをtopicごとに変更可能
- 全topic合わせて9.5TB（圧縮済み）を保持している。
- Kafka用のサーバはデータセンターごとに8台で、それぞれのサーバがStorage 6TB（RAID10で普通のSATAディスク）
- クラスターにつき、10,000コネクションを捌く
3. Enineering for High Throughput
logファイルにまとめる設計はbufferingして効率のよいIOパターンで書き込めるのでHigh-Throughputが有利な点だが、障害によりbufferingしているメッセージのロスやリアルタイム性に欠ける。つまり、ファイルサーバに収集される前に書き込みが終了していないといけない。これを縮めるにはファイルのローテーションを1分毎など短い間隔にすることも考えられるが、そうすると大量のファイル数を管理するコストがかかる。
アーキテクチャとしてロギングシステムで管理コストを抑えるモデルかつ、効率的なメッセージングシステムを設計するのがKafkaの設計のゴールとなる。
Kafkaでは、技術的な面で以下３つの効率化を行っている。（３項目の詳細については後日記載）
- パーティショニング
- chunk サイズの効率化
- データ圧縮
ここまでで、自身の経験と当てはまる部分も多くて参考になる.この先は気が向いたら追記