confluent博客解读part3 云原生多租户

发表于 分类于 阅读次数： 本文字数： 1.7k 阅读时长 ≈ 6 分钟

背景

confluent博客解读是一个系列，主要是对confluent以下博客内容的一个阅读总结。

今天我们介绍的是第4篇，主要是关于confluent cloud是如何做云原生多租的

前言

传统自建系统的多租户关键是需要预留资源，没有弹性。云原生多租户则更加cost-effective，可以充分利用云的弹性。所有租户都是按需使用资源。

Apache Kafka的多租

apache kafka本身也提供了一些功能性的多租能力，包括:

  • Security and data isolation:通过身份认证、授权、加密来隔离数据。例如通过SSL、SAS、kerberos等协议来控制kafka集群的访问权限。
  • namespace isolation: 按约定隔离用户空间。主要是对topic提供ACL
  • **performance isolation: **按照用量来做性能隔离。主要是针对client做client quotas，可以用user-principal或者client-id。quota本质是保护不同类型的资源，避免租户资源争用的副作用。apache kafka提供以下几种client quota:
    • producer/consumer带宽quotas
    • request quotas: 很重要，避免超量高负载导致的性能劣化和避免租户间互相影响
    • topic operation quotas: topic上操作的quotas
    • Broker/per-listener limits on connection creation rate
    • Per-IP limits on connection creation rate
    • Limit on the number of active connections

传统自建kafka做多租户需要面临的一个核心问题就是需要考虑容量评估。有quota也无法保证资源预留是合理的。自建kafka得花费很多成本做好监控，并且进行容量预估，提前准备资源。

云原生多租

云原生多租相比传统自建多租具有如下额外的要求：

  • 更高的抽象：apache kafka broker级别的quota抽象过于底层，有太高复杂性
  • pay as you go model: 按需使用模型
  • **更严格的SLA：**依托于公有云的技术红利，云原生多租可以有更高的可用性和安全性
  • cost-efficiency: 低成本

Confluent Cloud多租户实现

控制面给对应租户在物理集群的基础上分配一个逻辑集群lkc: 依靠之前提到的三种隔离手段：

  • data isolation(security)
  • metadata isolation(user space)
  • performance isolation(quotas)

confluent处理租户请求

针对客户租户，confluent设计了一个租户实体，一个租户实体表征三种isolation构成的基本单元。通过以下方式实现：

  • client连接时broker记录tenant实体
  • request/response拦截器限制租户访问其拥有的资源
  • 自定义的quota实体： 主要是复用了kafka的能力

image.png

性能隔离

  • confluent自己实现了一个ClientQuotaCallback使得所有lkc上的topic操作附带上quotas信息

租户quota与broker处理上的挑战

  • 利用quota进行性能隔离需要考虑scale的时候，需要考虑调整per-broker quota
  • 考虑租户实际可能是使用部分broker的情况

broker与request quota

confluent通过逻辑集群、不同维度的quotas来实现租户性能隔离
image.png

自动容量计划

云原生多租户，confluent cloud支持自动做容量计划。

实现思路——broker wide quotas

实现的关键挑战是在pay as you go的模型下做好自动的容量计划。传统预留资源配合quota的方式虽然奏效但是不符合pay as you go模型。之前提到的都是tenant wide quotas，confluent为了解决这个问题引入了broker wide quotas。broker wide主要是在broker级别进行quota控制，更加面向资源。类型主要包括：

  • Broker-wide producer and consumer bandwidth quotas
  • Broker-wide request quota
  • Broker-wide limit on connection attempt rate

broker quota的限制是临时性的（小于等于tenant wide quota的值），主要是配合一些balanced、scaling事件，在broker资源富足时再放开quota，从而使得容量调整和租户使用之间的衔接更加平滑，避免overload的情况出现。

笔者解读：要尽量预测好workload，避免tenant quota使用触发临时的broker quota，如果发生这样的事，其实对可用性是有影响的

The broker-wide producer/consumer bandwidth quota

设定的broker quota一般是按照理想均衡状态下的replication factor、机器规格等来确定：

  • broker写quotas: 复制因子为3，就是三分之一的broker max write capacity
  • broker读quotas: max read capacity去掉复制的占用

image.png

The broker-wide request quota

主要用于避免broker overload。quotas主要作用：

  • 确保broker预留足够的process capacity用于replication和其他request（去除一些白名单request，不受quotas限制，例如follower的fetch requst，确保follower拿到in-sync ISR）
  • 确保CPU处理部overload

这里的关键挑战其实还是这个capacity到底设置多少合理，本质是在uptime / performance SLOs和cost-efficiency之间做trade-off。协调capacity关键是协调下图的三种职责的thread，像IO thread其实不占用CPU可以空出算力给其他请求。
image.png

conflunt解决这个问题的核心办法是：根据请求队列长度来动态调整request quotas。

The network listener limit on connection attempts per second

request quota没法控制broker接受多少connection。新连接重试的请求过多（比如被auth拦截后重新请求）会占用原本的request quotas，此外如果有connetion quotas，我们也可以避免连接风暴。所以我们必须有个connection quotas来避免这样的情况发生。
image.png

Auto-tuned tenant bandwidth and request quotas

quota的自动调整可以避免capacity headroom不多的时候资源争用带来的集群稳定性问题。其实可以理解为tenant quota的分时复用，临时动态调整，使得多租在资源紧张的时候还可以相对稳定的运行，避免资源争抢期间的各种不可预测的行为。等集群扩容完毕后即可继续正常工作。

auto tune的时机：broker tenant合计的tenant quota超过broker quota的时候，会启用dynamic tenant quota，等扩容后再恢复。

auto tune作用的租户：active tenant（过去几分钟产生请求的）

笔者解读：要求很高，如果没有及时扩容，就可能影响SLA，需要做好workload预测

下图是带宽dynamic quota的算法示意图：

  • 先计算initial fair quota: 容量超过broker-wide quota的时候按照当前的broker wide quota平均到所有租户的事initial fair quota
  • 根据workload调整大家预留的quota,使用dynamic quota: 有些quota设置很高，但是不咋样，可以临时降低其quota，分配给别的有需要的人，从而整体上仍然保证可用性

image.png