快出海  > 亚马逊云  >  剖析Amazon、Autodesk等迁移上云的成功案例,看 AWS 数据库迁移的创新之处

剖析Amazon、Autodesk等迁移上云的成功案例,看 AWS 数据库迁移的创新之处

来源:AWS云计算
作者:AWS云计算
时间:2020-08-01

数据库迁移上云?你是否还在为千头万绪不知从何处开始而烦恼呢?别担心,小编今天告诉你一个数据库迁移的独家秘籍!

在数据库领域,过去的几十年里,客户不得不与具有高锁定性和惩罚性许可条款的商业数据库厂商打交道,付出高昂的成本。同时,我们看到许多客户试图尽可能地迁移到开源数据库,然而往往需要面对实现企业级性能和扩展的挑战。客户希望挣脱束缚,实现成本的节约,从而专注于发展和创新。

在转向开放源代码数据库的客户要求我们以客户友好的策略、开放源代码数据库的自由性和可移植性来实现商业级数据库的性能。这就是为什么我们构建了Amazon Aurora,一个与MySQL和PostgreSQL兼容的关系数据库,它是为云构建的,将高端商业数据库的性能和可用性与开源数据库的简单性和成本效益结合在一起。Amazon Aurora的性能是标准MySQL的5倍,是标准PostgreSQL的3倍,具有商业级数据库的安全性、可用性和可靠性,成本是标准PostgreSQL的1/10。

现在的你是不是对Amazon Aurora充满好奇呢?那就快来跟着小编一起看看在AWS上进行业务数据迁移的客户案例吧~

No.1

企业核心业务

数据库迁移之路

案例一:Autodesk的核心业务数据库迁移之路

作为全球软件解决方案的领导者,Autodesk始终关注中国制造业的痛点与发展需求,借助人工智能、数据库以及相关技术,帮助制造厂商挖掘设计的更多可能性,提升生产的可预判性,旨在让制造商无需高额的资金和人力成本即可实现轻松生产。

Autodesk公司多年之前就已经启动了自己的云计算现代化之旅,着手将工作负载从本地数据中心迁移至Amazon Elastic Compute Cloud(EC2)及其他AWS服务当中。Autodesk之所以积极推进现代化改造,自然是为了获取必要的灵活性与可扩展性,支持业务的预期增长。2019年,该公司将其关键任务单点登录(AutodeskSSO)应用从Amazon EC2上的自托管SQL Server中迁移至全托管Amazon Aurora MySQL。此项服务需要应对全球各地超过1.42亿用户的身份验证请求,每分钟API请求响应数量超过14万5千次。此外,该应用还整合了300多种用于实现身份验证与授权操作的产品及服务。

此次迁移有助于简化Autodesk SSO服务的管理与弹性、优化运营成本并降低基础设施的维护开销。根据初步成本分析结果,该公司在使用Amazon Aurora MySQL之后每月总体数据库成本可下降约40%至50%。

通过本文,我们将探讨Autodesk公司如何在尽可能缩短停机时间的前提下,对关键任务数据库进行迁移。以下各章节将分别介绍迁移前架构迁移策略迁移步骤以及性能比较等相关议题。

迁移前架构

下图所示,为Autodesk以往使用的SQL Server架构。该数据库以自托管形式在Amazon EC2实例之上运行,且跨越多个可用区与另一区域内的单一节点建立起Always On机制,借此实现灾难恢复能力。

wx_fmt=png&tp=webp&wxfrom=5&wx_lazy=1&wx_co=1.jpg

随着时间推移,Autodesk团队发现现有配置中存在以下挑战:

·中断——以往发生的诸多中断事件,正是由于这套复杂的自找托管数据库基础设施所导致。整个体系中涉及多个采用Amazon Elastic Block Store(EBS)加RAID 10存储配置的Amazon EC2实例,结果就是Windows Server故障转移集群(WSFC)、存储以及IOPS等众多元素构成极为复杂的分层体系。更重要的是,运营团队越来越难以对事件根源进行分析与追溯。

·备份——管理备份也带来可观的开销,特别是在跨区域设置层面。尽管我们使用了自动化脚本,但整个备份流程仍然需要人为介入与严格监控。

·补丁修复——由于Autodesk公司拥有多个环境(包括测试环境、暂存环境与生产环境),因此补丁修复消费了管理员们大量宝贵的时间。

·可扩展性——主节点负责填写只读路由请求,同时标记需要接入的辅助节点。尽管此功能能够保证连接始终被路由至运行状态良好的辅助节点,但从可扩展性的角度来看,主节点的存在本身即是最大的瓶颈。

