AWS五步迁移法

根据AWS推荐的最佳实践，已经以往的迁移经验，从本地数据中心或其他云迁移到AWS可以分为下面五步：

图1 AWS推荐的迁移步骤

第1阶段：迁移准备和业务规划

  1. 现状评估：与客户沟通Key Person沟通并了解系统部署情况，存在的问题或不足
  2. 用户目标：业务发展的要求，用户的希望通过迁移解决什么问题，有什么收益？
  3. 差距分析：目标和现在的差异是什么？
  4. 制定行动计划

第2阶段：产品组合发现和规划

当处理一个重大的项目时，最具挑战性的部分是决定从哪里开始。

如果客户已经开始了迁移项目，有明确的选择，这一步会相对简单；但是，如果客户的基础设施分布在多个数据中心或多个团队中，没有一组用于评估应用程序的统一度量标准，则很难确定哪个APP最适合第一波迁移。

我们需要结合正确的数据和正确的专业知识可以帮助客户完成这个阶段。

具体步骤如下：

步骤一：调研当前基础设施情况

  • 收集客户当前基础设施的性能、使用情况、部署情况，进行记录。（包括业务的闲忙时及该期间的使用情况。）
  • 了解业务应用的优先级，系统间的相互依赖度
  • 列出应用程序基础设施清单

步骤二：确定首批迁移的应用

建议首批迁移的应用如下：

  • 与其他业务应用依赖关系最少的应用。这样避免因为迁移原因影响其他业务，造成损失；同时也可以使在迁移的过程中逐步提升对AWS技术的了解和信心，为后续更复杂的应用的迁移打好基础。
  • 从供应过剩或空闲资源最多的应用开始。行业研究表明，多达30%的本地服务器(包括物理服务器和虚拟服务器)都是僵尸(在6个月或更长时间内没有显示出有用的计算活动的迹象)。最重要的是，超过35%的服务器显示活动的时间少于5%。只要在AWS上正确调整云部署的大小，这些应用在迁移之后将看到最大的价格/性能改进。

易于迁移且容易看到效果的应用有以下特点：

  • 应用间依赖关系少
  • 应用服务器有冗余
  • 服务器上的应用程序容量有浪费

迁移过程有挑战的应用有以下特点：

  • 大型的、遗留的应用程序（找不到开发人员或无技术支持的应用）
  • 需要与本地文件系统低延迟连接的应用程序
  • 应用中含有专用设备的应用

步骤三：确定迁移策略

一旦确定了最终状态和将要开始的应用程序，就必须确定迁移策略。根据工作负载情况、应用程序和业务单元，可能有多种不同的策略选择。

实际工作中比较常用的包括：

  • 重新托管（Rehost）。这种方法允许保持应用程序的原样，并在AWS上运行时进行任何必要的调整。这是最快的方法之一，有许多迁移工具可以帮助这个过程。一般情况下，用户首次迁移，又希望快速完成一般建议采用此方法。
  • 修补后迁移。Rehost策略是最简单、最快的方法，也是将其第一个应用程序迁移到AWS的公司最常用的方法。但是，使用这种方法，无法在AWS上看到显著的成本节约，因为无法使用AWS的一些成本节约服务，比如Auto Scaling、托管数据库等等。因此，在这种情况下，一般选择修补后迁移的方式（Replatform），通过选择托管数据库或者将应用程序迁移到 AWS Elastic Beanstalk 等完全托管的平台，以此来减少管理数据库实例花费的时间，获得更大的收益。
  • 部分重构。应用程序的某些方面可以保持原样，但其他部分可能需要重新构建才能在AWS上正常运行。部分重构还可以保留现有的应用程序，并在其上构建额外的支持服务。
  • 完整的重构。重新构建应用程序是最耗时的方法，但它也代表了利用AWS云的灵活性和可用性的最大机会。这也是将应用程序分解为微服务或构建基于容器的体系结构的好机会。很多传统企业上云的时候，由于其应用重新紧耦等原因，需要进行解耦将程序分解成微服务，再进行迁移。

步骤四：团队建设，确定全面的业务计划

许多用户都认为AWS是“容易的”。用户可以在几分钟内启动一个新的AWS实例，但是要构建和管理一个不断增长的AWS环境，则需要与管理任何复杂系统的人员相同的专业知识的专业团队。因此，我们在帮助客户完成迁移的同时，也同样需要帮助用户培训现有技术团队，将经验输出给用户团队，与用户内部技术团队密切配合下构建、迁移和管理用户的云架构。

