Upgrade to Pro — share decks privately, control downloads, hide ads and more …

High SLA Kafka - Kafka across Multiple Data Cen...

hashi
December 16, 2022

High SLA Kafka - Kafka across Multiple Data Centers

Kafka Meetup JP #12 - 登壇資料

Kafkaの活用が進みミッションクリティカルなワークロードを扱うようになると、Kafkaの持つ障害耐性を超えたSLAを目指すケースも見受けられます。本トークでは、Kafkaにおける基本的なHA/DRの概念やアプローチと、複数データセンター(or Cloud)を跨がる大規模な構成についてお話しします。

hashi

December 16, 2022
Tweet

More Decks by hashi

Other Decks in Technology

Transcript

  1. 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
  2. RPO and RTO Recovery Point Objective (RPO) 障害が発生した場合に、フェイルオーバーによってデータの履歴の どの時点から再開する必要があるかを表す。障害の発生時に許容で きるデータの損失量と言い換えることもできる。RPO

    をゼロにする には、同期レプリケーションが必要。 Recovery Time Objective (RTO) 障害が発生した場合に、フェイルオーバーの完了までに許容される 経過時間を表す。フェイルオーバー操作にかかる時間。RTO をゼロ にするには、シームレスなクライアントフェイルオーバーが必要。 11 ZERO RPO requires synchronous replication ZERO RTO requires seamless failover
  3. 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
  4. 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
  5. 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
  6. 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
  7. 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 (全てそのままミラーリング)
  8. 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
  9. Kafka Cluster Broker Broker Broker L Broker Broker Broker Broker

    2DC Cluster leader L follower F ZooKeeper Ensemble F 21 Tokyo Osaka Broker F
  10. 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.
  11. 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
  12. 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.
  13. 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
  14. 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”
  15. 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”
  16. 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”
  17. The Answer is Always “It Depends.” 34 “High SLA” とは何を指すのか?

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