Как развернуть сайт [Ruby on Rails] масштабируемым способом?

Я работаю над своим [первым] запуском в течение месяца, и, хотя он, вероятно, по меньшей мере на расстоянии еще одного месяца от альфа-версии, я хочу знать, как правильно его развернуть. У сайта будет начальная высокая загрузка (сеть + ЦП) для нового пользователя, поэтому я думаю о наличии отдельного сервера/очереди для этого первоначального процесса, чтобы он не замедлял работу сайта для существующих пользователей.

Основываясь на моих исследованиях до сих пор, я сейчас склоняюсь к nginx + haproxy + unicorn/thin + memcached + mysql и развертыванию на Linode. Однако у меня нет опыта в любом из вышеперечисленных; поэтому я надеюсь использовать опыт сообщества.

  • Является ли приведенная выше архитектура разумной? Любые предложения/статьи/книги, которые вы бы рекомендовали?
  • Является ли Linode хорошим выбором? Heroku/EY кажется слишком дорогим для меня (по крайней мере, пока у меня не будет достаточно дохода), но я пропустил еще один лучший вариант? MediaTemple?
  • Любые хорошие предложения по архитектуре балансировки нагрузки? Я все еще читаю об этом.
  • Лучше ли иметь 2 отдельных экземпляра сервера Rails на 2 отдельных linodes или запустить 1 экземпляр на линейке с удвоенной емкостью (с точки зрения RAM/storage/bandwidth)? Сколько Linodes следует начинать с?
  • Какой дистрибутив Linux я должен выбрать? (Linode предлагает 8 различных - http://www.linode.com/faq.cfm) Есть ли какие-либо относительные преимущества/недостатки между ними для сайта Rails?

Извиняюсь, если какой-либо из моих вопросов глуп или противоречив; пожалуйста, приложите его к моей неопытности.

ОТВЕТЫ

Ответ 1

Архитектура

Ты на правильном пути. Я лично предпочитаю Пассажира по тонкому/единорогу (долгое время запускать nginx для тонких backend) только для удобства, но предлагаемая вами установка довольно стандартная. Если вы используете Ruby 1.8.7, я бы рекомендовал, чтобы вы рассматривали REE + Passenger для экономии памяти фреймов.

Хостинг и балансировка нагрузки

Linode - это фантастика, и я использую их практически для всего, что могу, но вам нужно знать пределы RAM. В каждом Rails-процессе используется нетривиальное количество ОЗУ, и вы захотите избежать обмена машиной. Планируйте запуск достаточного количества экземпляров Rails на машину, чтобы распределение памяти составляло около 90% памяти на Linode. Вероятно, вам понадобится другой Linode, посвященный вашей базе данных, хотя вы можете начать с них как на одной машине; просто будьте готовы расколоть MySQL по мере роста. Вы можете настроить связь между Linodes в одном центре обработки данных на частных IP-адресах, которые не учитывают вашу квоту пропускной способности.

Ваша стратегия масштабирования должна быть как можно более горизонтальной, поэтому я бы порекомендовал просто получить второй Linode и добавить его в ваш haproxy-пул, когда вам нужно больше лошадиных сил. - Linode взимает с вас $20 за дополнительную RAM объемом 512 МБ, или вы можете просто получить цельный "линейный" (с процессором, оперативной памятью, жестким диском и полосой пропускания) за тот же самый $20. Кажется, это не проблема!). В случае Rails экземпляр - это экземпляр экземпляра, поэтому на самом деле не имеет значения, находится ли он на той же виртуальной машине или нет, если время для подключения к вашей машине базы данных или чего-то более или менее того же. Вы можете запускать 10 Linodes, каждый из которых запускает 10 Rails-процессов, без большой проблемы. Linode также предлагает отказоустойчивость IP, так что, если ваш основной Linode (с haproxy) опустится, он может автоматически сработать автоматически во вторичном Linode, который затем будет работать haproxy и готов действовать в том же качестве, что и первый.

Распределение

Честно говоря, это зависит от вас! Многие люди идут с дистрибутивами Ubuntu или Redhat (CentOS/Fedora) - мне нравится CentOS самостоятельно, но это действительно то, что вам больше всего нравится. Если у вас нет любимого дистрибутива, я бы порекомендовал попробовать Ubuntu/CentOS, поскольку они, как правило, очень дружелюбны к новичкам и имеют чрезвычайно надежную поддержку сообщества.

Вы, вероятно, захотите выбрать 32-разрядный дистрибутив, если у вас нет веской причины выбирать 64-разрядный дистрибутив; 64-разрядные исполняемые файлы требуют больше оперативной памяти, чем их 32-разрядные аналоги, и поскольку оперативная память, вероятно, будет вашим самым ценным ресурсом, имеет смысл сохранить ее там, где вы можете.