Above & Beyond

日々のアウトプット記録

Apache Kafka Meetup Japan #6 @Yahoo! JAPAN

04/09(火) は「Apache Kafka Meetup Japan #6 @Yahoo! JAPAN」に参加してきました。

kafka-apache-jp.connpass.com

f:id:kabukawa:20190407205358p:plain:w300

会場は YahooLodgeのイベントスペース。

f:id:kabukawa:20190413145537j:plain


目次


Apache Kafka Meetup Japan とは

前回の参加報告がありますので、そちらを参照してください。

kabukawa.hatenablog.jp


タイムスケジュール

時間 内容
18:30~19:00 入場受付
19:00~19:05 オープニング
19:05~20:05 "Dissolving the Problem: Kafka is more ACID Than Your Database"
Mr. Tim Berglund (Confluent Inc.)
20:05~20:25 "ログ監視システムにおける時刻ベース遅延の可視化"
大平哲也 (株式会社サイバーエージェント)
20:25~20:45 "Elastic StackでKafkaをモニタリング!"
Jun Ohtani / Community Engineer at Elastic
20:45~21:05 "大量トラフィックを受けるトピックのレプリケーションボトルネック"
Wilson(LINE株式会社)
21:05~22:00 懇親会 + LT(3枠ほど)
21:15~21:20 "有価証券情報システムにおけるKafka利用事例"
株式会社QUICK 近藤
22:00~22:30 撤収

内容


Dissolving the Problem: Kafka is more ACID Than Your Database

Mr. Tim Berglund (Confluent Inc.) さん

www.slideshare.net

同じタイトルで今年の7月にOpen Source Software Coferenceで講演されるようですね。

conferences.oreilly.com


問題を解決する(KafcaからACID準拠のデータベースを作成する)

https://www.amazon.com/dp/1449373321

データベースとは

物事を記憶し、データモデルとACIDトランザクションプロパティを持つプログラム。

ACIDとは何か?

  • Atomicity(原子性)
  • Consistency(一貫性)
  • Isolation(独立性)
  • Durability(耐久性)

Durability(耐久性)

f:id:kabukawa:20190413164711p:plain:w500

Atomicity(原子性)

f:id:kabukawa:20190413164944p:plain:w500

Isolation(独立性)

f:id:kabukawa:20190413165103p:plain:w500

Consistency(一貫性)

  • 不変式/制約
  • 固有のユーザ名
  • 口座残高がゼロより大きい

Kafkaとは何か?

  • イベントのログなどに使用できるメッセージングキュー
  • データアイテムはKey-Value Pair
  • 順序保証
  • 定数時間リード
  • ストレージへの永続化など

Kafkaクラスタで各ノード (ブローカー) にパーティショニングでき、ブローカー間でトピックを複製・保持する。

Topics

f:id:kabukawa:20190413165322p:plain:w400

パーティショニング

f:id:kabukawa:20190413165404p:plain:w400

複製

f:id:kabukawa:20190413165632p:plain:w400

プロデューサー

f:id:kabukawa:20190413165757p:plain:w400

コンシューマー

f:id:kabukawa:20190413170025p:plain:w400

Kafka ストリーム

f:id:kabukawa:20190413170515p:plain:w400

  • ストリームをテーブルに変換
  • テーブルでストリームを充填
  • 集約ストリーム
  • あるストリームを別のストリームに結合
  • ステートフルアプリケーションを拡張
  • 機能的なJava API
  • ストリームとテーブルの抽象化
  • スケーラブルでフォールトトレラントな状態

f:id:kabukawa:20190413170138p:plain:w400

KSQL

CREATE TABLE movie_ratings AS
    SELECT title,
        SUM(rating)/COUNT(rating) AS avg_rating,
        COUNT(rating) AS num_ratings
    FROM ratings
        LEFT OUTER JOIN movies
        ON ratings.movie_id = movies.movie_id
    GROUP BY title;

f:id:kabukawa:20190413170612p:plain:w500

  • 宣言型ストリーム処理言語
  • ストリームとテーブルの抽象化を提供
  • フィルター、結合、集約
  • 水平方向にスケーラブルなKSQLクラスタで実行する

www.confluent.io

クールだけどKafkaを使ってもいい?

  • Atomicity(原子性)
  • Consistency(一貫性)
  • Isolation(独立性)
  • Durability(耐久性)

データベースとは何ですか?

  • SQL
  • 表モデル
  • ストレージエンジン
  • コミットログ

あなたはマイクロサービスを書いているだけではありません。 あなたはACIDセマンティクスで裏返しのデータベースを構築しています、そしてそれは良いことです。

github.com


個人メモ:

  • 英語のセッションで話されていることが結構抜け落ちていたので、こうやって資料を読み直すことで思い出すことが有ってよかった。
  • Kafkaって結局一体何なのさ?という問いに対する一つの答えとして、このセッションの内容は興味深いなと思った。


ログ監視システムにおける時刻ベース遅延の可視化

大平哲也 (株式会社サイバーエージェント) さん

speakerdeck.com


ログの品質管理システム

f:id:kabukawa:20190413173006p:plain:w500

  • 不正なログをフィルタリングして後続に流す。
  • 許容可能な遅延時間に上限がある。

Kafkaはオフセットでログを管理しているが、古いログの滞留量が、流量増加のせいか処理遅延のせいかか分からない。

f:id:kabukawa:20190413173331p:plain:w500

