如何将本地应用程序连接到 AWS Aurora Serverless

Question

我们有一堆本地应用程序，每个应用程序都运行自己的本地 MySQL 服务器。我们的工作量很轻，偶尔会有活动爆发（一种 B2B 商业模式，在一个月中的某些特定时间使用我们的应用程序更有利可图，因此我们看到在那些日子里使用量激增）。我们认为通过将所有数据库移动到一个服务器/集群来简化基础架构是一个好主意，经过一些讨论后决定购买托管解决方案比尝试建立和维护我们自己的 MySQL 集群更好（没有我们都是 DBA）。

我们进行了大量研究，最终确定 Amazon Aurora Serverless 作为其自动扩展功能的可靠候选者，因此与我们研究的替代方案（AWS MySQL RDS 和 DigitalOcean 托管 MySQL）相比，成本（可能）更低)，因为我们的工作量通常很轻，偶尔会有一些活动。

但是，据我所知，仅仅从我们的本地应用程序连接到 AWS Aurora Serverless（例如，请参阅 Not able connect Amazon Aurora Serverless from SQL client）是不可能的，所以我的问题是：

1. 解决此问题的最佳实践和现代方法是什么 - 我们是否应该使用站点到站点 VPN 将我们的本地主机连接到云？这最终会让我们付出更多的代价吗？
2. Aurora Serverless 真的是最好的解决方案吗，还是我们应该退回到 Amazon RDS 或 DigitalOcean 的托管 MySQL 集群，它们都允许分配公共 IP，但都不会自动扩展（这意味着我们需要根据我们的高峰使用量购买一个等级，并且可能会浪费大量资金，因为它会在一个月的大部分时间里几乎处于闲置状态）？

我们想要实现的是一个简单的、即发即弃的 MySQL 集群设置，由其他人管理，理想情况下可以自动扩展，并且不会花费地球或最终比当前更难管理，本地解决方案。

我们并不排斥云，但我们也不想为了更简单的数据库基础架构而突然开始将一切全部迁移到云中。

为了投入额外的工作，我们不管理自己的防火墙 - 因此设置站点到站点 VPN 可能会很棘手，并且需要与第三方（我们的网络提供商）进行协调。理想情况下，如果可能的话，我也想避免这种麻烦。

Answer 1

您是对的，您无法直接连接从 AWS 外部连接到 Aurora Serverless (AS)。原因是 AS 不能公开。来自docs：

您不能为 Aurora Serverless 数据库集群提供公共 IP 地址。您可以仅从基于 Amazon VPC 服务的虚拟私有云 (VPC) 中访问 Aurora Serverless 数据库集群。

AS 还有many other limitations，您应该知道，其中一些是：没有副本也没有 IAM 身份验证。

Q1 与 AS 的连接

有几个选项用于连接到 SA，或其他无法从 Internet 访问的服务（例如 RDS 代理、ElasticSearch 域）。

堡垒/跳转主机

主要用于测试和开发的最便宜、最临时的选项是使用堡垒/跳转主机。使用此选项，您可以将 ssh 隧道设置到堡垒，而堡垒又会将您连接到 AS。

但是，这显然不适合可靠访问，但我觉得至少应该在答案中提到这一点。

AWS 站点到站点 VPN

AWS Site-to-Site VPN 是另一个选项，正如您已经提到的。这显然是实现从本地访问 VPC 的更好方法。

但值得关注的是成本，your charged每小时 0.05 美元和每次数据传输。

每小时的价格并不高。 1 个月约为 3.6 美元/月：

24 hours x 30 days x $0.05 = $3.6

数据传输更难估计，因为它取决于您的实际需求。例如，如果您估计每月从 AS 中获取 100GB 的数据（入站流量免费），您将每月支付大约 8.91 美元（前 1GB 是免费的）：

99GB * $0.09 = $8.91

假设上述情况，您每月将支付约 12.51 美元。这不包括 AS 价格本身。

但是，由于提到的防火墙设置问题，这可能会导致设置和管理更加麻烦，然后是有益的。

直接连接

AWS Direct Connect 是最昂贵的，但也是最可靠和私密的。只是想提一下，因为这可能不适合您的用例。

AS 的 Q2 适用性

AS 的一个用例是Infrequently used applications：

您有一个每天或每周只使用几分钟几次的应用程序，例如一个低流量的博客网站。使用 Aurora Serverless，您只需为每秒消耗的数据库资源付费。

您还需要考虑 AS 冷启动，这可能会出现问题，例如 here 或 here 所报告的。

从您的问题中不清楚 AS 的使用模式到底是什么，或者冷启动是否会出现问题。但基于上述问题，如缺乏对 AS 的公共访问、由于防火墙而难以设置 VPN，我会倾向于使用常规的 Aurora MySQL 或 RDS（不能真正评论 DigitalOcean）。

原因是您可以公开访问它，它的设置速度非常快，定价已知，没有冷启动问题，而且它是一项托管服务。另外，它支持autoscaling for storage，所以你不用担心。

此外，您还可以从 小型数据库实例（t3.small 或更小）开始，然后在需要时扩大规模，或者添加只读副本以减轻读取密集型工作负载的负担。

