Fast Data を扱うためのデザインパターン

®© 2016 MapR Technologies 1 ®© 2016 MapR Technologies 1 © 2016 MapR Technologies

®

Fast Data を扱うためのデザインパターン

Ian Downard, Technical Evangelist with MapR Portland Java ユーザーグループ 2016 年 10 月 18 日

®© 2016 MapR Technologies 2 ®© 2016 MapR Technologies 2

概要 •  このプレゼンテーションでは Apache Kafka を紹介し、Kafka API の

使い方について説明します。また、Fast Data への適用のために Kafka パイプラインのスループットを最大化するための戦略についても解説します。

•  説明で使われているコード例はこちらで入手可能: github.com/iandow/design-patterns-for-fast-data.


•  Ian Downard は MapR の技術エバンジェリストで、開発者フレンドリーな MapR コンバージド・データ・プラットフォームの使い方を生み出す活動に従事

•  個人ブログ: http://www.bigendiandata.com

•  Twitter: https://twitter.com/iandownard

•  GitHub: https://github.com/iandow

•  LinkedIn: https://www.linkedin.com/in/iandownard

著者


Kafka とは? •  分散 Publish-Subscribe 型メッセージングシステム •  ディスク上にデータを格納 (“インメモリ” ではない) •  真のストリーミングをサポート (ただの高速バッチではない) •  データストレージとデータ処理の両方に利用できる (ただのストレージ

ではない) •  小さいメッセージおよび動的なデータセット (いわゆる “ストリーム”) に

向いている


サービス A

サービス B

サービス C

ログ

サービス 1

サービス 2

サービス 3

n 個の Producer m 個の Consumer

コネクションがいくつ必要か? n×m 個。もしどれかを再スタートすると多くのコネクションを復旧する必要がある。システムが大きくなるにつれデータパイプラインの管理が難しくなる


サービス A

サービス B

サービス C

ログ

サービス 1

サービス 2

サービス 3

n 個の Producer m 個の Consumer

コネクションがいくつ必要か? n+m 個。Kafka はユニバーサルなメッセージバス。単一障害点になるように見えるが、Kafka は冗長性を持つ分散システムでスケーラブル


•  変化に柔軟、耐障害性、低遅延 –  マイクロサービスアーキテクチャによく適合

•  少ない設備投資で済むビッグデータ向けメッセージングバス

•  リアルタイム処理と短期ストレージの両方をサポート

•  Kafka はサービス間通信の第一の選択肢になりつつある

Kafka の長所


誰がデータをストリーミングしているか?

•  小売: 注文, 売上, 出荷, 価格調整

•  金融サービス: 株価, クレジットカード不正利用

•  Web サイト: クリック, インプレッション, 検索, Web 不正クリック

•  オペレーティングシステム: 機器のメトリクス, ログ


ストリーミングデータセットの例 •  ソーシャルメディア

–  https://dev.twitter.com/streaming/overview •  IoT

–  https://data.sparkfun.com/streams/ に多くのサンプル –  http://dweet.io はとてもイケてる

•  サーバ: –  /var/log/syslog –  tcpdump

•  銀行 –  Yahoo Finance API: https://github.com/cjmatta/TwitterStream,

http://meumobi.github.io/stocks%20apis/2016/03/13/get-realtime-stock-quotes-yahoo-finance-api.html

–  NYSE 市場: http://www.nyxdata.com/Data-Products/Daily-TAQ •  その他

–  スクリーンスクレイピング



“テキストマイニングは自然言語処理技術のアプリケーションであり、関連情報を抽出するためのテキストデータ分析手法”

http://adilmoujahid.com/posts/2014/07/twitter-analytics/


https://heroku.github.io/kafka-demo/


●  メッセージは <Key, Value> を含む ●  配信には順序がある ●  バイト列として送信 (シリアライザ/デシリアライザを指定) ●  TTL (生存期間, Time-To-Live) の期間保管される ●  At least once セマンティクスに準じる

1 2 3 4 5 6 7 8

トピック “topic1” Consumer Producer

Consumer Producer

メッセージログ


●  Producer は1つずつメッセージを送信 ●  Consumer はトピックを Subscribe してメッセージをポーリングし、

一度に複数のメッセージを受信

“topic1” Consumer Producer

Consumer Producer

1 2 3 4 5 6 7 8

メッセージログ


●  Producer はトピックを1つの論理オブジェクトとして扱う ●  個々のパーティション内のメッセージの順序は保証される

1 2 3 4

“topic1”, パーティション1

