え、まって。その並列分散処理、Kafkaのしくみでもできるの？ Apache Kafkaの機能を利用した大規模ストリームデータの並列分散処理

© 2019 NTT DATA Corporation
【テクノロジー】
え、まって。その並列分散処理、Kafkaのしくみでもできるの？
～Apache Kafkaの機能を利用した大規模ストリームデータの並列分散処理～
NTTデータ技術革新統括本部システム技術本部生産技術部
インテグレーション技術センタデータ活用チーム
佐々木徹
2019/09/05 NTTデータテクノロジーカンファレンス 2019

2 © 2019 NTT DATA Corporation
氏名/所属
– 佐々木徹（ささきとおる)
– NTTデータ技術革新統括本部システム技術本部生産技術部インテグレーション技術センタ
業務内容
– Apache Spark, Apache Kafkaの導入や技術サポートなど
オープンソースへの貢献
– 複数のオープンソースプロダクト(Hadoop, Spark, Kafkaなど)へパッチを投稿
著書/外部発表
– 翔泳社「Apache Kafka」、「Apache Spark入門」(共著)
– Strata Data Conference New York 2018
自己紹介

3© 2019 NTT DATA Corporation
このセッションのおはなし

© 2019NTT DATA Corporation 4
Apache Kafkaとストリーム処理
導入

Apache Kafkaとは
複数台のサーバで多くのストリームデータを処理する分散メッセージングシステム
・・・・・・
都度送られてくるメッセージ（データ）を受け取り必要に応じて受け取ったメッセージ（データ）を都度送る

 生成されたデータを受信次第、逐次処理を行っていく処理方式
ストリーム処理とは
ストリーム
処理
データ生成元データ利用先収集
すぐに処理データを受け取って
処理
データ生成元データ利用先
バッチ処理
保存
まとめて処理データを貯めて
(参考)
日次、月次など

 Kafkaで受け取り、後続の処理基盤で処理を行う
Apache Kafkaを用いたストリーム処理
Kafka Streams
データの流れ
データ生成収集・受け渡し処理
 複数個所からデータを収集する場合でも処理が行いやすい
 データ量/収集箇所などが変化した場合でも処理基盤に影響を与えにくい
 障害時の再処理などを行いやすくしてくれる
 Kafkaの送達保証などによりデータの扱いを容易にしてくれる
Kafkaを間に挟む利点

 処理基盤には分散管理機能をもつものとKafkaのAPIを利用するものが存在
このセッションでお話しするストリーム処理の実行方式
このセッションではKafka APIやKafka Streamを用いるストリーム処理について紹介します
分散管理機能をもつ処理エンジン
代表的なもの特徴など
 Kafkaの機能に依存せず、自前の方式で分散処理を行う
 自前の分散機構を備え、その上で実行される
 それぞれのAPI/フレームワークに沿ってAPを開発する
KafkaのAPIを利用するアプリケーション
実装方法特徴など
 Kafkaの機能を生かして分散処理などを実現している
 スタンドアロンのAPやコンテナ上で動作するAPとして実行される
 Pure Javaや一般的なAPフレームワークを利用してAPを開発する
Kafka APIを利用したAP
Kafka Streamsを利用したAP
 Kafka以外への対応が容易
 バッチ処理などとの共通化が
可能なケースもある
 専用の分散基盤を必要としない
 コンテナ化によって他の基盤などと
共通化を図れるケースもある

本題に関連するApache Kafkaの概念
前提知識の
確認

Kafkaの構成要素
“ Producer ” “ Consumer ”
（ ZooKeeper ※ ） ※分散処理ソフトウェアの管理に用いられるOSSのミドルウェア
（Kafkaクラスタ管理で利用）
・・・・・・
“ Broker ”
Kafkaにメッセージを送信する
クライアント
Kafkaからメッセージを受信する
クライアント
Kafkaクラスタを構成する
サーバ

Kafka内部の論理構造
各Replicaがそれぞれ違うBrokerに配置される
Kafkaクラスタ
Topic C
Topic B
Topic A
Partition 1
Replica1 Replica2 Replica3同期
Partition 0
Replica1 Replica2 Replica3
part.1 part.1 part.1
part.0 part.0 part.0
・・・P.0 R.1 P.1 R.1 P.0 R.2 P.1 R.2 P.0 R.3 P.1 R.3
Kafkaクラスタ上に作られる
メッセージの論理的な入れもの
分散処理のために
Topicを分割する単位
耐障害性のために作られる
各Partitionの複製
Topic
Partition
Replica
同期
同期同期
…

