Cloud Native Database Meetup Japan #3 LT Cloud Native Kafka - KIP-405、KIP-500、及び関連KIPについて Shinichi Hashitani, Solutions Engineer, Jan-17, 2021. #CloudNativeDB

Cloud Native Kafka Kafka自体がCloud Nativeになるということ。 #CloudNativeDB

Cloud Native … You Mean Kubernetes?

Operator Custom Resource Container Runtime No Operator. Just containers and a chart. Pod

クラウドネイティブ技術は、パブリッククラウド、プライベートクラウド、ハイブリッ ドクラウドなどの近代的でダイナミックな環境において、スケーラブルなアプリケー ションを構築および実行するための能力を組織にもたらします。 このアプローチの代表 例に、コンテナ、サービスメッシュ、マイクロサービス、イミュータブルインフラスト ラクチャ、および宣言型APIがあります。 これらの手法により、回復性、管理力、および可観測性のある疎結合システムが実現し ます。 これらを堅牢な自動化と組み合わせることで、エンジニアはインパクトのある変 更を最小限の労力で頻繁かつ予測どおりに行うことができます。 Cloud Native Computing Foundationは、オープンソースでベンダー中立プロジェクト のエコシステムを育成・維持して、このパラダイムの採用を促進したいと考えてます。 私たちは最先端のパターンを民主化し、これらのイノベーションを誰もが利用できるよ うにします。 CNCF Cloud Native 定義 v1.0

Kafka itself becoming “Cloud Native”. Meaning, Kafka is more: - Architecturally Simple - Scalable - Tolerable to runtime failures

Is Kafka a database? ストレージエンジンとしてのApache Kafka #CloudNativeDB

Kafka? Kafka is a message broker…

Copyright 2021, Confluent, Inc. All rights reserved. This document may not be reproduced in any manner without the express written permission of Confluent, Inc. How Kafka is used in the real world 9 Durable Asynchronous Messaging 非同期通信によるイベント駆動モデル - KafkaはPullモ デル。Brokerがメッセージを長期保存出来るのでバッ クプレッシャー不要。 CQRS with Change Data Capture CRUD処理と参照 (検索) 処理を異なるサービス/スト レージで提供。異なるストレージ (e.g. RDBMSからサー チエンジン）間でデータを同期。 Command Query

Copyright 2021, Confluent, Inc. All rights reserved. This document may not be reproduced in any manner without the express written permission of Confluent, Inc. Kafka Keeps Data Consistent 10 customer login: abc order confirmed: #001 order updated: #002 customer login: efg order canceled: #003 Append-Only Immutable 1 2 3 4 5 6 8 7 10 9 11 12 1 2 3 4 5 6 8 7 Old New

Copyright 2021, Confluent, Inc. All rights reserved. This document may not be reproduced in any manner without the express written permission of Confluent, Inc. Kafka Is a Durable Storage 11 Broker 1 Topic1 partition1 Broker 2 Broker 3 Broker 4 Topic1 partition2 Topic1 partition3 Topic1 partition4 Topic1 partition1 Topic1 partition1 Topic1 partition2 Topic1 partition2 Topic1 partition3 Topic1 partition3 Topic1 partition4 Topic1 partition4

Kafka is… Distributed Commit Log Storage.

リバランスは業と受け入れる事

Today, I will introduce some Kafka Improvement Proposal

KIP-405 From Disk I/O to Network I/O #CloudNativeDB

Copyright 2021, Confluent, Inc. All rights reserved. This document may not be reproduced in any manner without the express written permission of Confluent, Inc. Segment 1 Segment 2 KIP-405 - Kafka Tiered Storage 16 KIP-405: Kafka Tiered Storage Segment 1 Segment 2 Segment 3 Active Segment Segment 1 Segment 2 Write Read Read Offset = earliest ● ComputeとStorageの密結合 ● 高速 - Disk I/O ● ログ保全コスト大 ● 障害時 - 大量データのリバランス ● ComputeとStorageの分離 ● 低速 - Network I/O ● ログ保全コスト小 ● 障害時 - 限定的なデータのリバランス

KIP-500 Goodbye, Zookeeper. #CloudNativeDB

Copyright 2021, Confluent, Inc. All rights reserved. This document may not be reproduced in any manner without the express written permission of Confluent, Inc. KIP-500 - Replace Zookeeper with a Self-Managed Metadata Quorum 18 KIP-500: Replace Zookeeper with a Self-Managed Metadata Quorum ● 別途Zookeeperクラスタ必要 ● Zookeeperで合意形成 ● Controllerがメタデータ提供 ZK ZK ZK ● 別途Zookeeperクラスタ不要 ● Controllerx3+で合意形成 ● Controllerがメタデータ提供

Copyright 2021, Confluent, Inc. All rights reserved. This document may not be reproduced in any manner without the express written permission of Confluent, Inc. KIP-595 - A Raft Protocol for Metadata Quorum 19 ● メタデータ合意 (Leader/Follower) ● Leader Election KIP-595: A Raft Protocol for Metadata Quorum メタデータの永続化ストアからログベースへ 元々Kafkaはユーザーデータ/メタデータのそれぞれ をログベースで行っており、Raftモデルとの親和性は 高い。メタデータは内部Topic __cluster_metadata にて管理。スナップショットとTopicを利用して迅速 にメタデータを復旧。

Copyright 2021, Confluent, Inc. All rights reserved. This document may not be reproduced in any manner without the express written permission of Confluent, Inc. KIP-630 - Kafka Raft Snapshot 20 KIP-630: Kafka Raft Snapshot 0からのState復旧 Controllerはメタデータログから状態 (State) を更新 しメモリに保存、合わせて永続化している。この Metadata Stateを再現する為にはログが必要だが、 ログは絶えず増えState再現にかかる時間も比例的に 増大する。 Active Controllerはあるコミットされた状態で定期 てにMetadata Storeのスナップショットを取得。 新たに参加 (新規/復旧) する新しいControllerはス ナップショットを始点として必要なオフセットからメ タデータログを消化しStateを再現する。

#CloudNativeDB @ShinHashitani