f:id:kabukawa:20190413173356p:plain:w250 f:id:kabukawa:20190413173413p:plain:w250

  • 遅延への対応
    • 経験則でオフセットの遅延から遅延時刻を推定
    • メッセージを手動で取得し、タイムスタンプを一つずつ確認
  • 時間ベースでログの遅延を監視したい

f:id:kabukawa:20190413173717p:plain:w500

時間ベースの遅延計算

  1. オフセット情報䛾一覧を取得
  2. パーティションから䛾オフセット地点のメッセージを取得
  3. 現在時刻とtimestampの差を計算

実行時間の問題点

複数パーティション同時購読の課題

f:id:kabukawa:20190413174023p:plain:w250 f:id:kabukawa:20190413174047p:plain:w250

改善方法

f:id:kabukawa:20190413174520p:plain:w250 f:id:kabukawa:20190413174541p:plain:w250

高速化結果

  • 7分半→1分半へ高速化
  • 比率にすると1/5程度䛾時間に短縮
  • 1分半ほどの実行時間であれば常時回しておけば遅延監視には十分な速度

遅延の可視化

f:id:kabukawa:20190413174723p:plain:w250 f:id:kabukawa:20190413174738p:plain:w250


個人メモ:

  • こうやって工夫をしながら運用改善を積み重ねていくのは良いなと思った。
  • でも、こういう要望って他のところでもありそうな気がするので、本体に取り込んでもらえると良いのかもしれない。


Elastic StackでKafkaをモニタリング!

Jun Ohtani / Community Engineer at Elastic さん

noti.st

f:id:kabukawa:20190501003553p:plain

Monitoring Kafka with Elastic Stack: Filebeat | Elastic Blog


Elastic StackでKafkaのモニタリング始めてみるには? という内容

Elastic Stack

f:id:kabukawa:20190501003512p:plain:w500

f:id:kabukawa:20190501003659p:plain:w250 f:id:kabukawa:20190501003715p:plain:w250

f:id:kabukawa:20190501003729p:plain:w250 f:id:kabukawa:20190501003743p:plain:w250

ElasticStack の構成

f:id:kabukawa:20190501003949p:plain:w500

Beats を使ってモニタリング対象のデータを収集

www.elastic.co

製品名 収集対象
Filebeat ログファイル
Metricbeat メトリック
Packetbeat ネットワークパケット
Winlogbeat Windowsイベントログ
Auditbeat 監査データ
Heartbeat 稼働状況の監視
Functionbeat サーバーレスシッパー

Java ではないので軽量。Kafka にもデータを送れる。

Beats から直接 Elasticsearch に送ってもいいが、 Elasticsearch はデータベースでは無いのでトランザクションなどを要求されると弱い。 なので BeatsKafkaElasticsearchKibana のように、Kafka をElasticsearchの前段に挟むと良いのではないか。

Beatsからデータを送る対象アプリごとにモジュールが用意されてる。

www.elastic.co

参考文献

データ分析基盤構築入門[Fluentd、Elasticsearch、Kibanaによるログ収集と可視化]

データ分析基盤構築入門[Fluentd、Elasticsearch、Kibanaによるログ収集と可視化]

Elasticsearch実践ガイド (impress top gear)

Elasticsearch実践ガイド (impress top gear)

参考サイト


個人メモ:

  • Kafkaの監視、会場ではPrometheusでやっている人が多かった(と言っても数人)
  • Beats、種類も結構あるし、接続先のモジュールも多くて結構便利そう。
  • kibanaもデフォルトでここまで見られるようになるの、いいな。

大量トラフィックを受けるトピックのレプリケーションボトルネック

Wilson(LINE株式会社) さん

speakerdeck.com


正月のあけおめスパイクトラフィックによってReplicaがOut-of-Synkしてしまったお話

Kafkaのレプリケーションの仕組み

  • メッセージを複数のブローカに複製
  • Partition/Leader/Fetacherの割り当てをラウンドロビンで行なっている
  • 組合せの割当て方によって偏りが生じ、負荷分散が適切に機能しないことがある

正月のあけおめスパイクトラフィック

  • 01/01 00:00 前後。LINEに新年の挨拶が飛び交い、メッセージが滞留
  • NW, I/O, CPU の使用率は高くない
  • 一部のFetcherが複数のPartitionをFetchしようとしていたため、ReplicaのFetchが遅くなっていた

偏りをどうやって減らしたか

  • 組合せを見直す

個人メモ:

  • 正月のスパイクは通常時の倍以上の流量だったようで、これを遅延をできるだけ少なく捌くのはかなり大変そうだと思った。
  • 通常の利用では顕在化しない動きも出るだろうし、今回の偏りの話もその類の話かなと感じた。
  • とはいえ、最後はこうやって人間が調整して対応することで事なきを得た、というのが面白かった。

LT:有価証券情報システムにおけるKafka利用事例

株式会社QUICK 近藤 さん

[資料は公開されたら追記します]


懇親会

お寿司とピザを摘みつつ、参加者同士の歓談が続きました。

f:id:kabukawa:20190413145736j:plain

自分はちょっと疲れが溜まっていたので少し早めに撤収。美味しい料理と飲み物、ありがとうございました!


まとめ

今回も、Kafkaとはなにか?という話から実運用、監視と言った様々な切り口でお話を聞くことができました。 Apache Kafka Meetup Japanでは毎回1セッションは英語のみ(同時通訳無し)のものがあるのですが、それも慣れてしまえば楽しく聞くことができますので、とても良い勉強会だと思います。 次回も是非参加したいなと思いました。

講演者、スタッフ、参加者の皆様、ありがとうございました!