41
https://www.cloudflare.com/ . Такое решение позволяет быстро изменять размеры
инфраструктуры, разворачивать при необходимости новые сервисы, быстро
масштабироваться и избежать дополнительных затрат на поддержку и
эксплуатацию.
Сервисы разворачиваются в сервисе Elastic Container Service Fargate, что
позволяет использовать одни и те же образы, которые используют программисты
для тестирования и разработки, QA для интеграционного и юнит тестирования,
Demo стенд для проведения демонстрации клиенту и бенефициарам.
1.3.2 Выбор и обоснование стратегии автоматизации задачи
В нашем случае наиболее подходящими стратегиями автоматизации
являются синергия хаотичной автоматизации в местах так называемого
бутылочного горлышка, узкого места, которое мешает продвижению по
конвейеру производства программного обеспечения, и автоматизация по
направлениям:
• Тестирование
• Сборка программного обеспечения
• Непрерывная доставка программного обеспечения в инфраструктуру
• Управление конфигурациями
• Автоматизация разворачивания инфраструктуры
• Непрерывная безопасность
• Непрерывная интеграция
• Мониторинг, телеметрия, метрики
• Логирование
В первую очередь необходимо настроить автоматизацию сборки
программ, и запуск тестов по расписанию при помощи сервера непрерывной
поставки [16] TeamCity CI/CD [17] сервера:
• Модульное тестирование (Unit Testing)
• Интеграционное тестирование (Integration Testing)
• Системное тестирование (System Testing)
42
• Операционное тестирование (Release Testing)
• Приемочное тестирование (Acceptance Testing)
• Тестирование пользовательских интерфейсов (UI Testing)
Поставку программного обеспечения будем также осуществлять с
помощью сервера интеграции TeamCity, используя bash скрипты, AWS CLI [6],
Docker [8], Amazon Container Services [7] и подход практики инфраструктура как
код [3].
Управление конфигурациями частично решается с помощью Docker, а
также Ansible [18].
К развёртыванию инфраструктуры с помощью кода в AWS решено
использовать Terraform, это позволит иметь аналогичную конфигурацию
заказанных серверов в тестовом, демо и производственных окружениях, что
исключит возможность человеческой ошибки и неоднородности сред.
Статическую проверку кода и модулей на уязвимости решено проверять
при помощи SonarQube, это исключит возможность попадания в сборку
небезопасных модулей и позволит раньше проводить проверку кода на
безопасность, что поможет ускорить доставку ПО без необходимости проверять
и исправлять код, который находится на этапе перед доставкой кода в
производственную среду.
Статический анализатор образов докер производится во время сборки на
TeamCity при помощи сканера уязвимостей внутри образов Trivy [19]
Мониторинг разворачивается при помощи запуска Docker [8] стека,
данные из серверов отправляются при помощи экспортеров, которые
настраиваются на EC2 [15] серверах при помощи Ansible.
Для автоматизации логирования используется ELK (ElasticSearch,
Logstash, Kibana) [20] стек, который предоставляет анализатор логов Kibana, а
также отправку сообщений об ошибках при помощи Logstash в средство
управления оповещениями и инцидентами OpsGenie [21] и дальнейшую
эскалацию инцидентов в команду поддержки.
43
1.3.3 Выбор и обоснование способа приобретения ИС для автоматизации
задачи
Платформой для разворачивания инфраструктуры исторически выбран
Amazon Web Services для возможности работать с несколькими регионами и
использования готовых решений для различных задач автоматизации.
Используются следующие платные ресурсы, предлагаемые платформой:
• EC2 инстансы с установленной Ubunt в роли пограничных серверов
• ElasticSearch Service [20] для логирования и аналитики
• Куплена поддержка со стороны платформы
• RedShift — база данных для аналитической обработки
• LoadBalancer в роли балансировщика нагрузки для входящего и
исходящего трафика на web-сервер Nginx
• Elastic Container Service для запуска задеплоенных сервисов
• RDS PostrgreSQL сервер в роли реляционной базы данных
• CloudWatch как средство сбора и аналитики логов со всех внутренних
сервисов и пограничных серверов
Aiven Kafka предоставляет сервис стриминговой передачи данных для
хранения оперативной информации. Сервис выбран для снижения сложности
обслуживания со стороны эксплуатации и дороговизны покупки
соответствующей инфраструктуры.
Документ-ориентированная база данных MongoDB также используется
как платформа, также снижается стоимость и сложность обслуживания со
стороны эксплуатации.
1.4 Обоснование проектных решений
1.4.1 Обоснование проектных решений по информационному обеспечению
Итак, определим последовательность, которая определяет схему
движения процесса. От разработчиков код подтверждается для сохранения
изменений и затем попадает в хранилище (репозиторий). Затем сервер
интеграции CI определяет, что в репозитории произошли изменения и запускает
44
сборку кода вместе с необходимыми зависимостями. После сборки необходимо
запустить тесты, озвученные в главе 1.3.2. Затем, если тесты проходят проверку,
собранный код разворачивается в окружении, предназначенном для разработки
и тестирования, где снова проходит тестирование, например, миграций и
интеграционные тесты. Затем, если все задачи, которые необходимо было
выполнить, закрыты разработчиками, то коду присваивается версия и
отправляется в производственное окружение. И уже оттуда мы можем снимать
телеметрию, и таким образом иметь представление о том, как работает наш код.
Рисунок 22. Схема процесса доставки программного обеспечения
1.4.2 Обоснование проектных решений по программному обеспечению
Так как разработка осуществляется на языке Java версии 12.0.1, сборщик
для зависимостей выбрали Maven [9].
Для автоматизации сборки и деплоймента в роли CI сервера используется
TeamCity [17] сервер и агенты сборки в связи с тем, что порог вхождения для
использования гораздо ниже других решений, таких, как GitlabCI или
BitbucketCI.
Собранные артефакты необходимо заворачивать в универсальные образы
с определённым окружением, для этого решено использовать образы Docker [8],
с установленной системой Alpine 3.11 последней версии и установленной Java
12.0.1, это единственные образы, которые проходят все тесты на уязвимости в
Trivy.
45
Готовые образы с собранным кодом внутри разворачиваются в Amazon
Container Services, который помогает оркестрировать и настраивать
взаимодействие между микросервисами.
Когда код необходимо разворачивать на девелоперском или
производственном окружении, мы хотим это описать кодом [3], чтобы избежать
рутинной операции и минимизировать количество ошибок, которое возникает
из-за разницы окружений. Поэтому для разворачивания инфраструктуры выбран
Terraform [22], для хранения состояния изменений, сделанных в Terraform,
используется Amazon Simple Storage Service [23] хранилище. Для управления
конфигурациями выбран Ansible [18] из-за поддержки изнутри системы
автоматизации Amazon Systems Manager [24], который также позволяет
автоматизировать рутинные операции конфигурирования окружения.
Выбор базы данных
Мы выбирали базы данных для агрегации логов и их последующей
обработки. Платформа AWS предоставляет CloudWatch Logs для хранения логов
и метрик. Но мы хотели каким-то образом иметь доступ через пользовательский
интерфейс и аналитику. Для этого мы решили отправлять данные в документ-
ориентированную базу данных и затем установить инструмент для аналитики.
Мы выбирали между ClickHouse и ElasticSearch.
Таблица 3
Сравнение СУБД ClickHouse и ElasticSearch
№ п/п
ClickHouse
ElasticSearch
1.
Быстрая
Мощный API с возможностью обрабатывать
входящие данные, поддержка CRUD
2.
Хорошо сжимает
данные
Поисковая система, обратный индекс
3.
RESTful
Поиск по базе близок к реальному времени
4.
Удобный CLI
Предлагает решение с пользовательским
интерфейсом для аналитики Kibana
46
№ п/п
ClickHouse
ElasticSearch
5.
Полностью
утилизирует
ресурсы ЦПУ
Утилизирует ресурсы памяти, быстрее
обрабатывает входящие потоки
6.
Горизонтальное
масштабирование
Масштабируется вглубь и горизонтально
7.
Бесплатная
Предоставляется сервисом AWS
Посмотрим на их поведение под нагрузкой:
Рисунок
23. Утилизация ЦПУ на Cli
Рисунок 24. Утилизация ОЗУ при высокой нагрузке ElasticSearch
ckHouse
47
Рисунок 25. Утилизация CPU при высокой нагрузке ElasticSearch
Мы видим, что у ClickHouse очень высокий процент утилизации ЦПУ при
большом количестве записей на наших инстансах, так как мы живём в облаке,
для нас очень дорого оплачивать именно процессорное время, а в следствие
низкой скорости дисковой подсистемы мы получали ошибку «DB::Exception:
Too many parts (300). Merges are processing significantly slower than inserts» и
теряли наши логи. При этом у ElasticSearch [20] идёт повышенная утилизация
памяти, которая отдельно не оплачивается в AWS. Поэтому для агрегации логов
мы решили использовать стек ElasticSearch, Logstash и Kibana в роли UI для
анализа логов.
48
Рисунок 26. Пользовательский интерфейс взаимодействия с
анализом данных для логов
ElasticSearch также решили использовать для взаимодействия с
системами анализа безопасности Wazuh:
49
Рисунок 27. Система обнаружения уязвимостей Wazuh 3.11.7
Также для хранения метрик с Prometheus сервера мы будем использовать
InfluxDB 2.0, которая предназначена для хранения временных рядов. БД
написана на языке Go и не требует внешних зависимостей. Основным
назначением является хранение больших объемов данных с метками времени.
Например, данные мониторинга и метрики приложений.
1.4.3 Обоснование проектных решений по техническому обеспечению
Разрабатываемый код оборачивается в образы Docker [8], и затем во время
передачи образа в ECS кластер [7] мы можем определить, сколько ресурсов CPU
и памяти мы хотим выделить для работы сервиса и передать файл конфигурации
в виде json файла в сущность Task Definition внутри AWS ECS [10]. Это
позволяет разделять и платить только за те ресурсы, которые мы используем.
Также это позволяет конфигурировать, например, подключение к базе данных и
другие параметры при необходимости.
50
При конфигурировании EC2 серверов, таких, как Бастион сервер или
Nginx сервер, мы можем также заказывать сервера с определённым набором
CPU, объёмом памяти и размера жёсткого диска и при необходимости
увеличивать количество потребляемых ресурсов и платить только за их
использование, что очень удобно при условии необходимости масштабирования
и планирования бюджета.
Также инстансы можно предоплачивать на длительное время от года до
трёх, что помогает сократить расходы на инфраструктуру.
Кроме масштабирования в глубину AWS предоставляет возможность
масштабирования вширь, благодаря балансировщику нагрузки Amazon NLB,
который работает на уровне L4 [25] и предоставляет возможность
перенаправлять трафик сразу на несколько инстансов. И при увеличении
нагрузки увеличить количество инстансов, которые должны обслуживать
запросы. Например, это актуально для Nginx серверов.