大数据实用 DevOps/迭代增强

简介

DICE 的目标是提供一个新的 UML 配置文件和工具，帮助软件设计师分析数据密集型应用程序的质量，例如性能、可靠性、安全性以及效率。此外，DICE 开发了一种新的方法，涵盖质量评估、架构增强、持续测试以及敏捷交付，依托于新兴 DevOps 范式的原则。特别是，DICE 的目标之一是构建工具和技术来支持数据密集型应用程序质量特性的迭代改进，通过向开发者提供反馈来引导架构设计变更。

为了实现这一目标，DICE 增强工具被开发出来，以向 DICE 开发者提供关于应用程序运行时行为的反馈，利用来自 DICE 监控平台 (DMon) 的监控数据，帮助他们迭代地增强应用程序设计。DICE 增强工具引入了一种新方法和一个原型，以弥合测量和 UML 图表之间的差距。它将监控数据与 DICE UML 模型相关联，旨在弥合 UML 抽象与具体系统实现之间的语义差距。基于获取的数据，DICE 增强工具允许开发者在 DICE IDE 中进行更精确的模拟和优化，可以依赖于实验数据，而不是未知参数的猜测。DICE 增强工具还支持开发者进行重构场景，旨在以 DevOps 方式迭代地提高应用程序质量。据我们所知，在数据密集型应用程序 (DIA) 的研究文献中，没有成熟的方法可以解决从测量返回软件模型、注释 UML 以帮助分析应用程序设计的难题。DICE 增强工具旨在填补这一空白。

DICE 增强工具的核心组件是两个模块

• DICE 弥合差距 (FG) 模块，一个专注于用于模拟 和优化工具 的 UML 参数统计估计工具。该工具通过依赖于运行时收集的监控信息，为参数化应用程序设计时 UML 模型提供数据。目标是增强和自动化将应用程序性能信息传递给开发者的流程。
• DICE 反模式与重构 (APR) 模块，一个用于反模式检测和重构的工具。该工具根据观察到的和预测的性能和可靠性指标，为 DIA 的设计师提供建议改进。目标是优化一个参考指标，例如最大化延迟或最小化平均故障间隔时间 (MTTF)。

动机

我们开发了 DICE 增强工具，它源于根据测试和运行期间获取的数据（尤其是性能数据）推断软件设计中的不良实践（即性能反模式）的问题。由于系统运行时和设计时之间的抽象级别不同，开发者必须获得运行时信息，尤其是性能指标，并将它们反映到设计时模型中，才能分析应用程序设计的质量并推断重构决策。

为了在设计时模型中支持性能分析，开发者需要依赖于软件性能模型进行进一步的分析和评估。但是，为了提供可靠的估计，输入参数必须不断更新并准确估计。准确估计具有挑战性，因为某些参数没有被日志文件明确跟踪，需要进行深度监控仪器，这会造成很大的开销，在生产环境中是不可接受的。此外，性能反模式 (AP) 是通过不正确的软件决策识别的反复出现的问题。软件 AP 在行业中得到了广泛的研究。软件项目的规模和复杂性不断增加，会导致新障碍更频繁地出现。因此，在项目生命周期的早期阶段识别 AP 可以节省资金、时间和精力。为了检测 DIA 的性能反模式，首先需要指定设计时模型（即架构模型）和性能模型，以及模型到模型的转换规则。架构模型作为系统的设计时模型，在 DICE 中由 UML 指定。在实践中，开发者通常使用 UML 的活动图和部署图来建模系统行为和基础设施配置。作为最先进的技术，UML 是一种通用的软件工程建模语言，它提供了一种标准化的方法来可视化系统的设计。尽管它很受欢迎，但 UML 不适合自动分析（例如性能评估）。因此，模型分析阶段需要将带注释的 UML 图表转换为性能模型，例如 Petri 网、分层排队网络 (LQN)；我们的工作也考虑将 LQN 作为性能模型。就性能指标而言，LQN 比 UML 更有优势，因为 LQN 不仅以简洁易懂的方式描述了这些指标，而且还支持各种分析和仿真工具，例如 LINE、lqns，因此允许自动化系统性能分析以进一步检测性能反模式，并进一步检测 AP。

为了实现上述目标，我们开发了 DICE 增强工具，以弥合运行时性能测量与设计时模型之间的差距，用于反模式检测和重构。

现有解决方案

DICE-FG 最初是依赖于 MODAClouds 项目提供的基线开发的，该基线称为 FG，它是一种弥合开发和运维之间差距的方法。在 DICE 中，该工具经历了重大修订，正在集成和调整以在 DIA 数据集上运行。与原始 FG 相比，DICE-FG 中引入了架构变更。与 DICE-FG 不同，APR 没有基线软件可以开始使用，因为此领域中唯一可用的工具不适用于 UML。因此，据我们所知，它是 DICE 的一项原创贡献，在 UML 领域是新颖的。