メッセージ送信時のPartitionへの振り分け
Producerが対象とするTopicのいずれかのPartitionにメッセージを振り分けてから送信する
→ Partitionが各Brokerに分散して配置されていることで分散処理を実現する標準では各メッセージの内容をみて
いずれのPartitionに振り分けるか判断
Producer
Topic
Partition 0
Partition 1
Partition 2
Partition 3
Partition N -1
…
Kafkaクラスタ
Producer
……
Partition 0
Partition 3
Partition 1
Partition 2
…
Producer側で
割り振りを決定して
適切なPartitionに送る
Partitionが各Brokerに
分散して配置されていれば
メッセージが各Brokerに
分散される
Broker
Broker
Broker

 1つ以上のConsumerで構成されるConsumerの集合のこと
Consumer Group
Consumer Group○○
性質・利点
 同じConsumer Groupに属すConsumer同士で分散してメッセージを受信する
 どのConsumer Groupに属すかは基本的に各Consumerの自己申告で決まる
Consumer
Consumer
Group○○
Group○○
Group○○
Consumer
Group△△
Group△△
同じGroup名を申告したConsumerが
まとまって1つのConsumer Groupを形成する
異なるGroup名を申告したConsumerは
異なるConsumer Groupを形成する
①
②
③
同じConsumer Groupに属す
Consumer同士で分散して受信する
(各メッセージはいずれか1つの
Consumerが受信)
①
②
③
異なるConsumer Groupに属する
Consumerは他のGroupとは関係なく
それぞれメッセージを受信する

 各Partitionごとに受信(処理)するConsumerが1つずつ割り当てられる
 各Partitionごとに必ず1つのConsumerが割り当てられるが、
1つのConsumerには複数のPartitionが割り当てられることがある
 Partition数より多いConsumerが存在しても、Partitionが割り当てられずメッセージを受信できない
 Consumer Group内のConsumerが増減した場合は直ちにPartitionの再割り当てが行われる
Consumer Groupのメッセージ受信のしくみ
Topic Partition 0
Partition 1
Partition 2
Partition 3
Partition N-1
・
・
・
Consumer
Consumer
Consumer
Consumer Group
各PartitionごとにConsumerが1つだけ割り当てら
れるので、Consumer Groupの中でいずれか1つ
のConsumerのみが受信することが保証される

 Consumer Groupに属するConsumer数が変化したときはPartitionの再割り当てが行われる
 障害発生、意図的な増加・減少に関わらず、すべて同じ動作をする
Consumer Groupに属するConsumerの数が増減したときの挙動
Topic Partition 0
Partition 1
Partition 2
Partition 3
Partition N-1
・
・
・
Consumer
Consumer
Consumer
Consumer Group Topic Partition 0
Partition 1
Partition 2
Partition 3
Partition N-1
・
・
・
Consumer
Consumer
Consumer
Consumer Group
障害などでConsumer数が減少したとき拡張などでConsumer数が増加したとき
Consumer
New！
障害などで停止したConsumerを除いて再割り当てされる新しく増えたConsumerも含めて極力均等に再割り当てされる

 Kafkaの構成要素
 Broker/Producer/Consumer
 Kafkaの論理構成
 Topic/Partition/Replica
 メッセージを送信するPartitionはProducerが決定する
 Consumer Group
 同じグループに属するConsumer間で分散してメッセージを受信する
 グループ内のConsumer数が増減した際は直ちにPartition-Consumerの再割り当てが行われ
る
おさらい: 確認した関連するKafkaの概念

© 2019 NTT DATA Corporation 17
Apache Kafkaのしくみを利用した
分散処理によるストリーム処理
本題

 処理を行う際にそれまでの状態(ステート)を必要とする処理かどうか
