在将业务迁移到云平台的过程中，组织常常面临的关键问题之一是成本管理。云计算的特点使得IT支出从资本支出转变为运营支出，因此选择合适的云服务和进行合理的资源估算显得尤为重要。本文将探讨在调整云计算资源大小时常见的错误与陷阱，并提供相应的避免措施，以便更好地利用云计算的弹性。
1. 遵循提升和转移方法
提升和转移方法意味着组织可以将工作负载的副本移动到云平台中，所需更改较少。尽管这种模式在快速迁移业务时有其便利，但可能导致资源使用不充分。组织应考虑重构云计算解决方案，以更好地适应云环境。
过度依赖提升和转移的方法可能使组织在长期内承担更多成本，并错失云计算提供商所能带来的诸多优势。
2. 不标记资源
缺乏足够的数据会使得做出明智决策变得困难。如果无法追踪云计算资源的性能和相关成本，优化利用率就无从谈起。因此，最好根据项目或组织单位对资源进行标记，以便准确分配成本。
3. 未能持续监控资源使用情况
管理云计算架构是一个持续的过程，而非一次性任务。需要定期监控和评估组织的使用情况、方式及原因。初始对特定应用程序的使用假设可能并不准确，及时的调整可以显著降低成本。
例如，一个过度配置的Kubernetes集群可能会有过多的节点。在这种情况下，切换到无服务器选项可能更为合理。
不监控“僵尸”资源的现象并不罕见。在大型组织中，某些项目由于移交不完整而被放弃，相关资源仍保持活动状态。
4. 总是自己做所有事情
软件工程师有时会倾向于构建定制的解决方案。然而，首先对现有资源进行研究可能是更明智的选择。
比如，可能不需要在EC2上使用自托管数据库，而是采用完全托管的RDS，以便更轻松地进行扩展和维护。或者，可以考虑使用经过验证的无服务器消息队列SQS，而非自我管理的RabbitMQ实例。
通常，如果存在无服务器或完全托管的解决方案，优先考虑这些选项会更加合理，而不是在自己的解决方案上耗费过多时间和精力。
5. 只使用自己熟悉的工具
在一些讨论中，很多工程师因只熟悉EC2和人工管理的服务器而不愿尝试无服务器或容器编排平台。他们认为新技术可能只是短暂的潮流，因此不值得改变。这样的态度可能会阻碍组织的技术进步。更好的做法是用事实、成本和性能基准来评估新技术的实际价值。
6. 没有使用无服务器和容器编排平台
如果为每个服务都创建EC2实例，可能会面临维护的挑战。相反，将服务部署到Kubernetes或ECS集群的容器中，可以更有效地利用资源。
容器编排平台有助于确保实例之间的负载均衡，并保持工作负载的健康状态，这在一定程度上消除了容量预测的困难。可以明确指定容器实例的数量，控制平台会确保这些要求得到满足。
通过容器或无服务器资源的负载均衡，便无需再猜测哪种EC2或RDS实例最适合自己的需求。
7. 不考虑总拥有成本
单纯考虑硬件或服务成本，可能会误认为内部部署的资源更具成本效益。然而，若将维护、升级及员工管理这些服务器的额外费用计算在内，情况则完全不同。
8. 没有长远的思考
单凭当前状况扩展资源，可能无法满足未来需求的变化。如果组织的业务和数据增长超出预期，是否能灵活应对？如果情况相反，你的应用程序是否依然容易调整以适应未知的未来？此外，如何确保长期能够吸引并留住足够的员工以应对这些需求？
9. 过度配置“以防万一”
为了确保万无一失，可能会对所有资源过度配置，以应对峰值使用情况。如果能够基于历史使用模式证明过度配置是合理的，那是合适的策略。但若仅凭直觉，这往往是错误的做法。
云服务本身提供了弹性，可以在集群中添加节点，在多个容器之间负载均衡，或在需要时增加CPU和内存。如果配置和监控得当，则无需进行过度配置，尽管正确调整资源规模并不容易，但通过良好的流程和自动化，确实可以实现，并在大规模运行时显著节省成本。
10. 选择错误的数据存储
有时，瓶颈并非来自计算资源的不足，而是由于数据存储选择不当。应考虑一下：
- 是否需要复杂的查询语言（SQL），还是仅需简单的键值存储？
- 是否必须使用数据库，还是一个简单的S3数据转储就足够了？
如何解决云计算资源大小问题？
提高云计算资源利用率的一种有效方式是引入自动化技术。例如，可以使用仪表板监控资源的不足与过剩，并及时获得通知。借助结构良好的仪表板，可以发现，某个ECS集群的EC2实例在过去一小时内的CPU利用率超过90%。
接下来，可以深入分析特定时间段，查明使用峰值的原因。
同时，另一项服务可能出现超额配置，导致资源浪费。有了这些数据，可以根据实际使用模式优化资源配置。
结论
本文探讨了调整云计算资源时的常见错误，并提供了避免这些问题的建议。通过采用容器编排平台、无服务器和完全托管的解决方案，并持续监控使用模式，组织可以优化云计算架构的性能与成本。
