Что изменится при использовании AWS API Gateway c подключением существующего API endpoint?

Question

[Вадим]

Привет всем,

допустим у меня есть свой Restful API endpoint доступный по адресу https://api.mysimpleserver.ru/orders/vasya, который привязан к EC2 инстансу с elastic IP и доменом (NGINX/Django REST framework приложение). SSL termination на NGINX web servere.

В общих чертах как сделать чтобы этот endpoint работал через API Gateway и был scalable и available? Наверное лучше использовать Application Load Balancer и несколько instances в разных AZ?

не совсем понимаю, какая может быть архитектура в в этом случае ! Что прописать в API Gateway? Измениться ли вид этого endpoint?

всем бобра )
Вадим

Answer 1

[Иван Шумов]

API GW не даст масштабируемости по тому что у вас 1 виртуалка. Ваши варианты:
- ALB + Autoscaling Group + EC2 AMI
- ALB + Autoscaling Group + ECS ( + Fargate )
- API GW + Lambda

API GW это по сути прокачанный реверс-прокси и не имеет отношения к масштабируемости. Его основной функционал это конфигурация роуминга трафика удобным способом + безопасность + трансформация данных.

Comments

[Иван Шумов]

Ну и все что надо знать про API GW - тут

[Вадим]

Скажем я использую: API GW + ALB + Autoscaling Group + EC2 AMI(s) - несколько виртуалок

Если можете, ответьте на след вопросы, не совсем доходит:
1) CNAME домена должен указывать на ALB ?
2) SSL termination перевести на ALB или можно еще по другому?
3) Если ALB, то как быть уверенным что request/response пройдет через API Gateway?

Видео по Gateway я смотрел полгода назад, вроде все понятно, а как связать с существующим API endpoint пока не доходит ! В том числе хочу ограничить количество запросов - сделать throttling через API Gateway

[Иван Шумов]

1. да (можно alias в Route53)
2. да (он в частности для этого и нужен - разгрузка вычислительных мощностей на шифрование трафика)
3. никак. это не зона ответственности этих сервисов. ALB ничего не должен знать про API GW, а API GW максимум что может знать - куда перенаправить трафик. Максимум можно мониторинг в X-Ray прикрутить

а еще вам понадобится конфигурировать ALB чтобы принимать трафик только с API GW, что довольно веселое занятие

[Вадим]

Иван Шумов, Иван, спасибо за развернутый ответ - если можно хочу еще уточнить 2 момента

1. Нужно ли будет вписывать в API Gateway все ресурсы по такому пути: /orders/vasya , а также их HTTP методы?
2. Если домен будет привязан к ALB, то каким образом трафик сначала пойдет через API Gateway? Или мне нужно будет на фронтэнде прописать новый endpoint от API gateway??

[Иван Шумов]

Вадим, нет, можно прописать proxy endpoint и any тип запроса. Домен надо будет привязать к api gw. ALB должен работать на своём доменном имени, выданном aws

Answer 2

[mayton2019]

Наиболее дешевый вариант масштабирования - это переписать REST-приложение vasya на AWS Lambda. Это не всегда архитектурно возможно ввиду ограничений на сеанс и объемы ресурсов. Но если получится - то можно запускать до 1000 экземпляров Васи в параллель.

Comments

[Вадим]

Это я знаю. Не хочу использовать serverless, хочу понять какую можно сделать архитектуру если backend лежит или как standalone или как докер контейнер на EC2 !? Пока что одной статьи, которая ясно опимывает все - не нашел !

[Вадим]

Вернее нашел, но все с NLB

[mayton2019]

Смотри. Типичное бизнес-приложение всегда имеет лимит мастабирования. Эта тема корнями уходит в закон Амдала. Грубо говоря что-бы ты не проектировал - всегда будет какое-то бутылочное горло. Например 1 база данных которая не успевает отбивать транзакции или 1 сетевой канал который скушал 100 гигабит и дальше не растет потому что оптический канал по атлантике ты ухе забил выше крыши своим приложеним. Поэтому без NLB просто прикинь что у тебя вообще мастабируется. Может тебе вообще нет смысла маштабировать?

[Вадим]

Я искал вариант с ALB... масштабировать перестаешь когда канал через Атлантику дорого прокладывать ))