ステートレスな処理とステートフルな処理
ステートレスな処理ステートフルな処理でそれぞれどうなるかを見ていきましょう
ステートレスな処理: ステート(状態)を保持せず、入力メッセージを基にした処理を行う
処理の例: アプリケーションログの異常検知(エラーログのリアルタイム検知)
(出力)
APサーバ Kafka
ストリーム処理
(エラーログ検知)
都度入力されたAPログの文字列などのみを確認し、
前回の確認結果などの状態は保持・利用しない
APログ APログ検知結果
ステートフルな処理: ステート(状態)を保持して、処理の際にステートを参照・更新する
処理の例: Webサイトにおけるユーザの多重ログインの検知
(出力)
APサーバ Kafka
(多重ログイン検知)
検知結果
ログイン
情報
ログイン
情報
多重ログインかどうかを識別するために、
各ユーザのログイン状態を保持・更新・参照している

 並列分散処理を行うプロセスやコンテナをすべて同じConsumer Groupに属するようにする
ステートレスなストリーム処理の並列分散処理
対象のプロセスやコンテナ群を同じConsumer Groupで起動させることで
Kafkaのしくみを利用した並列分散処理を実現することができる
データソース
(データの生成元)
並列分散処理を行う
プロセスまたはコンテナ
Group○○
Group○○
Group○○
Group○○
Consumer(プロセス/コンテナ)を
すべて同じConsumer Groupに設定する
Consumer Group内で分散してメッセージを
受信するため、処理もまた分散されることになる
ステートレスな処理のため、
Group内のいずれのConsumer(プロセス/コンテナ)で
処理されても問題ない(ステートとの関係を意識しなくてよい)

 Consumer Group内で処理Partitionの再割り当てが行われ、他のプロセスが処理を引き継ぐ
ステートレスな処理のプロセスやコンテナに障害が発生したとき
同じConsumer Groupに属す複数のプロセスやコンテナが存在していれば、
一部に障害が発生した際に他の正常なプロセスやコンテナが引き継いで処理を継続できる
障害によってプロセス/コンテナが停止するため、
Consumer Groupに属するConsumerの数が減少し、
Consumer Group内での再割り当てが発生する
障害が発生したプロセス/コンテナに
割り当てられていたPartitionも含め再割り当てが行われるので、
結果的に障害が発生したプロセス/コンテナの処理を
正常なものが引き継ぐようにみえる
データソース

 障害が発生したときと同様にConsumer Group内で再割り当てが行われる
並列分散処理のプロセスやコンテナがオートスケールなどで増減した場合
オートスケールなどで処理プロセスやコンテナが増えた場合でも、
既存のものと同じConsumer Groupに属していれば再割り当てされて自動的に処理に加わる
オートスケールなどによって
プロセス/コンテナが増加/減少するため、
Consumer Groupに属するConsumerの数が変化し、
Consumer Group内での再割り当てが発生する
Consumer Group内の再割り当ての際に、
増加・減少したプロセス/コンテナも考慮されるため、
新たに追加したものも同じConsumer Groupに属していれば
メッセージを受信し、並列分散処理に加わる
データソース
New！

 ステートレスの項目に加え「処理プロセスの割り当て」と「再割り当て時のステート」の考慮が必要
ステートフルなストリーム処理の並列分散処理
Kafkaのしくみを利用したり、構成を工夫することで対応することができる
処理プロセスの割り当て再割り当て時のステート
ステートを保持しているプロセス/コンテナ上で
適切にメッセージの処理を行うように
Consumer Group内の再割り当てが起きた際に、
新たな割当先が適切なステートを有するように
例: ユーザ単位でステートを保持しているとき
保持している
ステート(状態)
ユーザ〇
ユーザ△
ユーザ□
保持しているステートに対応した
メッセージを送信しなければならない
(ここではユーザごとに適切に振り分ける)
〇
△
□
保持している
ステート(状態)
ユーザ〇
ユーザ△
ユーザ□
ユーザ△
再割り当て時に、
新たな割り当て先に
同様にステートが
存在する必要がある
移動？
〇
△
□
例: ユーザ単位でステートを保持しているとき

 ステートを保持する単位で関連メッセージが同一Partitionに割り当てられるようにする
ステートフルな処理でステートを保持するプロセス/コンテナで処理させるための対応
Kafkaへのメッセージの送信時に送信先のPartitionを工夫することで、
ステート(状態)を保持する単位で処理を行うプロセスやコンテナを統一できる
Consumer Group内の各ConsumerはPartition単位で割り当てられるので、
各ステートに関連するメッセージが必ず同じConsumer(プロセス/コンテナ)に取得され、処理される
ステートの単位(ここではユーザ)ごとに
同じPartitionに割り当てられるように
Producerからメッセージを送る
データソース
プロセスまたはコンテナ保持している
ステート
ユーザ〇
ユーザ△
ユーザ□
Kafkaクラスタ
Topic
Partition 0
Partition 1
Partition 2
…
〇
△
□
□
△
〇
□
△
〇
Partition単位の割り当てなので、
ステートの単位ごとに必ず
同じプロセスに送られる
割り当てられた
Partitionに
対応するステートを
保持して処理を行う

 処理途中の状態を適切なタイミングで外部(プロセス/コンテナ外)に保存しておく
