BenchCouncil交易基准，标准和评估1（2021）100010Fallout：分布式系统测试即服务MattFleming，Guy Bolton King，Sean McCarthy，Jake Luciani，Pushkala PattabhibiDataStax Inc.，美利坚合众国A R T I C L E I N F O关键词：分布式系统数据库性能阿帕奇卡桑德拉，脉冲星A B S T R A C T所有现代分布式系统都将性能和可伸缩性列为其核心优势。考虑到最佳性能需要仔细选择配置选项，并且典型的集群大小可以从2到300个节点不等，因此任何两个集群都很少完全相同。在这个大型配置空间中验证分布式系统的行为和性能具有挑战性，而没有跨越软件堆栈的自动化。在本文中，我们介绍了Fallout，这是一个开源的分布式系统测试服务，可以自动配置和配置分布式系统和客户端，支持运行各种工作负载和基准测试，并根据收集的指标生成性能报告进行可视化分析。我们已经在DataStax内部运行了5年多的Fallout服务，最近将其开源，以支持我们与Apache Cassandra，Pulsar和其他开源项目的合作。我们描述Fallout的架构及其设计的演变，以及我们在动态环境中操作此服务所学到的经验教训，其中团队使用不同的产品并支持不同的基准测试工具。1. 介绍构建具有高性能的数据库和分布式系统需要进行全面的测试和基准测试。性能测试在开发过程中完成得越早，解决问题的成本就越低[1]。软件团队现在被期望使用CI/CD [2]等技术来向用户交付频繁的版本。对于许多类型的产品，包括分布式系统和数据库，用户还希望系统具有弹性，永远不会丢失数据，并且始终实现高性能。需要强大的自动化测试工具来缩短开发时间并交付稳定的产品。复杂分布式系统的自动化测试需要严格控制软件的各个方面：从操作系统配置到应用程序级调优。 辐射演变成一个全栈编排系统，使我们能够测试和调整被测分布式系统的各个方面。Fallout是一种服务，它部署硬件资源，配置操作系统和分布式应用程序，在群集上运行工作负载或基准测试，并收集结果进行分析。通过丰富的基于YAML的说明，系统和应用程序的每个方面都可以详细和参数化。我们使用Fallout运行手动和自动测试的混合and Fallout辐射executes执行around 200 tests测试every一切day.这些测试用于验证新功能和优化的性能，在发布之前发现功能和性能退化∗通讯作者。并再现现场发现的问题。最近，我们还增加了对混沌测试的支持。自动化测试由Jenkins驱动，Jenkins是我们大多数团队的首选CI工具。本文的其余部分组织如下。在第2节中，我们讨论了我们构建Fallout的基本原理以及当时的现有工具。在第3节中，我们对辐射设计进行了高层次的概述，并在第4节中深入了解细节。 第5节说明了如何为用户显示Fallout测试运行结果。第62. 背景五年前，我们有一个名为cstar_perf的基于服务器的性能测试和比较工具，它可以将Apache Cas- sandra引导到已经配置的集群上，对其运行工作负载，并在网页上绘制性能结果。工作负载通过Web UI组成，并使用cassandra-stress [3]生成负载在集群上。cstar_perf为我们提供了一些灵活性，因为Cassandra安装可以通过多种方式进行配置，但它也有许多限制。 群集的大小是固定的，无法更改。工作量由若干线性步骤组成，每个步骤都可以调用少数工具中的一个。这给我们既没有模块化，我们需要支持不同的团队，电子邮件地址：matt@codeblueprint.co.uk（M.Fleming），guy@waftex.com（G.B. 金），肖恩麦卡锡@ datastax.com（S。 麦卡锡），jake@datastax.com（J. Luciani），datastax.com（P.Pattabhibi）。https://doi.org/10.1016/j.tbench.2021.100010接收日期：2021年8月6日;接收日期：2021年10月11日;接受日期：2021年10月20日2021年11月4日网上发售2772-4859/©2021作者。Elsevier B. V.代表KeAi Communications Co. Ltd.提供的出版服务。这是CC BY-NC-ND许可证下的开放获取文章（http://creativecommons.org/licenses/by-nc-nd/4.0/）。可在ScienceDirect标准和评价期刊主页：https://www.keaipublishing.com/en/journals/benchcouncil-transactions-on-benchmarks-standards-and-evaluations/BenchCouncil交易基准，M. 弗莱明，G. B.King，S.McCarthy等BenchCouncil交易基准，标准和评估1（2021）1000102对基准、工具和工作负载的不同偏好，以及同时运行多个测试所需Fallout被概念化以解决这些限制。有明确需要创建一个系统，可以无缝地将内部团队构建的过多工具和系统缝合在一起，以便他们可以在保持工具不可知性的情况下一起工作。还希望提供支持任何测试环境的能力，公共云或私有云。由于Fallout需要测试分布式系统，因此它需要支持涉及多个服务器/客户端集群和无数拓扑配置的场景，以及中断正常操作的工具，例如限制网络带宽和删除集群数据。虽然cstar_perf使我们能够分析单个测试运行的性能，但我们还希望能够通过从这些集群中收集工件来生成对结果的更好的洞察。为了鼓励不同利益相关者的采用，Fallout需要直观，简单和自我记录。目标用户群从经验丰富的数据库工程师到非开发人员。因此，Fallout需要使用一种声明性语言，这种语言对于非开发人员编写测试很简单。Fallout中涉及的工件需要持久化和版本化以供将来参考。 所有的测试配置、结果和工件都将存储在一个地方，这样一切都可以在我们的组织内进行简单的共享。总之，Fallout解决了以下工程挑战：• 构建一个测试服务，为多个团队提供一个单一的界面来运行测试和基准测试工具• 使用简单的测试配置文件将测试部署到准确反映真实配置的• 提取并保留测试运行工件以供以后分析• 对开发人员和非开发人员都易于使用Fallout的初始版本使用Jepsen [4]作为工作负载执行工具。这在很大程度上是一个务实的选择，因为Jepsen在最初的辐射团队中很有名，使用它可以避免需要通过创造一个全新的工具来重新发明轮子。Fallout扩展了Jepsen的正确性测试功能，在测试运行期间创建操作日志，并允许在测试完成时运行通过/失败检查。 随着时间的推移，Fallout已经发展成为一个更加注重性能的服务，但仍然保留了一些原始的Jepsen概念，如标记和操作日志。3. 架构Fallout作为单个服务运行，并公开一个REST API， 可以通过Python客户端API和命令行应用程序以及用户可以使用Web浏览器访问的WebUI访问。Fallout支持多个并发用户，同时允许每个用户独立存储和执行测试。对于其他用户的测试配置，授予测试配置的只读访问权限，这在多个工程师进行同一测试时特别方便，因为他们可以克隆测试配置并进行协作。持续集成工具使用Python客户端API和命令行应用程序将测试提交到Fallout的作业队列。 一旦作业到达队列的前端并且硬件资源可用，Fallout就会部署和配置测试的基础设施（设置），运行工作负载，然后收集测试工件并在测试完成后拆除基础设施。结果发布到中央服务器进行分析。Fallout维护测试每个步骤中涉及的所有操作的日志。Fallout的架构概述见图。1.一、3.1. 集群部署测试任务被提交给Fallout，Fallout根据基础设施中的可用硬件资源在内部调度它们。要在DataStax的数据中心（私有和公共）中配置集群Fallout依赖于一个专有的基础设施工具ctool。Fallout的开源版本包括支持使用Google Kubernetes Engine（GKE）来管理集群。ctool与云提供商无关，并抽象了Fallout测试的配置和部署步骤，因此用户只需在YAML测试配置文件中指定云提供商，实例类型和区域等高级要求。Fallout使用gcloud工具[5]处理GKE的预配置机器，并包括用于配置测试可能需要的资源的逻辑。例如，Fallout将自动向Kubernetes集群添加持久存储，以便在测试完成后可以从集群下载测试运行工件。用户还可以在配置群集资源的测试配置文件中指定自定义清单。Fallout监控来自集群的所有日志，并可以通过Fallout Web UI实时显示它们。一旦测试完成，集群被拆除，这些日志将永久存储在Fallout服务器上，以供离线分析。对集群运行性能测试需要应用工作负载和基准。Fallout还处理生成这些工作负载的客户端节点的配置和配置。所有客户端和服务器节点的数据和统计信息都是通过一个专用的观察者实例收集的，该观察者实例是以与客户端和服务器完全相同的方式为测试运行配置的：通过测试配置。在每个测试中，观察者实例在测试运行期间运行，并允许Fallout用户实时监控来自客户端和服务器的指标。当重新运行已知会出现性能问题的配置时，监视实时观察器节点通常非常重要，并且观察器可用于检测群集何时进入不良性能状态。在测试结束时，观察者指标被存档并保存到Fallout服务器本地，并在测试运行网页上可用。这将在测试执行完成后启用分析。最后，Fallout在测试完成后拆除基础设施，从而将分配的资源返回到云。3.2. 应用程序安装、配置和执行用于安装Apache Cassandra和Pulsar等应用程序的具体方法因版本而异，工程师通常不知道这些差异。Fallout会自动处理安装和系统配置，无论测试指定的是哪个版本。安装涉及到提取每个节点上的tarball，并更新cassandra.yaml配置文件，以使用部署阶段的额外更大磁盘- Fallout还需要处理每个单独节点的配置，以便在集群中工作。例如，ApacheCassandra要求集群中种子节点的IP地址是已知的，并在每个节点Fallout在客户端节点上安装了包括分析器和指标收集代理在内的基准测试工具。Fallout支持各种各样的工具，尽管目前只有少数工具在开源版本中可用。我们计划在未来做出更多贡献。每个基准都可以使用相同的YAML接口进行配置，配置中包含的各个选项将特定于每个基准。随着Fallout越来越受欢迎，越来越多的基准测试被添加进来，因为不同的团队喜欢不同的基准测试是很常见的。例如，YCSB是一个流行的开源基准测试，通常用于比较NoSQL数据库管理系统的相对性能。DataStaxStargate团队使用YCSB对每个版本的Stargate文档API性能进行基准测试。Fallout旨在适应这种异质性，同时仍然为用户提供相同的界面。这有一个额外的好处-因为支持多个基准的复杂性主要隐藏在Fallout中，使用Fallout的外部服务可以自动与任何基准一起工作，减少支持新团队和新工具所需的工作量。M. 弗莱明，G. B.King，S.McCarthy等BenchCouncil交易基准，标准和评估1（2021）10001033.3. 数据收集和分析Fig. 1. 辐射建筑。它直接链接到给定作业的Fallout测试运行（GitHub pull request）。能够从Jenkins工作导航到Fallout测试为了帮助运行后分析，Fallout将一系列日志和其他工件保存在中央服务器上，以便在测试运行完成后对其进行检查。这是分析作为手动测试运行的一部分收集的度量和其他基准数据的最常见情况。对于自动化测试分析，Fallout将把存档的指标推送到中央Grafana服务器，其他工具会在那里对它们进行进一步分析，包括Hunter，我们使用变化点检测的统计显著性检测工具[6]。Fallout使用工件检查器来检查日志中的特定错误或警告消息，并允许将测试运行标记为失败（如果存在）。其他工件检查器用于后处理文件。例如，hdrtool工件检查器合并从多个客户端检索的HDR文件[7]并产生聚合指标。即使Hunter自动检测到性能退化，工程师也可能需要查看测试运行期间收集的指标，以了解性能问题的原因。当用户需要检查观察者指标时，他们可以简单地从Fallout下载存档的工件，将其提取到他们的机器上，并使用包含Grafana的Docker映像来显示指标。3.4. 与CIFallout的自动化测试主要通过Jenkins驱动。 Jenkins使用Fallout API来启动测试运行，只要成功构建了来自GitHub的拉取请求。我们已经配置了Jenkins，run充当breadcrumb trail并简化测试运行后的分析。我们还运行每晚和每周的性能测试，这些测试在GitHub PR合并工作流之外安排，但仍然依赖于Jenkins 调用Fallout REST API。 Haxx是一个git仓库，用于存储Fallout测试文件的中央位置，因为Fallout本身不提供任何类型的版本控制，除了A）存储以前测试运行的YAML文件的只读副本和B）最新版本。Haxx还为Fallout YAML文件提供了模板，其中常见的配置片段（例如最佳的Apache Cassandra配置选项）可以存储在模板文件中并在测试过程中重复使用。这使我们能够大大减少 需要样板代码来支持大量的测试，其中只有机器大小，Apache Cassandra的版本或基准配置不同。更好的是，模板允许用户利用已知良好的性能选项，确保他们不会浪费时间分析配置不当测试导致的性能问题。4. 执行由于Fallout最初是作为Clojure的包装器创建的，因此必须用另一种JVM语言编写Fallout，以使开发更容易，Java被选为目标语言。尽管Fallout的开发主要是一个非常小的团队的责任，但Fallout受益于大量的贡献者，M. 弗莱明，G. B.King，S.McCarthy等BenchCouncil交易基准，标准和评估1（2021）1000104图二. 沉降测试配置示例。由于Java在DataStax中被广泛使用，编程语言的选择无疑是一个影响因素。一个类似的愿望，使配置界面作为欢迎尽可能地为用户提供服务，这导致了对配置文件使用YAML的决定。YAML语法对于新用户来说很容易学习，YAML语法突出显示在IDE和编辑器中很容易使用。Fallout4.1. 测试配置文件Fallout测试运行由单个YAML配置文件驱动，该配置文件具有许多必需的条目。测试描述机器和在这些机器上运行的服务一个节点是一个资源，服务在其上运行。一个节点的例子是一个多节点集群中的单个Apache Cassandra节点。节点组是节点的集合NodeGroup的一个例子是Apache Cassandra集群。集成是一组具有指定角色的节点组，测试运行配置文件将此概念公开给用户。合奏角色列表是：• 服务器：分布式服务器或集群，如Apache Cassandra• 客户端：基准或工作负载• 观察者：石墨等监控服务器• 控制器：外部控制器，如Jepsen。图2显示了Fallout测试配置文件的示例工作负载是从一个或多个阶段构建的，这些阶段是Fallout中并发的基本单元。每个阶段可以运行一个或多个模块，指定多个模块并行执行它们。阶段始终按顺序运行，并且阶段将不会开始执行，直到前一阶段完成。4.2. 测试供应生命周期当测试执行时，测试中的每个NodeGroup都要转换许多状态。有三种类型的状态：未知，Transitional和Runlevel。当节点组从一个状态移动到另一个状态时，就进入了过渡状态。运行级状态表示节点组当前没有转换的稳定状态，并根据UNIX运行级概念建模-节点组前进到更高的级别，每个级别都比前一个级别具有更多的功能。状态转换在NodeGroup上执行配置和配置操作，Fallout使用NodeGroup的当前状态来保证状态之间只能发生合法的转换。使用状态机，Fallout不可能在配置NodeGroup之前对其进行配置。如果在转换过程中遇到任何错误，例如如果Fallout无法安装分布式应用程序，则NodeGroup将进入FAQlist状态，整个测试运行将失败。转换图如图所示。3.上的椭圆形状态左和右表示过渡状态，矩形状态中间的代表运行级状态。4.3. 模块、提供程序和配置管理器向Fallout添加对新基准或工具的支持需要向Fallout代码库添加3个新组件：模块，提供程序和配置管理器。提供者允许通过API访问服务或工具，这些由Fallout测试工具调用以在节点上运行命令。例如，NoSqlBench- PodProvider负责在Kubernetes pod上执行nosqlbench [8]提供者还可以依赖于其他提供者，这使得可以表示基准测试仅在Kubernetes集群上运行时可用。Fallout支持Chaos Mesh [9]，这是一种在集群上运行混沌实验的工具，但是由于它只在Kubernetes上可用，Fallout将拒绝将其部署到任何不符合Kubernetes Provider依赖的环境中。配置管理器负责配置和取消配置在节点上运行的软件以及启动和停止服务。此外，配置管理器向M. 弗莱明，G. B.King，S.McCarthy等BenchCouncil交易基准，标准和评估1（2021）1000105图三. NodeGroup转换图。节点，使相关服务可用于测试工作负载中的模块。最后，模块是基准测试中面向用户的组件。模块定义支持的关键字和参数，这些关键字和参数可以通过YAML配置文件传递给基准测试。由于这在测试配置和基准测试本身之间提供了一层间接性，因此Fallout通常只支持基准测试所支持的参数的一个子集，尽管如果用户想要最大的灵活性，通常会有一个args参数，它可以在没有任何过滤的情况下传递参数虽然Fallout支持许多不同的基准测试，但我们了解到的一个问题是，用户需要某种支持模块，允许他们手动运行目前不支持的基准测试。提供了一个bash模块来填补用户需要运行简单脚本或将基准下载到节点并手动运行的空白。bash模块的扩展使用是不受欢迎的，因为我们已经看到它导致难以理解在测试脚本之间复制的shell脚本。4.4. 标记器和伪影检查器一旦测试完成，Fallout需要一种方法来验证被测系统在测试期间的行为是否正确。Fallout中的标记是负责确保在测试过程中不会发生可能使结果无效的错误的组件。 这对于性能测试很重要，即使检查器本身不执行任何类型的性能分析-未通过基本检查的测试的任何性能结果都可能无效，因为测试不是在真实条件下运行的。NoFailure是一个非常基本的检查器的示例，见图4。 每月平均每日测试运行。表1测试运行统计。年总平均值最小值最大值2016 759 8 0 442017 5512 15 0 1012018 58625 160 0 5622019 64633 177 0 3612020 62616 171 0 4212021 39945 197 34 349在一次测试中失败了操作的历史记录作为参数传递给检查器，以便他们可以对其进行任意检查。Fallout测试中可以包含的检查器数量没有限制，只有当所有检查器都通过时，测试才会通过。一个相关的概念是工件检查器，它对测试后收集的工件执行相同类型的验证过程 运行完成。一个经常用于Apache Cassandra测试的工件检查器是SystemLoglog，它检查Cassandra4.5. 测试队列当Fallout首次推出时，测试运行在提交后立即执行。随着Fallout越来越受欢迎，我们内部基础设施上的VM争用导致测试失败。添加了一个简单的队列机制来解决这个问题，它在尝试提交资源请求之前检查VM的可用性。随着时间的推移，它已被调整，变得更加强大和公平。例如，它现在倾向于用户较少的测试运行，以防止任何人垄断系统。有了这一点，Fallout现在每天可以处理200多个测试运行。图4显示了每月每日测试运行的平均次数。表1显示了这一时期的其他年度统计数据4.6. REST APIFallout命令行客户端使用Python库构建，用于访问Fallout RESTAPI。让这个API可用，而不是只通过Web UI提供对Fallout的访问，帮助了许多其他服务利用Fallout的测试运行功能，毫无疑问，这也导致了Fallout在DataStax的受欢迎程度上升。最近，我们使用Fallout5. 结果一旦在集群上运行了一个或多个基准测试，我们将使用多个工具来显示基准测试和操作系统指标。Fallout包含一个内置的方式来显示客户端基准测试指标作为Web UI的一部分，但我们通常会收集更多的指标，例如Apache Cassandra和OS指标。 我们使用一个中央Grafana服务器，称为历史服务器，来显示在测试运行期间积累的所有历史指标。M. 弗莱明，G. B.King，S.McCarthy等BenchCouncil交易基准，标准和评估1（2021）10001065.1. 执行情况报告Fallout可以生成性能报告，其中可视化从单个测试运行中收集的metrics 。 业 绩 报 告 的 基 础 是HdrHistogram 数 据 集 的 顶 部 [7] 。HdrHistogram格式是直方图数据的事实标准，许多基准测试工具都可以使 用 它 。 我 们 大 量 使 用 的 一 个 功 能 是跨 多 个 客 户 端 合 并HdrHistogram数据，从而可以跨节点拆分负载，收集单个HDR文件，并将它们合并以汇总群集上的总负载。最后，HDR文件以单一文件格式捕获吞吐量和延迟。图5示出了性能报告的示例使用时间序列数据来显示时间序列数据，这对于工作负载不具有一致行为的数据库工作负载是非常宝贵的，例如，当内存驻留数据结构填满并刷新到磁盘时，它会发生变化。能够看到整个测试运行持续时间的度量，使用户更容易发现测试遇到意外状态的情况。用于创建图表的指标数据可以通过从右侧的下拉菜单中选择一个项目来更改 页面和图5中的示例中的测试运行记录的每个阶段 一组单独的指标。将时间序列指标数字化到一个数字中是不可能手动完成的，因此我们还提供了汇总指标，列出了测试运行的吞吐量、平均值、中位数和平均值，尽管这些指标在图中没有列出。5、由于空间不足。性能报告对于所有登录的Fallout用户来说都是全局可读的，我们已经使用此功能在合作调查性能问题的团队之间共享测试运行-有一个单一的位置可以参考测试运行单独的性能报告可以组合到一个报告中，允许用户查找测试运行之间的性能差异。 图 6显示了分组性能报告的示例。在组报告中使用不同的颜色显示每次运行的图形度量，并且运行的详细信息包括在图表下方的关键字中，由于缺少空间，该关键字未再次包括在图6中。组性能报告对于比较不同版本的Apache Cassandra或服务器或客户端的不同配置选项特别有用。当业绩报告开始出现时， 在Jiratickets中，我们可以看到性能改进和退化，我们知道这个特性作为一种快速可视化基准性能的方法已经取得了成功。随着时间的推移，这些性能报告的链接变得更加有用，因为工程师可以通过随时可以运行的测试来参考以前的基准测试，他们可以重用这些测试来解决新问题。5.2. 历史服务器虽然性能报告提供了一种有用的方法来查看少量测试运行的性能以进行比较，但是测试运行的所有度量都显示在时间序列图表中，这使得它不适合分析历史趋势。当我们需要了解我们的自动化测试的性能在过去几天或几周内是如何变化的时，我们使用一个中央Grafana服务器，我们称之为历史服务器。此服务器聚合来自客户端和服务器的操作系统和应用程序指标以进行历史分析，并且是发布工程师评估DataStax产品质量的方法之一。聚合的指标是非常粗粒度的，以减少磁盘空间使用并计算简单的汇总统计数据-每个指标都减少到每次运行的单个数据点，而不管测试运行的持续时间考虑到历史服务器是发布质量工程的核心组件，运行它所用的硬件资源非常有限可能会让人感到惊讶历史服务器的原始版本运行在一个虚拟机上，目前的配置使用2个CPU、4 GB RAM和80 GB硬盘驱动器。我们相信历史之所以服务器已经存活了很多年，没有任何类型的停机时间，也没有耗尽其小磁盘空间，这要归功于我们应用于所有指标的积极的石墨保留策略。默认的度量名称空间temporary具有1 h：15d的保留策略，这对于一个因为指标可以每小时更新一次，并在15天后自动删除。我们使用一个单独的命名空间performance_regressions来更长时间地保留指标，但频率降低：每天最多记录一次指标，每周记录一次指标，两者都保留10年。Graphite图7示出了来自历史服务器的Grafana仪表板之一，其包括用于吞吐量、错误计数和百分位度量的面板6. 经验教训Fallout经过多年的发展，我们发现，虽然我们最初的一些设计选择是正确的，并经受住了时间的考验，但其他人是错误的，需要重新评估。以及一些我们从未预料到的问题6.1. 配置文件应该简短而富有表现力测试配置文件的行数越多，引入一个bug。Fallout的目标之一是在测试和基准测试模块中提供足够的支持，常见用例只需要小的测试运行配置文件，从而降低用户出错的可能性。这仍然是一个持续的努力，因为当添加对新模块的支持时，常见用法需要时间才能出现，但最终结果是用户对Fallout更有信心。这个目标很好地帮助我们创建了一种易于理解的有用的配置语言6.2. 配置文件的模板化鼓励重用随着Fallout积累了更多的用户和测试运行配置的数量增加，我们注意到许多用户开始在配置文件中复制和粘贴YAML。发生这种情况的一种 常见 情况 是， 当用 户需 要 跨多 个版 本的例 如， 针对 ApacheCassandra 3.11和4.0运行相同的基准测试以比较性能。我们在Fallout的YAML解析器中添加了对mustache [ 11 ]模板的支持即使使用mustache模板，我们也发现用户希望将YAML的常见块分离到不同的较小文件中，并将它们包含在多个配置文件中。此外，用户希望能够将这些文件存储在版本控制系统中。Fallout不支持这些功能，因此创建了haxx项目，该项目使用Jinja [12]模板来允许测试片段的组合，并通过git仓库提供版本控制6.3. 测试需要访问外部文件我们在早期没有预料到的一个特性是，测试、基准测试和工具需要访问外部文件的能力，例如配置文件。我们最初通过扩展测试模块来从GitHub gist获取外部文件，或者通过在运行时基于Fallout YAML配置中的键和值生成测试配置文件来当我们添加新模块时，这种方法无法扩展，现在可以使用统一的方法要访问外部文件，请使用“文件名”语法，而不考虑测试运行配置中使用的模块M. 弗莱明，G. B.King，S.McCarthy等BenchCouncil交易基准，标准和评估1（2021）1000107图五. 性能报告示例。见图6。 分组性能报告示例。见图7。 Grafana仪表板。6.4. 长时间运行的测试受益于语义检查和幂等性检查YAML文件的语法错误非常简单，有许多Java库可以执行此操作，例如SnakeYaml [13]是Fallout使用的库。然而，语法错误只是困扰用户的问题之一由于测试配置中的大多数YAML值都被Fallout以外的工具使用，因此验证这些值的语义是具有挑战性的。M. 弗莱明，G. B.King，S.McCarthy等BenchCouncil交易基准，标准和评估1（2021）1000108按预期行事。我们遇到过这样的情况：NoSQL表名中的一个错误字符导致所有后续测试阶段失败，并且只有在测试运行后才被触发一个小时此外，如果Fallout无法确定集群的运行级别，重新运行Fallout测试有时需要拆除基础设施并重新启动。其他部署工具，如Terraform [14]解决了这个问题，它允许重复应用相同的部署步骤，而不会导致底层机器的任何更改，如果这些步骤的相应配置没有更改。Fallout确实尝试检测当前集群运行级别并跳过不必要的配置步骤，但检测并不完美。这种检测在Fallout的集群重用机制中使用，该机制通过命名一个集群并在测试运行结束时请求将其留在特定的运行级别来触发;具有相同测试定义的后续测试运行将找到命名的集群，检测其运行级别，并从那里继续。这使得可以更快地创建测试，并且在某些特殊情况下，可以跳过大数据测试的缓慢数据加载步骤。然而，根据我们的经验，大多数用户不会遇到需要使用这些功能的情况。7. 相关工作自动化测试，包括运行基准测试，是确保软件项目质量的重要组成部分[15]。在[16]中讨论了将基准测试集成到持续部署管道中，重点是使用具有阈值的性能指标来决定是否应该允许将更改引入生产。由于我们使用Fallout来测试最终将部署到各种环境（从云到内部部署）的软件，因此没有内置功能可以根据性能变化阈值来控制部署。相反，使用变化点检测来检测统计上显著的变化，并且需要开发人员做出部署决策。使用Fallout自动化部署是我们未来的目标之一。MockFog 2.0 [17]通过在云中模拟雾基础设施来实现雾应用实验，并具有与Fallout非常相似的设计。MockFog和Fallout都提供基础设施，配置和部署应用程序，运行测试和基准测试，甚至使用状态（分别为Action状态和NodeGroup状态）来定义内部状态机的合法转换。 然而，MockFog使 用 Docker 来 管 理 应 用 程 序 ， 而 Fallout 支 持 本 地 和 基 于Kubernetes的应用程序，这与Apache Cassandra和Apache Pulsar的典型部署更接近。MockFog还使用Ansible来配置基础设施，该基础设施提供了Fallout实现中部分缺失的幂等状态更新。Adelphi [18]是一个开源QA工具，运行在Ku- bernetes之上，允许用户对Apache Cassandra运行数据完整性和性能测试。它被包装成一个掌舵图，包括有限数量的基准和测试工具，以便用户可以将两个集群相互比较。Adelphi负责执行测试，但不提供创建和终止底层Kubernetes集群的工具，也不提供基准测试和测试结果以供分析。MongoDBDSI与Fallout有许多共同之处，包括配置虚拟机、配置数据库服务器和基准测试、收集自动化和可视化检查的结果以及最终在测试完成时拆除基础设施的组件。Fallout和DSI都使用YAML配置文件来控制测试运行。然而，Fallout在许多方面与DSI不同。Fallout是用Java写的，DSI是用Python写的。 虽然DSI主要针对Amazon EC2，但Fallout目前可以启动测试在Google Cloud Platform、Amazon EC2、Microsoft Azure以及我们内部基于OpenStack的私有云上。因为ctool在Fallout创建时已经存在，所以Fallout具有非常模块化的架构，并依赖于其他工具和组件来执行某些任务，而大多数 DSI的相应功能内置于服务中。 最后，据作者所知，DSI没有公开API供其他工具调用。在[20]中讨论了通过在更少的物理服务器上运行许多虚拟机来降低测试非常大的分布式系统的成本的工作。这项工作的目标是具有数千个节点的网络服务，这些节点比典型的Apache Cassandra或Pulsar集群大得多。RocksDB包括运行基准测试和分析结果的工具，但没有项目来处理设置和拆除[21]第21章：我的心同样，SAP已经发布了一些工作，展示了他们如何将性能测试集成到CI流程中[22]，但没有详细介绍如何将测试部署在测试基础设施上8. 结论Fallout是一个分布式系统测试服务，能够自动配置客户端和服务器，安装，配置和执行分布式应用程序和工作负载，并集中收集结果供以后分析。 我们在DataStax内部使用Fallout，它驱动了我们的ApacheCassandra和Apache Pulsar产品的整个性能和测试生态系统。Fallout的生命始于 这是一个非常具体的目的，经过多年的工程努力，它已经发展成为我们性能和质量的支柱，它为我们的工程团队提供了分布式系统的全自动端到端测试。Fallout的REST API对于新团队利用Fallout的分布式测试至关重要，并鼓励了众多补充Fallout的工具和服务的诞生。我们的Fallout服务器每天执行大约200个测试，在繁忙的日子里运行接近400个测试。由于我们的每个工程团队对基准测试、集群配置和云基础架构的类型都有自己的偏好，因此所有这些组件都可以在Fallout中进行配置，Fallout在设计时考虑了模块化。我们已经扩展了这种模块化，允许测试和基准测试加载外部文件，并添加了模板，以便用户可以重用测试配置片段，而无需复制和粘贴。我们将Fallout作为一个开源项目发布，希望开源社区能够从我们的投资中受益，以及我们在生产中运行Fallout超过5年的经验教训。致谢我们要感谢匿名评论者的宝贵反馈和建议。《辐射》是由JakeLuciani、Joel Boghton和Philip Thompson创作的，我们感谢他们的决定。创建一个新的工具来解决分布式系统测试的复杂问题。历史服务器由Pierre Laporte创建，它的稳定性是由它一直是这是整个辐射生态系统中需要更新最少的。Christopher Lambert主要负责整合ctool对Fallout的支持，James Trevino继续维护和改进Fallout。Ulises CerviñoBeresi创建了haxx。Shaunak Das贡献了许多测试模块。更多的人为Fallout和相关测试服务做出了贡献，我们感谢他们的所有努力。 Fallout的开源版本非常感谢Jake Luciani和Jonathan Ellis在内部在DataStax。M. 弗莱明，G. B.King，S.McCarthy等BenchCouncil交易基准，标准和评估1（2021）1000109引用[1]B. Boehm，软件工程，IEEE Trans.Comput. C-25（1976）1226[2] J.Humble ， D. Farley ， Continuous Delivery ： Reliable SoftwareReleases ThroughBuild ， Test ， and Deployment Automation ， Addison-Wesley，2010.[3]ApacheCassandra，Cassandra压力，2021，URLhttps://cassandra.apache.org/doc/latest/cassandra/tools/cassandra_stress.html，访问日期：2021-08-05。[4]K. Kingsbury，分布式系统安全研究，jepsen，2021，URLhttps：//jepsen.io/，访问时间：2021-07-29。[5]谷歌 云 SDK 文档， Gcloud 工具 概述， 2021, 网址https：//cloud.google.com/sdk/gcloud，访问时间：2021-10-07。[6]D. Daly，W.布朗，H。Ingo，J.Bradford，使用变化点检测来识别连续集成系统中的软件性能回归，在：2020年ACM/SPEC性能工程国际会议（ICPE '20）会议记录http://dx.doi.org/10.1145/3358960。三三七五七九一。[7]HdrHistogram，高动态范围直方图，2021，URL http：//hdrhistogram. org/，检索日期：2021-08-05。
我的内容管理
展开