Producer 1 2 3 4


パーティショニング


●  個々のパーティションは1つの Consumer だけが読むことができる ●  パーティショニングにより Consumer の並列動作が可能になる ●  新しい Consumer は自動的にパーティションが割り当てられる

Producer 負荷分散されたConsumer

1 2 3 4

1 2 3 4



パーティショニング


●  コミットを呼び出すことで Consumer が処理を完了した場所を記録する

1 2 3 4 5 6 7 8


Consumer

commit (p1, o6)

コミット


●  コミットしてしまえば Consumer がクラッシュしても問題がない

1 2 3 4 5 6 7 8


Consumer

コミット


●  別の Consumer が引き継いだときに、前の Consumer が中断したところから再開する

1 2 3 4 5 6 7 8


新しい Consumer

コミット

カーソル


Kafka は Zookeeper に依存

•  リーダー選出 – 各パーティションがリーダーを持つ

•  クラスタメンバーシップ – ブローカーの稼働状況

•  トピック設定 – トピック名、パーティション、レプリカ、TTL…


デモ: Kafka CLI •  トピックの作成、変更、Pub/Sub、削除 •  トピックがどこに保存されるかを確認してください


デモ: Java API •  基本的な Producer/Consumer の例


デモ: Heroku Kafka-as-a-Service •  デモアプリ:

–  https://github.com/iandow/heroku-kafka-demo-java

•  ドキュメントと価格: –  https://devcenter.heroku.com/articles/kafka-on-heroku –  $1,500/月 !!! –  あ、でもクレジットの四捨五入があります


デモ: Web アプリで Kafka を利用 •  メッセージの送信方法

–  配信保証の実現方法 –  障害の対処方法

•  実演: –  DemoResources.java の20秒のタイムアウトを変更 –  java.util.concurrent を確認。ユーザ指定のコールバック内でタイムアウト –  メッセージが最終的に到達するかどうかも確認 (送信中の場合)

•  Dropwizard メトリクスを取り除くには、DemoApplication.java のタイムアウトを変更

–  reporter.start(1, TimeUnit.MINUTES);

®© 2016 MapR Technologies 25 ®© 2016 MapR Technologies 25 © 2016 MapR Technologies © 2016 MapR Technologies

Consumer グループ、カーソル、パーティション


ProducerRecord と ConsumerRecord の比較

•  Producer は ProducerRecord としてメッセージを1つずつ送信

•  Consumer はトピックを Subscribe してメッセージをポーリングし、ConsumerRecords として一度に複数のメッセージを受信


Consumer グループ、カーソル、パーティション •  Consumer グループ – 協調動作する Consumer のグループ

•  カーソル – Consumer の位置を追跡

•  パーティション – スケールさせるためにトピックを細分化

•  レプリケーションファクター – 耐障害性のためにパーティションをノード間で複製する


パーティションのバランシング •  パーティションは同じグループに所属する Consumer 間でバランスされる

–  個々のパーティションは1つの Consumer だけが読むことができる –  個々の Consumer は複数のパーティションを読むことができる –  例:

•  3つのパーティション, 2つの Consumer: 2 と 1 •  5つのパーティション, 1つの Consumer: 5 •  3つのパーティション, 4つの Consumer: 1, 1, 1, 0 (4つ目の Consumer はメッセージを受信し

ない)

•  新しい Consumer が加わる、または新しいパーティションが追加される場合、再バランスが起こる –  パーティションを獲得する、または失う Consumer があり、これが発生する時はメッ

セージの配信が少しの間停止する可能性がある –  Consumer が正しくカーソルをコミットしていない場合は重複を引き起こす可能性があ

る


Consumer グループ

•  個々のトピック/パーティションを同時に Consume できるのは、「同じグループ内では」1つの Consumer だけ

•  異なるグループに所属する Consumer であれば、同じトピック/パーティションを読んでいれば同じメッセージを見ることができる

http://kafka.apache.org/documentation.html


カーソルの永続化

•  Consumer が停止後、中断したところから読めることを保証 •  メッセージを読んだことを示す最後のコミット位置を追跡 •  デフォルトでは、5秒の自動コミット (auto.commit.interval.ms)

–  遅い Consumer コードの場合、処理完了前に自動 commit() が実行されてしまうかも –  consumer.commit() で明示的にコミットすることが可能

•  Consumer の並列実行が必要な場合、Consumer グループまたはトピックパーティションを使いますか?

8 7 6 5 4 3 2 1

トピック “topic1”

Consumer グループA

Consumer グループB

カーソルA

