使用亚马逊 DynamoDB 加快您的多区域战略：第 1 部分

当您决定跨多个地理区域运行应用程序时，需要回答许多问题。首先，业务驱动因素是什么？弹性？事实证明，您的应用程序对灵活性的要求，例如可用性和灾难恢复，可以在单个 亚马逊云科技 区域内得到满足。如果您确实需要多区域解决方案，则需要考虑诸如如何：

  • 使您的关键数据在这些区域之间保持同步和一致。
  • 随着数据量和用户流量的增加，保持应用程序的可扩展性、可靠性和性能。
  • 即使在故障场景下也能正常运行。
  • 以最小的运营开销管理您的解决方案。

实施多区域战略可能是一项艰巨的任务，其中一些最大的挑战与数据有关。在这篇文章中，我们从头开始介绍如何制定多区域战略——确定驱动因素，重点是将弹性作为战略不可分割的一部分。然后，我们将介绍 使用 亚马逊云科技 区域在 亚马逊网络服务 (亚马逊云科技) 上构建弹性多区域应用程序的方法。最后，我们将介绍如何使用 Amazon Dynamo DB 及其久经考验的多区域数据复制功能来帮助解决这些挑战。我们展示了一种渐进的方法，可以将您的数据架构从单个区域发展到多个区域。

无论您是刚接触 DynamoDB 还是已经在运行 DynamoDB 支持的应用程序，本系列文章都将为您提供指南，帮助您从大处着眼，从小处着手，随着业务需求的增长超出单一地理区域和 亚马逊云科技 区域，按照自己的节奏进行扩展。

多区域部署的业务（和其他）驱动因素

在踏上多区域之旅之前，您必须仔细考虑跨多个区域运行应用程序和数据库的业务驱动因素。以下是我们经常听到 亚马逊云科技 客户来信的原因：

  • 弹性（高可用性和灾难恢复） — 自然灾害、硬件故障、软件错误和人为错误可能会导致业务运营失误，从而对您的业务产生负面影响。您需要一个灾难恢复解决方案，让您的企业在故障条件下继续运营。该解决方案将保护您的企业免受销售机会损失、法律影响、品牌负面影响和客户信任受损的影响。您可能还需要比单个区域内可以实现的 99.99%（ 四个 9 ）更高的可用性。如果您需要 99.999%（ 五个 9 ）的可用性，则必须使用至少两个区域。
  • 地域扩张 — 如果您的组织决定将业务扩展到新的地理区域、国家甚至大洲，则您的应用程序需要在离用户所在位置更近的地方运行，以提供更快的响应时间和良好的客户体验。

亚马逊云科技 客户通常将灵活性作为主要驱动力，然后发展到地域扩张。即使你的主要驱动力是地域扩张，你仍然应该考虑灵活性。

作为最佳实践，您的多区域策略应始终包括弹性策略。更广泛地说，在构建对您的业务至关重要的所有应用程序时，弹性应该是基本考虑因素，就像安全性一样。

要全面了解在 亚马逊云科技 上构建应用程序时的灵活性主题，请参阅 可靠性支柱 — 亚马逊云科技 架构完善的框架 和 亚马逊云科技 上的工作负载 灾难恢复：云端恢复 。

除了业务驱动因素外，您还必须考虑可能影响将数据复制到其他区域的能力的合规性要求。例如，安全问题和对政府数据请求的担忧促使人们将数据保存在地缘政治或法律实体（例如一个国家或更广泛的实体）内。一个例子是欧盟关于保护和保密欧盟个人数据的《通用数据保护条例》（GDPR）。

确定业务驱动因素后，您可以与业务和IT团队合作，识别和分析对您的业务至关重要的应用程序。例如，您可能会认为面向客户的应用程序比交易后市场分析或聊天机器人更重要。在某些情况下，您可能还需要在应用程序中做出一些权衡决定。例如，您的电子商务系统必须优先考虑处理购买交易的能力，而不是处理点击流的能力。

