Предлагаем вашему вниманию проект Михаила Бурочкина, успешно окончившего курс “Cloud Solution Architecture”.
Я работаю над разработкой 3-уровневой архитектуры веб-приложения в облаке AWS. Вся инфраструктура разворачивается по парадигме IaaC через terraform.
Модель предполагает наличие трёх типов компонентов (уровней):
- балансировщиков (которые принимают на себя весь входящий трафик);
- серверов приложений (с которыми работают клиентские приложения);
- серверов баз данных (с которыми работают серверы приложений).
Цели проектной работы:
- Использовать знания и лучшие практики, полученные на курсе.
- Подготовить дизайн и архитектуру решения для облака AWS.
- Развернуть инфраструктуру через terraform (IaaC).
Используемые технологии:
- Облачные сервисы AWS
- Terraform
Дизайн/архитектура решения:
Реализация:
Используется два региона AWS, в каждом из них развёрнута идентичная сетевая инфраструктура (поэтому схема второго не описана подробно): отдельные vpc для приложения и для БД. В реализованном проекте используются две зоны доступности, но схема может быть масштабирована на три. В vpc для БД используется только одна сеть в каждой зоне доступности, а в vpc для приложений создаётся по три подсети, условные названия:
- private (там разворачиваются инстансы приложений);
- public (там разворачиваются ALB и NAT Gateway, через который приложения выходят в интернет);
- bastion (в этой подсети находится хост-бастион, через который можно попасть во внутреннюю часть проекта для возможной отладки).
Между vpc внутри одного региона установлен пиринг, между vpc app и data в соседнем регионе также установлен пиринг (поскольку приложению необходимо ходить в мастер базы данных для записи), между vpc app между регионами также установлен пиринг для работы хоста-бастион. Приложение разворачивается на EC2 инстансы, которые управляются autoscaling группами (автомасштабирование). Приложение настроено сохранять загружаемые файлы в s3-бакеты. Бакеты синхронизируются между регионами, а перед ними установлен aws cloudfront. В каждом из регионов установлен кластер БД RDS из двух инстансов, но во втором регионе он является репликой, поэтому он может работать только на чтение.
Описание конфигурации
Сетевая адресация:
Регион us-east-1:
| Весь регион | 10.1.0.0/16 |
| vpc app | 10.1.0.0/18 |
| vpc data | 10.1.64.0/18 |
| subnet app_private us-east-1a | 10.1.0.0/21 |
| subnet app_public us-east-1a | 10.1.8.0/21 |
| subnet app_private us-east-1b | 10.1.16.0/21 |
| subnet app_public us-east-1b | 10.1.24.0/21 |
| subnet app_bastion us-east-1a | 10.1.48.0/24 |
| subnet data us-east-1a | 10.1.64.0/21 |
| subnet data us-east-1b | 10.1.80.0/21 |
Регион us-central-1:
| Весь регион | 10.2.0.0/16 |
Внутри региона нарезка адресов аналогична региону us-east-1
Security group
ALB (Балансировщики): разрешены входящие подключения на порт 80 и 443 из интернета App
EC2(виртуальные машины приложений): разрешены входящие подключения на порт 80 из vpc app своего региона и на порт 22 из всей приватной сети (10.0.0.0/8)
DB (БД): разрешены входящие подключения на порт 3306 из всей приватной сети (10.0.0.0/8)
Bastion: разрешены входящие подключения на порт 22 из интернета
Таблицы маршрутизации
Для каждой vpc создаётся таблица маршрутизации, с маршрутом по умолчанию на созданный internet gateway и добавляются маршруты в те vpc, с которыми требуются пиринг (для app во все регионы в app и data, для data — во все регионы в app). Также для каждой сети с приложениями (subnet app private) создаётся отдельная таблица маршрутизации с аналогичными правилами, но маршрут по умолчанию ведёт на nat gateway, созданный в той же зоне доступности в сети public.
Правила масштабирования
Приложение может нелинейно зависеть от количества пользователей и выбран способ масштабирования по нагрузке на cpu на ec2 инстансы. При средней нагрузке более 70% за 2 минуты на все инстансы приложения в данном регионе поднимается ещё один инстанс. При падении нагрузки ниже 20% удаляется один из инстансов.
Сценарии реагирования
- Увеличение входящего трафика выше настроенных правил автомасштабирования
При деградации работы приложения необходимо выполнить следующие действия:
- проверить метрики ALB, увеличилось ли количество трафика на приложение, в случае, если есть корреляция с выкаткой новой версией — откатить к предыдущему релизу;
- проверить нагрузку на поднятые инстансы, если есть проблемы с одним из них, удалить его, чтобы он был пересоздан;
- включить бастион хост (если выключен), подключиться к нему и с него зайти на одну из нод с приложением и проанализировать, откуда взялась повышенная нагрузка;
- увеличить максимально возможное количество инстансов в autoscaling группе — увеличить тип инстанса в autoscaling группе на более мощный;
- если проблема наблюдается только в одном регионе, рассмотреть возможность переключить нагрузку только на второй (смотрите следующий сценарий);
- проанализировать трафик на хостах, является ли он легитимным. В случае подозрения на нелегитимный трафик (боты, атака) рассмотреть возможность подключения AWS WAF или AWS Shield.
- Выход из строя одного региона
При выходе из строя одного из регионов, если это регион с мастером БД, необходимо через консоль выполнить для реплики Promote, затем поменять локальную переменную в app/main.tf main_region на второй регион и сделать импорт ресурса терраформ: terraform import module.app-eu.aws_db_instance.default[0] <db-instance> — тут db-instance — это название БД, которое можно увидеть в консоли. После чего прокатать terraform, он заменит шаблон для создания инстансов на новый, с новым хостом БД для подключения и поменяет дефолтную запись в route53 (эти действия можно выполнить и вручную через консоль). После чего надо удалить в route53 записи, которые ведут в вышедший из строя регион. Если это регион с репликой БД, необходимо только удалить в route53 проблемные записи.
Комментарии по реализации
Запуск терраформа производится в три этапа.
- Первый — от админской учётки, которая создаст необходимых для работы пользователей и необходимые для работы аккаунты.
- Второй — от учётки сетевого инженера, которая создаст необходимые vpc, подсети, шлюзы, пиринги и таблицы маршрутизации.
- Третий — от учётки разработчиков. Здесь описываются необходимые security groups, базы данных, конфигурация приложений, бакетов и балансировщиков, настраиваются политики доступов в бакеты с ec2-инстансов, заводятся записи в днс и сертификаты для них.
Из того, что остаётся сделать «руками» после прокатки — настройка уже непосредственно приложения и как потенциал роста его деплой в рамках CI/CD pipeline.