カーソルB


At Least Once セマンティクス •  メッセージは複数回現れる可能性がある

–  Producer 側 •  ネットワーク上での再送 •  Producer が異常終了し、再開時にすでに送ったメッセージを再送する可能性がある

–  Consumer 側 •  クライアントがメッセージ取得後、cursor.commit() の前にクラッシュする可能性がある

•  アプリケーションは冪等な (何回行っても結果が同じ) メッセージ処理コードでなくてはならない


バッチの振る舞い •  Producer.send() はクライアント側のメモリバッファにメッセージを置く

•  次の3つの条件のいずれかが満たされるまでは、このバッファはフラッシュされない: –  タイムアウト (linger.ms) –  メモリ上限 (buffer.memory) –  Producer.flush() 呼び出し


シリアライゼーション •  各 Kafka メッセージはバイト列

•  <K,V> をバイト列にシリアライザで変換する必要がある

•  2つのシリアライザが提供されている: –  ByteArraySerializer/ByteArrayDeserializer –  StringSerializer/StringDeserializer

•  独自のシリアライザを実装することも可能


基本的な考え方 – シリアライゼーション

•  バイト列データをストリーミングする場合、ByteArraySerializer を使う

•  String データをストリーミングする場合、StringSerializer を使う

•  POJO データをストリーミングする場合、何を使う?


POJO のストリーミング方法 1.  Serializable にする

–  これをしないと後でオブジェクトをバイト列に書き出すときに java.io.NotSerializableException が発生

2.  オブジェクトをバイト列に書き出す 3.  バイト列を送信

–  なぜ Person オブジェクトをそのまま送信できないのか?

4.  Consumer でトピックをポーリングし、record.value() を POJO に変換する

もし Person オブジェクトからバイト列への変換を省略すると、Kafka がバイト列に変換しようとした時に SerializationException が発生


POJO のストリーミングの問題 •  もし生データに異常があり、ストリーミングした POJO フィールドの欠

損が原因でキャストが失敗したらどうなるか?

•  POJO からバイト列またはその逆のエンコーコーディング/デコーディングのオーバーヘッドは冗長で、特に Kafka パイプラインの複数のステージで行われる場合はそれが顕著

•  パースやキャストは下流の処理まで延期したほうがよい


これをどのようにストリーミングするか? 080449201DAAT00000195700000103000N0000000000000004CT1000100710071007080449201DAAT00000131000000107000N0000000000000005CT10031007080449201DAAT00000066600000089600N0000000000000006CT10041005080449201DAAT00000180200000105100N0000000000000007CT100310051009080449201DAAT00000132200000089700N0000000000000008CT100410051005080449201DAAT00000093500000089400N0000000000000009CT10031007080449201DAAT00000075100000105400N0000000000000010CT100410081006080449201DAAT00000031300000088700N0000000000000011CT1004100810081007080449201DAAT00000021800000105100N0000000000000012CT100410091005080449201DAAT00000191300000104500N0000000000000013CT10041006080449201DAAT00000124500000105100N0000000000000014CT1001100610071008


選択肢A? •  各レコードをパースして JSON オブジェクトにする •  json_object.toString() を Publish •  String シリアライザでストリーミング

下流の処理でフィールドへのアクセスが簡単 (開発者に優しい)。しかし、多くのオブジェクトを作ることになり、オブジェクトはネイティブ型に比べてコストが高い


選択肢B? •  各フィールドを属性として持つ

POJO (“Tick”) を作成 •  各レコードをパースして Tick オブ

ジェクトを作る •  Tick オブジェクトをカスタムシリア

ライザを使ってストリーミング

パースのコストが高い。多くのオブジェクトを作ることになり、オブジェクトはネイティブ型に比べてコストが高い。多くの文字列を作ることになりメモリの利用効率が悪くなる可能性


選択肢C? •  単一の byte[] 属性と、

byte[] のインデックスを直接計算してフィールドを返す Getter を持つ POJO “Tick” を作成

•  @JsonProperty で Getter をアノテート

フィールドへのアクセスが簡単で、JSON オブジェクトの作成も容易。byte[] の検索が高速でパースを下流の処理に先送りできる。メモリ局所性が向上し、キャッシュのスラッシングを最小化する


A

B

C


性能に影響する主な要因 •  レプリケーションが有効になっているか? •  大きなメッセージをストリーミングしているか? •  Producer は同期送信しているか、非同期か? •  次の3つの条件のいずれかが満たされるまでは、バッファのフラッシュ

