8. Azure Chaos Studio与Azure Load Testing

第八章 Azure Chaos Studio 与 Azure Load Testing

在当今快速发展的技术格局中，确保应用程序的弹性和稳健性至关重要。通过严格测试我们的解决方案，我们可以在潜在漏洞影响最终用户之前预见并解决它们。这种主动方法不仅增强了系统的可靠性，也树立了其抵御现实世界中断能力的信心。

本章涉及的服务为测试应用程序的弹性和性能提供了强大的解决方案。

Azure Chaos Studio 允许你执行混沌实验，通过有意向系统注入故障，观察其在压力下的反应。这有助于识别并缓解弱点，确保应用程序能够应对现实世界的中断。

Azure Load Testing 则侧重于模拟高流量负载，以衡量应用程序的性能和可扩展性。通过了解应用程序在峰值条件下的行为，你可以进行优化，确保其对最终用户的可靠性。

本章将涵盖以下混沌工程概念（我将首先介绍混沌工程）：

• 理解混沌工程
• 配置 Azure Chaos Studio 服务
• 定义 Azure Chaos Studio 混沌实验
• 针对目标资源运行混沌实验
• 理解负载/性能测试
• 配置/运行 Azure Load Testing 服务

---

混沌工程简介

混沌工程是一门对系统进行实验的学科，旨在建立对系统承受生产环境中动荡条件能力的信心。 — https://principlesofchaos.org/

混沌工程的核心是实验——通常是针对生产运行系统——以识别并发现系统运行方式中的漏洞或缺陷，这些漏洞会降低系统的可靠性。

我们越能提前识别出漏洞，就能对系统的可靠性越有信心。通过引入一系列事件模拟——无论是基于过去真实发生的事故，还是基于可能发生的模拟故障——我们针对工作负载进行测试，并从其影响中学习。

一个简单的例子是 CPU 压力。假设一个工作负载数月来运行良好，平均 CPU 负载使系统保持健康。突然，CPU 出现峰值并导致应用程序崩溃。除了排查 CPU 峰值的根本原因外（这可能是工程或开发团队的任务），同样重要的是找出系统为何以应用程序崩溃作为反应。更重要的是，如果我们事先模拟了 CPU 峰值，工程和开发团队本可以专注于通过发布修复、更新架构以实现更高容错性来缓解问题。

但请不要误解，混沌工程远不止是注入故障触发器来使生产环境瘫痪。其中涉及更多复杂性，尤其是因为故障通常并非由单一失败引起，而是一系列事件的连锁反应。

沿用 CPU 压力的例子，我们可以考虑这样一种场景：由于数据库操作延迟，导致某个计算或数据库更新挂起，从而引发 CPU 峰值。或者，可能存在网络连接问题，导致某个操作无法写入数据库后端，从而引发大量重试操作，进而导致 CPU 峰值。因此，仅仅“模拟”CPU 峰值是不够的，还必须捕获所有可能导致 CPU 压力的可能副作用。

对我而言，这也解释了为什么它被称为一门工程学科，因为在不同系统、组件和工作负载之间的所有交互中涉及相当多的工程工作。

现在，你可能会认为混沌工程是下一个大事件（甚至可能继 SRE 和 DevOps 之后？），但对于你的云环境来说还过于革命性。但事实恰恰相反。

实际上，混沌工程已经存在超过 15 年了，最初由 Netflix 的软件工程师在 2008 年左右发起，当时他们开始从本地数据中心迁移到公共云数据中心。虽然管理自己的数据中心和使用公共云有很多相似之处，但也存在巨大差异。正是这些差异迫使 Netflix 的工程师创建了具有更高弹性的服务架构。

---

Chaos Monkey

Chaos Monkey - https://github.com/netflix/chaosmonkey

图 8-1. Chaos Monkey

来自 README.md 文件：

Chaos Monkey 会随机终止生产环境中运行的虚拟机实例和容器。让工程师更频繁地暴露在故障中，会激励他们构建弹性服务。

Chaos Monkey 是遵循混沌工程原则的工具的一个例子。

要求

