亚马逊云科技精选博客
我们使用机器学习技术将英文博客翻译为简体中文。您可以点击导航栏中的“中文(简体)”切换到英文版本。
a-tune 使用亚马逊数据库迁移加速器提供的迁移策略和实施计划来加速他们的 亚马逊云科技 迁移
亚马逊云科技 推出了
a-tune首席执行官安德烈亚斯·斯陶比说:“ 我们的 tick @lab 应用程序支持许多部分复杂的业务流程。 ”“因此 ,有大量不同的模块提供了很多功能。数据库结构非常广泛并且包含一些复杂性。Amazon DMA 团队在深入研究我们的架构、应用程序和代码方面做得非常出色。几周之内,他们不仅理解了这一点,而且分析到了堆栈的最底层。关于问题和解决方案的沟通非常好,这份非常全面的报告为我们未来的规划提供了很好的基础。感谢亚马逊 DMA 团队的大力支持! ”
在这篇文章中,我们讨论了 Amazon DMA 团队为a-tune的迁移制定迁移策略和实施计划所使用的方法。
迁移策略和实施计划评估
Amazon DMA 团队使用五阶段方法来制定迁移策略和实施计划。这包括分析 tick @lab 的当前状态架构,创建满足a-tune的要求和目标的未来状态架构,分析迁移范围并估算迁移工作量,制定迁移设计和实施计划,以及制定生产部署计划。该团队进行了多次信息收集会议,以了解他们的需求、目标、工作负载的当前架构和特征、来自现有技术计划和工件的特定领域知识等。
除其他外,他们就当前的州架构提出了以下问题:
-
- 商业 — 你在做什么生意?
- 工作负载 -计划迁移的工作负载的名称是什么?
- 目标 — 通过将工作负载迁移到 亚马逊云科技,您的目标是什么?
- 架构 — 工作负载的当前架构是什么?
- 依赖关系 -工作负载是否使用需要迁移的 ETL(提取、转换和加载)、报告和脚本?
- 数据库 -工作负载使用什么数据库技术和数据库层?
- 应用程序 -应用层使用什么技术?
- COTS — 工作负载是否使用任何商用现货 (COTS) 软件?
- 数据库许可 — 是否有现有的数据库许可证续订需要考虑?
- 第三方软件 -工作负载是否使用任何数据库平台特定的第三方软件?
- 租户 — 工作负载使用单租户还是多租户架构?
- 性能 -迁移的工作负载中是否需要考虑任何关键性能指标?
- 工作负载大小 -工作负载(源代码和数据库)的大致大小是多少?
- 架构 -需要迁移多少数据库架构?
- 复杂性 -迁移工作负载时是否需要考虑任何已知的复杂性?
- 环境 — 工作负载迁移后,需要在 亚马逊云科技 上创建哪些环境(开发、测试、生产)?
- 赞助 — 计划中的迁移是否有高管级别的赞助?
以下是有关未来国家架构的一些问题:
-
- 愿景 — 您对将他们的工作负载迁移到 亚马逊云科技 有何愿景?
- 技术偏好 — 在未来的状态架构中是否有需要考虑的首选 亚马逊云科技 技术?
- 基础架构 — 未来的状态架构是否需要满足特定的新的或改进的业务需求?
- 验收标准- 需要 哪些指标来衡量迁移工作负载的接受程度或成功率?
- 其他 亚马逊云科技 服务 — 除了数据库平台之外,还有其他需要考虑的 亚马逊云科技 服务吗?
- DevOps — 您需要什么 DevOps 基础设施来管理迁移的工作负载?
- 迁移时间表 -您计划何时迁移工作负载?
- 迁移计划 — 您是否有现有的迁移计划?
以下是有关迁移范围和工作量估算的问题的示例:
-
- 亚马逊云科技 支出 — 在 亚马逊云科技 数据库和分析服务上的预计支出是多少?
- 多租户 — 如果工作负载使用多租户架构,则如何托管多个租户?
- 依赖关系 — 是否 有需要迁移的依赖关系?
- 实例 — 预计将部署 多少个工作负载实例?
- 实施 — 谁来实施迁移?
以下是有关迁移设计和实施计划的问题:
-
- 测试计划- 您计划 如何测试迁移的工作负载?
- PII — 工作负载是否有任何个人身份信息 (PII)?
- 部署 -您计划如何部署工作负载(应用程序和数据库)?
- 最终客户迁移 — 您的最终客户将如何迁移?
- 高可用性和灾难恢复 -工作负载的高可用性 (HA) 和灾难恢复 (DR) 要求是什么?
以下是有关生产部署计划的问题:
-
- 试点部署 -在大规模部署工作负载之前,是否有理由进行有限的部署?
- 测试实施 — 您需要 哪些基础架构和资源来测试迁移的工作负载?
- 切换和备用计划 — 如果切换失败,系统将如何回退?
- 云采用率 — 您目前的云采用水平如何(低、中、高)?
- 培训 — 您计划如何培训内部团队(开发、运营)?
迁移选项
工作负载使用了 VB.Net 和 C# 作为应用程序层,并使用商业关系数据库来满足数据库需求。亚马逊 DMA 对 tick @lab 工作负载的当前状态架构进行了深入分析,并建议 a-tune 重构工作负载的数据库层,以从商用数据库迁移出并采用 PostgreSQL。该团队创建了三个具有不同级别的高可用性、可扩展性和多区域功能的可行选项。
迁移到适用于 PostgreSQL 的亚马逊关系数据库服务 (亚马逊 RDS)
在此选项中,亚马逊 DMA 介绍了 a-tune 如何使用
-
- 静态加密和传输中 加密
- 自动备份保留期长达 35 天
- 手动备份没有任何保留限制
- 最多 15 个只读副本用于卸载报告查询 的恢复时间目标 (RTO) 为
- 5 分钟,并且能够从不同的可用区域中的备份中恢复
下图说明了这种架构。
迁移到亚马逊 RDS 代理
第二个选项是迁移到
迁移到兼容 Amazon Aurora PostgreSQL 的版本
亚马逊 DMA 表明,如果 a-tune 迁移到兼容亚马
-
- 一种弹性解决方案,可在三个可用区中保存六个数据副本。 可以
- 选择使用可以立即扩展的
无服务器 基础架构。 - 快速克隆,零停机补丁。
- 如果需要,通过在写入端点和读取器端点使用 RDS 代理来提高可用性。RPO 为零,RTO 以秒为单位。
下图说明了这种架构。
亚马逊 DMA 解释了这三个选项的优缺点,并帮助调整了满足其业务需求的未来状态架构。
迁移工作量估算
为了估算迁移工作,Amazon DMA 进行了以下活动:
-
- 提取了应用程序层中的嵌入式 SQL 语句,以了解需要手动转换的 SQL 语句的百分比以及重构这些语句所需 的工作量
- 分析了工作负载的数据库层,观察到需要重构数据库配置、数据库查询、过程和函数、特定数据类型、架构、表、触发器、视图和调度程序作业在以下内容中 创建了详细的迁移工作量估算值
- 在 亚马逊云科技 上将工作负载重构和部署到生产环境所涉及的步骤:
-
- 未来状态架构
- 数据库架构转换
- 应用程序转换
- 脚本、ETL 和报告转换
- 与第三方应用程序 集成
- 数据迁移机制
- 测试 和错误修复
- 性能调整
- 集成和部署
- 文档和知识传授
- 项目管理和版本控制
- 后期制作支持
-
Amazon DMA 估计,重构应用程序层将花费大约 20% 的工作量,重构数据库层需要 61% 的工作量,其余 19% 的精力用于进行测试、生产部署和后期制作部署支持活动。
迁移过程
亚马逊 DMA 建议使用两个环境进行迁移。
-
-
重构环境:在此环境中,将使用 DMS 架构 转换对应用程序和数据库代码进行重构,并使用 亚马逊云科技 CodeCommit 、AW S CodeD eploy 进行 CI/CD。 - 数据迁移和验证环境:此环境将用于迁移数据和测试转换后的对象。对于数据迁移,我们推荐使用
亚马逊云科技 Database M igration Servic e,为了验证迁移的对象,我们建议使用比较脚本。
-
亚马逊 DMA 帮助 a-tune 将其 亚马逊云科技 迁移速度加快了 3 个月。
结论
在这篇文章中,我们分享了 Amazon DMA 如何帮助 a-tune 加速向 亚马逊云科技 数据库和分析服务的迁移。
Amazon DMA 提供补充咨询服务以制定迁移策略和实施计划,并使您的内部迁移团队(或亚马逊专业服务或 APN 合作伙伴,如果有)能够进行迁移实施。如果您计划将工作负载迁移到 亚马逊云科技 数据库和分析服务,
作者简介