·副本数量——SQL Server最多允许设置8个辅助副本,而Amazon Aurora MySQL最多可支持15个副本。

·成本——原本的总体拥有成本,达到迁移至Amazon Aurora之后新体系的两倍。

·弹性——对基础设施进行规模伸缩需要耗费大量时间。

迁移策略

我们从概念验证起步,借此确定需要完成的应用程序变更、数据库变更、脚本自动化以及各类预创建服务。更重要的是,我们还借此确定迁移至Amazon Aurora这一举措能够有效解决前面提到的种种挑战。

在实施必要的变更之后,我们制定了计划,以分阶段方式迁移至不同环境。以此为基础,我们对策略进行微调,逐步明确了在不同环境上运行迁移时所带来的相应停机时间。我们的目标是在最少的停机时长之内完成迁移。为了在不同环境间灵活高效地实现迁移,我们利用Terraform自动执行数据库创建与AWS DMS配置等步骤。当然,大家也可以使用AWS CloudFormation实现相同的自动化效果。

在以下章节中,我们将具体探讨迁移过程中的各注意事项。

Schema迁移

AWS Schema转换工具是一款出色的schema迁移工具,能够将迁移工作量控制在最低水平。但在本示例中,由于存在大量定制化需求,我们只能放弃效率、选择更适合的schema转换方法。

作为schema转换流程中的一部分,我们首先为数据库选择了最佳字符集。如此一来,我们的数据库体积将缩减到原始大小的三分之一左右。对数据库的成功“瘦身”,将在迁移过程中带来巨大助益。

在确定目标数据库的最终架构之前,我们需要全面评估以下因素:

·字符集与排序规则

·数据类型选择

·日期/时间模式

·多字节字符存储

·特殊字符存储

·索引类型

这些注意事项不仅有助于数据迁移,同时也将避免因引入特殊数据集而导致的各类迁移后问题。

容量规划

我们对容量规划进行了广泛测试,包括迭代运行工作负载以确定合适的实例大小与对应容量。此外,我们还比较了来自各类监控工具(例如Amazon CloudWatch、New Relic以及MonYog)的关键指标、分析慢查询日志,并对现有生产工作负载/流量及未来数据增长做出预测。

应用程序迁移

应用程序迁移将以无缝化形式进行,因为我们使用NHibernate(ORM)进行数据访问。ORM生成约80%的查询比例,因此我们可以在应用程序内以最少的ORM配置变更生成MySQL查询。这里也建议大家首先观察应用程序通过ORM生成了多少查询,并据此估算转换其余查询所需要的具体工作量。

我们在SSO应用程序中开发了一项功能,用于支持按需数据库连接切换并进一步实现对读取/写入流量的控制。以此为基础,我们能够在整个迁移计划中实现连续部署与跨环境执行。最后,这项举措还有助于最大程度减少数据库切换操作所带来的停机时间。

之前,我们使用的是完整NET框架,遗憾的是带有NHibernate的NET完整框架中的MySQL驱动程序并不支持Amazon Aurora MySQL故障转移功能。换句话说,我们的应用程序将无法自行实现故障恢复。为此,我们提出了一项自定义解决方案,针对NET中MySQL驱动程序缺失的问题为Amazon Aurora MySQL故障转移提供新的支持方法,确保应用程序能够在迁移过程中继续正常支持业务流量。

数据迁移

数据迁移与验证是整个迁移流程中的重要一步。我们使用AWS Database Migration Service(DMS)以实现安全且经济的迁移效果。关于更多详细信息,请参阅AWS DMS上手指南。

迁移步骤

下图所示,为迁移中的各项状态与具体步骤。图中为前滚迁移模式,各个步骤将帮助大家快速理解与迁移进度相关的情况。在下面几个章节中,我们将就每种状态及其内容做出说明。

wx_fmt=png&tp=webp&wxfrom=5&wx_lazy=1&wx_co=1(1).jpg

只要可能,我们都会提前创建服务与基础设施。例如,在开始迁移之前,我们的Amazon Aurora MySQL数据库、SQL服务回滚数据库以及AWS DMS实例都已经准备就绪。

初始状态

即SQL Server服务的初始状态。

第一步

在这一步中,我们将正式开始从SQL Server到Amazon Aurora MySQL的全加载迁移。所谓全加载迁移,实际上是一套时间点快照副本,DMS负责将数据从源数据库复制到目标数据库。

从数据库的约束角度来看,要想获得最佳全加载性能,理想的作法是在导入全加载前仅部署各主键。在全加载之后,我们再逐步添加其他约束元素,例如外键。由于AWS DMS会从多个表处并行加载数据,因此复杂的外键关系可能会减慢加载过程。在Amazon Aurora MySQL上,最好只包含写入节点。而在SQL Server回滚设置中,理想的作法是在主节点中创建回滚数据库。另外,在单一节点上创建索引会进一步提升速度,特别是在表体积很大的情况下。

第二步

在完成从SQL Server到Amazon Aurora MySQL的全加载创建后,下一步是从Amazon Aurora MySQL到SQL Server回滚数据库创建全加载副本。任务完成后,我们即在源数据库、Amazon Aurora MySQL以及SQL Server回滚数据库之间完成了全加载数据同步。

第三步

在这一步中,我们将向Amazon Aurora MySQL与SQL Server回滚数据库添加索引与外键,向Amazon Aurora MySQL添加读取节点,并将回滚数据库添加至Always On数据库。通过这些操作,我们的全加载性能将有所提升,同时保证数据库在切换完成之前始终处于高可用性状态。

大家当然可以在全加载期间启用验证,但如果您接下来打算使用变更数据捕捉(CDC),这里提醒大家在CDC阶段再启用验证效果更好。AWS DMS负责对整体数据进行验证,其中包括全部全加载组成部分的迁移数据。AWS DMS提供一项特殊功能,允许用户在其中设置定制化验证功能。我们会大量使用此项功能以验证各特殊字符与Blob数据类型。

作为质量检查(QA)流程中的一部分,我们对部分重要工作流者做了验证。我们在全加载后进行了一轮示例数据验证,希望确保关键工作流能够按预期正常运作。此项示例数据验证以DMS验证为基础。经过全面测试之后,我们开始进入CDC阶段,将全加载之后累积的增量变更从源数据库传输至Aurora MySQL,再将Aurora MySQL传输至SQL Server回滚数据库。

在此期间,AWS DMS会将迁移指标发送至Amazon CloudWatch。若需了解更多详细信息,请参阅监控AWS DMS任务。

第四步

在CDC执行期间,我们一直在密切监控Amazon CloudWatch中的以下几项指标:

  ·ValidationPendingOverallCount

  ·CDCLatencySource

  ·CDCLatencyTarget

在ValidationPendingOverallCount达到低值,而源数据库与目标数据库之间的CDC延迟最低时,我们即可着手执行数据库切换。数据库切换同样分几个步骤,我们首先需要停止应用程序的写入流量、等待挂起记录得到全部验证,而后切换应用程序中的标记以使其指向Amazon Aurora MySQL。

上述指标的最佳数值,取决于您的实际用例与变化速度。大家可能需要通过多轮测试以确定具体数值。

以下示例图为ValidationPendingOverallCount指标。大家可以看到初始挂起行数很高,之后逐渐减少。

wx_fmt=png&tp=webp&wxfrom=5&wx_lazy=1&wx_co=1(2).jpg

以下示例图为CDC LatencySource指标,它显示的是源数据库最后捕捉到的事件与AWS DMS实例当前系统时间戳之间的间隔(单位为秒)。如果因任务作用域导致未能从源数据库处捕捉到任何变更,则AWS DMS会将此值设置为0。

wx_fmt=png&tp=webp&wxfrom=5&wx_lazy=1&wx_co=1(3).jpg

以下示例图为CDC LatencyTarget指标,它显示的是Amazon Aurora MySQL上首个等待提交的事件时间戳与AWS DMS实例当前时间戳之间的间隔(单位为秒)。如此出现此值,则意味着存在Amazon Aurora MySQL无法处理的事务。因为如果所有事务都得到正常应用,那么目标数据库延迟应该与源数据库延迟相同。目标数据库延迟不得低于源数据库延迟。

第五步

在本步当中,我们的应用程序已经指向Amazon Aurora MySQL并保持良好运行。我们的团队对应用程序进行了端到端测试,旨在确保所有功能都可正常工作。整个回滚设置共运行数天,帮助我们观察其实际运行状态。

最终状态

在这一步中,我们删除了回滚设置。下图所示为我们构建完成的迁移后架构。

wx_fmt=png&tp=webp&wxfrom=5&wx_lazy=1&wx_co=1(4).jpg

回滚步骤

在这一步中,我们的目标是在最糟糕的情况下制定备份计划。由于数据库在关键任务服务中扮演重要角色,因此我们必须引入完善的回滚机制以从最坏的情况中恢复正常。

如果在发生故障时仍必须使用当前数据库,我们的计划是首先停止向Amazon Aurora写入流量,等待挂起记录得到验证,而后将应用程序切换至回滚数据库SQL Server Always On)。如此一来,我们就可以在不丢失任何数据的前提下还原至旧有设置。

