Назад | Перейти на главную страницу

Архитектура Rails AWS - переход с одной машины Linode на AWS

У нашего стартапа есть приложение, которое разрабатывается уже почти год. Rails/MySQL+MongoDB/Unicorn/Nginx успешно на одной коробке Linode.

Недавно мы решили перейти на AWS по нескольким причинам:

  1. Стоимость - мы получили кредит AWS на несколько тысяч долларов (через программу ускорения, в которой мы участвуем), и было бы стыдно не использовать его.
  2. Масштабируемость - в последнее время мы начинаем получать довольно много прессы, и количество наших пользователей растет. Из-за стоимости коробки Linode и того, что мы получаем взамен, она не будет хорошо масштабироваться в ближайшем будущем.
  3. Способности - стек AWS кажется впечатляющим с точки зрения возможностей и доступных инструментов, и я слышал и читал много хорошей (и немного плохой) прессы о том, что это может быть хорошим местом для начала роста.

В целом, для нас выигрывают вопросы стоимости и масштабируемости, поскольку бесплатный надежный хостинг трудно превзойти (ну, пока у нас не закончится кредит AWS). Нам еще предстоит найти средства, поэтому все затраты на ИТ покрываются из моего собственного кармана (несколько сотен долларов в месяц).

По сути, я хочу перенести наше приложение на AWS и думал о следующем стеке:

     Elastic-Load-Balancer
              |
              |
[1+ Rails App over Unicorn/Nginx]
              |
              |
[1+ DB Server (MySQL + MongoDB)]

Где серверы приложений или БД могут расти по горизонтали по мере необходимости. Поскольку мы еще не продвигаем точку останова, я подумал просто начать с 1 сервера приложений, 1 сервера db (пока не RDS) и ELB + Route53 для управления DNS и балансировкой нагрузки.

Я никогда не использовал AWS и не являюсь экспертом по DevOps, поэтому мне хотелось получить отзывы по нескольким вопросам:

  1. Как мне управлять частью стека веб-сервера в отношении настройки unicorn + nginx? До сих пор все это было на одной машине, и поэтому это не было большой проблемой. Следует ли мне сохранить настройку nginx.conf и просто заставить nginx прослушивать порты 80/443 в каждом экземпляре приложения?
  2. Я хотел бы иметь возможность расширять уровень приложения, просто добавляя больше экземпляров (AMI) по мере необходимости. Будет ли это управляемо в краткосрочной перспективе? Например - пока у нас не будет денег нанять девопса или закрыть магазин из-за бедности :)
  3. Будем очень признательны за любые другие извлеченные уроки или вещи, о которых следует помнить.

Примечание. По разным причинам я пока не хочу использовать OpsWorks: наш сервер приложений очень настроен, нет поддержки Mercurial, не очень развит и т. Д.

Спасибо.

AWS может обеспечить масштабируемость, если вам это нужно. Предложения по архитектуре

  • использовать elb для первого уровня
  • использовать два или более сервера приложений (по причинам избыточности)
  • используйте rds, если можете

Теперь ... Если rds не вариант, вы получите master db и slave. Для db я рекомендую тома ebs с полосами.

Управление конфигурацией может быть любым, если вам это удобно. Конечно, есть повар, марионетка и тому подобное.