《Amazon DynamoDB》论文笔记 1网站首页 技术杂谈

《Amazon DynamoDB》论文笔记 1

phantom_111 2024-06-17 10:49:01

简介《Amazon DynamoDB》论文笔记 1

文章目录

1. 写在最前面

最近读到一句话，「所谓云原生并不是简单的将一个云下的数据库搬到云上自动部署就叫 DBaaS，而是需要从内核到管控平台针对云提供的能力和环境进行深层次的改造，否则一个直观的代价就是：在云上的成本降不下来。」

这大概就是为什么在 Q2 评估上云的优势的时候，大家较劲脑汁也只想出来「运维方便」这一个小点的原因了吧。

本文仅是笔者结合目前在做的服务上云工作以及 DynamoDB 论文学习的一点记录，如有笔误欢迎指出。

注：能在云上运行和能充分利用云的资源应该是两个维度的事情

2. 核心观点

介绍了 DynamoDB 如何从一个需要程序员自主运维、配置的数据库系统，演进为一个

超高可靠（highly availbale）
超大规模（highly scale）
超级稳定（predictable performant）
全自动化数据库服务（fully managed database as service）。

注：满足需求的延迟远比追求极致性能来的重要，特别是对于云服务来说

构建一个 DBaas 和构建一个数据库完全是两回事，并不是简单的将多个 DB 部署放到云上托管就叫做 Service 了。DBaas 需要给用户提供通过 endpoint 连接后，即支持跟使用本地数据同样的感受，至于关于其他背后运维、监控等可用性事情用户都无需关心。

2.1 作为服务提供要考虑的问题

自 2012 年推出 DynamoDB 以来，根据运维经验对其设计和实现进行了改进。在不影响可用性和性能的情况下，成功解决了公平性、跨分区的流量不平衡、监控和自动化系统运维方面的问题。可靠性是至关重要的，因为即使是最轻微的中断也会对客户造成重大的影响。

在分析从 Dynamo -> DynamoDB 的过程中，该团队面临的问题前，先试着总结一下，作为服务直接面向客户中可能的遇到的问题：

部署的方案
多租户问题的解决
容量上限
容量扩展
可用性指标评估

2.1.1.1 部署方案

DynamoDB 的论文里提及了很多对 S3 以及 IAM 等云服务的依赖，但是对于 ECS 以及 EBS 没有任何提及，所以大概率 DynamoDB 的 Hardware Infra 很可能是自己维护的，直接跑在裸机上的。

注：这点也很好理解，作为一个成熟的服务链路依赖的越复杂，带来的不稳定因素就越多

笔者在做服务上云（即基于 k8s 做部署）相关的内容，有一点很深刻的认知是，以前服务不可用的因素有：

物理机失联
服务自身不可用

现在上云之后，服务不可用的因素多了：

上云服务的组件不可用
发布平台不可用

不能简单的总结上云不好，只是上云后对「云稳定有一定的要求」，从一定程度来讲基于脚本来管理发布确实不如基于发布平台。

总结：「盲目上云不可取，建议谨慎评估 ROI 后操作」

2.1.1.2 多租户的问题

DynamoDB 将不同客户的数据存储在相同的物理机器上，以保证资源的高利用率，是其可以为客户提供更经济的服务。资源预留、严格分配和用量监控为驻留在同一处的表提供隔离。

注：对比了一下在做的上云服务，平台不支持业务混部是上云后成本无法下降的一个原因。

在为多租户提供服务的时候有两个问题无法避免：

从业务角度：为物理上混部的用户，提供逻辑上的隔离，即部署在同一个机器上的业务不会互相影响，docker 部署是一个很好的解决方案
从成本角度：多租户计费模型设计以及计费数据埋点

注：产品上线后，再反过来推导多租户的计费模型以及埋点，真的是非常痛苦的

2.1.1.3 容量上限

Dynamo 属于 Shared Nothing 的存储系统，可以通过 Scale-out 的技术来提升容量。所以当 Dynamo 的容量可以随着部署节点的增加而进行水平扩容。

名词解释：

Shared Nothing：把某个表从物理存储上水平分割，并分配给多台服务器（或多个实例），每台服务器可以独立工作，具备共同的 Schema。
Scale Out：指 Application 可以在水平方向上扩展。一般对数据中心的应用而言，Scale out 指的是当添加更多的机器时，应用仍然可以很好的利用这些机器的资源来提升自己的效率从而达到很好的扩展性。
Load Base Split：Partition 会有一个默认吞吐阈值，超过这个值后触发分裂。

注：热点出现在以下情况下时，分裂无效：

a. 单行热点；b.按照 key 的顺序访问的 pattern，可能是类似顺序扫描的模式

思考?：在非大单体架构中，绝大多数的服务应该都可以通过机器进行水平扩容，从而来提升整体容量。

2.1.1.4 容量扩展

「知己知彼，才能百战不殆」

在知道 Dynamo 的容量的上线可以通过水平扩容来增加以后，让我们来思考两个问题：

问：如果基于现有的部署规模来评估容量？

答：（单台机器的负载上限 * 集群内的机器个数）* 预留的系数 n

问：容量打到上限后，如何扩容？

答：DynamoDB 使用自适应容量来应对「长时峰值」。自适应容量使 DynamoDB 能更好地吸收跨多个分区的严重倾斜负载。

自适应容量通过监控所有表的分配容量和消耗容量在进行：

当表被限流，但总吞吐量没有超过表级别分配给它的吞吐量，就会使用比例控制算法自动增加表分区分配的吞吐量。
如果表消耗的容量超过了分配给它的容量，被提升的分区容量就会被消减。自动管理系统（autoadmin system）将被提升分区迁移到一个适当的节点，该节点有能力增加吞吐量。

2.1.1.5 可用性指标评估

DynamoDB 是为全局表达到 99.999% 可用性和为区域表达到 99.99% 可用性设计的。

为了确保达到这些目标，DynamoDB 以每 5 分钟的间隔计算成功处理请求的百分比。DynamoDB 持续监控服务和表级别的可用性。监控得到的可用性数据用于分析客户感知的可用性趋势，并在客户感知的错误超过某个阈值时触发告警。（ps：这大概是接口请求的成功率监控）
DynamoDB 还可以从客户端观测可用性并发出告警。有两组客户端专门用于测量用户感知的可用性。
- 第一组客户端时使用 DynamoDB 作为数存储的 Amazon 内部服务，这些服务共享它们的软件所观测到的 DynamoDB API 调用的可用性指标。
- 第二组客户端时 DynamoDB canary 程序。这些程序在每个区域中运行并通过所有公共端到与 DynamoDB 通信