关键是从最重要的业务功能开始，查看为用户提供价值的所有步骤，并确定每个功能的依赖关系树。依赖关系树由执行该功能所需的所有应用程序、服务和数据库组成。然后，您需要在任何步骤中考虑失败对业务的影响。因此，对于每个步骤，您都需要定义系统停机时间的 可用性目标 和 灾难恢复目标 ——恢复时间目标 (RTO) 和数据丢失——恢复点目标 (RPO)。这些目标是根据每次失败的严重程度和潜在影响来定义的。根据出现中断时对业务的潜在影响，应用程序按层分组。每层都有一组定义的 RPO、RTO 和可用性指标，首先是最关键的第 1 层应用程序。例如，组织可以按以下方式对其应用程序进行分类：

  • 第 1 层 — 2 小时 RTO、30 秒 RPO、99.999% 的可用性
  • 第 2 层 — 8 小时 RTO、4 小时 RPO、99.9% 的可用性
  • 第 3 级 — 24 小时 RTO、24 小时 RPO、98% 的可用性
  • 第 4 级 — 4 8 小时 RTO、48 小时 RPO、95% 的可用性

在此示例中，第 1 层应用程序被认为对该组织的运营至关重要，例如订单处理或客户关系管理。某些第 1 层应用程序的中断也可能会影响业务合作伙伴及其他方面。

您可以使用多种技术来分析应用程序和服务并确定其优先级。您可能会发现一种有用的技术叫做失效模式和影响分析 (FMEA)。FMEA 是国际标准化组织 (ISO) 的一项工程技术，用于根据严重程度、概率和可探测性来捕获风险并对其进行优先级排序，每种风险的评级分为 1-10。将这三个维度相乘以估算出介于 1—1,000 之间的风险优先级数 (RPN)。极低概率、低严重性、易于检测的风险的 RPN 为 1。极其频繁、永久损害、无法发现的风险的RPN为1,000。例如，请查看在 亚马逊云科技 上 构建任务关键型金融服务应用程序 的附录 F。

亚马逊云科技 上的弹性和多区域策略

您的弹性策略应优先考虑对成本和业务风险影响最大的应用程序和服务。例如，您的第 1 层应用程序将需要多区域解决方案来满足五个 9 的可用性要求。应用程序的 RTO 和 RPO 将告知您决定选择以下哪种 灾难恢复方法 ：备份和恢复、指示灯、热待机或主动/主动（如以下图 1 所示）。

图 1：从最低优先级到关键任务的灾难恢复方法

RPO/RTO：

时长

RPO/RTO：

10 分钟

RPO/RTO：

分钟

RPO/RTO：

实时

  • 优先级较低的用例
  • 活动结束后预置所有 亚马逊云科技 资源
  • 活动结束后恢复备份
  • 成本 $
  • 数据直播
  • 服务处于空闲状态
  • 预置一些 亚马逊云科技 资源并在活动结束后进行扩展
  • 成本 $$
  • 关键业务服务
  • 一直在运行，但体积更小
  • 活动结束后扩展 亚马逊云科技 资源
  • 成本 $$$
  • 关键任务服务
  • 零停机时间
  • 数据丢失几乎为零
  • 成本 $$$$

一方面，主动/被动备份和恢复策略最简单、成本最低，但 RTO 和 RPO 最高。另一方面，主动/主动策略的 RTO 和 RPO 最低，但成本和复杂性最高。有关更多信息，请参阅 云中的 灾难恢复选项 。

进化方法：从单个区域到多个区域

首先，请选择您之前确定的关键业务应用程序之一。您的多区域战略应与您的业务目标和目的紧密结合。根据我们的经验，它有助于制定路线图，描述您从单个区域到多个区域的演变。在决定扩大规模之前，最好从小处着手，测量并确定需要改进的领域。

