Shuffle Sharding

Posted 2021-05-01 武力程序猿

本文翻译自AWS技术架构Blog

https://aws.amazon.com/blogs/architecture/shuffle-sharding-massive-and-magical-fault-isolation/

01

—

问题

对于Multi-Tenant 服务来讲，有很多种情况会导致customer之间的相互影响。例如：

• 一个customer出现了突发的流量高峰

• 一个customer的一个request可能处理起来额外的慢，或者干脆处理这个request会造成死锁等问题。
  

因此，在Multi-Tenant 服务，减轻customer之间的相互影响是非常重要的一个话题。如何做customer之间的隔离呢？

02

—

传统方法：水平扩容(Horizontal Scaling)

服务由多个instance组成，整个集群里的instance平摊服务所有的流量。
这种方法基本没有任何的隔离。
如果一个customer出问题的话，那么这个customer会很快影响到你的整个服务。

03

—

分片(Sharding)

一个简单的隔离方法是做分片(Sharding)。假设我们的集群里有8个instance，我们可以创建4个shard。如下图所示：

如何做shard？可以通过customer id做哈希等等。这里不过多赘述。

Sharding的效果是我们在shard之间创造了所谓的“挡板”(bulkhead)。如果一个customer出了问题，最多影响到一个shard，而被分配到其他三个shard上的customer不会受到影响。

在这里，通过合理的隔离，我们将“爆炸半径”(blast radius)降低到了1/4。

04

—

随机分片(Shuffle Sharding)

通过shuffle sharding，我们可以比1/4做得更好。

对于上图所示，还是8个instance的集群，从8个中选出2个instance一共有28种方式。（注意这里是组合并不是排列，原文中用排列来计算这个值我感觉不太对，也可能理解错误欢迎指正）

对于每一个组合，我们都看作一个shard，这样我们有了28个shard。当一个customer出了问题，最多影响一个shard，也就是两台机器。

举例，假设干掉了(3,5)两台instance组成的shard，也就是说3和5两台instance都down了。但是我们还有27个shard，但是没有一个shard同时包含了3和5。这种情况下，其余27个shard都有存活的instance，还可以继续维持service。

结论：通过ShuffleSharding我们可以将“爆炸半径”(blast radius)降低到1/28。

05

—

还不够！！

熟悉排列组合的同学知道，对于8个instance的集群：

• 选出2个一共有28种排列

• 选出3个一共有56种排列

• 选出4个一共有70种排列
  

因此我们可以通过调整shard里instance的数量=4来把“爆炸半径”(blast radius)降低到1/70。