此版本的 Chaos Monkey 与 Spinnaker (https://spinnaker.io) 完全集成，这是 Netflix 使用的持续交付平台。你必须使用 Spinnaker 管理你的应用程序，才能使用 Chaos Monkey 终止实例。

Chaos Monkey 应与 Spinnaker 支持的任何后端（AWS、Google Compute Engine、Azure、Kubernetes、Cloud Foundry）一起使用。它已在 AWS、GCE 和 Kubernetes 上经过测试。

Netflix 设计 Chaos Monkey 是为了验证其生产运行工作负载（我们都在使用的流媒体服务）的稳定性，该服务运行在 Amazon Web Services 上。Chaos Monkey 的主要目的是检测系统在关键组件被关闭时的反应。通过有意关闭工作负载，可以清楚了解整个拓扑中存在哪些弱点，并允许工程团队着手缓解。

---

混沌（工程）原则

虽然并非专门为此开发，但我可以肯定地说，将 Chaos Monkey 作为开源解决方案提供，无疑有助于推广混沌工程的信息，正如混沌原则（www.principlesofchaos.org）所定义的那样。

不逐字重复他们定义的混沌工程，其核心可以归结为以下几点：

• 传统对故障和中断的测试通常只关注单一场景，例如前面提到的 CPU 峰值；而对于生产运行的工作负载，事故几乎从不与单一原因相关，而是由一系列事件组成。混沌工程倾向于专注于实现对系统的这一系列操作。模拟越复杂，你对系统可靠性的信心就越大。

• 系统和运行工作负载中的弱点和缺陷，无论架构是传统的虚拟机、更复杂的容器化架构，还是面向无服务器和微服务的架构，都应在它们表现为关键业务生产工作负载之前被识别出来。以 Chaos Monkey 为例，其起始编排器主要基于虚拟机。你可能可以列出一长串可能影响虚拟机正常运行时间的典型事件，例如存储延迟或中断、磁盘崩溃、操作系统故障、CPU 压力、系统宕机、系统持续重启等。但转向容器化工作负载后，这个过程变得更加困难。除了底层虚拟机监控程序，你还需要识别容器、网络安全、存储集成之间的相关性，例如识别 Kubernetes 集群中不同节点上的 Pod 如何运行、Pod 何时以及如何重启等。最终，你可能会遇到最“不可控”的场景：微服务和无服务器。如果你不管理底层平台，不管理网络或存储交互，几乎每一层都为你管理好了，你可能没有太多可控之处，但你仍然负责确保微服务（Azure Functions、AWS Lambda）正常运行。也许正因为如此，实际管理和验证正常运行时间可能更加困难。

• 混沌工程在设计上是主动的，这意味着你倾向于在弱点（可能）发生之前很久就识别出它们。首先是为了发现弱点本身，其次也是为了在它们发生时做好准备。这听起来可能有些奇怪，因为按理说应该在问题出现之前就缓解它，特别是得益于之前进行的演练。但在我从事 IT 行业 25 年后，我确信几乎不可能为所有情况做好计划，尤其是在公共云环境中，你并不管理架构工作负载的完整堆栈。

---

Azure Chaos Studio

Chaos Monkey 是一个出色的工具，虽然它高度集成并依赖于 Spinnaker，但这也使其成为平台和云无关的工具，例如支持 Amazon AWS、Google GCP、Microsoft Azure 以及 Kubernetes（本地或云端场景）。

由于本书是关于在 Azure 上实现 SRE 的，我最初本章的意图是介绍 Chaos Monkey（以及用于 Kubernetes 的 Chaos Mesh）并将其用于 Azure 参考架构场景，正如前几章所讨论的那样。

然而，在 2021 年 11 月的 Microsoft Ignite 大会上，好消息传来：Azure Chaos Studio 发布，这意味着现在任何人都可以尝试使用它。

Azure Chaos Studio 架构

Azure Chaos Studio 以服务形式提供，这意味着你无需先部署自己的基础设施即可启动并运行。在底层，它基于开源解决方案 Chaos Mesh（混沌工程平台 | Chaos Mesh (chaos-mesh.org)），该解决方案通常作为基于 Kubernetes 的架构运行。但同样，这些你都不需要了解，因为一切都在幕后运行。

1. 你需要做的第一件事是确保“Microsoft.Chaos”Azure 资源提供程序已在你的订阅中启用（注册）。为此，请打开 Azure 门户并搜索“Subscriptions”。

   图 8-2. 注册 Microsoft.Chaos

2. 现在，你已准备好开始在你的订阅中使用 Azure Chaos Studio。

   图 8-3. Azure Chaos Studio

   图 8-4. 目标（Target）部分

3. 在此处，你可以筛选特定的订阅或特定的资源组（或两者），然后需要选择要作为目标的 Azure 资源。

本章的其余部分将引导你完成两个常见场景：如何将混沌工程与 Chaos Studio 集成到 Azure 虚拟机（基于代理）和 Azure Kubernetes 服务（AKS）集群中。

[演示] 将 Azure VM 加入 Chaos Studio

图 8-5. 启用目标

2. 在此处，我可以在服务直连目标（service-direct targets）和基于代理的目标（agent-based targets）之间进行选择。由于这是一个虚拟机，建议使用基于代理的目标。

8. Azure Chaos Studio 与 Azure Load Testing

演示：将 Azure VM 载入 Chaos Studio（续）

如图 8-6 所示，需要创建一个 Application Insights 资源，为运行 Chaos Studio 提供可观测性和监控支持。

4. 首先创建用户分配托管标识。在 Azure 门户中搜索“托管标识”并创建新的标识。

7. 在 Chaos Studio 可以将 Azure 资源设为目标之前，需要将用户分配托管标识分配给该资源。以示例虚拟机为例进行操作：在 Azure 门户中浏览到“虚拟机”，选择该 VM 资源。

9. 在“用户分配”下，单击“添加”，选择之前创建的用户分配托管标识。
10. 单击“添加”确认更改。

16. 单击“审阅+启用”，并在下一个边栏中再次确认。

21. 完成必要参数，允许创建新的实验资源：定义资源组、指定实验名称（例如 CPUStressTest）、定义 Azure 区域（注意：区域应与目标资源运行区域相同）。单击“下一步”。
22. 选择上一步的用户分配托管标识，并保留“Azure 内置角色”选项。

接下来为故障模拟指定一些参数。首先，单击“故障”下拉列表，选择“CPU 压力”。此测试将模拟示例 Ubuntu VM 的 CPU 峰值。然后将“持续时间”参数设置为十分钟，将压力水平调整为 95%（如图 8-20 所示）。

31. 单击“选择”确认，然后依次单击“审阅并分配”。等待此 RBAC 权限分配给混沌实验。
32. 返回 Chaos Studio，选择“实验”，打开之前创建的实验。

38. 至此完成了部署 Azure Chaos Studio、分配正确标识、所需先决条件（如用户分配托管标识和 Application Insights 资源）以及如何创建并运行混沌实验的配置与演示。

---

演示：将 AKS 集群载入 Chaos Studio

接下来的示例将详细介绍如何集成混沌工程故障注入，以验证包含 Linux 节点的 Azure Kubernetes 集群场景。

如果尚未部署 AKS，可以使用以下“Demo Deploy”解决方案（由本书合著者 Peter de Tender 创建）。参考 AKS 示例并使用 AZD 快速部署：

• https://microsoftlearning.github.io/trainer-demo-deploy/?tags=aks

1. 与之前的虚拟机场景相比，Azure Kubernetes 服务的主要区别之一在于：需要先在集群资源中安装 Chaos Mesh 故障，然后才能通过 Azure Chaos Studio 与之交互。虽然可以通过管理员工作站的 Azure CLI 远程执行，但最简便的方式是使用 Azure Cloud Shell。也可以参考最新说明：https://learn.microsoft.com/zh-cn/azure/chaos-studio/chaos-studio-tutorial-aks-portal

2. 在已部署 Kubernetes 解决方案的情况下，打开 Azure Cloud Shell 并选择 Bash 选项。运行以下命令建立与 AKS 集群的连接：

az aks get-credentials -g $RESOURCE_GROUP -n $CLUSTER_NAME

3. 示例中之前已运行过此命令，但覆盖重试是安全的，以确保获取最新的凭据信息。

NOTE

如果使用了前面提到的演示环境，它已经安装了 chaos-mesh！

接下来，需要安装 Chaos Mesh 包，最简单的方法是使用 Kubernetes Helm 包管理器。由于 Azure Cloud Shell 已预装 Helm，可以直接运行以下命令：

helm repo add chaos-mesh https://charts.chaos-mesh.org
helm repo update
kubectl create ns chaos-testing
helm install chaos-mesh chaos-mesh/chaos-mesh --namespace=chaos-testing --set chaosDaemon.runtime=containerd --set chaosDaemon.socketPath=/run/containerd/containerd.sock

4. 接下来，运行以下命令验证 Chaos Mesh Pod 是否成功运行：

kubectl get pods --namespace chaos-testing -l app.kubernetes.io/instance=chaos-mesh

6. 注意：此场景中“基于代理”选项不适用，因为我们直接连接到 Kubernetes 集群的服务层。

7. 在上方菜单中选择“启用目标”/“启用服务直接目标（所有资源）”。

8. 启用并等待与此组件安装相关的通知。

完成后，即可继续指定 Chaos Studio 实验。

1. 在 Chaos Studio 中，浏览到“实验”。单击“创建 ➤ 新建实验”。完成 Azure 所需的订阅、资源组、实验名称以及创建位置的设置。由于每个实验本质上只是一个独立的 Azure 资源对象，其创建方式应与创建类似对象一致。
2. 在“权限”选项卡中，保留默认选项“系统分配托管标识”（也可以重用之前创建的用户分配托管标识，但此处我们采用不同方式）。
3. 单击“下一步”导航到“实验设计器”。在此处定义混沌工程中要运行的实际混沌测试（故障注入）。如本章开头所述，每个故障遵循步骤和分支的层次结构，在其下定义一个或多个故障场景（操作）。

5. 从可用故障列表中选择“AKS Chaos Mesh Pod Chaos”，以模拟 AKS 集群中的 Pod 故障。指定持续时间（分钟），并完成 jsonSpec 字段。

目前需要将 Chaos Mesh 的 YAML 语法转换为 JSON 语法。门户中会提供相应指引。以下 YAML 语法：

action: pod-failure
mode: all
duration: '600s'
selector:
  namespaces:
    - default

在 JSON 格式中应如下所示：

{
   "action": "pod-failure",
   "mode": "all",
   "duration": "600s",
   "selector": {
      "namespaces": [
         "default"
      ]
   }
}

为此，在 Azure 门户中导航到 AKS 服务资源，选择“访问控制 (IAM)”。

14. 等待过程完成，或单击“详情”验证正在进行的流程的更多信息。
15. 至此完成了如何为 AKS Kubernetes 服务集群设置 Chaos Studio 并运行 Pod 故障模拟的过程。

建议继续尝试并体验可用于 Azure 虚拟机和 AKS 的其他场景，以及适用于其他 Azure 资源（如 Azure Key Vault 机密存储或 Azure 网络安全组）的故障注入。

虽然这原本是 Azure Chaos Studio 混沌工程主题的结尾，但如前所述，微软发布了另一款面向 SRE 的工具，用于负载/性能测试。虽然其功能并不局限于 SRE，但该工具提供了大量与 SRE 相关的特性，因此我们决定在本章中对该服务进行快速介绍。接下来我们一探究竟。

第8章 Azure Chaos Studio与Azure负载测试

负载/性能测试

负载测试（通常称为或关联于性能测试）研究解决方案在特定虚拟用户负载下的行为，分析诸如响应时间或架构如何适应负载（自动缩放）等指标。

回顾第3章，性能测试可分为两类：

• 负载测试：主要用于在预期用户负载下触发可伸缩性（尝试模拟可能的场景）。
• 压力测试：通常用于验证应用程序或系统在崩溃前能够承受的最大负载（尝试找到系统的极限）。

历史上，微软通过Visual Studio产品提供了性能和负载测试工具。然而，Visual Studio 2019是最后一个完全支持该功能的版本。连同Azure DevOps，这套工具集曾提供基于云的、聚焦CI/CD的负载测试服务，直至2020年3月：https://devblogs.microsoft.com/devops/cloud-based-load-testing-service-eol/。产品团队开始推荐切换至社区流行的开源工具Apache JMeter（https://jmeter.apache.org/）来设计性能测试。运行高可扩展性的Apache JMeter测试在基础设施设置方面并不容易；人们开始使用基于Kubernetes的架构来创建高可扩展性的测试。

---

Azure负载测试

2022年初，微软还宣布了一项新的完全托管式Azure服务，用于负载测试场景。它使工程师能够基于JMeter或Locust脚本运行高规模模拟，以了解解决方案的性能瓶颈，带来诸多优势，例如：

• 无需关心复杂的测试基础设施
• 查看预定义资源的客户端/服务器端指标
• 轻松集成到Azure DevOps或GitHub Actions管道的CI/CD执行中

只需提供要测试的URL或上传更高级的JMeter脚本，即可创建简单的负载测试。让我们通过一个演示场景来审视该工具。

---

[演示] Azure容器应用的Azure负载测试

该场景将基于前几章使用的解决方案：运行在Azure容器应用上的.NET 8容器化解决方案。如前几章所述，Azure容器应用通过提供一种简单的方式来应用那些与Kubernetes相关的功能，从而免去Kubernetes管理与配置的复杂性。本演示将利用自动缩放功能，根据处理的HTTP请求（还支持许多其他基于KEDA的规则）将容器应用从0个副本扩展到20个副本。KEDA是一个基于Kubernetes的事件驱动自动缩放器，是一个可以添加到集群中的轻量级简单组件（https://keda.sh/）。Azure容器应用已包含它。

图8-48 HTTP缩放规则

图8-49 创建快速测试

让我们创建一个测试，目标如下：测试1000个虚拟用户访问容器应用演示的主页，运行测试300秒，并在前500秒内缓慢增加用户数量（从0到1000个用户，每秒增加）。

基本信息选项卡：

• 指定测试名称，其余保持默认。

测试计划选项卡：

• 添加请求：
  • 在UI中添加输入，请求名称“HomePage”，URL填写容器应用网站的地址（容器应用概览页面中的应用程序URL，形如 https://yyyyy.xxxxx.eastus.azurecontainerapps.io）。HTTP方法为GET。
  • 无输入文件。
  • 本演示无需身份标识。

参数选项卡：保持默认。

图8-50 负载测试详情

• 四个引擎实例（每个引擎最多250个用户）
• 线性
• 每个引擎250个用户
• 测试持续时间5分钟
• 升温时间4分钟（在第4分钟达到250个用户）
• 默认区域和流量模式

监视选项卡：

• 添加要跟踪的资源，本例中为Azure容器应用资源。如果测试涉及与数据库、存储、API等服务的集成，还可以添加更多组件。保持系统分配标识选项。

测试条件选项卡：

• 针对“客户端”指标，定义一个规则：对于定义的请求，“错误”百分比大于2%。如果此条件成立，测试将失败。

图8-51 测试页面

测试创建后将自动开始运行（如之前所定义）。在测试页面上，查找“测试运行”，单击正在执行的测试，等待执行完成。

图8-52 测试运行结果

您还可以进入Azure容器应用资源，打开指标资源管理器，将请求数与副本数进行比较，副本数应根据请求负载进行缩放。

图8-53 Azure容器应用指标资源管理器

---

总结

在本章中，您接触到了混沌工程的概念，它允许组织及其SRE团队对生产环境中运行的资源运行模拟故障。通过整合混沌测试，它使您能够在事件发生时识别任何关键中断，并让您的团队做好缓解准备。总体而言，为工作负载识别出的故障越多，它们就越可靠。

混沌工程最初由Netflix工程团队创立，他们将自己的经验转化为一个（现为）开源工具——Chaos Monkey。

混沌工程的概念现在也已在Azure Chaos Studio中可用。本章尝试解释并带您了解其存在的原因，并通过逐步演示指导您如何启用混沌实验，例如模拟针对Azure Ubuntu虚拟机的高CPU压力。

此外，本章还快速介绍了负载/性能测试，重点介绍了最近发布的Azure负载测试服务，并通过一个演示场景展示了其能力。