云原生架构系列第七篇：通过容器和细胞设计提升韧性和效率

作者：Anuj Gupta Emmanuel Isimah 和 Steven David，于2023年10月30日发布于 Amazon CloudWatch、Amazon Elastic Kubernetes Service、Architecture 和 AWS App2Container

关键要点

在之前的 云原生架构系列博客 中，我们讨论了如何将架构演变为更具可扩展性、安全性和成本效益，以应对超大规模的需求。在这篇文章中，我们将采取以下两项措施：1/ 容器化应用程序以提高资源效率，2/ 通过细胞设计提升韧性和生产时间。

容器化应用程序以实现标准化与扩展

标准化容器编排工具

选择合适的服务来适应特定用例，需考虑组织的需求和管理容器编排器的技能。我们的团队选择了 Amazon Elastic Kubernetes ServiceEKS，因为我们具备与 Kubernetes 合作的技能和经验。此外，领导层致力于开源，并且 拓扑感知特性 与我们的韧性需求相符合。

为了容器化我们的 Java 和 NET 应用程序，我们采用了 AWS App2ContainerA2C来创建部署工件。AWS A2C 减少了对依赖分析所需的时间，创建了可以嵌入到部署管道中的工件。A2C 支持 EKS 蓝图与 GitOps，有助于缩短容器采用时间。蓝图也提高了一致性，并符合安全最佳实践。如果您不确定适合运行容器化工作负载的工具，可以参考 选择 AWS 容器服务。

识别适合的日志记录和监控工具

在容器环境中的日志记录增加了动态日志源数量的复杂性，这些源可能是短暂的。为了对事件进行适当的追踪，我们需要一种方法来收集所有系统组件和应用程序的日志。我们设置了 Fluent Bit 插件 来收集日志并发送到 Amazon CloudWatch。

我们使用 CloudWatch Container Insights for Prometheus 来从容器化应用程序抓取 Prometheus 指标。这使我们能够使用现有工具如 Amazon CloudWatch 和 Prometheus为不同团队和应用程序构建专用仪表板。我们在 Amazon Managed Grafana 中创建了仪表板，利用与 Amazon CloudWatch 的原生集成。这些工具从我们团队身上减轻了管理日志记录和容器监控的负担。

管理资源利用率

在超大规模环境中，一个 吵闹的邻居 容器可能会占用整个集群的所有资源。Amazon EKS 提供了定义和应用 请求和限制 的能力。这些值决定了容器可以拥有的最小和最大资源数量。我们还使用了 资源配额 来配置在命名空间内所有运行的 pod 可以使用的总内存和 CPU。

为了更好地了解单个应用程序和 pod 的资源利用率与运行成本，我们实施了 Kubecost，并参考了 使用 Kubecost 和 Amazon Managed Service for Prometheus 的多集群成本监控 的指导。

动态扩展集群和应用程序

通过 Amazon EKS，Kubernetes 指标服务器Kubernetes Metrics Server从 Kubelets 中收集资源指标，并在 Kubernetes API 服务器中公开。这是通过指标 API 进行的，供 Horizontal Pod AutoscalerHPA和 Vertical Pod AutoscalerVPA使用。HPA 消耗这些指标，通过增加副本的数量来实现横向扩展，从而分散工作负载。VPA 使用这些指标动态调整 pod 资源，如 CPU 和内存预留。

通过与指标服务器的集成，Amazon EKS 减轻了应用程序扩展的操作复杂性，并提供了更细粒度的动态扩展控制。我们建议超大规模客户考虑将 HPA 作为首选的应用程序自动扩展器，因为它不仅提供韧性增加副本数量，还具备了扩展能力。在集群层面，Karpenter 提供快速的多样化计算资源的配置和去配置，同时还确保了成本效益，有助于应用程序以超大规模满足业务增长需求。

构建回滚策略以管理故障

在超大规模环境中，部署推出通常容错率低，且需要接近零的停机时间。我们实施了 渐进式推出、金丝雀部署和自动回滚，以降低生产部署的风险。我们使用关键绩效指标KPI如 应用程序响应时间 和 错误率 来判断是否继续或回滚我们的部署。我们利用与 Prometheus 的集成来收集指标并测量 KPI。