假设您的最终目标是实施主动/主动的多区域策略。与其将应用程序作为一个整体来处理，不如采用特定的用例（架构的纵向部分），逐步实现主动/被动指示灯策略的要求。然后，您可以在吸取的经验教训和自动化流程的基础上再接再厉，实现热备用策略中更复杂的要求。从那时起，你可以继续进行迭代、测量、学习和自动化。有了自动化设计模式和最佳实践的坚实基础，您就可以着手实施多站点主动/主动策略（最复杂的架构）的要求。

使用这种方法，你可以通过运行小型实验来实现最终目标，每次迭代一次，这些实验可以快速产生可衡量的结果。在每项实验中，我们建议使用 亚马逊云科技 Well-Architected Framework 以迭代方式实施最佳实践和核心策略，以便在 亚马逊云科技 上设计和运行可靠、安全、高效且 经济实惠的应用程序。该框架基于亚马逊云科技在各种业务垂直领域和用例中架构数千种解决方案的多年经验。

借 助 亚马逊云科技 全球基础设施 ，您可以在每次实验后以具有成本效益的方式增量构建、测量和学习。您知道自己可以根据业务需求立即扩大或缩小规模，因此只能预置所需的资源。这还可以降低成本并提高您满足用户需求的能力。

截至撰写本文时，亚马逊云科技 的全球网络横跨全球 31 个地理区域中的 99 个可用区，并宣布计划在加拿大、以色列、新西兰和泰国再建一个 12 个可用区和另外 4 个 亚马逊云科技 区域。

为什么 DynamoDB？

DynamoDB 是一个完全托管的无服务器数据库，可在任何规模下提供低延迟，并允许您灵活地实时管理容量。来自不同行业的成千上万的 亚马逊云科技 客户选择了 DynamoDB 作为其任务关键型应用程序和其他应用程序。金融服务、商务、广告技术、物联网 (IoT) 和游戏应用程序（仅举几例）依靠 DynamoDB 存储数万亿个项目，以个位数毫秒返回结果，并管理来自全球数百万用户和智能设备的每秒数百万个请求。

例如，DynamoDB 为多个高流量的亚马逊物业和系统提供支持，包括 Alexa、亚马逊 网站和 所有亚马逊 配送中心。在 2022 年 亚马逊 Prime 会员日 期间 ，这些系统对 DynamoDB API 进行了数万亿次调用，达到每秒 1.052 亿次请求的峰值，而 DynamoDB 保持了高可用性并提供了个位数毫秒的响应。使用 DynamoDB，您也可以轻松构建这种任意规模的应用程序。

经验丰富的数据库专业人员知道，扩展生产数据库的容量很麻烦。它可能会影响应用程序的性能，甚至可能导致停机。此外，根据底层数据库技术的不同，扩展可能需要几个小时甚至几天。DynamoDB 允许您即时更改桌子的容量。您可以根据应用程序流量模式轻松增加或减少容量。更重要的是，全局表的跨区域复制功能是由该服务内置并完全管理的。让我们仔细看看 DynamoDB 的功能，从单个区域开始。

单个区域中的 DynamoDB