组建迁移团队后，甲乙双方项目经理将一同对后续的迁移进行计划，并制作预算，计划和预算通过后，双方签订合同，开始正式迁移工作。

在合同签订前，我们的售前工程师将需要根据用户的迁移计划进行后续的服务选型，如选择哪种实例类型，如何最大化投资等等。根据选择的实例类型和服务类型，进行预算，然后提交给客户讨论并确定

第3阶段：迁移设计

在此阶段，项目组的架构设计师将根据用户的业务情况，帮助用户进行以下设计：

整体架构设计

    1. 应该使用哪些实例类型，以及在哪些配置中使用? 查看用于服务器的CPU、内存、网络和磁盘的历史性能数据，以及用于存储的跨吞吐量、容量和IO的性能数据。
    2. 决定希望为每个资产提供多少“可用空间”，然后查看跨这些指标的实际最小、最大和平均使用量，以确定哪种实例类型在AWS上最有意义。当CPU需求在任何1小时的1%以上达到70%以上的峰值时，就会认为虚拟机的大小过小。另一方面，如果在7天的时间内，CPU需求在30%以下的时间内超过1%，则虚拟机被认为是超大的。查看30天的历史记录就足够了，因为如果需要，可以很容易地扩展云上的资源。在进行此过程时，对不同代的物理基础设施进行规范化是至关重要的。确定应该购买哪些保留实例来最大化投资回报率?
    3. 设计AWS体系结构，包括体系结构图和建议服务列表，包括EC2实例、EBS卷、VPC等，以及相关成本。

系统可靠性设计

  1. 收集业务方面对RTO和RPO的要求
  2. 设计系统的高可用性和弹性，可以考虑多AZ部署和Auto Scaling等技术
  3. 数据备份方面需求，进行备份设计
  4. 了解用户对容灾的需求，根据用户的实际情况和经济情况，进行容灾设计

系统安全性设计

  1. 与用户的安全工程师一起设计整体架构的安全性，如果有合规性要求，则同样要求进行合规性设计。
  2. 进行MFA账号设计
  3. 安全组策略设计
  4. 密钥保护设计
  5. 数据安全设计
  6. 操作审计设计

上云后运维管理设计

  1. 运维体系设计
  2. 运维工具设计
  3. 监控指标设计
  4. 自动运维设计

成本设计

  1. 资源购买方式设计
  2. 资源容量选择设计
  3. 自动伸缩设计
  4. 总体拥有成本评估

与甲方的Key Person进行沟通，汇报设计情况，在获得甲乙双方对设计的一致认可情况下，才运行进入后面的迁移实施阶段。

第4阶段：迁移和验证

理想情况下，该过程遵循以下模式:

  • 实施工程师在AWS CloudFormation中构建已批准的架构，这是一个架构模板工具，允许 “构建”一次，然后立即派生出未来的环境
  • 使用AWS提供的机器映像(AMI)，并使用Puppet或Chef等自动化配置管理工具为每个应用程序进一步配置
  • AWS CloudFormation模板和Puppet或Chef脚本一起保存在代码存储库(Git)中，并像软件一样进行版本控制和更新
  • 服务器、数据库和数据通过internet(这需要相当多的时间)或AWS迁移服务迁移到AWS
  • 云工程师开始初始测试过程，在此过程中，基础设施可以通过CloudFormation被无数次地拆除/重建。
  • 其他团队测试和验证应用程序性能、安全性、合规性等。

不推荐使用CLI或控制台手动构建AWS资源，会使未来测试/开发环境的构建变得复杂，并导致长期管理问题。

第5阶段：运营及优化

虽然在迁移过程中确定了许多具有成本效益的迁移的关键元素，但是在AWS平台上获得长期成功的关键是不断优化。

在迁移阶段，必然会遇到一些低效的情况。当在测试环境中更改实例以满足应用程序的需求时，将会产生一些意想不到的成本。迁移之后，我们需要有专门的时间对系统进行整体Review，检查这些低效性，提出优化建议。

只有通过在新的基础上进行迭代、关闭旧系统，并向现代化运行模式不断迭代。才能使运营的人员、流程和技术会始终保持最佳状态。

本文参考文献：

1、AWS Migration Whitepaper