使用细胞设计提升韧性和扩展

我们仍需要应对 黑天鹅事件，并减少意外故障或扩展事件的影响，使系统更加坚韧。我们提出了一种设计，创建独立可部署的应用程序单元，并设置故障隔离边界。新的设计使用细胞设计方法，以及 Shuffle Sharding 技术来进一步提高韧性。关于这方面的具体细节可以参考 Peter Vosshall 的 reInvent 演讲。

首先，我们创建了一种细胞设计架构，如 使用细胞架构减少影响范围 所述。其次，我们应用了 Shuffle Sharding，如 你问的 Shuffle Sharding 怎么样？ 中所述，以确保在黑天鹅事件发生时进一步控制系统的影响。

在图1中，我们可以看到两个组件：

图1 高层次的细胞架构

我们遵循了 AWS 上细胞架构的指导 来实施我们的细胞架构和路由层。为了减少路由层的故障风险，我们将其设计为最薄的层，并针对所有可能的场景进行了稳健性测试。我们使用哈希函数将客户映射到细胞，并将映射存储在高度可扩展和可靠的数据存储服务 Amazon DynamoDB 中。此层简化了新细胞的添加，并为应用程序提供了水平扩展的环境，以优雅地处理客户或订单的超大规模增长。

在图2中，我们重新审视了在 系列博客第3篇 中提到的架构。为了管理 AWS 服务限制并降低故障影响范围，我们将应用程序分散到多个 AWS 账户中。

图2 来自博客第3篇的架构

以下是实现于 AWS 上的新设计示例：

图3a 细胞架构

图3a 使用 Amazon EKS 替代 Amazon EC2 部署应用程序，并为入站流量使用轻量路由层。在一个网络共享服务 AWS 账户中配置了 Amazon Route 53。我们的设计中有多个隔离边界AWS 可用区、AWS 区域和 AWS 账户，从而使架构在超大规模增长时更具韧性和灵活性。

我们将 AWS 可用区用作细胞边界，并实施 Shuffle Sharding 将客户映射到多个细胞。这样在某个细胞发生故障时，可以减少影响。Shuffle Sharding 还允许该架构在客户产生前所未有的请求时扩展。

细胞设计应对黑天鹅事件

现在让我们讨论细胞设计的应用在黑天鹅事件中的反应。首先，我们需将 pod 对齐到 Amazon EKS 集群中的细胞组。现在可以观察到每个部署之间的相互隔离。只要是路由层包括 Amazon Route 53、Amazon DynamoDB、ECS 细胞路由器和负载均衡器，在系统中便是共享的。

图3b 细胞架构在 EKS 中的特写

如果没有细胞设计，黑天鹅事件可能在初次攻击时瘫痪我们的应用程序。现在，由于我们的应用程序分散至三个细胞，最坏的情况是初次攻击仅对我们应用程序 33 的能力造成影响。我们现在拥有了节点级和可用区的韧性边界。

结论

在这篇博客中，我们讨论了如何容器化应用程序以提高资源效率，并帮助工具和流程的标准化。这减少了应用程序扩展的工程开销。我们还提到采用细胞设计和 Shuffle Sharding 如何进一步增强应用的韧性，改进故障管理能力，并处理意外的大规模扩展事件。

进一步阅读：

Anuj Gupta

Anuj Gupta 是一名首席解决方案架构师，致力于帮助数字原生企业客户推进云原生之旅。他热衷于运用技术解决难题，曾与客户合作构建高分布和低延迟的应用程序。同时，他还为开源解决方案作出贡献。工作之余，他喜欢与家人旅行，结识新朋友。

Emmanuel Isimah

Emmanuel 是一名高级解决方案架构师，专注于超大规模的数字原生企业。他拥有网络、安全性和容器方面的专业背景，帮助客户构建和安全创新的云解决方案，通过数据驱动的方法解决商业问题。Emmanuel 的深度领域包括安全性与合规、容器以及网络技术。

Steven David

Steven David 是 Amazon Web Services 的首席企业解决方案架构师，帮助客户构建安全且可扩展的解决方案。他拥有应用程序开发和容器方面的专业背景。