在我们进行桌面研究的过程中，我们发现了以下解决方案，可以被认为是我们 DICE 增强工具的直接竞争对手。

LibReDE：一个包含用于在线和离线分析的资源需求估计方法的实现库。LibReDE 用于一般分布式系统，而 DICE-FG 专门针对数据密集型应用程序设计；LibReDE 主要关注性能模型的资源需求估计，而 DICE-FG 则关注性能和可靠性估计；LibReDe 的估计输入的测量数据是从标准 CSV 文件中读取的，而 DICE-FG 的输入数据的格式是更流行的 JSON 文件，通过 DMon 传递；LibReDE 无法将估计结果反映到设计时模型中，而 DICE-FG 则不断地使用估计的性能和可靠性指标对设计时模型（用 DICE 配置文件注释的 UML 模型）进行参数化，这可以告知开发者如何重构软件架构。

KieKer：是一个可扩展的框架，用于监控和分析并发或分布式软件系统的运行时行为。KieKer 支持应用程序级别的性能监控，包括允许选择数据以进行进一步分析的过滤器。然而，DICE-FG 可以分析设计时模型，以从运行时监控数据中提供更准确的模型参数推断。因此，DICE-FG 工具不仅仅是简单的监控，它被设想为一个机器学习组件，它了解应用程序软件架构，并可以利用它来改进参数学习。

PANDA：它是一个框架，用于通过性能反模式来解决结果解释和反馈生成问题。DICE-APR 遵循类似的方法来自动检测和解决性能问题。PANDA 和 DICE-APR 之间的共同点是它们都利用 UML 模型作为它们的设计时模型（即架构模型），而 DICE-APR 的输入 UML 模型则用特定配置文件（DPIM、DTSM 和 DDSM）进行注释，这些配置文件指定了大数据应用程序和平台的独特属性。PANDA 使用排队网络作为其性能模型，而 DICE-APR 可以考虑 Petri 网或分层排队网络模型。DICE-APR 的重构处理专注于大数据应用程序，并将改进以前关于重构云应用程序的工作，它将考虑大数据应用程序的硬件和软件知识。

PAD: PAD 是一个基于规则的性能诊断工具，名为性能反模式检测（PAD）。PAD 仅关注基于组件的企业系统，针对 EJB 应用程序，而 DICE-APR 则关注大数据应用程序和平台。它们都基于对运行系统的监控数据，但 PAD 的范围仅限于特定领域，而 DICE-APR 的起点是更通用的数据密集型应用程序的 UML 模型。

工具的工作原理

DICE 增强工具旨在迭代地增强 DIA 的质量。增强工具旨在提供大数据应用程序的性能和可靠性分析，使用分析结果更新 UML 模型，并在检测到性能反模式时提出设计重构建议。下图显示了增强工具的工作流程。它涵盖了其所有预期功能，这些功能将在下面详细讨论。

DICE 增强工具

DICE-FG

作为增强工具的核心组件，DICE-FG 工具扮演着两个角色

• 更新设计时模型的参数（使用 DICE Profile 注释的 UML 模型）
• 在 UML 中提供数据密集型应用程序的资源使用细分信息

这些功能共同为 DICE 设计师提供了以下可能性：

• 受益于模拟和优化模型的半自动化参数化。这支持 DICE 的状态目标，即降低 DICE 平台的学习曲线，以便那些在性能和可靠性工程方面技能有限的用户能够使用。
• 在 Eclipse 中检查 DICE-FG 自动放置的注释，以了解工作负载在软件和基础设施资源上的资源使用情况。

DICE-FG 工具的主要逻辑组件是分析器和执行器。下面我们将描述每个组件。

• DICE-FG 分析器：DICE-FG 分析器执行必要的统计方法以获得性能模型参数的估计值，依赖于输入文件上可用的监控信息。
• DICE-FG 执行器：DICE-FG 执行器更新 UML 模型中的参数，例如资源需求、思考时间，这些参数是从 DICE-FG 分析器获取的。

DICE-APR

DICE-APR 模块旨在实现以下目标

• 将使用 DICE Profile 注释的 UML 图转换为性能模型，以进行性能分析。
• 以正式的方式指定选定的流行 DIAs AP。
• 从性能模型中检测潜在的 AP。
• 生成重构决策以更新架构模型（手动或自动），以根据 AP 解决方案修复设计缺陷。

