Pull to refresh
0

Наш опыт использования AWS на этапе запуска

Reading time 4 min
Views 9.2K
Перед нами стояла задача, обеспечить бесперебойную работу Staply, минимизировав затраты, сохраняя гибкость и простоту архитектуры.
В этой статье мы расскажем какую серверную конфигурацию используем в период перехода из закрытой беты в открытое использование. Период, когда вопрос стоимости стоит наиболее остро, так как есть нагрузка, но еще нет прибыли.




Отсутствие материалов по периоду средних нагрузок и просьба synck побудила к написанию этой статьи.

Наши результаты:
  • Сервис справился с нагрузкой: раздела «популярное» на HackerNews, Хабр и ProductHunt
  • Пик нагрузки в эти периоды находился в районе > 400rps, продолжительностью ~ 5 часов.
  • максимально ~10 регистраций в минуту.
  • Доступность согласно NewRelic: 96.092% за последние три месяца и 99.991% в феврале


С начала разработки мы использовали Amazon AWS E2, позволяющий создавать собственную архитектуру без необходимости искать пути обхода ограничений хостинга, как в случае с Heroku, при этом предлагающий обширные облачные решения.
Для поддержания сервиса в рабочем состоянии, мы старались избежать резкого увеличения нагрузки, постепенно увеличивая трафик, что позволило выявить узкие места в системе и устранить их в рабочем режиме, без аварийный ситуаций.

Конфигурация по рекомендации Amazon:


Наша конфигурация:
  • t1.micro инстанс в качестве балансировщика (в настоящее время, скорее, в роли роутера) с Haproxy
  • t1.small и m3.medium инстансы с nginx passenger и redis
  • S3 хранилеще для файлов
  • RDS m1.small инстанс с MySql


Ежедневный счёт: ~8.21$

Внимание! Регулярно проверяйте детализированные счета, Amazon распределяет оплату на много мелких статей расходов, и счет за неиспользуемый элемент может неприятно удивить.


Серверная конфигурация

Сервис написан на Rails, однако, в статье этот факт затрагивается минимально.
В начале разработки достаточно одного t1.micro инстанса со включенным swap. Свести затраты до нуля позволяет AWS Free Tier с бесплатным периодом использования.

При выходе сервиса в открытый доступ, лучше не скупиться и с самого начала заложить в архитектуру возможность к резкому увеличению мощностей. Распределенная мультисерверная архитектура, позволяет работать с каждым элементом отдельно, не влияя на остальные (например если потребуется перезагрузить инстанс, или увеличить его мощность).
Обязательно воспользуйтесь мониторингом, бесплатного плана NewRelic будет достаточно.

При запуске публичной версии проекта, запускаем второй сервер, m3.medium (1 CPU Intel Xeon, 3.7 GB RAM, magnetic store, настроенный swappiness).

Мощность сервера рассчитывалась с учетом конфигурации Rails приложения:
  • Ruby 2.1.0
  • Nginx + Passenger 4
  • Каждый поток потребляет ~200mb памяти.


Для удобного роутинга запросов между development и production серверами, мы использовали один t1.micro инстанс с установленным Haproxy и настроенным SSL termination.
Существенно сократить задержку между серверами позволяет использование Private IP, вместо Public в Haproxy конфигурации.

Не бойтесь преждевременной оптимизации, сейчас для нее самое подходящее время. Каждое выявленное узкое место в коде сервиса, каждое сокращение времени ответа на сотые доли секунды позволит вам поддерживать большее количество клиентов и экономить. Максимальное внимание уделите циклам в коде, в нашем случае, наибольший потенциал к оптимизации находился в них. Вынося все лишнее за пределы циклов, мы сократили время ответа в десятки раз.

Для отправки писем используется Amazon SES,
Отлично интегрируется в Rails с Action Mailer, и предоставляет бесплатную квоту в 10000 сообщений/сутки.

Файлы

Файлы хранятся в S3, но не стоит использовать его для хранения статики (скрипты, стили, изображения), задержка будет большей, чем при хранении файлов на самом инстансе.
Задержка при доступе к файлу:
  • S3: ~280ms — 1.80s
  • CloudFront: ~60ms — 200ms

Включить кеширование контента из S3 позволяет добавление заголовка {'Cache-Control'=>'max-age=315576000'}.

Для сокращения задержки Amazon предлагает воспользоваться сервисом CloudFront, распределяющим контент из S3 по регионам.
Трафик с CloudFront дешевле трафика c S3.

База данных

Для базы можно использовать тот же инстанс, что и сервер, но это увеличивает связи между элементами и снижает гибкость архитектуры. Для БД мы используем RDS db.m1.small инстанс с magnetic store, позволяющий не заботится о бекапах и конфигурации.
Начиная с самой ранней бета версии, сервисом пользовались клиенты и имелись данные в базе, сохранность которых мы должны были обеспечить

Регионы

Необходимо учитывать географию потенциальных клиентов и рынка на котором хотим работать: Весь мир сразу охватить можно, но сетевая задержка будет серьёзной.
Все элементы архитектуры должны находиться в одном и том же регионе.

Скорость загрузки между регионами:
image

На практике, задержка из Санкт-Петербурга до серверов в регионе US-EAST может быть в 6 раз большей, чем при запросе к серверам EU-WEST.

Построение простой и модульной архитектуры с самого начала, заложит высокий потенциал к плавному росту и переходу на высокие нагрузки.

Мы рады выслушать ваши советы и замечания, обратная связь с хабра помогла нам серьезно улучшить многие моменты в нашем сервисе.

Использованные ресурсы:
Tags:
Hubs:
+3
Comments 6
Comments Comments 6

Articles

Information

Website
www.staply.co
Registered
Founded
Employees
2–10 employees
Location
Россия