Как правильно маштабировать проект на Amazon AWS?

Question

[hoodie]

Имеется проект на Amazon AWS который состоит из:

- База данных AmazonRDS
- EC2 инстанс (c4.xlarge)

На инстансе есть два проекта - один на php (самописный фреймворк), один на nodejs (api)
В качестве вебсервера - nginx

Разработка ведеться в гите (два разных репозитория на каждый проект).

Деплой (релиз) происходит следующим образом: по ssh подключаюсь к серверу и в папке с каждым проектом делается
git pull RemoteBranchName master
После этого проект пересобирается make update

Задача состоит в том что бы выдержать прирост нагрузки который планируеться в ближайшее время.

Как это правильно сделать?

Думал над следующими вариантами:

1) Просто увеличить тип инстанса на более мощный. Тут все понятно.

2) Используя Load Balancers и Auto Scaling Groups

А вот тут много вопросов.

Если использовать Auto Scaling Groups, то нужно создавать Launch configuration на основе AMI образа.
Но получаеться что после каждого релиза нужно создавать новый образ с обновленным кодом проектов, что не очень удобно.
Как вариант думал, что можно в AMI образ, который используеться для Launch Configuration прописать в автозагрузку скрипт, который будет стягивать последнюю версию проекта и собирать его.
Ок, но это занимает время. Получается, что пока создаеться новый инстанс во время нагрузки, будут запросы которые не будут обработаны, так как старые инстансы нагрузку уже не выдерживают, а нового еще нету.

Как правильно лучше решить эту задачу?

Посоветуйте еще почитать что-то полезное на эту тему.

Answer 1

[Dmitri Kaminin]

Вообще то есть "best practices". Да, это использовать Load Balancer и Auto Scaling.
А вот AMI можно приготовить или как говорят на западе в этом контексте "to bake the image". Есть очень удобный тул от Hashicorp - Packer. С его помощью можно сделать готовый AMI со свежей версией вашего проекта. Далее создаете новый ASG с этим AMI.

Делаем релиз:
Старый AS оставляем 100% и плавненько увеличиваем капасити нового AS, доходим до количества инстансов 100%. Трафик идет и на старые инстансы и на новые(со свежим кодом), смотрим логи, всё в порядке? Новая версия встала как надо? Тогда уменьшаем количество инстансов старого AS до нуля. Релиз закончился. Если что то не так с новой версией можно легко ролбекнутся на старую, и даже спустя время(час, день, неделя) можно сделать удобный и четкий роллбек на любой ваш релиз, благо все ASG у вас есть, капасити нужного релиза увеличиваем, не нужного уменьшаем. Это и есть zero downtime deployment. Кстати таким макаром удобно делать A/B тестирование.

P.S создавать AS тоже можно делать удобно: terraform

Answer 2

[chupasaurus]

Новые инстансы никогда не будут подниматься за 1 наносекунду, да и за 1 секунду тоже. Для переживания пиков надо заранее увеличивать размер кластера.
По поводу ASG на основе своего AMI: образ надо регулярно обновлять дабы не отставать по системным пакетам и уменьшать время деплоя кода. Процесс простой: создаёте копию текущего Launch configuration с новым AMI ID, переключаете на него ASG (настройки терминации инстансов по-умолчанию сами выводят инстансы по старости их конфига).
Про деплой кода при старте: ваша мысль верная, с помощью User-Data (скрипт на баше или cloud-init - по вкусу), заодно избавляет от заморочек с уведомлением ASG о готовности инстанса т.к. является частью стандартного процесса запуска.

Answer 3

[Saboteur]

так а бутылочное горлышко где?
Если база тормозит - кластеризуем, оптимизируем.
Если база не тормозит, а тормозит бэкенд - ставим какой-нить балансер и несколько бэкендов к той же базе.

В общем выясните что больше всего страдает от нагрузки

Comments

[hoodie]

А как правильно узнать, что будет тормозить при возростании нагрузки?

Делал нагрузочное тестирование с помощью artillery.io

В какое-то время nginx стал отдавать ошибку 502.
В логе nginx:

1185#1185: *52455 connect() to unix:/run/php/php7.0-fpm.sock failed (11: Resource temporarily unavailable) while connecting to upstream

А что смотреть в базе?

Можете дать приблизительные ориентиры как правильно замерять, куда смотреть?

[Saboteur]

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

log_slow_queries = /var/log/mysql/mysql-slow.log
long_query_time = 4
log-queries-not-using-indexes

смотрите что в лог попадает.