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

Имеется проект на 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 прописать в автозагрузку скрипт, который будет стягивать последнюю версию проекта и собирать его.
Ок, но это занимает время. Получается, что пока создаеться новый инстанс во время нагрузки, будут запросы которые не будут обработаны, так как старые инстансы нагрузку уже не выдерживают, а нового еще нету.

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

Посоветуйте еще почитать что-то полезное на эту тему.
  • Вопрос задан
  • 1449 просмотров
Решения вопроса 2
crezd
@crezd
AWS solution architect
Вообще то есть "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
Ответ написан
chupasaurus
@chupasaurus
Сею рефлекторное, злое, временное
Новые инстансы никогда не будут подниматься за 1 наносекунду, да и за 1 секунду тоже. Для переживания пиков надо заранее увеличивать размер кластера.
По поводу ASG на основе своего AMI: образ надо регулярно обновлять дабы не отставать по системным пакетам и уменьшать время деплоя кода. Процесс простой: создаёте копию текущего Launch configuration с новым AMI ID, переключаете на него ASG (настройки терминации инстансов по-умолчанию сами выводят инстансы по старости их конфига).
Про деплой кода при старте: ваша мысль верная, с помощью User-Data (скрипт на баше или cloud-init - по вкусу), заодно избавляет от заморочек с уведомлением ASG о готовности инстанса т.к. является частью стандартного процесса запуска.
Ответ написан
Пригласить эксперта
Ответы на вопрос 1
saboteur_kiev
@saboteur_kiev
build engineer
так а бутылочное горлышко где?
Если база тормозит - кластеризуем, оптимизируем.
Если база не тормозит, а тормозит бэкенд - ставим какой-нить балансер и несколько бэкендов к той же базе.

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

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы