Kafka: a Distributed Messaging System for Log Processing を読んだ

Kafka: a Distributed Messaging System for Log Processingを読んだ時のメモ。

どんなもの？

• LinkedInによって開発された分散メッセージングシステム
  • 大容量のログを高スループットで配信、低レイテンシで収集することを目的としている

先行研究とくらべて何がすごい？

• ログの処理の焦点を絞って開発されたので低レイテンシで高スループット
  • 従来のメッセージングシステムに備わっていた、不要な機能を削ぎ落としている
    • delivary guaranteeや順番の担保等
      • ログなので多少欠けていても問題ない
    • 従来のメッセージングシステムはスループットにforcusしてなかった
      • バッチ処理でやればいいと考えていた
      • ビジネス的にはリアルタイムでログを処理したい場面も増えた
• スケールアウトしやすい

技術や手法の肝は？

• Kafka Architecture and Design Principles
  • producer
    • topic(メッセージのfeedのようなもの)にメッセージを送る
  • broker
    • topicに送られてきたメッセージを保存する

  • consumer

    • 1つ以上のtopicをsubscribeできて、pullすることでbrokerからデータを取得する

  • 負荷を分散するためtopicは複数のbrokerに分散されている

  • producerとconsumerは同時にmessageをpublish/subscribeできる

• Efficiency on a Single Partition
  • Simple storage
    • topicのそれぞれの部分はlogical logに対応している
    • 物理的なログは一定サイズのsegment fileとして、保存されている
    • producerがメッセージをpartitionにpublishすると、brokerはログの最後にメッセージを追加していく
    • パフォーマンス向上のために、ある程度メッセージが溜まってからdiskにflushする
    • メッセージはflushされてから、consumerにconsumeされる
    • 従来のメッセージングシステムと異なり、メッセージにはIDは振られていない
      • それぞれのメッセージはlog内のoffsetで位置を決められている
    • consumerは特定のpartitionから順番にメッセージをconsumeする
      • consumerからのpull requestにはメッセージのoffsetとfetchするbyte数が含まれている
    • brokerはin-memoryに各segment fileの初期位置を示したoffset listを持っている
  • Efficient transfer
    • Kafka Layerにはcacheを持たず、file systemのpage cacheを利用している
      • GCのoverheadが小さい
  • Stateless broker
    • brokerは各consumerがどれくらいメッセージをconsumeしたかについての情報は管理しない
      • consumer自身がその情報を持っている
      • brokerが管理すると複雑になってしまうのと、overheadが生まれるから
    • brokerはどこまでデータが読まれたかがわからないので、一定時間が経ったデータを消していく
      • アプリケーションのバグがあっても一定期間内であれば、再度同じ情報をconsumeできる
• DistributedCoordination
  • consumer group
    • 1つ以上のconsumerから成るグループ
    • そのグループに対して一つずつメッセージが配信される
    • グループはそれぞれ独立していて、他のグループと協働しない
  • 工夫点
    • topic内のpartitionを並列化の最小単位とした
      • どんな時も1つのpartitionの全てのメッセージはそれぞれのグループの1つのconsumerからのみconsumeされる
        • どのconsumerにどのメッセージを送ったかという情報やlockのことを考えずにすむのでoverheadが少ない
    • central master modelは避けた
      • ZooKeeperを用いて、master無しでconsumer達が協調して動くようにした
  • Delivery Guarantees
    • at-least-once delivery
      • consumerがcrashしてももう一度同じメッセージを読みにいける
      • 正確に一度だけ送ろうとすると2PC等を使わねばならず、非効率
    • single partitionからは順番にデータが送られるが、partition間での順序は保証しない

どうやって有効と検証した？

• LinkedInで半年間使った

• KafkaとApache ActiveMQの比較をした

• Producer Performance

  • producerはbrokerからのackを待たないので速い
  • 効率的なメッセージフォーマットなので速い
    • メッセージのoverheadは9bytes(ActiveMQは144bytes)
  • ActiveMQはメッセージのメタデータを管理するindexへのアクセスに時間がかかる

• Consumer Performance
  • 効率的なメッセージフォーマットなので速い
  • 全てのメッセージの配信状況を管理しないので速い
    • 中には送られていないメッセージもある
  • sendFile APIが転送のoverheadを少なくした

議論はある？

• 複数のbroker間でのメッセージレプリケーションをbuilt-inの機能として入れる
• 幾つかのストリーム処理を組み込む
  • window countingとか
• producerはbrokerのackを待たないので、全てのメッセージが送られていることを保証できない

次に読むべき論文は？

ZooKeeper: Wait-free coordination for Internet-scale systems