High SLA Kafka - Kafka Across Multiple DCs Shinichi Hashitani, Solutions Engineer, Dec. 2022 #kafkajp

Kafka Internals #kafkajp

Control Plane and Data Plane Kafka Cluster Broker Broker Data Plane Broker Broker Controller Broker Broker Zookeeper Zookeeper Zookeeper Control Plane ● Cluster Membership ● Broker and Controller ● Topic Partition and Partition Leader ● Access Control List 3

Inside The Apache Kafka Broker Broker Broker Broker Broker Broker Broker 4

Network Thread Adds Request to Queue 5

IO Thread Verifies Record Batch And Stores 6

Kafka Physical Storage /var/lib/kafka/data/account-deposits-1 00000000000047926734.log 00000000000047926734.index ... 00000000000052497535.log 00000000000052497535.index ... 7

Purgatory Holds Requests Being Replicated 8

Response Added to Socket Send Buffer 9

The Nature of Multi DC and Availability #kafkajp

RPO and RTO Recovery Point Objective (RPO) 障害が発生した場合に、フェイルオーバーによってデータの履歴の どの時点から再開する必要があるかを表す。障害の発生時に許容で きるデータの損失量と言い換えることもできる。RPO をゼロにする には、同期レプリケーションが必要。 Recovery Time Objective (RTO) 障害が発生した場合に、フェイルオーバーの完了までに許容される 経過時間を表す。フェイルオーバー操作にかかる時間。RTO をゼロ にするには、シームレスなクライアントフェイルオーバーが必要。 11 ZERO RPO requires synchronous replication ZERO RTO requires seamless failover

Stretch Cluster and Replication Stretch Cluster クラスタ自体が物理的なDCを跨いで構成される。RPO=0との要件が ある場合には必須の構成となり、低いDC間のネットワークレイテン シが必要となる。 Replication アクティブクラスタのデータを全体/部分的にワームクラスタに連携 する。より一般的な手法であり、アプローチは様々あるが、 Replicationの利用単体ではRPO=0とはならない。 12 ZK ZK ZK Tokyo ZK ZK Osaka ZK ZK ZK Tokyo ZK ZK ZK Osaka

High Availability and Disaster Recovery どのような構成であっても単体のKafkaクラスタのSLAには 限界があり、またSLA要件に限らず災害時の復旧について は計画が必要となる。 大きく分けて3つのアプローチが考えられる： Active-Active - 2DCのクラスタが共にリクエストに応える 構成とする。 Active-Warm - アクティブなDCに対し、データは何かしら の形でパッシブなDCに連携する。 Active-Passive - DRクラスタを構成するがデータは連携 しない。 13 ZK ZK ZK ZK ZK ZK ZK ZK ZK ZK ZK ZK ZK ZK ZK ZK ZK ZK

DC Failure and Split Brain DC Failure DC全体が障害の為完全に機能しない状態。復旧まで他のDCで全ての リクエストを受け付ける必要がある。 Split Brain アクティブなクラスタ同士が互いに通信が出来なくなった状態。一 方のみ稼働し続ける状態を保つ必要がある。 14 ZK ZK ZK Tokyo ZK ZK Osaka ZK ZK ZK Tokyo ZK ZK Osaka

Replication #kafkajp

Kafka Cluster B Kafka Cluster A Broker Broker L p0 Broker F p0 Broker F p0 F p0 F p0 L p0 Broker Broker Replication (MM2, uReplicator, Confluent Replicator) leader L follower F 16 Tokyo Osaka ● 基本的にはConsumer/Producer ● Offset Translation等ツールによってサポートはまちまち ● Consumer Rag = Replication Rag

Confluent Cluster Linking Destination Cluster Broker Source Cluster Broker L p0 Broker F p0 Broker F p0 F p0 F p0 L p0 Broker Broker Broker Broker leader L follower F 17 Tokyo Osaka ● Broker同士の通信でレプリケーション (Replica Fetcher) ● 低レイテンシ ● Offset Preservation (全てそのままミラーリング)

Replication Patterns 18 Tokyo Osaka tokyo-topic osaka-topic osaka-topic-mirror tokyo-topic-mirror Tokyo Osaka tokyo-topic osaka-topic osaka-topic-mirror topic-aggregated ● 低RPO / 低RTO ● スループット：200% ● For OLTP ● 低RPO / 低RTO ● スループット：100% - 200% ● For OLAP

Challenges どうやってもRPO=0にはならない 最大倍のキャパシティが必要 19

Stretch Cluster #kafkajp

