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
概要
•  このプレゼンテーションでは 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”
ConsumerProducer
ConsumerProducer
メッセージログ

®
●  Producer は1つずつメッセージを送信
●  Consumer はトピックを Subscribe してメッセージをポーリングし、
一度に複数のメッセージを受信
“topic1”
ConsumerProducer
ConsumerProducer
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© 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 パイプラインの複数のス
テージで行われる場合はそれが顕著
•  パースやキャストは下流の処理まで延期したほうがよい

®
これをどのようにストリーミングするか?
080449201DAA T 00000195700000103000N0000000000000004CT1000100710071007
080449201DAA T 00000131000000107000N0000000000000005CT10031007
080449201DAA T 00000066600000089600N0000000000000006CT10041005
080449201DAA T 00000180200000105100N0000000000000007CT100310051009
080449201DAA T 00000132200000089700N0000000000000008CT100410051005
080449201DAA T 00000093500000089400N0000000000000009CT10031007
080449201DAA T 00000075100000105400N0000000000000010CT100410081006
080449201DAA T 00000031300000088700N0000000000000011CT1004100810081007
080449201DAA T 00000021800000105100N0000000000000012CT100410091005
080449201DAA T 00000191300000104500N0000000000000013CT10041006
080449201DAA T 00000124500000105100N0000000000000014CT1001100610071008

®
選択肢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” とはどういうことか:
vv
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 よりスケーラブル

®
コンバージド・アプリケーションのブループリント 
リアルタイム証券情報ストリーミング
vv
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

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

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (20)

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

Similar a Fast Data を扱うためのデザインパターン (20)

Más de MapR Technologies Japan

Más de MapR Technologies Japan (12)

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