および送信は行われない: –  タイムアウト (linger.ms) –  メモリ上限 (buffer.memory) –  Producer.flush() 呼び出し

•  トピック / Producer 間のアフィニティ (関連付け)


•  何が Producer のレイテンシに影響を及ぼすか? –  send 機能 (同期送信) を利用? –  acks=all,1,0 (リーダーがロギング後に ack / 全ての複製がロギング後 / ack なし) –  ”Nagle アルゴリズム” と linger.ms 設定

•  何が Producer のスループットに影響を及ぼすか? –  Producer の batch.size –  producer.send() の並列呼び出し –  トピック数 –  メッセージサイズ

•  何が Consumer のスループットに影響を及ぼすか? –  パーティション

性能に影響する主な要因


性能に影響する主な要因 •  何が Kafka サーバの安定性に影響を及ぼすか?

–  ガベージコレクション: 大きなメッセージの送信に伴う長い GC により Kafka/Zookeeper 接続が中断する可能性がある

–  トピックは容易にディスク容量消費の原因となる –  ファイルハンドラ上限を増やす必要性

•  トピックデータとインデックスファイルは log.dir (例: /tmp/kafka-logs) に保存される •  Kafka は各トピックのオープンファイルを保持する

–  参考: http://www.michael-noll.com/blog/2013/03/13/running-a-multi-broker-apache-kafka-cluster-on-a-single-node/


読み込み並列性と処理並列性 •  Consumer の読み込みの並列性

–  並列読み込みはトピックパーティションと Consumer グループにより実現できる

–  Consumer ロジックが CPU の能力に依存する処理の場合、パーティションか Consumer グループを使う

•  下流の処理の並列性 –  読み込みスレッドよりも多くの処理スレッドが必要な場合、データを複数のト

ピックに“fan-out (展開)” する


“Fan-out” とはどういうことか:

Kafka API

v v

SQL

15 分毎

デイトレード

取引情報を投入

取引情報のアーカイブ

マイクロサービス送信者/受信者毎にインデックス

証券情報ストリーム

マイクロサービス STREAMING

https://www.mapr.com/appblueprint/overview


性能上のアンチパターン •  問題: 各 Consumer スレッドで読んだ全てのメッセージの数をカウント

したい

•  アンチパターン: synchronized ブロック内でカウンタを加算しよう


性能上のアンチパターン •  各 Consumer スレッドで読んだ全てのメッセージの数をカウントしたい

•  よし、synchronized ブロック内でカウンタを加算しよう

–  教訓: 同期処理はスループットに深刻な影響を与える –  解決策: 各スレッドにメトリクス構造体を用意し、1秒程度ごとにロックを使って

共有メトリクス構造体を更新することで、メトリクス収集のコストをほとんどゼロにまで削減


性能上のアンチパターン •  重複メッセージを絶対読むことがないようにしたい

•  よし、各メッセージを Consume するたびに読んだ位置をコミットしよう


性能上のアンチパターン •  重複メッセージを絶対読むことがないようにしたい

•  よし、各メッセージを Consume するたびに読んだ位置をコミットしよう

–  教訓: そのようにしても重複メッセージを読まないという保証はない。Kafka Consumer は冪等でなくてはならない

–  解決策: 重複排除は下流の処理まで延期 (つまり、あきらめて後でやる)


性能上のアンチパターン •  Spark での DB 格納とカラム選択をシンプルにするために、JSON 文

字列をストリーミングしたい

•  よし、パイプラインの最初の段階ですべてのメッセージを JSON オブジェクトに変換して JSON シリアライザを使おう


性能上のアンチパターン •  Spark での DB 格納とカラム選択をシンプルにするために、JSON 文字列

をストリーミングしたい

•  よし、パイプラインの最初の段階ですべてのメッセージを JSON オブジェクトに変換して JSON シリアライザを使おう

–  教訓: パースにはコストがかかる! パースエラーの扱いにはコストがかかる。カスタムシリアライザは思っていたほど簡単ではない

–  このアンチパターンの解説はこちら: https://github.com/mapr-demos/finserv-ticks-demo/commit/35a0ddaad411bf7cec34919a4817482df2bf6462

–  解決策: 生データを保持する byte[] を含むデータ構造をストリーミングして、com.fasterxml.jackson.annotation.JsonProperty でアノテート

–  例: https://github.com/mapr-demos/finserv-ticks-demo/blob/35a0ddaad411bf7cec34919a4817482df2bf6462/src/main/java/com/mapr/demo/finserv/Tick2.java


