Opsani:在AWS上调整应用程序时要避免的诱人简单度量标准
2018年05月29日 由 荟荟 发表
865934
0
在线快速搜索将找到许多工具来检查您的AWS日志或账单,并提供低利用率的虚拟机列表。当然,这个想法是,如果你减小vm大小甚至删除它们,你会省钱。
提高利用率是一个诱人的简单想法。
毕竟,如果某个虚拟机没有使用它的资源,显然你花了太多钱。此外,利用率很容易理解为优化的指标。好吧,如果你运行的只是独立的vm,这可以很好用。但是,如果您正在运行具有多个虚拟机的服务,则可能会产生新问题。
要了解这种简单化方法如何适得其反,请考虑使用Web前端和数据库后端的简单两个虚拟服务。仅基于利用率,您可能会收到后端虚拟机未充分利用的警报以及选择较小虚拟机类型的建议。但为什么后端vm利用率低?问题可能是没有足够的流量来利用vm中的资源,在这种情况下,选择新的vm类型将是有利的。然后,问题可能是未正确选择前端vm类型。可能会有大量流量,但如果前端虚拟机太小,则可能无法处理所有传入流量。在这种情况下,后端vm的低利用率实际上是前端瓶颈的结果。
利用率和瓶颈
创建瓶颈的虚拟机并不总是导致链中下一个虚拟机的利用率低。有时,效果会显示在您最不期望的位置。
典型的服务显然比两个虚拟机更复杂,这使得整个事情变得更加复杂。创建瓶颈的虚拟机并不总是导致链中下一个虚拟机的利用率低。有时,效果会显示在您最不期望的位置。那么我们对此有何看法?嗯,有一个简单的蛮力方法和一个更有洞察力的长期方法,需要一点思考。
蛮力方法是先在服务中检查所有vm,寻找高利用率。调整这些的vm类型以提供更多资源。这可以确保它们不会阻碍来自其他虚拟机的流量。接下来查看低利用率vm并调整这些vm类型以提供更少的资源。重复这两个步骤几次,直到最低利用率可接受。最后,重新调整高利用率vm资源。重复这几次,你将得到一个良好的调整服务。
如果这看起来像很多工作,那就是。显然,我们需要一种更自动化的方法,但在我们开始注意之前,在我们的示例中,我们只调整了几个变量,内存和CPU。还有许多其他设置会影响您可能无法调整的性能。
欢迎关注ATYUN官方公众号
商务合作及内容投稿请联系邮箱:bd@atyun.com