当然,要保证回滚设置正常起效,我们必须对其进行充足的测试与验证。我们在测试环境中使用生产规模的数据以执行测试,并确保当应用程序从Amazon Aurora MySQL切换至回滚数据库时,不会导致任何数据丢失问题。

性能比较

我们从迁移前与迁移后的读写查询中,捕捉到前10条查询性能进行比较。

下图所示,为前10条读取查询的查询性能。可以看到,Amazon Aurora的性能表现相当出色。

wx_fmt=png&tp=webp&wxfrom=5&wx_lazy=1&wx_co=1(5).jpg

下图所示为前10科写入查询的查询性能。Amazon Aurora MySQL在这里的性能表现同样胜过MSSQL,执行时长也远低于MSSQL。

wx_fmt=png&tp=webp&wxfrom=5&wx_lazy=1&wx_co=1(6).jpg

相关建议

除了之前章节中提到的方法,我们还为大家整理出以下建议:

·充分规划运行测试,这样您才能总结出适合现有数据库的迁移策略。绝不存在百试百灵的策略,因此请务必拿出自己的配置思路并逐步做出优化。

·进行多轮性能测试以实现SQL查询调优;SQL查询在不同的数据库上会表现出不同的行为。

·最大限度提升迁移流程的自动化水平。在实践中,我们使用Terraform实现自动化,从而快速重复多轮测试并总结出统一的迁移执行流程。

·尽可能设置警报机制,同时通过适当监控以分析迁移流程。

·为了预留充足的时间以处理意外错误,理想的作法是至少在计划切换的一天之内实现数据库切换点(详见迁移步骤中的第四步)。

Autodesk案例小结

异构数据库的迁移工作往往困难重重,但凭借AWS DMS的协助以及妥善规划,Autodesk仍然顺利从SQL Server迁移到了Amazon Aurora MySQL。通过此轮迁移,该公司不断显著提升了运营效率,同时也对基础设施的成本与性能做出优化。

Autodesk以及其他众多企业已经开始享受Amazon Aurora MySQL带来的种种助益,包括Amazon电商也利用AWS实现了数据库自由。除此之外,中国支线航空商业模式的引领者和践行者——华夏航空也通过AWS完成了核心数据的迁移,跟着小编一起看看吧。

案例二:Amazon电商利用AWS实现数据库自由

Amazon电商在迁移过程中面临两项关键挑战。一是如何解决大规模的项目管理问题,因为这对于带动多样化、全球分布的团队开展项目和跟踪进度非常必要。二是迁移涉及高度技术复杂性。要想成功完成该项目,很明显,公司的业务线需要集中协调、培训和技术支持。

为了克服这两项挑战,Amazon电商一开始就创建企业项目管理办公室(PMO),设定明确的业绩要求,并且对每个服务团队进行周度、月度、季度审查,以跟踪和报告项目进度和状态。

AWS技术核心团队,由经验丰富的解决方案架构师和数据库工程师组成,这也是项目成功的关键。该团队就哪些AWS服务最适合于从Oracle迁移过来的Amazon电商数据的每一个类别提出了建议。

Amazon电商还仔细考虑了如何以最佳方式,帮助Oracle数据库管理员走上现行的新职业发展道路。其中一个选项是,帮助他们获得转型成为AWS解决方案架构师所需的必要技能。另一个选项是,在基于Oracle的传统环境和AWS云环境之间搭建桥梁的过程中,给予管理角色,在此角色下,Oracle背景很有帮助。

例三:华夏航空选择AWS将核心数据迁移上云

华夏航空股份有限公司成立于2006年,是中国支线航空商业模式的引领者和践行者。截至2018年底,公司在飞航线123条,其中国内航线120条,国际支线航线3条,独飞航线114条,占公司航线比例达93%;通航城市107个,其中国际航点城市2个;公司支线航点占全部国内支线机场比例达41%。

2018年华夏航空开始具体地实施迁移上云工作。按照规划,华夏航空将全面采用由西云数据运营的AWS中国(宁夏)区域构建云基础架构,到2020年左右把绝大部分应用都迁移上云。

华夏航空的上云顺序是这样规划的。第一步,让华夏航空的中转系统2.0上云;第二步,迁移营销、内部管理以及相关的业务系统,2018年总共完成十几个这样的系统上云;第三步,核心业务运行和保障系统上云,这一块比较庞大,计划在2019年做迁移。第四步,到2020年,把飞行管理、安保管理、安全管理以及一些周边的业务管理,尽可能都迁移上云。