ステートフルな処理でConsumer数の増減が発生することへの対応
ステート(状態)は適切なタイミングでプロセス/コンテナの外部に保存しておき、
Partitionの再割り当てに時に必要なステートを取得して処理を再開させる必要がある
Consumer Group内で再割り当てが発生した際に、
外部に保存してある必要なステートを取得して、正しく処理を再開することができる
プロセスまたはコンテナ保持している
ステート
ユーザ〇
□
△
〇
Kafkaクラスタ
外部データストア
(KVSなど)ユーザ△
ユーザ□
ユーザ△
通常時(再割り当て発生前)から
定期的(※)に外部のデータストアに
各ステートを保存しておく
再割り当てが起きた後、
新たに必要になったステートを
取得してから処理を再開する
※ Offset Commitの実行時に
前回から更新があったら保存する

 Consumer Rebalanceが起きた際に任意の処理を実行させる機能
 Consumer Rebalance: Consumer Group内のPartitionの再割り当てのこと
関連機能1: Consumer Rebalance Listener
新たなPartitionの割当: 〇, …
新たなPartitionの割当: △, …
新たなPartitionの割当: □, …
処理
処理
処理
Consumer Rebalanceが発生すると
新たなPartitionの割り当てと共に
Consumerに通知される
通知を受けたConsumerは
事前に設定された処理を実行する
適切な処理をConsumer Rebalance Listenerで実装しておくことで、
再割り当て時のステートの取得などを実行させることができる
※ 実際にはConsumer側からKafkaクラスタにRebalanceについてPollingしているが、
ここではAPIの利用方法のイメージとしてConsumerに通知していると表現

 ステートをKafka自体に記録して利用するための機能
 Kafkaのメッセージングを利用したKafka Streamsの標準機能
関連機能2: Kafka StreamsのState Store
Kafka Streams以外にもステートを管理する
機能をもつストリーム処理エンジンは存在
通常処理時
新たなステートの取得が必要になったとき
※ 設定/実装によります
Kafka
クラスタ
(Topic)
処理対象データ
ステート記録
(Topic)
ストリーム処理AP
(Kafka Streams)
State Store
参照・更新・削除
メッセージ取得
ステート変更情報送信
(処理結果)
メモリやローカルディスクに
ステートデータを保持し、
変更があったらKafkaに記録
Kafka
クラスタ
(Topic)
処理対象データ
ステート記録
(Topic)
ストリーム処理AP
(Kafka Streams)
State Store
参照・更新・削除
ステート変更履歴の取得
ステート変更履歴を取得し、
最新のステートの状態を復元
障害/オートスケールの影響による
再割り当てで新たなステートが必要になった

Apache Kafkaのしくみを利用した
分散処理によるストリーム処理の注意点
発展

 現在のConsumer Group内のPartitionの再割り当ては一度全ての割り当てを外してから行われる
Stop-the-world Rebalance Protocol
Partition割当: 〇、…
Partition割当: △、…
Partition割当: □、…
Partition割当: ◇、…
(再割り当て実行前)
Partition割当: 〇、◇、…
Partition割当: △、…
Partition割当: □、…
(再割り当て完了)
割り当てなし
割り当てなし
割り当てなし
②増減したConsumer以外も含め
一度すべての割り当てを外す
③Consumer Groupに属す全て
のConsumerに割り当てる
①一部Consumerの障害などで
Consumerの数が増減する
この間、全てのConsumerのメッセージ受信が停止する
Consumer Group内のPartitionの再割り当ての間は全Consumerのメッセージ取得が停止する
(Stop-the-worldの由来)
×(障害のため停止) ×(障害のため停止)
障害
発生

 Consumer Groupに属するConsumerが多い場合や、Consumerの増減が多い場合に顕著に影響がある
Stop-the-world Rebalance Protocolが特に問題になる場合
1つのConsumer Groupに属するConsumerが多いとき
頻繁にConsumerの増減が発生するとき
 1回の再割り当て影響範囲が大きい(環境によっては数100～数1000のConsumerが存在することも)
 障害などの発生確率が上がり、Consumer増減の発生確率が上がる