示例费用为：

• Aurora MySQL、t3.small 和 100 GB 初始存储 39.93 美元（详情 here）：

• RDS MySQL、t3.small 和 100 GB：36.32 美元（详情 here）。

上述内容不包括 RDS 或 Aurora 提供的任何只读副本、多可用区设置或其他额外功能。您可以使用calculator.aws 根据您的个人需求进行自己的估计。对于 RDS，您可以使用比 t3.small 更小的实例，例如t2.micro.

同时，通常不建议通过 Internet 公开您的生产级数据库。因此，您最终还是要么将其保密，要么使用 VPN 通过 Internet 私下访问它。但是通过正确设置安全组和网络 ACL，您可以限制其对单个工作站或您的工作场所的 IP 范围的公共访问。如果 VPN 不是一个真正的选项，这将降低数据库拥有公共 IP 的风险。

附言

我建议独立验证所提供的价格和详细信息，因为可能会出错。

Answer 2

我了解到，您对 Am​​azon Aurora Serverless 的混合云架构有一些疑问。 这是一个非常棘手的话题，很容易被视为固执己见（幸运的是社区保持开放）。 因此，如果我必须设计这种设置，我会尝试尽可能多地参考公共材料并尝试解释我的想法。

作为免责声明，我不是 AWS 官员。 然而，在过去的三年里，我一直在创业行业构建和运营云应用程序......巧合的是，我有几分钟的时间，所以这是我的想法：

1。问题陈述

Aurora Serverless 可通过 VPC 接口端点 [1] 访问：

每个 Aurora Serverless 数据库集群需要两个 AWS PrivateLink 终端节点。如果您在 VPC 中达到 AWS PrivateLink 终端节点的限制，则无法在该 VPC 中创建更多 Aurora Serverless 集群。

根据文档 [1]，正如您已经正确指出的那样，这些端点是私有构造：

您不能为 Aurora Serverless 数据库集群提供公共 IP 地址。您只能从基于 Amazon VPC 服务的虚拟私有云 (VPC) 中访问 Aurora Serverless 数据库集群。

2。问题范围

您的问题涉及最佳实践 (Q1)、成本方面 (也是 Q1) 以及与云中其他数据库选项的功能差异 (Q2)，例如通过 Internet 和 Auto Scaling 进行公共访问。

在将数据库工作负载迁移到公共云时，这些都是有效的问题。但与此同时，它们只是应该考虑的问题的一个子集。
据我了解，这里有三个需要明确强调的挑战：您正在 (CI) 开始迁移到云，(CII) 您即将修改现有工作负载，使其成为混合工作负载和 (CIII) 您正在执行数据库迁移。 这三个通常都是独立的大话题，不应该过早地决定它们。 但是，如果您的工作量如您所描述的“轻”，那么将它们一起完成的风险可能是可以接受的。这不是我能够在下面讨论的内容。

因此，让我们关注当我看到上述挑战 (C1) - (C3) 时想到的一个非常基本的问题：

3。混合工作负载是否可接受？ (C2)

我认为您应该问自己的主要问题是本地工作负载是否可以转换为混合工作负载。 因此，您应该考虑将数据库远离客户端对延迟和可靠性的影响。 此外，您应该评估新的数据库引擎是否符合您的性能预期（例如，扩展速度足以应付窥视流量）[3]，以及数据库兼容性和限制是否可以接受 [4]。

通常，与云的连接（可能通过外部网络运营商）不如本地的一堆电缆可靠。也许您的工作负载甚至那么小，以至于数据库及其客户端运行在同一管理程序/机器上。 在这种情况下，绝对应该仔细考虑将事物分开（通过 3rd 方网络连接）。

事实上，要使工作负载可靠和/或高度可用，不仅 Aurora 必须满足这些标准（它确实如此），而且您的网络连接也必须满足。

当您问自己正确的问题时，您会自动开始描述您的工作量。 AWS 发布了一系列公共指南来帮助您完成此过程。
有 Well-Architected Framework [10] 和 Well-Architected Tool [11] - 后者是应用框架的“自动化”方式。 例如，可靠性支柱 [9] 包含来自 AWS 专家的一些想法和专业知识，以真正质疑您的混合方法。

此外，AWS 发布了所谓的 Lenses [13] 以从架构完善的角度讨论特定的工作负载类型。 正如您要求的最佳实践（第一季度），我想指出，目前没有针对您描述的工作负载类型的详细指南/镜头。

但是，文档 [12] 中有一个名为“使用 Amazon Aurora 执行概念证明”的 Aurora 指南。 （更多信息请参见“Aurora POC 指南”部分）

我过去从事过大量使用数据库层的应用程序，因此如果不进行重大重构就无法进行这样的更改...
这让我想到了第二点：迁移策略。

4。可接受的迁移策略是什么？ (C1)

由于这是一次数据库迁移，您应该问自己两个主要问题：(a) 您希望迁移到何种程度（称为迁移的 6R，一个独立于数据库的一般概念）和 (b ) 如何将数据库部分提升到云端（尤其是数据）。 我不想在这里详细介绍，因为它高度依赖于您的工作负载特征。

