0 added
0 removed
Original
2026-01-01
Modified
2026-03-10
1
<p><em>Предлагаем вашему вниманию проект<strong>Михаила Бурочкина</strong>, успешно окончившего курс “<a>Cloud Solution Architecture</a>”.</em></p>
1
<p><em>Предлагаем вашему вниманию проект<strong>Михаила Бурочкина</strong>, успешно окончившего курс “<a>Cloud Solution Architecture</a>”.</em></p>
2
<p>Я работаю над разработкой 3-уровневой архитектуры веб-приложения в облаке AWS. Вся инфраструктура разворачивается по парадигме IaaC через terraform.</p>
2
<p>Я работаю над разработкой 3-уровневой архитектуры веб-приложения в облаке AWS. Вся инфраструктура разворачивается по парадигме IaaC через terraform.</p>
3
<p>Модель предполагает наличие трёх типов компонентов (уровней):</p>
3
<p>Модель предполагает наличие трёх типов компонентов (уровней):</p>
4
<ul><li>балансировщиков (которые принимают на себя весь входящий трафик);</li>
4
<ul><li>балансировщиков (которые принимают на себя весь входящий трафик);</li>
5
<li>серверов приложений (с которыми работают клиентские приложения);</li>
5
<li>серверов приложений (с которыми работают клиентские приложения);</li>
6
<li>серверов баз данных (с которыми работают серверы приложений).</li>
6
<li>серверов баз данных (с которыми работают серверы приложений).</li>
7
</ul><p><strong>Цели проектной работы:</strong></p>
7
</ul><p><strong>Цели проектной работы:</strong></p>
8
<ol><li>Использовать знания и лучшие практики, полученные на курсе.</li>
8
<ol><li>Использовать знания и лучшие практики, полученные на курсе.</li>
9
<li>Подготовить дизайн и архитектуру решения для облака AWS.</li>
9
<li>Подготовить дизайн и архитектуру решения для облака AWS.</li>
10
<li>Развернуть инфраструктуру через terraform (IaaC).</li>
10
<li>Развернуть инфраструктуру через terraform (IaaC).</li>
11
</ol><p><strong>Используемые технологии:</strong></p>
11
</ol><p><strong>Используемые технологии:</strong></p>
12
<ul><li>Облачные сервисы AWS</li>
12
<ul><li>Облачные сервисы AWS</li>
13
<li>Terraform</li>
13
<li>Terraform</li>
14
</ul><p><strong>Дизайн/архитектура решения:</strong></p>
14
</ul><p><strong>Дизайн/архитектура решения:</strong></p>
15
<a></a><p><strong>Реализация:</strong></p>
15
<a></a><p><strong>Реализация:</strong></p>
16
<p>Используется два региона AWS, в каждом из них развёрнута идентичная сетевая инфраструктура (поэтому схема второго не описана подробно): отдельные vpc для приложения и для БД. В реализованном проекте используются две зоны доступности, но схема может быть масштабирована на три. В vpc для БД используется только одна сеть в каждой зоне доступности, а в vpc для приложений создаётся по три подсети, условные названия:</p>
16
<p>Используется два региона AWS, в каждом из них развёрнута идентичная сетевая инфраструктура (поэтому схема второго не описана подробно): отдельные vpc для приложения и для БД. В реализованном проекте используются две зоны доступности, но схема может быть масштабирована на три. В vpc для БД используется только одна сеть в каждой зоне доступности, а в vpc для приложений создаётся по три подсети, условные названия:</p>
17
<ul><li>private (там разворачиваются инстансы приложений);</li>
17
<ul><li>private (там разворачиваются инстансы приложений);</li>
18
<li>public (там разворачиваются ALB и NAT Gateway, через который приложения выходят в интернет);</li>
18
<li>public (там разворачиваются ALB и NAT Gateway, через который приложения выходят в интернет);</li>
19
<li>bastion (в этой подсети находится хост-бастион, через который можно попасть во внутреннюю часть проекта для возможной отладки).</li>
19
<li>bastion (в этой подсети находится хост-бастион, через который можно попасть во внутреннюю часть проекта для возможной отладки).</li>
20
</ul><p>Между vpc внутри одного региона установлен пиринг, между vpc app и data в соседнем регионе также установлен пиринг (поскольку приложению необходимо ходить в мастер базы данных для записи), между vpc app между регионами также установлен пиринг для работы хоста-бастион. Приложение разворачивается на EC2 инстансы, которые управляются autoscaling группами (автомасштабирование). Приложение настроено сохранять загружаемые файлы в s3-бакеты. Бакеты синхронизируются между регионами, а перед ними установлен aws cloudfront. В каждом из регионов установлен кластер БД RDS из двух инстансов, но во втором регионе он является репликой, поэтому он может работать только на чтение.</p>
20
</ul><p>Между vpc внутри одного региона установлен пиринг, между vpc app и data в соседнем регионе также установлен пиринг (поскольку приложению необходимо ходить в мастер базы данных для записи), между vpc app между регионами также установлен пиринг для работы хоста-бастион. Приложение разворачивается на EC2 инстансы, которые управляются autoscaling группами (автомасштабирование). Приложение настроено сохранять загружаемые файлы в s3-бакеты. Бакеты синхронизируются между регионами, а перед ними установлен aws cloudfront. В каждом из регионов установлен кластер БД RDS из двух инстансов, но во втором регионе он является репликой, поэтому он может работать только на чтение.</p>
21
<p><strong>Описание конфигурации</strong></p>
21
<p><strong>Описание конфигурации</strong></p>
22
<p><strong>Сетевая адресация:</strong></p>
22
<p><strong>Сетевая адресация:</strong></p>
23
<p><strong>Регион us-east-1:</strong></p>
23
<p><strong>Регион us-east-1:</strong></p>
24
<strong>Весь регион</strong>10.1.0.0/16<strong>vpc app</strong>10.1.0.0/18<strong>vpc data</strong>10.1.64.0/18<strong>subnet app_private us-east-1a</strong>10.1.0.0/21<strong>subnet app_public us-east-1a</strong>10.1.8.0/21<strong>subnet app_private us-east-1b</strong>10.1.16.0/21<strong>subnet app_public us-east-1b</strong>10.1.24.0/21<strong>subnet app_bastion us-east-1a</strong>10.1.48.0/24<strong>subnet data us-east-1a</strong>10.1.64.0/21<strong>subnet data us-east-1b</strong>10.1.80.0/21<p><strong>Регион us-central-1:</strong></p>
24
<strong>Весь регион</strong>10.1.0.0/16<strong>vpc app</strong>10.1.0.0/18<strong>vpc data</strong>10.1.64.0/18<strong>subnet app_private us-east-1a</strong>10.1.0.0/21<strong>subnet app_public us-east-1a</strong>10.1.8.0/21<strong>subnet app_private us-east-1b</strong>10.1.16.0/21<strong>subnet app_public us-east-1b</strong>10.1.24.0/21<strong>subnet app_bastion us-east-1a</strong>10.1.48.0/24<strong>subnet data us-east-1a</strong>10.1.64.0/21<strong>subnet data us-east-1b</strong>10.1.80.0/21<p><strong>Регион us-central-1:</strong></p>
25
Весь регион10.2.0.0/16<p>Внутри региона нарезка адресов аналогична региону us-east-1</p>
25
Весь регион10.2.0.0/16<p>Внутри региона нарезка адресов аналогична региону us-east-1</p>
26
<p><strong>S</strong><strong>ecurity group</strong></p>
26
<p><strong>S</strong><strong>ecurity group</strong></p>
27
<p>ALB (Балансировщики): разрешены входящие подключения на порт 80 и 443 из интернета App</p>
27
<p>ALB (Балансировщики): разрешены входящие подключения на порт 80 и 443 из интернета App</p>
28
<p>EC2(виртуальные машины приложений): разрешены входящие подключения на порт 80 из vpc app своего региона и на порт 22 из всей приватной сети (10.0.0.0/8)</p>
28
<p>EC2(виртуальные машины приложений): разрешены входящие подключения на порт 80 из vpc app своего региона и на порт 22 из всей приватной сети (10.0.0.0/8)</p>
29
<p>DB (БД): разрешены входящие подключения на порт 3306 из всей приватной сети (10.0.0.0/8)</p>
29
<p>DB (БД): разрешены входящие подключения на порт 3306 из всей приватной сети (10.0.0.0/8)</p>
30
<p>Bastion: разрешены входящие подключения на порт 22 из интернета</p>
30
<p>Bastion: разрешены входящие подключения на порт 22 из интернета</p>
31
<p><strong>Таблицы маршрутизации</strong></p>
31
<p><strong>Таблицы маршрутизации</strong></p>
32
<p>Для каждой vpc создаётся таблица маршрутизации, с маршрутом по умолчанию на созданный internet gateway и добавляются маршруты в те vpc, с которыми требуются пиринг (для app во все регионы в app и data, для data - во все регионы в app). Также для каждой сети с приложениями (subnet app private) создаётся отдельная таблица маршрутизации с аналогичными правилами, но маршрут по умолчанию ведёт на nat gateway, созданный в той же зоне доступности в сети public.</p>
32
<p>Для каждой vpc создаётся таблица маршрутизации, с маршрутом по умолчанию на созданный internet gateway и добавляются маршруты в те vpc, с которыми требуются пиринг (для app во все регионы в app и data, для data - во все регионы в app). Также для каждой сети с приложениями (subnet app private) создаётся отдельная таблица маршрутизации с аналогичными правилами, но маршрут по умолчанию ведёт на nat gateway, созданный в той же зоне доступности в сети public.</p>
33
<p><strong>Правила масштабирования</strong></p>
33
<p><strong>Правила масштабирования</strong></p>
34
<p>Приложение может нелинейно зависеть от количества пользователей и выбран способ масштабирования по нагрузке на cpu на ec2 инстансы. При средней нагрузке более 70% за 2 минуты на все инстансы приложения в данном регионе поднимается ещё один инстанс. При падении нагрузки ниже 20% удаляется один из инстансов. </p>
34
<p>Приложение может нелинейно зависеть от количества пользователей и выбран способ масштабирования по нагрузке на cpu на ec2 инстансы. При средней нагрузке более 70% за 2 минуты на все инстансы приложения в данном регионе поднимается ещё один инстанс. При падении нагрузки ниже 20% удаляется один из инстансов. </p>
35
<p><strong>Сценарии реагирования</strong></p>
35
<p><strong>Сценарии реагирования</strong></p>
36
<ol><li><strong>Увеличение входящего трафика выше настроенных правил автомасштабирования</strong></li>
36
<ol><li><strong>Увеличение входящего трафика выше настроенных правил автомасштабирования</strong></li>
37
</ol><p>При деградации работы приложения необходимо выполнить следующие действия:</p>
37
</ol><p>При деградации работы приложения необходимо выполнить следующие действия:</p>
38
<ul><li>проверить метрики ALB, увеличилось ли количество трафика на приложение, в случае, если есть корреляция с выкаткой новой версией - откатить к предыдущему релизу;</li>
38
<ul><li>проверить метрики ALB, увеличилось ли количество трафика на приложение, в случае, если есть корреляция с выкаткой новой версией - откатить к предыдущему релизу;</li>
39
<li>проверить нагрузку на поднятые инстансы, если есть проблемы с одним из них, удалить его, чтобы он был пересоздан;</li>
39
<li>проверить нагрузку на поднятые инстансы, если есть проблемы с одним из них, удалить его, чтобы он был пересоздан;</li>
40
<li>включить бастион хост (если выключен), подключиться к нему и с него зайти на одну из нод с приложением и проанализировать, откуда взялась повышенная нагрузка;</li>
40
<li>включить бастион хост (если выключен), подключиться к нему и с него зайти на одну из нод с приложением и проанализировать, откуда взялась повышенная нагрузка;</li>
41
<li>увеличить максимально возможное количество инстансов в autoscaling группе - увеличить тип инстанса в autoscaling группе на более мощный;</li>
41
<li>увеличить максимально возможное количество инстансов в autoscaling группе - увеличить тип инстанса в autoscaling группе на более мощный;</li>
42
<li>если проблема наблюдается только в одном регионе, рассмотреть возможность переключить нагрузку только на второй (смотрите следующий сценарий);</li>
42
<li>если проблема наблюдается только в одном регионе, рассмотреть возможность переключить нагрузку только на второй (смотрите следующий сценарий);</li>
43
<li>проанализировать трафик на хостах, является ли он легитимным. В случае подозрения на нелегитимный трафик (боты, атака) рассмотреть возможность подключения AWS WAF или AWS Shield.</li>
43
<li>проанализировать трафик на хостах, является ли он легитимным. В случае подозрения на нелегитимный трафик (боты, атака) рассмотреть возможность подключения AWS WAF или AWS Shield.</li>
44
</ul><ul><li><strong>Выход из строя одного региона</strong></li>
44
</ul><ul><li><strong>Выход из строя одного региона</strong></li>
45
</ul><p>При выходе из строя одного из регионов, если это регион с мастером БД, необходимо через консоль выполнить для реплики Promote, затем поменять локальную переменную в app/main.tf main_region на второй регион и сделать импорт ресурса терраформ: terraform import module.app-eu.aws_db_instance.default[0] <db-instance> - тут db-instance - это название БД, которое можно увидеть в консоли. После чего прокатать terraform, он заменит шаблон для создания инстансов на новый, с новым хостом БД для подключения и поменяет дефолтную запись в route53 (эти действия можно выполнить и вручную через консоль). После чего надо удалить в route53 записи, которые ведут в вышедший из строя регион. Если это регион с репликой БД, необходимо только удалить в route53 проблемные записи. </p>
45
</ul><p>При выходе из строя одного из регионов, если это регион с мастером БД, необходимо через консоль выполнить для реплики Promote, затем поменять локальную переменную в app/main.tf main_region на второй регион и сделать импорт ресурса терраформ: terraform import module.app-eu.aws_db_instance.default[0] <db-instance> - тут db-instance - это название БД, которое можно увидеть в консоли. После чего прокатать terraform, он заменит шаблон для создания инстансов на новый, с новым хостом БД для подключения и поменяет дефолтную запись в route53 (эти действия можно выполнить и вручную через консоль). После чего надо удалить в route53 записи, которые ведут в вышедший из строя регион. Если это регион с репликой БД, необходимо только удалить в route53 проблемные записи. </p>
46
<p><strong>Комментарии по реализации</strong></p>
46
<p><strong>Комментарии по реализации</strong></p>
47
<p>Запуск терраформа производится в три этапа. </p>
47
<p>Запуск терраформа производится в три этапа. </p>
48
<ol><li>Первый - от админской учётки, которая создаст необходимых для работы пользователей и необходимые для работы аккаунты. </li>
48
<ol><li>Первый - от админской учётки, которая создаст необходимых для работы пользователей и необходимые для работы аккаунты. </li>
49
<li>Второй - от учётки сетевого инженера, которая создаст необходимые vpc, подсети, шлюзы, пиринги и таблицы маршрутизации.</li>
49
<li>Второй - от учётки сетевого инженера, которая создаст необходимые vpc, подсети, шлюзы, пиринги и таблицы маршрутизации.</li>
50
<li>Третий - от учётки разработчиков. Здесь описываются необходимые security groups, базы данных, конфигурация приложений, бакетов и балансировщиков, настраиваются политики доступов в бакеты с ec2-инстансов, заводятся записи в днс и сертификаты для них. </li>
50
<li>Третий - от учётки разработчиков. Здесь описываются необходимые security groups, базы данных, конфигурация приложений, бакетов и балансировщиков, настраиваются политики доступов в бакеты с ec2-инстансов, заводятся записи в днс и сертификаты для них. </li>
51
</ol><p>Из того, что остаётся сделать "руками" после прокатки - настройка уже непосредственно приложения и как потенциал роста его деплой в рамках CI/CD pipeline.</p>
51
</ol><p>Из того, что остаётся сделать "руками" после прокатки - настройка уже непосредственно приложения и как потенциал роста его деплой в рамках CI/CD pipeline.</p>
52
52