Автор статьи: Роман Шнырев
Cloud & AI architect
Передаем слово Роману
Привет, Хабр!
Сегодня хочу поговорить об уровнях приложений в проде с точки зрения архитектуры/размещения компонентов конечного решения и практиках, рекомендациях по их построению, защите/изоляции.
Статья навеяна общением с юными адептами DevOps-практик, которые изучают, как строить CI/CD pipeline, понимают базовые компоненты, из которых строится решение, но не всегда представляют, как выглядит архитектура решения в проде в целом, какие уровни есть, и как можно их сделать более безопасными (DevSecOps практики для всего CI/CD в данном случае не рассматриваем) хотя бы на базовом уровне.
Цель статьи – показать, из каких уровней строится архитектура приложений, что на них вообще происходит и что можно улучшить, согласно мировым практикам. Рассматривать будем на примере облаков, в частности — AWS, но и для on-premise это будет актуально.
«При чем тут адепты DevOps, да и вообще DevOps?» — спросите вы. И будете абсолютно правы, ведь, как правило, архитектуру решения в облаке рисует Solution Аrchitect или Cloud Architect, а уже DevOps инженер разворачивает инфраструктуру согласно дизайну и обеспечивает работу непрерывного конвейера сборки и доставки. Однако есть и множество исключений, например:
не всегда у компаний из small business есть ресурсы архитектора;
да и в middle зачастую данный функционал отдают роли senior devops, экономя косты;
на freelance, как правило, такие вещи может сделать и devops инженер, cloud инженер и т.д.
На рисунке ниже приведен пример архитектуры абстрактного приложения, в идеале, согласно cloud native практикам, чтобы Ваше приложение выкатывалось и размазывалось по ним через IaaC.
Количество уровней, как правило, зависит от конкретной реализации вашего решения, они могут удаляться/склеиваться с другими (2-х звенная, 3-х звенная архитектуры и т.д.), могут появляться новые для определенной бизнес-логики, обработки данных или использования AI в ваших решениях, могут располагаться в разных облаках при Multi Cloud или Hybrid Cloud сетапе. Но, в целом, это отражает базовую архитектуру.
Рассмотрим уровни подробнее:
Пограничные сервисы ( Edge services) – сервисы, взаимодействующие с небезопасной средой. Это сервисы, куда приходит трафик пользователей, желающих поработать с вашим решением/приложение. На данном уровне, как правило, настраиваются правила распределения трафика в зависимости от географического расположения пользователей, правила фильтрации трафика и отдача кеша. Примеры таких сервисов – DNS, CDN (Content delivery network), web firewall, защита от ddos. В облаке AWS это Route53(DNS), CloudFront (CDN), WAF (web firefall). Пограничные сервисы в большинстве облаков предоставляет облачный провайдер (далее — CSP или cloud service provider), они отказоустойчивы, прозрачно масштабируемы
VPC (Virtual private cloud) – по сути, изолированная виртуальная сеть для нашего решения в облаке, в рамках которой мы разворачиваем свои сервисы и строим следующие слои решения, периметр нашей безопасности. В данной сущности присутствуют все те же компоненты, что и в обычных/традиционных сетях в on-premise, но все они, как правило, являются управляемыми сервисами CSP. Примеры сетевых сервисов и компонентов в VPC — NAT gateway, internet gateway, firewall правила для подсетей и зон безопасности, таблицы маршрутизации.
Публичные сервисы (public services) — можно сказать, что это DMZ, слой, в котором обеспечивается взаимодействие с вашими сервисами из сети Интернет (Ingress) и доступ от ваших сервисов в сеть Интернет (Egress). Правилом хорошего тона является:
— Принимать весь входящий трафик на ваше решение через балансировщики нагрузки в слое Ingress и далее его обрабатывать, например, редиректить, фильтровать, зеркалировать.
— Исходящий трафик направлять через nat gateway для компонентов решения из других слоев, которым необходим «непрямой» доступ в сеть интернет, например, для обновления пакетов или через internet gateway, в случае если для компонента предусмотрено прямое взаимодействие, например, для публичного балансировщика.
Front-end сервисы – фронтенд вашего приложения, веб-серверы + кеш принимающие трафик от пользователя на первой линии. CSP предоставляют широкий набор компонентов для реализации фронтов. Это могут быть виртуальные машины, контейнеры или, например, serverless.
Application/backend – уровень с бизнес-логикой решения, аналогично прошлому слою может использовать достаточно широкий набор компонентов и управляемых сервисов от CSP для их реализации.
Базы данных/ Работа с данными (DB/data pipeline) – уровень хранения, где размещаются различные БД для хранения данных решения, в зависимости от сложности решения могут использовать различные типы СУБД или даже их микс. В данном уровне также может выть выстроен pipeline для работы с данными, например, для их нормализации, получения ценности/обработки их с помощью AI моделей, архивирование данных на различные типы storage или даже их зеркалирование в другие облака.
Как и в on-premise, все уровни имеют между собой сетевую связанность и необходимо понимать, какие у нас есть информационные потоки в рамках нашего решения, чтобы их контролировать. В идеале «положить схему решения на бумагу», где отразить все взаимодействия в рамках нашего решения, чтобы понять, какие правила firewall (NACL на картинке) нам необходимо настроить и какие маршруты (RT на картинке) прописать отдельно и на каких/для каких сущностей.
В качестве заключения надеюсь, что данная статья оказалась действительно полезной юным адептам DevOps и всем, кто начинает свой путь в облака и ИТ или просто пытается разобраться, из каких слоев состоит архитектура решения.
Спасибо, Хабр! Комментарии крайне привествуются.
Скоро состоится открытое занятие «Оптимизация стоимости владения». На нем поговорим о принципах проектирования с точки зрения оптимизации стоимости владения. Обсудим выбор наиболее подходящих типов ресурсов и определение необходимого количества. Проанализируем расходы в течении времени и масштабирование ресурсов для удовлетворения потребностей бизнеса. Регистрация доступна по ссылке для всех желающих.