AWS 已发布详细指南，可帮助您做出这些决定。 [15]
它提到了一些有用的工具，例如 DMS 和 SCT，它们可以帮助您正确转换架构（如果需要）并将数据从源数据库集群移动到目标数据库集群（可选择以“在线”/“实时”迁移方​​式，无需停机）。

我想再次强调，您必须做出一个重大决定：平台重构 vs. 重构应用程序（即数据库客户端） 我想您只需进行少量更改即可使 Aurora Serverless 工作，但为了充分利用 Aurora 功能，可能需要重新架构（最终可能会将整个工作负载移至云中）。

如果您决定对应用程序进行部分重构，您也可以使用所谓的 Data API。 用于 Aurora Serverless 的数据 API [7][8] 可以直接通过公共互联网发送查询。 如果 (i) 您有能力重构应用程序代码的某些部分并且 (ii) 您的应用程序的特征适合 Data API，那么它可能适合您。 Data API 有一种全新的数据库连接管理方法，因此非常适合一些无服务器用例。但是，这可能不适用于一些具有长期保持/大量使用连接的传统数据库工作负载。 您还应该注意 Data API 的数据库引擎兼容性（“Data API 的可用性”[12]）。

5。决策制定

我认为从技术上讲，访问 Aurora Serverless 应该没有问题。 您基本上有四种连接选项：(a) 直接通过 Internet，(b) 通过 AWS 托管（站点到站点）VPN 连接，(c) 通过基于 EC2 实例的 VPN 连接和 (d) 通过 Direct Connect (缩写DX）。

• 选项 (a) 仅在您重新架构应用程序以使用数据 API AFAIK 时才可行。
• 应支持选项 (d)，但根据固定成本，它是最昂贵的。应该支持它，因为 AWS 接口终端节点（Aurora Serverless 的入口点）可通过 DX 访问。
• 这里的专家认为应该支持选项 (c)。 [19]
• 一开始当然不支持选项 (b) - 但据我了解，现在可能支持。这是因为自 2018 年 9 月以来，AWS PrivateLink（支持 AWS 接口终端节点的技术）支持通过 AWS 托管 VPN 从本地进行连接。[17]

此外，您可能必须将 DNS 查询从本地转发到云端，才能正确解析 VPC 接口终端节点。 [18]

您应该描述您的工作负载，指定关于安全性、可靠性、性能（参见架构完善的框架）和最后看看实现它的最具成本效益的方法。 在 B2B 模式中，我不会为了降低成本而在这三个方面妥协（请参阅下面部分中的我的意见）。

您基本上有两种选择：

1. 自己完成工作（希望使用本文中引用的材料会更容易一些）
2. 向 AWS 或外部公司寻求 AWS 解决方案架构师的帮助

这纯粹是在 (1) 弄清楚这一切并使其发挥作用所需的时间、(2) 成本（即实施解决方案的运营成本和咨询成本）、(3) 财务迁移过程中出现问题时所涉及的风险。

正如您在“将所有内容移入云端”问题中所说的那样，我猜您正处于云之旅的开始阶段。 对于处于这种情况的公司，AWS 官方文件声明如下：

如果您的企业是 AWS 的新手，请考虑使用托管服务提供商（例如 AWS Managed Services）来构建和管理该平台。 [14]

拥有创业行业的背景，我知道这对于小公司来说无论如何都不是一个选择 - 但只是想提一下这个选择存在。

6。结论/我的意见（！）

最好避免将数据库暴露在互联网上。这不仅是我自己的观点，还有其他人的观点。 [19]

我会尝试（至少！）使用 AWS 托管 VPN 方法，并在本地和云之间建立 冗余 VPN 连接。

我为什么说“最低限度”？
因为一个合适的解决方案可能是将整个工作负载转移到云中。 但是，如果这不可能，我会尝试降低建立混合工作负载所涉及的风险。 从安全角度来看，托管 VPN 连接可能是小型工作负载降低风险的最具成本效益的方式。

根据我的经验：
在过去三年中，我运行了一个完全构建在 AWS 云中的 SaaS 应用程序。 从那时起，我们的网络运营商多次中断。我永远不会足够信任他们来建立某种混合架构。 不适用于我们提供的工作负载类型（B2B 领域的 SaaS Webapp）和我们拥有 ATM 的互联网合同/连接。绝不。 但是，对您而言，情况可能完全不同 - 特别是如果您已经从数据中心/办公室托管服务，并且长时间没有可靠性问题。

如果你读到这里，你可能会问自己，为什么有人会想写这样一篇文章。 好吧，我正在准备 AWS Certified Database Specialty [20]，这是一个进行认真研究、做一些笔记并收集一些资源/参考资料的好机会。 我想支持各种 AWS 认证路径 [16] 以及围绕它的学习平台生态系统。 AWS 发布了很多非常有用的东西。

希望你自己也能在这篇文章中找到一些有趣的东西。

A.极光 POC 指南

该指南提到，在将数据库迁移到 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/architecture/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]https://stackoverflow.com/a/52842424/10473469
[20]https://aws.amazon.com/de/certification/certified-database-specialty/