如何在 Amazon EC2 上配置基于内存的 Auto Scaling？
我正在 EC2 实例上部署 Rails 应用程序，我想在其中配置 Auto Scaling 以与弹性负载均衡器一起使用。在特定阈值上，我想生成一个新实例。在为自动伸缩组配置触发器时，我们可以选择CPU利用率、网络或磁盘IO；但作为一个 Rails 应用程序，我将面临内存而不是 CPU 或 IO 的资源紧缩。
有人成功为 Rails 应用程序配置了 EC2 Auto Scaling 吗？将 AWS 与 Rails 结合使用的首选方式是什么？
仅供参考：我使用乘客作为应用程序服务器。
感谢您抽出时间。
I am deploying a rails application on EC2 instances, where I want to configure Auto Scaling to be used with an Elastic Load Balancer. On a particular threshold I want to spawn a new instance. While configuring trigger for auto scaling group, we have options for CPU Utilization, Network or disk IO; but being a rails application, I will face resource crunch on memory rather than CPU or IO.
Has anyone configured EC2 Auto Scaling for a rails application successfully? What is the preferred way of using AWS with rails?
FYI: I am using passenger as application server.
Thanks for your time.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
我没有使用 Rails 完成此操作，而是使用 Tomcat 中的 java 完成。我们使用 tomcat 阀门/脚本来检测内存使用情况并将其作为自定义云监视指标发布在 Amazon cloudWatch 中。您可以根据监控此指标的cloudwatch警报创建横向扩展触发器。
上述技术的某些部分甚至可以与铁轨重叠。
I have not done it with Rails, but with java in Tomcat.We used tomcat valves/scripts to detect the memory usage and post it in Amazon cloudWatch as Custom cloud watch metrics. You can create an scale out trigger based on cloudwatch alarm monitoring this metric.
Some sections of the above technique can even be overlapped for rails.
实际上，我认为您应该尝试根据您正在使用的实例类型调整您的 Passenger 配置（这里有一篇关于此的文章：http://blog.scoutapp.com/articles/2009/12/08/product-rails-tuning-with-passenger-passengermaxprocesses）。这应该确保在满载时您使用所有可用的 RAM，但您不会生成比可用 RAM 多的乘客实例。
根据我的经验，这会导致所有资源（CPU 和 RAM）饱和，您可以根据 CPU 使用情况触发自动缩放策略。您还应该调整实例类型以获得最佳性能（我使用 cc1.xlarge 实例取得了相当大的成功）。
如果您设置基于 RAM 的自动扩展，您应该能够在 CloudWatch 上创建一个指标来监控 RAM 使用情况并使用该指标进行自动扩展。创建指标只是使用 CloudWatch API 定期发布指标数据 (http://docs.aws.amazon.com/AWSRubySDK/latest/AWS/CloudWatch/Metric.html）。您可以创建一个每分钟运行一次并发布指标数据的 Rails 后台任务。
Actually, I think you should try to tune your Passenger configuration based on the instance type you are using (here is an article about this: http://blog.scoutapp.com/articles/2009/12/08/production-rails-tuning-with-passenger-passengermaxprocesses). This should ensure that at full load you are using all the RAM available but you are not spawning more passenger instances than RAM available.
This, in my experience leads to saturating all the resources (CPU & RAM) and you could trigger an autoscale policy based on CPU usage. You also should tweak the instance type in order to achieve the best performance (I've used cc1.xlarge instance with a fair amount of success).
If you're set on autoscaling based on RAM, you should be able to create a metric on CloudWatch that is monitoring RAM usage and autoscale using that metric. Creating a metric is just publishing the metric data at regular intervals using the CloudWatch API (http://docs.aws.amazon.com/AWSRubySDK/latest/AWS/CloudWatch/Metric.html). You could create a rails background task that runs every minute and publishes the metric data.
我认为您可以使用新的信号发送功能、监控内存指标并使用 api 启动实例：
http://aws.typepad.com/aws/2010/12/amazon-cloudwatch-alarms.html
i think you can use the new signaling feature, monitor the memory metric and start the instance using api:
http://aws.typepad.com/aws/2010/12/amazon-cloudwatch-alarms.html