Slide 1

Slide 1 text

イベントストリーミング入門 〜Apache Kafkaを活用した大規模リアルタイムデータ処理〜 2022年7月29日 Confluent Japan合同会社 シニアソリューションエンジニア 清水 亮夫

Slide 2

Slide 2 text

2 世界は変わってきています

Slide 3

Slide 3 text

新しいビジネスの現実 テクノロジーこそがビジネス イノベーションが必要なのは 生き残るため 昨日のデータ = 障害 モダンなリアルタイムデータ インフラストラクチャが必要 テクノロジーは サポート機能 イノベーションが必要なのは 成長のため “必要十分”なデータの鮮度は 昨日のデータ

Slide 4

Slide 4 text

「店舗」はソフトウェアに

Slide 5

Slide 5 text

「銀行」はソフトウェアに

Slide 6

Slide 6 text

「タクシー」はソフトウェアに 2 min

Slide 7

Slide 7 text

「自動車」はソフトウェアに

Slide 8

Slide 8 text

この変革を可能にするもの は何でしょうか。

Slide 9

Slide 9 text

クラウド 機械学習 モバイル Data in Motion 意思決定の再考 ユーザーエクスペ リエンスの再考 データの再考 データセンターの 再考

Slide 10

Slide 10 text

Data at RestはData in Motionに変わっていく 輸送機関 リアルタイムのセンサー 診断 運転手-乗客のマッチング 到着予想時刻のリアル タイム更新 銀行 不正使用の検出 取引・リスクの管理 モバイルアプリ / 顧客体験の向上 小売 リアルタイム在庫管理 リアルタイムPOS レポート パーソナライゼーション 娯楽 リアルタイムの リコメンデーション パーソナライズされた お薦め アプリ内決済

Slide 11

Slide 11 text

Data in Motionとは?

Slide 12

Slide 12 text

Data in Motionは エンタープライズ企業の 中枢神経系 Apache Kafka® はそのテクノロジー

Slide 13

Slide 13 text

「イベント」とはビジネスで起きていること 輸送機関 今岡さんの車の TPMSセンサーが午前 7時11分にタイヤの空気圧低下を検 知した Kafka 銀行 金曜日の午後3時47分に赤星さんが藤本さんに 3万円送金した Kafka 小売 金本さんが注文したデジタルカメラが午前 9時10分に配送された Kafka

Slide 14

Slide 14 text

Key Value

Slide 15

Slide 15 text

中枢神経系 一連のイベント・ストリームとしての業務, powered by Kafka 在庫情報 配送 レポート 注文 フロントエ ンド 小売業の例

Slide 16

Slide 16 text

Data in Motionの興盛 2010 Apache Kafka Confluentの創業者によって Linkedinで生まれる 2014 2021 80% のFortune 100 企業がApache Kafkaを信頼し、採 用

Slide 17

Slide 17 text

Apache Kafka® とは?

Slide 18

Slide 18 text

Apache Kafkaのコア機能 01 一連のイベントを Publish & Subscribe する 02 イベント・ストリーム を保存する 03 イベント・ストリーム を処理 & 解析する

Slide 19

Slide 19 text

“Everything is just a series of events.” - Apache Kafka

Slide 20

Slide 20 text

同じKafkaコインの表面と裏面 Client Broker

Slide 21

Slide 21 text

Producer: 最初のクライアント ポリシー 決済処理 アプリケーション テレメトリーデータ 書込み

Slide 22

Slide 22 text

Kafka Broker: 繊細だけどパワフル ローカルストレージ リテンション時間 書込み

Slide 23

Slide 23 text

Consumer: もう一方のクライアント データレコード レポート ダッシュボード 分析 後続処理 永遠に 繰り返す ポーリング

Slide 24

Slide 24 text

24 ● 長いブロックコマンドの連鎖を 断ち切る ● 同期アクションと非同期 アクションを区別する ● immutableなイベントレベルの ログによるトレーサビリティの 維持 ProducerとConsumerを分離する

Slide 25

Slide 25 text

Broker

Slide 26

Slide 26 text

Brokerの基本 ● ProducerはイベントをBrokerに送信 ● Brokersはイベントを受信して蓄積 ● Kafka Clusterは複数のBrokerを持つことが できる ● それぞれのBrokerは複数のTopic、 パーティションを管理

Slide 27

Slide 27 text

Brokerのレプリケーション Topic, パーティションの 論理セット