1つのConsumerの障害が停止で同
じConsumer Groupに属する全ての
Consumerの処理が一時停止する
…
Consumer Group
 頻繁に発生すると累積の停止が増え、結果的にスループットが低下する
 オートスケールなどを利用している場合は影響が顕著(特に複数コンテナなどが同時に起動する場合など)
問題
など
問題
など
関連
時間経過
減少増加減少増加
★
一時停止
★
一時停止
★
一時停止
★
一時停止
★
一時停止
頻繁にConsumerの増減が起きる
Consumer Groupでは再割り当ての
一時停止も頻繁に起きる

 Topicを手動で細分化し、それぞれに対応するConsumer Groupを作成
Stop-the-world Rebalance Protocol問題へのワークアラウンド
Consumer Group内に属するConsumerの数を少なくすることで影響を軽減
Kafkaクラスタ
…
Consumer Group
データ
生成元
Topic
Topic
Topic
…
…
ワーク
アラウンド
通常は1つのTopicと
1つのConsumer Groupで
1つのストリーム処理を構成
1つのストリーム処理に対して
複数のTopicと対応する
Consumer Groupを用意して細分化
Kafkaクラスタ
Topic …
Consumer Group
標準データ
生成元
Consumer Groupを細分化することで
 各Groupの内のConsumerの増減を
相対的に減らせる
 再割り当て時の影響範囲を
限定的にできる

 Incremental Cooperative Rebalancing という方式が提案されている(KIP-429で実装を議論)
Stop-the-world Rebalance ProtocolへのKafka開発コミュニティの対応
参考1: https://cwiki.apache.org/confluence/display/KAFKA/Incremental+Cooperative+Rebalancing%3A+Support+and+Policies
参考2: https://cwiki.apache.org/confluence/display/KAFKA/KIP-429%3A+Kafka+Consumer+Incremental+Rebalance+Protocol
再割り当て(Rebalance)に関連するPartitionを3つに区分してそれぞれ処理を実施
(引用:https://cwiki.apache.org/confluence/display/KAFKA/KIP-429%3A+Kafka+Consumer+Incremental+Rebalance+Protocol)
Rebalance後に
新たに割り当られるPartitionRebalance後に
割り当てられなくなるPartition
Rebalance前後で
割り当てが変化しないPartition

クロージング

 Kafkaの機能を活用した分散処理によるストリーム処理について紹介
 Kafkaを利用したストリーム処理
 関連するKafkaの基本的な概念
 ProducerとConsumer
 TopicとPartition
 Consumer Group
 Kafkaのしくみを利用した分散処理によるストリーム処理
 ステートレス処理とステートフルな処理
 Kafkaのしくみを利用した分散処理の注意点
 Stop-the-world Rebalance Protocol問題
本セッションのまとめ

 処理に関連する基盤全体での検討や見通しをあらかじめよく検討しておくことが重要
 一部の設計や構成が他の箇所に広く影響を与えることはストリーム基盤では珍しいことではない
 本セッションで紹介したものにも構成に広く影響がでるものがいくつかあった
メッセージ: Kafkaを利用する基盤の検討時に意識していただきたいこと
処理速度やスループットが
特に重要な基盤のため
ステートフルな処理をKafkaの後続で行う
ために、Kafkaの前段の基盤に影響
(Partitionの選定)がある例
特定の領域に閉じて検討せずに、全体を見渡してアーキテクチャなどの検討を行う必要がある

え、まって。その並列分散処理、Kafkaのしくみでもできるの？ Apache Kafkaの機能を利用した大規模ストリームデータの並列分散処理

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (20)

Ähnlich wie え、まって。その並列分散処理、Kafkaのしくみでもできるの？ Apache Kafkaの機能を利用した大規模ストリームデータの並列分散処理

Ähnlich wie え、まって。その並列分散処理、Kafkaのしくみでもできるの？ Apache Kafkaの機能を利用した大規模ストリームデータの並列分散処理 (20)

Mehr von NTT DATA Technology & Innovation

Mehr von NTT DATA Technology & Innovation (20)

え、まって。その並列分散処理、Kafkaのしくみでもできるの？ Apache Kafkaの機能を利用した大規模ストリームデータの並列分散処理

Hinweis der Redaktion