APR 模块的组件是模型到模型 (M2M) 转换 (Tulsa)、反模式检测和架构重构 (APDR)，如下所述。

• 模型到模型 (M2M) 转换 (Tulsa)：该组件提供将使用 DICE Profile 注释的 UML 模型转换为质量分析模型的功能。目标性能模型是分层排队网络。
• 反模式检测和重构 (APDR)：该组件依赖于 Tulsa 的分析结果。选定的反模式（即无限等待 (IW)、过度计算 (EC)）被正式指定，以识别模型中是否存在任何反模式问题。根据发现的反模式的解决方案，将提出重构决策（例如，组件替换或组件重新分配）来解决它们。架构模型将共享回 DICE IDE 以进行演示，以便用户决定是否应该应用建议的修改。

开放挑战

DICE 增强工具假设设计师使用 UML 来表示架构模型（即活动图和部署图），并使用 LQN 模型作为性能模型。如果没有 UML 模型，用户必须根据他们的架构模型手动定义 LQN 模型。这可能会导致额外的努力。此外，DICE-APR 目前可以检测两种性能反模式，其目标是基于 Storm 的大数据应用程序。

应用领域：已知用途

DICE FG

DICE-FG 已跨越各种技术，包括 Cassandra、Hadoop/MapReduce。例如，DICE-FG 为 hostDemands 提供了一种新颖的估算器，它能够有效地解释对大数据系统监控的所有状态数据。大数据应用程序的 hostDemands 可以被看作是请求在资源上花费的时间。例如，Cassandra 查询类型为 $c$ 在 Cassandra 集群的节点 $r$ 上的执行时间。DICE-FG 分发中包含了一种名为 EST-LE（逻辑扩展）的新需求估算方法。此方法能够使用概率最大似然估算器来获得 hostDemands。这种方法比以前的方法 est--qmle 更具表现力，因为它除了通过监控获得的状态样本外，还包含有关请求响应时间的信息。为了提供这种方法而克服的一个障碍是，由此产生的最大似然方法在计算上难以处理，导致似然函数计算的执行时间非常慢。还开发了一种渐近逼近方法，它允许即使在具有多个资源、请求类型和高并行级别的复杂模型中也能有效地计算似然函数。

DICE-APR

DICE-APR 的实际应用是针对基于 Storm 的应用程序。DICE-APR 适合基于 Storm 的应用程序有两个原因。首先，由于 Storm 拓扑可以被视为交换消息的缓冲区和处理元素的网络，因此将它们映射到排队网络模型中是很自然的。Storm 应用程序的核心元素（即 Spout 和 Bolt）之间的交互以及部署信息也可以很容易地由 UML 活动图和部署图指定，这些图在语义上类似于 LQN 模型。因此，DICE-APR 将基于 Storm 的应用程序的 UML 模型（使用 DICE 和 MARTE Profile 注释）作为输入，并生成一个性能模型（即分层排队网络 (LQNs) 模型）以进行性能分析。其次，在软件工程中，AP 是在不同层次结构级别（架构、开发或项目管理）中由不正确的软件决策识别的反复出现的问题。性能 AP 在行业中得到了广泛的研究。然而，其中很少有人关注数据密集型应用程序的 AP。因此，我们研究了三种经典的 AP，即循环寻宝、Blob 和扩展处理，并为 DICE-APR 定义了基于 Storm 的应用程序的两种反模式（即无限等待和过度计算）。以下是这些 AP 的问题陈述以及相应的解决方案。

• 无限等待 (IW)：当一个组件必须向多个服务器请求服务才能完成任务时发生。如果每个服务都需要大量的时间，性能将受到影响。为了解决这个问题，DICE-APR 报告导致 IW 的组件，并向开发人员提供组件复制或重新设计建议。
• 过度计算 (EC)：当一个处理器执行应用程序的所有工作或保存应用程序的所有数据时发生。表现为过度的计算，会降低性能。为了解决这个问题，DICE-APR 报告导致 EC 的处理器，并向开发人员提供添加新处理器以迁移任务的建议。

因此，DICE-APR 使用 LINE 求解器分析基于 Storm 的应用程序的性能模型，如果检测到上述性能反模式 (AP)，则提供重构建议。

结论

DICE 增强工具的主要成果如下

DICE FG 提供统计估计算法来推断应用程序的资源消耗，并提供拟合算法将监控数据与参数统计分布相匹配，并使用上述算法来参数化用 DICE 配置文件注释的 UML 模型。

DICE APR 有助于将用 DICE 配置文件注释的 UML 模型转换为 LQN 模型，定义和指定两个 AP 以及 DIA 的相应 AP 边界，从模型中检测上述 AP，并提供重构建议来指导开发人员更新架构。