Применение шаблонов WAF в реальных архитектурах

Применение шаблонов WAF к реальным архитектурам — это не теоретическое упражнение: оно требует оценивать каждое проектное решение по пяти основам и принимать обоснованные компромиссные решения. Часто начинают с архитектурной схемы: прослеживают путь пользовательского запроса через каждый компонент и на каждом переходе спрашивают, что произойдёт при сбое этого компонента, сколько это будет стоить и как он защищён.

Рассмотрим традиционное монолитное веб-приложение: одна VM, на которой вместе работают веб-сервер и база данных, за общедоступным IP-адресом. По основам WAF такая архитектура получает низкие оценки по всем пяти направлениям: отсутствует избыточность (надёжность), база данных размещена на том же узле, что и веб-уровень (безопасность), VM постоянно работает независимо от трафика (затраты), отсутствует CI/CD (эффективность эксплуатации) и поддерживается только вертикальное масштабирование (эффективность производительности).

Чтобы усилить аспект надёжности, распределите веб-уровень между несколькими VM в разных зонах доступности, обеспечьте для базы данных георепликацию во вторичный регион и разместите перед ними балансировщик нагрузки Azure. Это устраняет единственную точку отказа и позволяет приложению пережить сбой зоны или региона без ручного вмешательства.

Для аспекта безопасности разместите веб-уровень и базу данных в разных подсетях и настройте правила NSG, разрешающие веб-уровню подключаться только к порту базы данных. Храните строку подключения к базе данных в Azure Key Vault, а в веб-приложении используйте управляемое удостоверение для получения этой строки во время выполнения — так учётные данные не будут жёстко прописаны в коде приложения и конфигурационных файлах.

Для оптимизации затрат замените постоянно работающие VM на набор масштабирования Virtual Machine, который уменьшает число экземпляров в часы низкой нагрузки. Для базы данных выясните, будет ли управляемая служба PaaS, например Azure SQL Database с подходящим уровнем DTU, дешевле полноценной VM с SQL Server. Приобретите зарезервированные экземпляры для базовой ёмкости, которую можно спрогнозировать за 12 месяцев вперёд.

Повышайте операционное совершенство, описывая всю инфраструктуру с помощью шаблонов Bicep или ARM, хранящихся в системе контроля версий. Создайте конвейер CI/CD в Azure Pipelines или GitHub Actions, который автоматически развёртывает изменения инфраструктуры и код приложения. Добавьте этапы контроля развёртывания — автоматические дымовые тесты и ручное утверждение — прежде чем изменения попадут в рабочую среду.

Для эффективности производительности добавьте Azure Cache for Redis перед базой данных, чтобы кэшировать часто выполняемые запросы и снизить нагрузку на базу данных. Развёртывайте статические ресурсы (изображения, CSS, JavaScript) через Azure CDN, чтобы предоставлять их с пограничных узлов, расположенных близко к пользователям по всему миру. После каждого изменения выполняйте нагрузочное тестирование приложения, чтобы убедиться, что улучшения измеримы.

Каждое архитектурное изменение связано с компромиссом. Например, переход к архитектуре с несколькими зонами повышает надёжность, но увеличивает затраты (две зоны = две VM). Добавление кэширования Redis повышает производительность, но усложняет эксплуатацию (появляется ещё одна служба, которую нужно отслеживать и обслуживать). В хорошей архитектурной документации эти компромиссы явно зафиксированы, чтобы будущие архитекторы понимали причины принятых решений.

Не пытайтесь достичь совершенства за один редизайн — такой подход дорог, рискован и медленен. Вместо этого используйте цикл итеративных улучшений: проведите проверку Well-Architected, определите три наиболее значимые проблемы, устраните их, измерьте улучшения и повторите цикл. Этот подход согласует архитектурные улучшения с гибкой разработкой и делает прогресс видимым для заинтересованных сторон в каждом спринте.

Microsoft публикует эталонные архитектуры для распространённых шаблонов рабочих нагрузок в Azure Architecture Center. Среди них — архитектуры веб-приложений, микрослужбы на AKS, конвейеры аналитики данных и многие другие решения. Каждая эталонная архитектура уже оценена по аспектам WAF и содержит примечания о компромиссах, сделанных для соответствующего шаблона.

Используйте записи архитектурных решений (ADR), чтобы документировать важные архитектурные решения, контекст, в котором они были приняты, рассмотренные альтернативы и последствия для аспектов WAF. ADR, хранящиеся в системе контроля версий вместе с кодовой базой, создают проверяемую историю, которая помогает новым участникам команды понять, почему архитектура устроена именно так.

Проверьте своё понимание концепций Microsoft Azure Fundamentals (AZ-900) из этого урока.

В этом уроке Вы узнали: шаблоны WAF применяются посредством оценки каждого архитектурного решения по всем пяти аспектам; улучшения можно вносить итеративно, начиная с проблем, оказывающих наибольшее влияние; а компромиссы необходимо документировать, чтобы будущие архитекторы понимали логику решений. Далее мы рассмотрим SLA Azure и способы расчёта составных SLA для архитектур с несколькими службами.