Как развернуть сайт [Ruby on Rails] в масштабируемом режиме? - PullRequest
14 голосов
/ 01 октября 2010

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

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

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

Я прошу прощения, если какой-либо из моих вопросов глуп или противоречив; пожалуйста, укажитеэто к моей неопытности.

1 Ответ

18 голосов
/ 01 октября 2010

Архитектура

Вы на правильном пути.Лично я предпочитаю Passenger вместо thin / unicorn (долгое время запуская nginx для thin backends) просто для удобства, но предлагаемая вами настройка довольно стандартна.Если вы используете Ruby 1.8.7, я бы порекомендовал вам использовать REE + Passenger для экономии памяти фреймворка.

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

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

Ваша стратегия масштабирования должна быть как можно более горизонтальной, поэтому я рекомендую просто получитьвторой Linode и добавление его в ваш пул haproxy, когда вам нужно больше мощности - Linode берет с вас 20 долларов за 512 МБ ОЗУ или вы можете просто получить еще один «Linode» (с ЦП, ОЗУ, HDD и пропускной способностью) за те же 20 долларов,Кажется, ежу понятно!).В случае с Rails, экземпляр - это экземпляр, поэтому на самом деле не имеет значения, находится ли он на одной и той же виртуальной машине или нет, если время подключения к вашей машине базы данных или что-то еще примерно одинаково.Вы можете без проблем запускать по 10 линод каждый с 10 процессами Rails.Linode также предлагает восстановление после отказа IP, так что если ваш основной Linode (с haproxy) выйдет из строя, он может автоматически переключиться на вторичный Linode, на котором вы затем запустите haproxy и будете готовы к работе в том же качестве, что и первый.

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

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

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

...