グッドプラクティス •  Java または Scala 標準のコレクションクラス (例: HashMap) ではなく、

オブジェクト配列やプリミティブ型を使うようにデータ構造を設計 •  トピックと Producer スレッド間のアフィニティを管理

–  Kafka は複数の送信をまとめてバッチ送信する。もし送信先のトピックが1つだけなら、シーケンシャルなメモリ空間への書き込みによるメリットがある

–  参考コード: https://github.com/mapr-demos/finserv-application-blueprint/blob/master/src/test/java/com/mapr/demo/finserv/ThreadCountSpeedIT.java

•  キーに文字列ではなく数値 ID もしくは列挙オブジェクトを使うことを考慮


3つの性能上の知見 1.  パイプラインでは最低限の処理を行う

–  バイト列で転送すること。文字列や POJO のシリアライザや、カスタムシリアライゼーションよりも高速

2.  JSON アノテーションを利用する。最終ステージでデータ格納が楽になる。簡易なスキーマが提供されるため、データ分析も容易になる

3.  生データを複数トピックのカテゴリに分ける (別名 “fan-out”)。リアルタイム分析が容易になる

4.  Kafka をチューニングするために JUnit でパラメータ化テストを利用する


デモ: JUnit で Kafka をチューニング

https://github.com/iandow/kafka_junit_tests


JUnit パラメータ化テストの作成方法 1.  テストクラスを @RunWith(Parameterized.class) でアノテート

2.  テストデータセットとしてオブジェクトのコレクションを (Array として) 返す、@Parameters でアノテートされた public static メソッドを作成

3.  テストデータの1"行"を引き受ける public なコンストラクタを作成


ベンチマーク •  LinkedIn の Jay Kreps による Lazy benchmark (2014年):

–  https://engineering.linkedin.com/kafka/benchmarking-apache-kafka-2-million-writes-second-three-cheap-machines

•  次のような疑問への回答: –  もしメッセージを Consume しなかったら Kafka は遅くなるのか? –  (スループットを最大化するために) 小さいメッセージもしくは大きいメッセージ

のどちらをストリームすべきか?


Kafka MapR Streams 標準 Kafka API 準拠 ✓ ✓ 数千トピックまでのスケール ✗ ✓ 大きなパーティションのクラスタノードをまたいだ自動展開

✗

✓

Consumer および Producer のミラークラスタ間フェールオーバー

✗ ✓

データセンター間のリアルタイムクラスタレプリケーション

✗ ✓

Kafka と MapR Streams の比較


•  MapR-FS から効率的な I/O パターンを継承、トピックはより多くのデータを保存し効率的に複製することが可能に

•  トピックおよびパーティションの負荷分散がより効率的

•  複数データセンターのクラスタをまたいでトピックの利用が可能で、クラスタ間でオフセットを同期

•  コア MapR プラットフォームから効率的な I/O パターンを継承

MapR Streams は Kafka よりスケーラブル


コンバージド・アプリケーションのブループリントリアルタイム証券情報ストリーミング

Kafka API

v v

SQL

15 分毎

デイトレード

取引情報を投入

取引情報のアーカイブ

マイクロサービス送信者/受信者毎にインデックス

証券情報ストリーム

マイクロサービス STREAMING

https://www.mapr.com/appblueprint/overview


オープンソースエンジンおよびツール商用エンジンおよびアプリケーション

エンタープライズグレードプラットフォームサービス

デー

タ

プロ

セッ

シン

グ

Web スケールストレージMapR-FS MapR-DB

Search and Others

リアルタイム統合セキュリティマルチテナント災害復旧グローバル名前空間高可用性

MapR Streams

クラウド・マネージドサービス

Search and Others

統合

管理

・監

視

検索その他

イベントストリーミングデータベース

カスタムアプリ

HDFS API POSIX, NFS HBase API JSON API Kafka API

MapR コンバージド・データ・プラットフォーム


•  Kafka と Spark Streaming についての記事をご覧ください •  https://www.mapr.com/blog/real-time-streaming-data-pipelines-

apache-apis-kafka-spark-streaming-and-hbase

•  Streaming Architecture 電子ブックをご覧ください •  https://www.mapr.com/streaming-architecture-using-apache-kafka-

mapr-streams

•  このプレゼンテーションとデモコードはこちら •  https://github.com/iandow/design-patterns-for-fast-data

次のステップ:


無料トレーニング à http://learn.mapr.com


Q & A

@mapr @iandownard

Engage with us!

mapr-technologies

Data & Analytics

Fast Data を扱うためのデザインパターン