[Из песочницы] AWS — сколько нужно сервисов, чтобы поднять веб-приложение?
Так получилось, что до 2020 года я не имел дело с облаками. Когда же, наконец, углубился в эту тему, то немного потерялся от обилия сервисов, предлагаемых в AWS.
Необходимо было создать приложение с такими фичами:
- Авторизацией через facebook или google.
- Возможностью загрузки и отображения медиа-файлов.
- Получением событий с сервера в реальном времени.
В этой статье описаны сервисы, которые понадобились мне для реализации проекта и ощущения от процесса.
Архитектура приложения
Веб-сервис
Бизнес-логика нашего приложения реализована в виде веб-сервиса и помещена в докер-контейнер. Для запуска контейнеров в AWS можно использовать два сервиса Fargate и Elastic Beanstalk.
Fargate
Модный PaaS поверх ECS или EKS (EKS-Elastic Kubernetes Service, ECS-Elastic Container Service — проприетарная альтернатива kubernetes). Конфигурация выполняется путем описания высокоуровневой абстракции — задачи (Task), в которой указывается необходимое количество вычислительных ресурсов для ваших контейнеров.
Elastic Beanstalk
Появился задолго до Fargate. Позволяет запустить приложение на виртуалках (EC2). В том числе есть конфигурация и для старта докер-контейнера. Из недостатков — сложен в конфигурировании, виртуалки медленно создаются. Из преимуществ — цена. Elastic Beanstalk значительно дешевле при небольших средних нагрузках.
Еще один небольшой плюс Elastic Beanstalk — возможность мониторить сетевой трафик виртуалок. В Fargate я так и не разобрался как это сделать.
Application Load Balancer
И Fargate, и Elastic Beanstalk предусматривают возможность горизонтального масштабирования. В обоих случаях балансировщик нагрузки конфигурируется автоматически. Предполагается, что вы не меняете настройки балансировщика напрямую. В Fargate масштабирование описывается в Task Definition, Elastic Beanstalk создает Auto Scaling Group.
Application Load Balancer работает на уровне HTTP. В принципе он может обрабатывать и HTTPS, но, так как он находится за CloudFront, то нам это не требуется. От ALB на инстансы идет уже только HTTP.
Состояние
Для хранения состояния используются три сервиса.
DynamoDB
NoSql база данных. Работает очень быстро (в пределах 10–20 миллисекунд на запрос). Поддерживает условные обновления, что позволяет организовать оптимистическую транзакционность.
S3
Хранилище файлов. Практически безразмерное. Позволяет открыть прямой доступ из интернета. Таким образом пользователи могут заливать и скачивать контент без использования вычислительных ресурсов сервиса нашего приложения.
Parameters Store
Хранилище настроек сервиса. Позволяет хранить ключи в зашифрованном виде.
Фасад
Технически, в облаке каждый сервис выставлен в интернет, так что, при наличии прав, клиент может обращаться к нему напрямую. Например, в нашем приложении, клиент напрямую заливает медиа-файлы в S3.
В остальных же случаях взаимодействие клиента с бэкендом идет через описанные ниже сервисы.
Route53
DNS от AWS.
CloudFront
CDN от AWS. В настройках CloudFront задаются правила по перенаправлению запросов к медиа-контенту на S3, а api-вызовов на наш веб-сервис. Также здесь можно настроить редирект с Http на Https (понадобится отдельный публичный S3 bucket с правилом редиректа).
AppSync
AppSync — часть большой перспективной концепции — AWS Amplify. Позволяет быстро разрабатывать мобильные приложения с serverless-бэкендом или даже no-code-бэкендом. Наше приложение не такое «модное», но мы не могли пройти мимо AppSync, так это чуть ли не единственный сервис AWS, позволяющий публиковать и подписываться на сообщения.
Cognito
Отвечает в aws за регистрацию и авторизацию пользователей. Позволяет создать User Pool c привязкой к аккаунтам в Google, Amazon, Facebook и не только.
DevOps сервисы
Сервисы для базовых девелоперских операций представлены на следующей схеме.
Управление доступом к сервисам и ресурсам осуществляется с помощью IAM-Identity and Access Management.
Для автоматизации развертывания ресурсов используется CloudFormation, как с помощью шаблонов, так и из программного кода, с помощью SDK. Единица управления ресурсами называется стеком.
Конвейер обновления версий кода создается с помощью группы сервисов:
- CodeCommit — менеджер git-репозиториев, может быть безболезненно заменен на github.
- CodeBuild — сборка и публикация артефактов. Докеровские образы сохраняются в ECR-Elastic Container Repository.
- CodeDeploy — поставка, в нашем случае в Fargate или Elastic Beanstalk.
- CodePipeline — оркестрация конвейера.
Все логи накапливаются в CloudWatch. Там же, в пару кликов мыши, можно настроить алерты и дашборды для мониторинга.
Ответ на заглавный вопрос
Итак, для того, чтобы запустить веб-приложение, понадобилось 9 сервисов AWS, а для того, чтобы настроить девелоперские операции — еще 8 сервисов.
Следует отдать должное AWS, они максимально уменьшили порог вхождения, документации и примеров — предостаточно, но все же 17 раз пришлось разбираться с логикой проприетарного сервиса!
Когда я начинал, то не думал, что мне это может понравится. Я сопротивлялся. Так, например, закодил самостоятельно механизм jwt-аутентификации, вместо того, чтобы использовать Cognito.
Но я поменял свое мнение. Все же приятно сбросить с плеч груз инфраструктурного кода и сконцентрироваться на бизнес-логике. Немного освоившись, я начал испытывать чувства ребенка в парке аттракционов. Каждый новый сервис — новое веселье. Я рад, что этот парк пока не исследован до конца. Для себя я принял решение, что я здесь надолго.
