Chr*_*wne 5 amazon-web-services aws-aurora-serverless
我们有一堆本地应用程序，每个应用程序都运行自己的本地 MySQL 服务器。我们的工作量很轻，偶尔会有突发活动（一种 B2B 业务模型，在每月的某些特定时间使用我们的应用程序更有利可图，因此我们会在那些日子里看到使用高峰）。我们决定通过将所有数据库移动到一个服务器/集群来简化基础架构是一个好主意，经过一些讨论后决定购买托管解决方案比尝试设置和维护我们自己的 MySQL 集群更好（没有我们中的人是 DBA）。
我们进行了大量研究，最终确定 Amazon Aurora Serverless 作为其自动扩展功能的可靠候选者，因此（可能）与我们研究的替代方案（AWS MySQL RDS 和 DigitalOcean 托管 MySQL）相比成本更低，原因是到我们平时很轻的工作量，偶尔会有突发活动。
但是，据我所知，无法从我们的本地应用程序简单地连接到 AWS Aurora Serverless（例如，请参阅无法从 SQL 客户端连接 Amazon Aurora Serverless），所以我的问题是：
我们想要实现的是一个简单的、一劳永逸的 MySQL 集群设置，它由其他人管理，理想情况下可以自动扩展，并且不会花费地球或最终比当前更难管理，on-处所解决方案。
我们并不厌恶云，但我们也不希望为了更简单的数据库基础架构而突然开始将所有内容都移到云中。
为了投入额外的工作，我们不管理自己的防火墙 - 因此设置站点到站点 VPN 可能会很棘手，并且需要与第三方（我们的网络提供商）进行协调。理想情况下，如果可能的话，我也想避免这种麻烦。
我了解您对 Amazon Aurora Serverless 的混合云架构有一些疑问。这是一个非常棘手的话题，很容易被视为固执己见（幸运的是，社区对此持开放态度）。所以，如果我必须设计这种设置，我会尝试尽可能多地参考公共材料，并尝试解释我的想法。
作为免责声明，我不是 AWS 官员。然而，过去三年我一直在创业行业构建和运营云应用程序......巧合的是我有几分钟的时间，所以这里是我的想法：
Aurora Serverless 可通过 VPC 接口端点 [1] 访问：
每个 Aurora Serverless 数据库集群都需要两个 AWS PrivateLink 终端节点。如果您达到 VPC 内 AWS PrivateLink 终端节点的限制，则无法在该 VPC 中创建更多 Aurora Serverless 集群。
根据文档 [1]，正如您已经正确指出的那样，这些端点是私有结构：
您不能为 Aurora Serverless 数据库集群提供公共 IP 地址。您只能从基于 Amazon VPC 服务的 Virtual Private Cloud (VPC) 中访问 Aurora Serverless 数据库集群。
您的问题涉及最佳实践 (Q1)、成本方面（也是 Q1）以及与云中其他数据库选项的功能差异（Q2），例如通过互联网和自动缩放的公共访问。
在将数据库工作负载迁移到公共云时，这些都是有效的问题。但同时，它们只是应该考虑的问题的一个子集。
据我所知，我们在这里应该清楚地强调三个挑战：您 (CI) 开始迁移到云，(CII) 您即将将现有工作负载修改为混合工作负载，以及 (CIII) 您正在执行数据库迁移。这三个通常都是大话题，不应过早地决定。但是，如果您的工作量如您所描述的那样“轻”，那么将它们一起做的风险可能是可以接受的。这不是我能够在下面讨论的东西。
因此，让我们关注在我查看上述挑战 (C1) - (C3) 时出现在我脑海中的非常基本的问题：
我认为您应该问自己的主要问题是本地工作负载是否可以转换为混合工作负载。因此，您应该考虑将数据库远离客户端对延迟和可靠性的影响。此外，您应该评估新的数据库引擎是否符合您的性能预期（例如，扩展速度足够快以获取窥视流量）[3] 以及数据库兼容性和限制是否可以接受 [4]。
通常，连接到云端（可能通过外部网络运营商）不如内部部署的一堆电缆可靠。也许您的工作负载甚至很小，以至于数据库及其客户端运行在同一台管理程序/机器上。在这种情况下，将东西移得很远（通过 3rd 方网络连接），绝对应该仔细考虑。
事实上，要使工作负载可靠和/或高度可用，不仅 Aurora 必须满足这些标准（确实如此），而且您的网络连接也必须满足。
当你问自己正确的问题时，你会自动开始描述你的工作量。AWS 发布了一系列公共指南来帮助您完成此过程。
有完善的架构框架[10] 和架构完善的工具[11] - 后者是应用框架的“自动化”方式。例如，可靠性支柱[9] 包含来自 AWS 专家的一些想法和专业知识，可以真正质疑您的混合方法。
此外，AWS 发布了所谓的Lenses [13]，以从架构良好的角度讨论特定的工作负载类型。当您询问最佳实践 (Q1) 时，我想指出，目前没有针对您描述的工作负载类型的详细指南/镜头。
但是，文档 [12] 中有一个名为“使用 Amazon Aurora 进行概念验证”的 Aurora 指南。（更多信息请参见“Aurora POC 指南”部分）
过去我从事过大量使用数据库层的应用程序，因此如果不进行重大重构，就无法进行这样的更改......
这让我想到了第二点：迁移策略。
由于这是一次数据库迁移，因此您应该问自己两个主要问题：(a) 您想要迁移到什么程度（称为迁移的 6R - 一个独立于数据库的一般概念）和 (b) 如何迁移将数据库部分提升到云端（尤其是数据）。我不想在这里详细介绍，因为它高度依赖于您的工作负载特征。
AWS 发布了一份详细的指南，可帮助您做出这些决定。[15]
它提到了一些有用的工具，例如DMS和SCT，它们可以帮助您正确转换架构（如有必要）并将数据从源数据库集群移动到目标数据库集群（可选地在“在线”/“实时”无需停机的迁移方式）。
我想再次强调您必须做出一个重大决定：重新平台与重新架构应用程序（即数据库客户端） 我想您只需进行少量更改就可以使 Aurora Serverless 工作，但为了采取充分利用 Aurora 功能，可能需要重新架构（无论如何最终可能会将整个工作负载移至云中）。
如果您决定对应用程序进行部分重构，也可以使用所谓的数据 API。Aurora Serverless [7][8]的数据 API可以直接通过公共互联网发送查询。如果 (i) 您有能力重构应用程序代码的某些部分，并且 (ii) 您的应用程序特性适合数据 API，那么它可能适合您。Data API 有一种全新的数据库连接管理方法，因此非常适合一些无服务器用例。但是，这可能不适用于某些具有长期保持/频繁使用连接的传统数据库工作负载。您还应该注意数据 API 的数据库引擎兼容性（“数据 API 的可用性”[12]）。
我认为从技术上讲，访问 Aurora Serverless 应该没有问题。您基本上有四种连接选项：(a) 直接通过 Internet，(b) 通过 AWS 托管的（站点到站点）VPN 连接，(c) 通过基于 EC2 实例的 VPN 连接和 (d) 通过 Direct Connect（缩写为 DX）。
此外，您可能必须将 DNS 查询从本地转发到云中，以便正确解析 VPC 接口终端节点。[18]
您应该描述您的工作负载，指定有关安全性、可靠性、性能的最低要求（请参阅架构完善的框架），最后查看实现它的最具成本效益的方法。在 B2B 模式中，我不会为了降低成本而在这三个方面妥协（见下一节我的观点）。
您基本上有两种选择来决定：
这纯粹是在 (1) 解决所有这些问题并使其工作所需的时间，(2) 成本（即实施解决方案的运营成本和咨询成本），(3) 所涉及的财务风险之间进行权衡迁移过程中出现问题。
正如您在问题“将所有内容移入云中”中所述，我猜您正处于云之旅的开始。AWS 的官方文件针对处于这种情况的公司说明了以下内容：
如果您的企业不熟悉 AWS，请考虑使用托管服务提供商（例如 AWS Managed Services）来构建和管理该平台。[14]
拥有创业行业的背景，我明白这对于小公司来说无论如何都不是一个选择——但只是想提一下这个选择是存在的。
最好避免将数据库暴露给 Internet 的做法。这不仅是我自己的观点，也是 SO 上其他人的观点。[19]
我会尝试（作为最低限度！）使用 AWS 托管 VPN 方法并在本地和云之间设置冗余VPN 连接。
为什么我说“最低限度”？
因为一个合适的解决方案可能是将整个工作负载转移到云中。但是，如果这是不可能的，我会尝试降低建立混合工作负载所涉及的风险。托管 VPN 连接可能是小型工作负载从安全角度降低风险的最具成本效益的方式。
根据我的经验：
在过去三年中，我运行了一个完全构建在 AWS 云中的 SaaS 应用程序。从那以后，我们的网络运营商发生了几次中断。我永远不会足够信任他们来建立某种混合架构。不是因为我们提供的工作负载类型（B2B 领域的 SaaS Webapp）和我们拥有 ATM 的互联网合同/连接。绝不。但是，情况对您来说可能完全不同 - 特别是如果您已经从数据中心/办公室托管服务很长一段时间没有可靠性问题。
如果你读到这里，你可能会问自己为什么有人会想要写这样一篇文章。好吧，我只是在为 AWS Certified Database Specialty [20] 做准备，这是一个进行认真研究、做一些笔记并收集一些来源/参考资料的好机会。我想认可各种 AWS 认证途径 [16] 以及围绕它的学习平台生态系统。AWS 发布了很多非常有用的东西。
希望您也为自己在这篇文章中找到了一些有趣的东西。
该指南提到，在将数据库迁移到 Aurora 时，应考虑：
重写客户端应用程序代码的某些部分 - 特别是正确使用 DNS 端点 [5][6] 和连接池 [5]
如果从相当复杂的（专有）源数据库引擎迁移（“移植您的 SQL 代码”[12]），则进行模式转换
（可选）合并一些 Aurora 特定的更改以使迁移更有效（适用于 Rearchitect 类型的迁移）[2]：
- 要充分利用 Aurora 功能进行分布式并行执行，您可能需要更改连接逻辑。您的目标是避免将所有读取请求发送到主实例。只读的 Aurora 副本处于待机状态，具有所有相同的数据，准备处理 SELECT 语句。对您的应用程序逻辑进行编码，以便为每种操作使用适当的端点。请遵循以下一般准则：
- 避免对所有数据库会话使用单个硬编码连接字符串。
- 如果可行，请将写入操作（例如 DDL 和 DML 语句）包含在客户端应用程序代码的函数中。这样，您可以使不同类型的操作使用特定的连接。
- 为查询操作制作单独的函数。Aurora 将读取器端点的每个新连接分配给不同的 Aurora 副本，以平衡读取密集型应用程序的负载。
- 对于涉及查询集的操作，当每组相关查询完成后，关闭并重新打开与读取器端点的连接。如果该功能在您的软件堆栈中可用，请使用连接池。将查询定向到不同的连接有助于 Aurora 在集群中的数据库实例之间分配读取工作负载。
[1] https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/aurora-serverless.html#aurora-serverless.limitations
[2] https://docs.aws.amazon.com/AmazonRDS/latest /AuroraUserGuide/aurora-poc.html#Aurora.PoC.Connections
[3] https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/aurora-poc.html#Aurora.PoC.Measurement
[4] https ://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/aurora-serverless.html#aurora-serverless.limitations
[5] https://d1.awsstatic.com/whitepapers/RDS/amazon-aurora-mysql -database-administrator-handbook.pdf
[6] https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/Aurora.Connecting.html
[7]https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/data-api.html
[8] https://www.youtube.com/watch?v=I0uHo4xAIxg#t=12m30s
[9] https: //d1.awsstatic.com/whitepapers/architecture/AWS-Reliability-Pillar.pdf
[10] https://aws.amazon.com/architecture/well-architected/
[11] https://aws.amazon.com /de/well-architected-tool/
[12] https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/aurora-poc.html
[13] https://aws.amazon.com/blogs/架构/well-architected-lens-focus-on-specific-workload-types/
[14] https://d1.awsstatic.com/whitepapers/Migration/aws-migration-whitepaper.pdf
[15]https://docs.aws.amazon.com/prescriptive-guidance/latest/database-migration-strategy/database-migration-strategy.pdf
[16] https://aws.amazon.com/training/learning-paths/
[17] https://aws.amazon.com/about-aws/whats-new/2018/09/aws-privatelink-now-supports-access-over-aws-vpn/
[18] https://docs。 aws.amazon.com/Route53/latest/DeveloperGuide/resolver-forwarding-inbound-queries.html
[19] /sf/answers/3698969711/
[20] https://aws.amazon.com/ de/certification/certified-database-specialty/
| 归档时间： |
|
| 查看次数： |
821 次 |
| 最近记录： |