Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
Strimzi Kafka Operator を試す Part 3 / Try Strimzi...
Search
suzukiry
January 31, 2022
Technology
640
0
Share
Embed
Copy iframe code
Copy JS code
Copy link
Start on current slide
Strimzi Kafka Operator を試す Part 3 / Try Strimzi Part3
suzukiry
January 31, 2022
More Decks by suzukiry
See All by suzukiry
OpenShiftの内部レジストリって何?/What's OpenShift Image Registry
suzukiry
1
1.9k
Apache Kafka on Kubernetes 基礎編 ワークショップ QA 2022-01-12 / Apache Kafka Workshop QA 2022-01-12
suzukiry
0
120
GitOps と Apache Kafka Part 1 / GitOps and Apache Kafka Part 1
suzukiry
0
330
Strimzi Kafka Operator を試す Part 2 / Try Strimzi Part2
suzukiry
0
390
Apache Kafka on Kubernetes 基礎編 ワークショップ QA 2021-11-24 / Apache Kafka Workshop QA 2021-11-24
suzukiry
0
160
Apache KafkaとKubernetes / Kafka and K8s
suzukiry
1
1.6k
Other Decks in Technology
See All in Technology
誤解だらけの開発生産性 / Myths and Misconceptions about Developer Productivity
i35_267
1
240
穢れた技術選定について
watany
3
320
Gen3R: 3D Scene Generation Meets Feed-Forward Reconstruction
spatial_ai_network
0
120
依頼文化をやめる日 EM視点で語るPlatform EngineeringとInclusive SRE / Discussing Platform Engineering and Inclusive SRE from an EM's Perspective
shin1988
4
5.3k
インフラと開発の垣根を超えていき!〜元AWSインフラエンジニアがAWS開発で奮闘している話〜
hatahata021
1
160
AI駆動開発におけるQAエンジニアの役割事例 〜AI駆動開発の現場から〜
kobayashiyorimitsu
0
500
ruby.wasmとPicoRuby.wasmに対応した仮想DOMライブラリを作ってる話 #kaigieffect_kaigi
sue445
PRO
0
140
AICoEでAIネイティブ組織への進化
yukiogawa
0
160
AIレビューはどこまで任せられるのか?自動化と人が背負うレビューの境界
sansantech
PRO
2
730
最適な自走を最小限の支援で — M&Aで拡大する組織で少人数SREが挑んだ1年 / SRE NEXT 2026
genda
0
1.1k
なぜ私たちのSREプラクティスはなかなか機能しないのか 〜システムより先に組織を見る〜 / Why our SRE practices aren't really working
vtryo
3
3.6k
SRE依存からの脱却 運用を開 発チームへ移す、 フルサイ クル開 発体制の実践
joooee0000
0
2.7k
Featured
See All Featured
Agile Actions for Facilitating Distributed Teams - ADO2019
mkilby
0
220
Sharpening the Axe: The Primacy of Toolmaking
bcantrill
46
2.9k
Information Architects: The Missing Link in Design Systems
soysaucechin
0
1k
Collaborative Software Design: How to facilitate domain modelling decisions
baasie
1
260
Speed Design
sergeychernyshev
33
1.9k
Connecting the Dots Between Site Speed, User Experience & Your Business [WebExpo 2025]
tammyeverts
11
970
The Pragmatic Product Professional
lauravandoore
37
7.4k
svc-hook: hooking system calls on ARM64 by binary rewriting
retrage
2
330
Being A Developer After 40
akosma
91
590k
Code Review Best Practice
trishagee
74
20k
Easily Structure & Communicate Ideas using Wireframe
afnizarnur
194
17k
How to build an LLM SEO readiness audit: a practical framework
nmsamuel
1
800
Transcript
Strimzi Kafka Operator を試す Part 3 Kafka Connect - 補足資料
-
Kafka Connect
Kafka Connect とは • Apache Kafkaと外部システム、例えばデータベース、ストレージ、メッセージングシ ステムとを連携することができるKafkaのエコシステムに含まれるコンポーネントで す。 • 外部システム
→ Kafka へ連携:Source と呼ぶ • Kafka → 外部システムへ連携:Sink と呼ぶ ETL処理で言う Extract相当 ETL処理で言う Load相当
Kafka Connect を使う理由 • スケーラブル ◦ Kafka のクラスタ上で動作することとから、Kafka Brokerと同じくスケーラビリ ティと信頼性を維持しながら、大量のデータをKafkaのBrokerへ出し入れする
ためのフレームワークを提供。 • Zero-Code Streaming Pipeline ◦ “For Kafka Connect no coding is required. Just write configuration files”と 言われているように、Kafka Connectのフレームワークを利用し、提供プラグイ ンを利用することで、分散処理・管理の開発をKafka Connect自体に任せてし まうことができる。
Kafka Connect 分散処理の仕組み 1. Worker • ConnectorとTaskを実行するプロセス 2. Connector: •
タスクの作成を担当。 3. Task: • 実際にデータをコピーするアクター。状態は専用トピックで管理され、耐障害性も考慮。 REST API、設定管理、信 頼性、高可用性などを担 当 データ移動を担当 Kafka Connectのメリットは、これらの障害処理を担当してくれ るところ。コネクタを作成する場合は、作成にのみ 注力できるのが良い。 Worker Connector Task Worker-1 Connector-1 Task-1 (Conn1) Task-2 (Conn1) Worker-2 Connector-2 Task-3 (Conn1) Task-1 (Conn2) Worker-3 Taskの数は、tasks.maxによって指定。 全クラスタノード上でいくつの Taskかを決める。 Thread JVM Process https://www.slideshare.net/vitojeng/streaming-process-with-kafka-connect-and-kafka-streams-80721215
Note: 分散処理の仕組み - パラメータ:tasks.max • Connectorで作られるタスク数の最大数 ◦ Source Connector の場合はその対象(テーブル、ファイルなど)、
Sink Connector の場合はTopic のPartition数を気にしながら設定すべき。 ◦ Source の場合 ▪ テーブル毎の割り当て • テーブルx3・タスクx3であれば、各タスクで 1テーブルを担当する。 • テーブルx6・タスクx2であれば、各タスクで 3テーブルを担当する。 • テーブルx1・タスクx2であれば、1タスクのみ1テーブルを担当する。(つまり別の 1タス クは無駄になる) ◦ Sink の場合 ▪ 対象Topicのパーティション数次第。 • Sink タスク(=Consumer)は Partition の数より多く持つことができない。 • 高スループットにしたい場合は、パーティション数 =タスク数( パーティション数<タスク 数だとアイドルするだけ ) • パフォーマンスを下げて良い場合は、 パーティション数>タスク数 の設定もOK.
Kafka Connect の機能 Producer Kafka Connect (Source) Connector Kafka Cluster
SMTs Converter Kafka Connect (Sink) Converter Kafka Cluster SMTs Connector Consumer/ App 1. Connector 対象のデータストアへの接続を担う 2. SMT(Single Message Transformations) フィルタやメタデータの追加などが行う 3. Converter データのシリアライズ・デシリアライズを行う
Note: SMTs (Single Message Transformation) • 各メッセージに対して変換処理を行う機構 ◦ 複数メッセージの結合や Joinは行えない(ここはKafka
Streamsが担当) • 主な変換処理の例 ◦ フォーマット変換 ▪ Timestamps ▪ Value masking ▪ Numeric types ▪ Name adjustments ◦ フィルター・ルーティング ▪ Source Connector が書き込む Topic 名や、Sink Connector がターゲットに作成するオブ ジェ クト名を変更したい場合、 RegExRouterが使える。 ◦ スキーマの一貫性の確保 ◦ Tombstoneハンドリング https://www.morling.dev/blog/single-message-transforms-swiss-army-knife-of-kafka-connect/
Kafka Connect の起動 1. プラグインが、Sink Connector を提供 2. 1つのWorkerが Sink
Connector のインスタンスを 起動 3. Sink Connector は、データをストリームするための Task を作成 4. Task は並行して実行され、 Kafkaをポーリングして メッセージを取得 5. Transform で、必要に合わせてメッセージを調整 (SMTのところ) 6. Converter は、メッセージをKafka Brokerに適した形 式に変換 7. Source Connectorは、Kafka Connect API または KafkaConnectors を使用して管理します。 参考:https://strimzi.io/docs/operators/latest/overview.html
Kubernetes & Operatorでの実行方法の違い • Non-Kubernetes の場合 1. Workerの立ち上げ(スタンドアロンor分散モード) ▪ クラスタ構成を指定。
2. ConnectorをREST APIで起動 ▪ コピー対象のDB・テーブル、タスク数を指定。 ▪ ここでの設定によって、タスクがどのテーブルを担当するのかが決まる。 ※タスクの起動は、Connectorが勝 手に行う。 • Strimzi Operator を使う場合 1. KafkaConnect カスタムリソースの作成 ▪ Strimziが裏でクラスタを作ってくれます。 2. KafkaConnector カスタムリソースの作成 ▪ KafkaConnector カスタムリソースに利用したいプラグインやタスク数の設定を記載します。 ▪ Strimziが裏でREST APIでの設定部分を補ってくれます。 Connector 設定もKubernetesライクに設定すること ができます。
Kafka Connect の商用サポート • Kafka Connectのコネクター ◦ 自前で作成する or ◦
オープンソースを使う or ◦ 商用サポートされているものを使う • 各社のConnectorのサポート ◦ Red Hat (Debezium, Camel Kafka Connector) ◦ Cloudera (HDFS Sink Connector、Amazon S3 Sink Connector) ◦ Confluent (120+ものConnectorを取り揃えている [1]) ◦ Amazon MSK ? ◦ Heroku ? それぞれ商用サポートするコネクターは異なる。 なので、使用したいコネクターのサポートをそれぞれ確認することが大事。 [1] https://www.confluent.io/product/connectors/#commercial
Debezium • Apache Kafka の Kafka Connect(Source側) を利用 • 複数のデータベース向けのチェンジデータキャプチャ
◦ トランザクションログベース ◦ スナップショット、フィルタリング などの用途にも利用 参考:https://debezium.io/documentation/reference/stable/architecture.html
オープンソースの範囲 • MySQL • PostgreSQL • SQL Server • Mongo
DB • Db2 • Oracle • Cassandra • Vitess Debeziumのサポート Note: ←2021年12月時点でDev Preview からTech Previewへ。GAはまだです が、大きく期待 Red Hat Integration の範囲 • MySQL • PostgreSQL • SQL Server • Mongo DB • Db2 • Oracle • Cassandra • Vitess
環境
my-kafka-project 構成図 kafka-operator my-cluster3 tls-sidecar Zookeeper topic-operator user-operator tls-sidecar connect-
cluster Consumer Strimzi- kafka- operator message message 名前空間 kafkaconnect kafkaconnector kafka License (送信用ファ イル)
その他
AMQ Streams • Apache Kafka のエンタープライズ向けディストリビューション ◦ 2018年から Kafka をサポート、Kubernetes
上でも提供 (Strimzi) ◦ Red Hat AMQ Streams としてローンチ • 提供形態 ◦ Red Hat Enterprise Linux ◦ Red Hat OpenShift Container Platform Apache Kafka on Kubernetes 基礎編 ワークショップ: https://redhat-open.connpass.com/ Strimzi/AMQ Streamsをハンズオンをしてみたい
Thank you