根据华夏航空的估算,业务应用上云后,可以节省成本20%~30%,有的应用甚至可以节省50%以上的成本。对一些应用,如果加以改造、优化后上云,可以节省更多成本。例如,把原来的Oracle数据库改成MySQL数据库,省去商业数据库软件昂贵的授权及持续的高额服务费用。

版权说明

本文内容来自于AWS云计算,本站不拥有所有权,不承担相关法律责任。文章内容系作者个人观点,不代表快出海对观点赞同或支持。如有侵权,请联系管理员(hj@kchuhai.com)删除!

相关文章
被Gartner高分推荐背后 AWS保持持续创新有哪些方法论
被Gartner高分推荐背后 AWS保持持续创新有哪些方法论
近日,Gartner发布了一个针对AWS的供应商评估报告,报告对AWS给予了有史以来的最高评分:28分(满分为30分)。在此之前,Gartner还没有给过其它IT供应商27分以上的评分。
4天前
万物互联!锱云科技借助AWS构建高效制造企业数字化解决方案
万物互联!锱云科技借助AWS构建高效制造企业数字化解决方案
锱云科技希望能够继续借助AWS先进的服务高效部署自家解决方案,帮助更多中国离散制造企业以及制造行业企业开启数字化变革。
4天前
AWS:新希望草根知本聚焦私域流量,创新 C 端大平台
AWS:新希望草根知本聚焦私域流量,创新 C 端大平台
AWS服务资源的动态转化能力令人印象深刻。通过在流量低谷时间段将更多资源用于数据仓库计算,实现了50%的成本节省。使用AWS大数据分析服务支撑千万级消费者全生命周期的标签画像,计算成本降低了50%,查询时间缩短了80%。
4天前
Cypress发布集成AWS的安全物联网设备管理解决方案
Cypress发布集成AWS的安全物联网设备管理解决方案
PSoC64标准安全AWS MCU包括预验证的安全固件,有助于降低设计风险,降低研发成本,并加快上市时间。
5天前
如果AWS仍然不愿支持“多云”,会发生什么?
如果AWS仍然不愿支持“多云”,会发生什么?
微软和谷歌正在推广一项战略,以使用户的云服务更易于使用“多云”的用户公司使用。亚马逊网络服务在两家公司的多云战略方面落后了一步,试图通过自己的服务来满足用户的需求。
5天前
服务商推荐 更多 >
太平洋电信股份有限公司
太平洋电信
太平洋电信为游戏、电商等客户提供低延时、高可靠的多点互联、企业上云、全球移动应用测试、主机托管等服务。通过与澳大利亚电信合作,凭借在全球丰富的海缆网络资源及多年的国际化运营经验,助力企业业务出海布局。 更多产品详情,请访问官方网站:https:www.t-pbs.com
云服务
北京云中融信网络科技有限公司
融云
融云为全球开发者和企业提供 IM即时通讯和实时音视频通信云服务,独立的海外数据中心,全球 30 万+应用的通信选择。一套 SDK 解决所有通信场景,快速集成,1天实现跨国互动,实时沟通,助力应用出海
云服务
凝视数科(北京)科技有限公司
AppStare
Apple Search Ads 代投,美国真人积分墙,FB | GG代投代运营
推广
深圳哈希信息技术有限公司
哈希信息
深圳哈希信息技术有限公司成立于2018年,是国内领先的智能网络服务提供商,基于软件定义网络、下一代网络协议、大数据等技术研发面向不同行业领域的产品和解决方案,秉着“专业、创新、信任、分享“的核心价值观,致力为客户提供一个高效可靠的流量云平台。公司对外提供分发云(CDN)、加速云(动态加速)、安全云(防DDOS&云WAF)、流量云(广告交易)、边缘云、短信云等多个云产品,帮助游戏/资讯等互联网公司构建、加速和更好的保护核心业务。
云服务变现
奇亿音乐
奇亿音乐
奇亿音乐为各类型国内外游戏提供:游戏音乐、游戏音效、游戏配音等资源制作。配音方面语种齐全,除了游戏中常见的英语,还可以录制阿语、日语、韩语、法语、西班牙语、德语、意大利语…….等几十种语言,还可录制各地方言。
本地化
广州线条信息技术有限公司
SuperADS
SuperADS是一家为企业深度国际化服务的移动互联网大数据广告科技公司,旗下程序化营销平台SuperADS主打可玩互动广告,激励视频广告,通过ML/AI技术赋能,以提高广告投放ROI为目标,帮助广告主高效获取优质用户,帮助开发者实现流量高效变现。
发行应用电商
小程序
公众号
商务合作
投稿采访
出海管家
0