Slide 28

Slide 28 text

Topic ● 類似イベントを格納する名前付きコンテナ ○ システムには多くのTopicが存在する ○ Topic間でデータが重複することもできる ● イベントの耐久性のあるログ ○ 追記(Append)のみ ○ オフセットによるシークのみ可能で、インデックス化はされない ● イベントは不変 (immutable)

Slide 29

Slide 29 text

Topicのリテンション・ポリシー イベントをどれだけの期間保持する必要があるか ? • どれだけの期間 (デフォルト: 1週間) • Topic単位で設定 ○ もしくはBorokerのデフォルト値を使用 • 業務要件による決定 • コスト要因 • コンプライアンス要因 (例: GDPR)

Slide 30

Slide 30 text

Topicのコンパクション

Slide 31

Slide 31 text

Topic、パーティション、セグメント

Slide 32

Slide 32 text

セグメントの中身 - ストリーム 無限に続く一連のイベント 過去 未来 現在 ストリーム イベント

Slide 33

Slide 33 text

イベントの中身

Slide 34

Slide 34 text

クライアント

Slide 35

Slide 35 text

Producerのデザイン

Slide 36

Slide 36 text

Producerの保証

Slide 37

Slide 37 text

送達の保証

Slide 38

Slide 38 text

Javaによる基本 的なProducer

Slide 39

Slide 39 text

パーティショニングの戦略 なぜパーティショニングするのか ? • Consumerは何らかのキーで集計または結合する必要がある • Consumerは順序の保証が必要 • ストレージの効率化やインデックス作成のためのデータの集中化

Slide 40

Slide 40 text

Partition 0 Partition 1 Partition 2

Slide 41

Slide 41 text

Partition 0 Partition 1 Partition 2

Slide 42

Slide 42 text

Partition 0 Partition 1 Partition 2 1 4 7 2 5 8 3 6 9 #

Slide 43

Slide 43 text

Partition 0 Partition 1 Partition 2 1 2 3 4 5 7 6 8 9 #

Slide 44

Slide 44 text

Consumerのオフセット ここまで 読み込んだ

Slide 45

Slide 45 text

Consumerグループ 同じ グループID 自動 ロードバランス

Slide 46

Slide 46 text

Consumerの リバランス リバランス発生 リバランス発生 Consumer 追加! Consumer 削除!

Slide 47

Slide 47 text

.NET/C#による 基本的な Consumer

Slide 48

Slide 48 text

特別なクライアント

Slide 49

Slide 49 text

Sink Source KAFKA STREAMS KAFKA CONNECT KAFKA CONNECT Your App Kafka ConnectとKafka Streams

Slide 50

Slide 50 text

ストリーム処理のアーキテクチャをシンプルに DB CONNECTOR CONNECTOR APP APP DB STREAM PROCESSING CONNECTOR APP DB 2 3 4 現状では、3から5にわたる分散システムの構築・インテグレーション・管理が必要 1

Slide 51

Slide 51 text

KSQL は、イベントの取得、ストリーム処理、プッシュ/プルクエリの両方を単一のソリューション として提供します ストリーム処理のアーキテクチャをシンプルに DB APP APP DB PULL PUSH CONNECTORS STREAM PROCESSING STATE STORES KSQL 1 2 APP

Slide 52

Slide 52 text

1つのシステムで2種類のクエリに対応: ● Pushクエリ リアルタイムで変化するクエリ結果を 購読 (subscribe)する (ドライバーはどこにいて、到着予測時間はいつ?) ● Pullクエリ : 情報のポイントインタイムでの検索 (乗車運賃はいくら? ドライバーの名前は?) ストリーム処理のアーキテクチャをシンプルに

Slide 53

Slide 53 text

ストリームの世界に入門する敷居を下げる Kafka利用者の人口分布 コーディングの洗練度 コアJava開発者 Java/Scalaを使用しないコア開発者 データエンジニア、アーキテクトDevOps/SRE streams BI分析者

Slide 54

Slide 54 text

ハンズオンのご案内

Slide 55

Slide 55 text

7/30(土) 14時からハンズオンを行います! ZoomのURLが不明な際は、OSPNのSlackで 清水宛にDMください

Slide 56

Slide 56 text

ありがとうございました! Confluent: confluent.cloud Developer Site: https://developer.confluent.io/

Slide 57

Slide 57 text

No content