Kafka Cluster Broker Broker Broker L Broker Broker Broker Broker 2DC Cluster leader L follower F ZooKeeper Ensemble F 21 Tokyo Osaka Broker F

Kafka Cluster Broker Broker Broker L Broker Broker Broker Broker 2DC Cluster leader L follower F ZooKeeper Ensemble F 22 Tokyo Osaka Broker F The ensemble cannot form a quorum. F L ISR might not be available, requiring dirty leader election.

Challenges Tokyoがダウンするとクラスタ全体がダウン 全ISRが一方のDCに寄るとデータ欠損の恐れ 23

Kafka Cluster Broker Broker Broker L Broker Broker Broker Broker Rack Aware 2DC with Observer Zookeeper leader L follower F ZooKeeper Ensemble F 24 Tokyo Osaka Broker F F broker.rack=”tokyo” broker.rack=”tokyo” broker.rack=”tokyo” broker.rack=”tokyo” broker.rack=”osaka” broker.rack=”osaka” broker.rack=”osaka” broker.rack=”osaka” RF=4 ISR=3 Observer Mode Rack awareness

Kafka Cluster Broker Broker Broker L Broker Broker Broker Broker Rack Aware 2DC with Observer Zookeeper in Disaster leader L follower F ZooKeeper Ensemble F 25 Tokyo Osaka Broker broker.rack=”tokyo” broker.rack=”tokyo” broker.rack=”tokyo” broker.rack=”tokyo” broker.rack=”osaka” broker.rack=”osaka” broker.rack=”osaka” broker.rack=”osaka” F F F L Adding a new one Observer promotion ISR promoted to Leader.

Challenges 復旧にやや時間 (RPO > 0) DRでのZookeeper Ensemble再構成が必要 Zookeeperデータ不整合の可能性 26

Kafka Cluster Broker Broker Broker L Broker Broker Broker Broker Rack-Aware 2DC with Hierarchical Quorum leader L follower F ZooKeeper Ensemble F 27 Tokyo Osaka Broker broker.rack=”tokyo” broker.rack=”tokyo” broker.rack=”tokyo” broker.rack=”tokyo” broker.rack=”osaka” broker.rack=”osaka” F F broker.rack=”osaka” broker.rack=”osaka” RF=4 ISR=3

Kafka Cluster Broker Broker Broker L Broker Broker Broker Broker Rack-Aware 2DC with Hierarchical Quorum in Disaster leader L follower F ZooKeeper Ensemble F 28 Tokyo Osaka Broker F Break this group out of hierarchy, forming a simple 3ZK ensemble F F L ISR promoted to Leader. broker.rack=”tokyo” broker.rack=”tokyo” broker.rack=”tokyo” broker.rack=”tokyo” broker.rack=”osaka” broker.rack=”osaka” broker.rack=”osaka” broker.rack=”osaka”

Challenges 復旧にやや時間 (より短い) DRでのZookeeper Ensemble再構成が必要 29

Kafka Cluster Broker Broker Broker L Broker Broker Broker Broker Rack-Aware 2.5 DC Cluster leader L follower F ZooKeeper Ensemble F 30 Tokyo Osaka Broker F F Nagoya broker.rack=”tokyo” broker.rack=”tokyo” broker.rack=”tokyo” broker.rack=”tokyo” broker.rack=”osaka” broker.rack=”osaka” broker.rack=”osaka” broker.rack=”osaka”

Kafka Cluster Broker Broker Broker L Broker Broker Broker Broker Rack-Aware 2.5 DC Cluster in Disaster leader L follower F ZooKeeper Ensemble F 31 Tokyo Osaka Broker F F Nagoya F L broker.rack=”tokyo” broker.rack=”tokyo” broker.rack=”tokyo” broker.rack=”tokyo” broker.rack=”osaka” broker.rack=”osaka” broker.rack=”osaka” broker.rack=”osaka”

Challenges Fail Back時のリバランス 3つ目のDC... 32

Final Thought #kafkajp

The Answer is Always “It Depends.” 34 “High SLA” とは何を指すのか？ - そもそも何を求めているのか？ - ホスト/ラック/AZ/リージョンダウン耐性? - 全体のBCPに沿っているか? - 予算は？ シングルクラスタでまだやれることは？ - Replication Factor > 3 - Zookeeper/Broker冗長 - Partition/Retention Periodの削減 - リバランス（商用製品、Cruise Control、等） - 自動化 - クラスタ分割

Your Apache Kafka® journey begins here developer.confluent.io