如果你不熟悉 DynamoDB，最好的入门方法是在单个区域 创建 DynamoDB 表 。 亚马逊云科技 文档提供了 多个示例 和 教程 ，可帮助您开发 支持 DynamoDB 的应用程序。在单个区域中使用时，DynamoDB 具有以下好处：

  • 性能和可扩展性 — DynamoDB 每天可以处理超过 10 万亿个请求，并且只需最少的数据库管理即可支持每秒超过 2000 万个请求的峰值。它的性能符合预期，响应时间几乎没有变化，具体取决于表的容量模式。DynamoDB 有两种容量模式用于处理表上的读取和写入：
    • 预置模式 -在 预置模式下 ，您可以指定应用程序预计每秒需要的读取和写入次数。如果您确信指定的预置容量会得到良好的利用率，则预配置模式更具成本效益。您还可以使用 自动扩展 来自动调整表的预置容量以响应流量的变化，这使您可以保持或低于定义的请求速率，从而获得成本的可预测性。
    • 按需模式 -使用 按需模式 ，DynamoDB 负责为您管理容量。您无需指定预期应用程序执行的读取和写入吞吐量。当您的应用程序向上或向下扩展时，它可以立即适应它们。按需模式非常适合不可预测的应用程序，当你不确定自己的利用率是否会很高时，你只需为所用量付费。
  • 高可用性和耐用性 — DynamoDB 在设计时考虑到了灵活性。它在单个区域 内提供 99.99% 的正常运行时间服务等级协议 (SLA) ，提供高可用性和耐久性。您在 DynamoDB 中的数据可靠地存储到固态磁盘 (SSD) 中，并自动复制到一个地区的三个可用区。DynamoDB 还会自动将表的数据和流量分散到足够数量的服务器上，以满足您的吞吐量和存储需求，同时保持快速的性能和一致性。 说到一致性，DynamoDB 支持三种 读取一致性 模型 ：最终一致性、强一致性和 事务性。
  • 备份和恢复 — 为了支持您的数据弹性和备份需求，DynamoDB 提供两种类型的完全托管备份：
    • 按需备份 — 您可以使用按 需备份 创建表格的完整备份， 以实现长期数据存档和合规性。这些备份将一直保留到明确删除为止。无论表大小如何，备份都会在几秒钟内完成。您可以随时通过 亚马逊云科技 管理控制台 或 亚马逊云科技 API 备份和恢复表数据，而不会影响表的性能或可用性。如果您愿意，可以使用 DynamoDB 与 亚马逊云科技 Bac kup 的集成 （参见将 亚马逊云科技 Backup 与 DynamoDB 结合 使用 ）来创建包含表计划和保留策略的备份计划，甚至还可以进行跨账户和跨区域复制。
      • 时间
    • 点恢复 -时间 点恢复 可保护您的数据免受由于应用程序错误而导致的意外写入或删除操作。DynamoDB 会维护表的增量备份，因此您不必担心创建、维护或安排按需备份。您可以将数据恢复到过去 35 天内的任何时间点。万一发生意外写入或删除，您可以通过识别项目密钥、将表恢复到最后一个已知的正常时间点以及有选择地从恢复的表中读取正确的数据并将其写入生产表来恢复原始数据。
  • 安全与合规性 — 如 亚马逊云科技 分担责任 模型所述，安全是 亚马逊云科技 和您的组织之间的共同责任 。DynamoDB 保护静态存储的用户数据、客户端和 DynamoDB 之间以及 DynamoDB 与位于同一区域的其他 亚马逊云科技 资源之间传输的数据。此外，您的公司可以完全控制谁可以获得身份验证和授权他们使用 DynamoDB 资源。您在使用 DynamoDB 时的合规责任由数据的敏感性、贵组织的合规目标以及适用的法律和法规决定。作为多个 亚马逊云科技 合规计划的一部分，亚马逊云科技 与第三方审计机构合作，评估 DynamoDB 的合规性，包括系统和组织控制 (SOC)、支付卡行业 (PCI)、联邦风险和授权管理计划 (FedRAMP) 以及《健康保险流通与责任法案》(HIPAA) 等。有关特定合规计划范围内的 亚马逊云科技 服务的最新列表，请参阅 按合规性计划划分的 亚马逊云科技 范围内的服务 。有关如何配置 DynamoDB 以实现您的安全与合规目标的更多详细信息，请参阅 Amazon Dynamo DB 中的 安全与合规 。

多个区域的 DynamoDB：全球表

