我正在 AWS 上设置一个 Rails 应用程序：1）所有流量都必须进行 SSL 加密 2）每周的流量波动很大 3）将由比系统管理员更强大的程序员来维护
我认为 SSL 终止于由运行 nginx 和 unicorn 的小型 ec2 实例支持的弹性负载均衡器上
一小部分请求将花费超过 10 秒的时间，因此我也在考虑使用“thin”而不是“unicorn”。
我的问题是：这是明智的吗？我是否陷入了成本、可维护性、安全性或性能问题的泥潭？
答案1
无论这是否合理，如果您不是系统管理员并且愿意处理此事，那么您将很快成为系统管理员。您能做到吗？ :) 我可能没有抓住重点，但让我讲讲我作为一名在亚马逊上担任系统管理员的 Ruby 开发人员的一些经验：
在亚马逊上运行需要很多技巧：- 亚马逊上的 ELB（弹性负载均衡器）只是一个 CNAME 记录，因此您无法让 yourdomain.com 指向 ELB，因此您需要一个具有弹性 IP 的 Web 服务器，以便拥有 .htaccess 或反射，或者 nginx 或 unicorn 上的重写内容。为此做好计划，这样它就不会让您吃亏。
至于 Thin 与 Unicorn，在这种情况下，这是超越亚马逊的设计策略。我从未使用过 Thin，但听说 Comet 风格的长池连接不错。在我看来，亚马逊对于长连接来说应该没问题。如果您甚至想要更安全，您可以使用粘性 cookie 来确保客户端浏览器只粘在一台服务器上。
“我是否陷入了成本的泥潭？”
是的，亚马逊上的价格很快就涨了。
“我是否陷入了可维护性的泥潭？”
是也不是。我习惯于使用“几英里外”的机器，这样我就可以去那里重置或更换硬盘。在亚马逊上，你需要准备好你的一台机器会过时，你必须重新启动它。所以你需要计划要么拥有一个强大的形象并保持更新，要么找一个厨师或傀儡来管理你的服务器（然后发疯，这太难设置了，我花了一个月的时间，但我确实从零开始学习）
“我是否陷入了业绩的泥潭？”
请记住，磁盘 io 远非理想，因此如果您的数据库进行大量写入，则写入 DB 的速度会变慢，一定要进行简单的试验以确保速度足够好。此外，您必须使用 EBS 来处理数据库文件。
处理器速度和内存都很不错。我不用担心。
此外，我会先使用更大的实例，然后再对许多小实例进行水平扩展，除非您计划因为这些长池连接而耗尽端口。如果您想获得更好的性能，垂直扩展直到达到超大规模比旋转大量机器更便宜。
“我是不是陷入了可维护性的泥潭？”——再次
如果您有大量小型机器，您想弹性地上下移动这些机器，而这样做会很麻烦。
如果你想对开发人员友好，我会选择 EngineYard并检查您是否可以使用他们的服务进行部署。这是值得的。
请随意提问！