共计 2551 个字符，预计需要花费 7 分钟才能阅读完成。
组织在将业务迁徙到云平台时，遇到的最常见的问题之一是老本。采纳云计算，组织能够将 IT 老本从资本收入 (硬件设施和软件许可的长期投资) 转换为经营收入，因而抉择正确的云服务并进行正确估算至关重要。以下将探讨在调整云计算资源大小时常见的谬误和陷阱，并探讨如何防止，从而真正受害于云计算的弹性。
01 遵循晋升和转移办法
晋升和转移办法意味着组织能够将工作负载的正本挪动到云平台中，而只需进行大量的更改。即便组织只将部署业务疾速迁徙到云平台中，这种模式也很有用，但它可能导致资源应用有余。AWS 公司抵赖，通过创立服务来简化迁徙 (CloudEndure 迁徙和 AWS 服务器迁徙服务) 是一个艰难的问题。不过，为了取得更好的资源利用率，组织最好思考从新构建云计算解决方案。
组织采纳晋升和转移办法，从久远来看可能会领取更多的老本，也可能会错过云计算提供商提供的许多益处。例如，当抉择齐全治理的 AWS Aurora 而不是传统的 Postgres 实例时，组织能够取得高达三倍的吞吐量、存储主动扩大和低提早读取正本。这可能是 Aurora 成为目前最受欢迎和倒退最快的 AWS 云服务之一的起因。
02 不标记资源
如果组织没有足够的数据来做出理智的决定，则很难改良。如果无奈跟踪云计算资源的性能以及它们产生的老本，那么就很难优化其利用率。
最好的做法是依据我的项目或组织单位标记资源，以将老本正确调配给相应的服务。
03 未能随着工夫的推移监控资源应用状况
治理云计算构造并不是一次性的过程。这是监督和评估组织应用的内容、应用形式以及起因的继续实际。兴许组织最后对特定应用程序的增长的假如并不完全正确，而进行更改可能会显著地降低成本。
例如一个适度配置的 Kubernetes 集群，它的节点比须要的多很多。在这种状况下，兴许转向无服务器版本 (Fargate 上的 EKS) 更有意义。
放弃“僵尸”资源不受监控的状况并没有人们设想的那么广泛。在规模较大的组织中，可能会产生某些我的项目因为不残缺的移交过程而被放弃并且相应的资源放弃活动状态的状况。
04 总是本人做所有的事件
软件工程师有时可能会本人构建定制的解决方案和服务。一种可能更好的办法是首先对现有资源进行适当的钻研。例如：
兴许不须要在 EC2 上应用自托管数据库，而是应用齐全托管的 RDS，这能够帮忙更轻松地扩大和操作实例。
- 兴许不须要这个自我管理的 RabbitMQ 实例，而是能够应用通过实际测验的无服务器音讯队列 SQS。
通常状况下，如果有一个无服务器或齐全托管的解决方案，那么至多在为本人的解决方案投入过多的工夫和精力以进行保护之前，先思考采纳这些计划是有意义的。
05 只应用本人相熟的工具
在浏览 Reddit 或博客的一些文章时，常常看到许多工程师不违心应用无服务器或容器编排平台，因为他们只晓得 EC2 和人工治理的服务器。他们认为有些新技术可能只是过眼云烟，因而没有必要扭转本人的形式。这意味着转移到容器编排平台、无服务器和其余云服务是没有价值的。这仿佛是一种审慎的办法。最好挑战一下这种假如，用分明的事实、老本和性能基准来判断新技术的可用性，而不是对新技术持狐疑态度。
06 没有应用无服务器和容器编排平台
如果要为所治理的每个服务和工具创立一个 EC2 实例，则可能会陷入保护的噩梦。然而，如果将每个服务部署到 Kubernetes(EKS)或 Fargate(ECS)集群的容器中，那么因为容器的动静端口映射和更紧凑的资源利用(例如共享层)，能够将更多的资源分配到单个服务器实例中。
容器编排平台将帮忙你确保实例之间的负载平衡，并使工作负载放弃衰弱。这在某种程度上打消了猜想容量的状况。你能够指定在任何时候应该运行多少个容器实例，并且管制平台将确保它产生，就像你定义的那样。
如果能够轻松地在许多容器或无服务器资源之间实现负载平衡，那么不用再猜想哪种 EC2 或 RDS 实例大小适宜本人的用例。
07 不思考总领有老本
如果只思考硬件或服务老本，你可能最终会认为许多资源在外部部署设施中运行可能更具老本效益。然而，如果加上额定的保护、降级和员工治理这些服务器的老本，那么状况就齐全不同了。
08 没有久远的思考
如果只依据当前情况扩大资源，则可能无奈思考到将来需要的变动。如果组织的业务和数据增长更好怎么办？如果后果正好相同呢？你的应用程序依然易于更改，并适应未知的将来状况吗？最初，你是否可能找到并保留足够的员工以长期满足这些需要？
09 适度配置“以防万一”
如果你要保障十拿九稳，可能会适度配置所有货色，以确保为应答应用高峰期做好筹备。如果你能够依据过来的应用模式来证实适度配置的合理性，则这是一个很好的策略。然而，如果是出于直觉，这样做可能是一个谬误的策略。
从某种意义上说，云服务能够提供弹性，你能够在集群中增加节点，在更多容器之间负载平衡工作负载，或者在须要时减少 CPU 数量或内存。如果配置和监督正确，则无需过多配置。这并不是说正确调整大小很容易，然而有了良好的流程和自动化，这是可行的，并且能够显著节省成本，尤其是在大规模运行大量资源时。
10 抉择谬误的数据存储
有时，瓶颈不是计算资源有余，而是数据存储抉择不当。最好考虑一下：
你是否须要丰盛的查询语言(SQL)，还是应用程序只需简略的键值存储即可(例如 DynamoDB)。
- 首先是否须要数据库，兴许一个简略的 S3 数据转储就足够了。
它天然取决于用例，然而数据库通常是形成任何可扩大架构的次要瓶颈。
如何解决云计算资源大小问题？
进步云计算资源利用率的一种可能的解决方案是采纳自动化技术。例如，你能够应用 Dashbird 跟踪资源有余和资源过剩的状况，并取得无关它们的告诉。应用构造良好的 lens 仪表板时，能够发现，具备 EC2 实例类型的 ECS 集群在过来一小时内的 CPU 利用率超过 90%。
而后，能够深刻到特定的工夫距离，并进一步查看呈现这一应用峰值的起因。
同时，另一种容器服务可能会被超额配置，可能会节约老本。有了这些信息，你能够依据理论应用模式优化资源配置。
论断
以上钻研了调整云计算资源大小时的常见问题，并探讨了如何防止这些问题，并真正从云计算的弹性中受害。通过应用容器编排平台、无服务器和齐全托管的解决方案，以及随着工夫的推移继续监督应用模式，能够优化云计算架构的性能和老本。
（文章来自企业网 D1Net，鸣谢）