DynamoDB 使用 亚马逊云科技 全球骨干网，通过一项名为全局表的功能为您提供完全托管的、多区域、多活跃的数据复制。全局表由多个副本表组成，每个区域一个，如下面的图 2 所示。每个副本都有相同的表名和相同的主键。您可以使用控制台、 亚马逊云科技 命令行接口 (亚马逊云科技 CLI) 或 亚马逊云科技 开发工具包 创建全局表 。全局表的当前版本（ 版本 2019.11.21 ）允许您将 单区域表 转换为全局表 。

DynamoDB in multiple Regions: Global tables

图 2：一个跨三个区域复制的全局表

除了单区域 DynamoDB 表的好处外，全局表还为您提供了以下独特优势：

  • 通过本地读取和写入进行全球数据访问 -全局表使您能够从任何地区读取数据并将数据写入任何区域。DynamoDB 通常会在 1 秒内将您的数据异步复制到其他区域。数据复制不会影响应用程序写入的性能。使用全局表时，每个副本表存储相同的数据项集，您的数据最终在所有区域中保持一致。虽然您的应用程序可以在同一区域执行强一致性读取，但由于数据复制的异步性质，从全局表的其他区域复制的数据读取最终始终保持一致。交易操作仅在最初发生写入的地区提供 ACID 保证。
  • 弹性 — 全球表格提供了 99.999% 的正常运行时间 SLA ，允许您构建具有多区域弹性的防灾解决方案。您的应用程序可以实现自定义逻辑，以检测全局表的区域何时变得隔离或降级，以便将读取和写入重定向到不同的区域。此外，DynamoDB 还会跟踪所有已执行但尚未传播到其他区域的写入操作。如果由于某种原因通信中断，DynamoDB 将在该区域恢复联机时传播所有待处理的写入操作。
  • 冲突解决 -当在两个不同的区域同时写入全局表中的同一项目时，可能会发生写入冲突。为了确保数据一致性，DynamoDB 全局表使用 最后写入者获胜的冲突解决机制 ，因此所有副本表都同意最新的更新，并趋向于它们都具有相同数据的状态。
  • 运营效率 -全局表格消除了复制数据的艰巨工作，因此您可以专注于应用程序的业务逻辑。您可以使用 亚马逊 CloudWatc h 监控 DynamoDB（ 参见 DynamoDB 指标和 维度），并 使用复制延迟指标跟踪全局表的复制延迟。 Replicat ion Latency 以毫秒为单位表示，针对每个源区域/目标区域对发出。

从成本的角度来看，您需要为读取容量和存储支付通常的 DynamoDB 价格，并为跨区域复制支付数据传输费用。写入容量按复制的写入容量单位计费。有关更多详情，请参阅 亚马逊 DynamoDB 定价。

结论

在关于使用 DynamoDB 加快多区域战略的系列文章的第一部分中，我们讨论了如何制定多区域战略，首先是确定驱动因素、确定应用程序和服务的优先顺序以及定义弹性目标。我们强调了弹性作为良好多区域战略不可分割一部分的重要性，并介绍了 亚马逊云科技 上的灾难恢复方法。最后，我们介绍了 DynamoDB，这是一种完全托管的无服务器数据库服务，提供多活动、多区域功能，并描述了它在单区域和多区域环境中的功能。

该系列的下一部分将重点介绍使用 DynamoDB 的多区域策略和用例。

作者简介


Edin Zulich 领导着 亚马逊云科技 的数据库解决方案架构师团队。他帮助各行各业的许多客户设计了可扩展且具有成本效益的解决方案，以解决棘手的数据管理问题。Edin 自 2016 年以来一直在 亚马逊云科技 工作，自 2005 年起一直在研究和使用分布式数据技术。


Guillermo Tantachuco 是 亚马逊云科技 的首席解决方案架构师，他在软件交付和互联网规模系统的各个方面与金融服务客户合作，包括应用程序和数据架构、DevOps、深度防御和容错能力。自2011年以来，他一直领导财富500强和全球组织实施云原生和数字化转型计划。他热衷于家庭、商业、科技和足球。