保存成功
订阅成功
保存失败,请重试
提交成功

云计算生产环境架构性能调优和迁移套路总结(以 AWS 为例)

软件研发效能专家,资深 DevOps 专家、应用架构专家,DevOps 标准、微服务标准核心编写专家。目前专注于 DevOps,云计算,微服务和全功能敏捷团队的实践和推广。在过去 6 年中在国内外不同规模的客户和项目中提供了敏捷,DevOps 和 微服务实施和咨询服务,积累了丰富的实践和培训经验。并且参与了《研发运营一体化能力成熟度模型》(DevOps标准)和《分布式应用架构技术能力要求 第一部分:微服务平台》(微服务标准)的编写。
查看本场Chat

云计算生产环境架构性能调优和迁移套路总结

在我过去作为 DevOps 咨询师的 4 年里,不少项目都是帮客户把应用迁移到云计算平台上。作为云计算平台的翘楚, AWS 以其卓越的技术能力和集成能力为广大海外客户所喜爱。相比其它供应商而言,AWS 价格算是较高的,但从稳定性、自动化和社区支持来说,AWS 是最佳选择。

本文通过一个我最近完成的案例来对我这几年来进行云计算生产环境调优和应用迁移的套路进行总结。

案例背景

案例是一个泰国网站的生产环境(请脑补一句 “ 萨瓦迪卡 ”,为了叙述方便,下文中均以 “ 萨瓦迪卡 ” 指代这个网站。)“萨瓦迪卡”是一个 采用 Wordpress + MySQL搭建的应用。这个遗留系统已经工作了五年。客户已经把在其它 VPS 上平移到 AWS 上。平移(lift and shift)是说原样复制,而迁移(migration)还要进行改造。而客户唯一发挥 AWS 优势的一点就是用了一个配置很高的 EC2 虚拟机 —— m4.4xlarge。这样一台配置的虚拟机有 16 个虚拟 CPU,64 GiB 的内存,以及 2000 Mbps 的网络带宽,最高 3000 IOPS 的 200GiB 的块存储设备(也就是硬盘)。

知识点: GiB 是用二进制计算的,GB 是用十进制计算的。1 GiB 是 2的30 次方,而1 GB 是10 的 9 次方,1 GiB 略大于 1GB。 而且,AWS 的 FreeTier 免费计划是按 GB 计算的哦!

除了基本的网络和虚拟机以外,“ 萨瓦迪卡 ” 的所有东西都放在一台虚拟机上。没错,是所有东西——Web 服务器,反向代理,数据库,上传的文件——都放在一台虚拟机上。唯一个一个负载均衡用来承载 HTTPS 证书,没有使用集群,没有高可用,没有数据库/应用分离,没有防火墙,没有 WAF,没有 APM,没有 CDN 而且,没有持续交付流水线,所有部署都要 ssh 到机器上进行操作。如图所示:

enter image description here

“ 萨瓦迪卡 ” 的生产环境可以被认为是一个裸奔的肉鸡。我曾经一度它已经被轮番入侵很久了,只是还没有被发现而已。而且,“ 萨瓦迪卡 ” 生产环境的唯一一台服务器的内存率使用经常超过 95%,我很担心它的状况,任何一个小的 DoS,都不需要 DDoS,就可以让它整站宕机了。

我于是把我的担忧汇报给了客户,客户也意识到了问题。在我发现问题之前的一个月就启动了 “ 萨瓦迪卡 ” 的翻新(Revamp)项目,让这个应用保持原样(Keep it as is),直到 6 个月后新项目上线,替换掉当前应用。

然而,没想到我一语成谶。一天,“ 萨瓦迪卡 ” 被删库了!

删库?别慌!

作为一个运维工程师,最悲催的事情就是 “ 人在家中坐,锅从天上来 ”。这天是世界杯的某一场小组赛,而我刚吃完晚饭正在洗碗。突然被客户的 P1 告警(P1 - Priority 1,最高级别告警)惊吓到,得知 “ 萨瓦迪卡 ” 被删库了。

判断的依据是:

  1. “ 萨瓦迪卡 ” 主页打开是 Wordpress 的初始化安装页面。证明应用是正常的,数据不在了。
  2. 在服务器上用 MySQL 客户端登录数据库,找不到“萨瓦迪卡”的数据库。

还好客户每天有全量数据备份,于是客户快速从全量备份恢复了数据库,只是缺少了从备份点到故障点的业务数据。全量数据库的备份文件有 10 GiB,这么大的表如果采用 mysqldump 会因为锁表而导致 10 分钟左右的停机时间(别问我怎么知道的)。

还没有评论
评论
查看更多