Основы надёжности и эффективности производительности

Пиллар Reliability фреймворка Well-Architected гарантирует, что рабочая нагрузка правильно и стабильно выполняет свои функции тогда, когда это требуется. Reliability охватывает три области: основы (ограничения сервисов, топология сети), архитектура рабочей нагрузки (распределённые системы, отказ от единых точек отказа) и управление изменениями и сбоями (мониторинг, масштабирование, восстановление после сбоев). Цель — создавать системы, которые автоматически восстанавливаются после нарушений работы инфраструктуры или сервисов.

AWS устанавливает квоты сервисов (ранее называвшиеся ограничениями) для ресурсов, чтобы защищать всех клиентов. Например, существуют квоты на количество экземпляров EC2 в регионе по умолчанию, квоты VPC и ограничения на количество одновременных выполнений Lambda. Если рабочая нагрузка неожиданно достигает квоты, запросы будут ограничиваться или отклоняться, что приведёт к сбоям Reliability. Используйте консоль Service Quotas или CLI, чтобы просматривать текущие ограничения и запрашивать их увеличение заранее. Отслеживайте показатели использования, чтобы обнаружить приближение к ограничениям до того, как это повлияет на доступность.

Пиллар Reliability подчёркивает необходимость автоматического восстановления без вмешательства человека. AWS предоставляет несколько механизмов автоматического восстановления: EC2 Auto Recovery автоматически восстанавливает экземпляр на том же оборудовании или перемещает его на исправное оборудование при сбое базовых проверок. Проверки работоспособности ASG завершают работу неисправных экземпляров и запускают им замену. RDS Multi-AZ автоматически переключается на резервный экземпляр. Проектируйте архитектуру так, чтобы большинство сценариев сбоев запускали автоматические действия по восстановлению, заданные в оповещениях CloudWatch.

Пиллар Reliability рекомендует горизонтальное масштабирование (добавление большего количества небольших экземпляров), а не вертикальное (переход к более крупным экземплярам) для повышения надёжности. Один большой экземпляр является единой точкой отказа. Если за балансировщиком нагрузки работает много небольших экземпляров, отказ любого отдельного экземпляра оказывает минимальное влияние. AWS Auto Scaling автоматически регулирует размер группы в соответствии со спросом, обеспечивая достаточную вычислительную ёмкость и предотвращая оплату простаивающих ресурсов в периоды низкой нагрузки.

Пиллар Reliability требует тестировать процедуры восстановления, а не предполагать, что они работают. Используйте AWS Fault Injection Simulator (FIS), чтобы контролируемым образом вносить сбои в систему: завершать работу случайных экземпляров EC2, ограничивать вызовы API и добавлять задержку в сети. Проводите такие эксперименты в рабочей среде (с предусмотренными мерами защиты), чтобы убедиться, что мониторинг обнаруживает сбои, автоматическое масштабирование реагирует, а восстановление завершается в пределах Вашего RTO. Непротестированные процедуры восстановления часто не выдерживают нагрузку реального инцидента.

Пиллар Performance Efficiency посвящён эффективному использованию вычислительных ресурсов для выполнения требований системы и поддержанию этой эффективности по мере изменения спроса и развития технологий. Основные принципы проектирования: сделайте передовые технологии доступными — используйте управляемые сервисы (RDS, SageMaker) вместо создания всего с нуля. Выходите на глобальный уровень за считаные минуты — развёртывайте ресурсы в нескольких регионах с помощью CloudFormation. Используйте бессерверные архитектуры — исключите управление инфраструктурой. Экспериментируйте чаще — тестируйте разные типы экземпляров и конфигурации.

Performance Efficiency начинается с выбора подходящего типа вычислительных ресурсов для рабочей нагрузки. EC2 предлагает десятки семейств экземпляров, оптимизированных для разных сценариев: c-series — для ресурсоёмких вычислений (кодирование видео, пакетная обработка), r-series — для ресурсоёмких операций с памятью (базы данных в памяти, кэширование), i-series — для ресурсоёмких операций с хранилищем (NoSQL, хранилища данных), p/g-series — для рабочих нагрузок на GPU (обучение моделей машинного обучения). Использование неподходящего типа экземпляра означает оплату неиспользуемой ёмкости или снижение производительности.

Кэширование — фундаментальный приём повышения Performance Efficiency, снижающий задержку и нагрузку на базу данных. ElastiCache (Redis/Memcached) хранит результаты запросов к базе данных в памяти, обеспечивая доступ за миллисекунды. CloudFront кэширует HTTP-ответы в пограничных расположениях рядом с пользователями. Кэширование API Gateway снижает количество вызовов Lambda за счёт кэширования ответов API. DAX (DynamoDB Accelerator) добавляет перед DynamoDB внутриизменяемый кэш с доступом за микросекунды. Выбирайте подходящий уровень кэширования в зависимости от места возникновения узкого места — базы данных, API или доставки на периферии.

Выбор хранилища значительно влияет на производительность. io2 Block Express EBS обеспечивает до 256 000 IOPS для высокопроизводительных баз данных. gp3 используется по умолчанию для большинства рабочих нагрузок при меньшей стоимости. Хранилище экземпляра обеспечивает максимальное количество IOPS (NVMe) для временных данных. S3 масштабируется до тысяч запросов в секунду для объектного хранилища. EFS предоставляет общий доступ к файлам POSIX. Выбирайте хранилище с учётом характера операций ввода-вывода: последовательное чтение выигрывает от st1 (Throughput Optimised HDD), а для случайного ввода-вывода требуются тома SSD.

Performance Efficiency — это не разовое решение: необходимо Continuously отслеживать показатели производительности и пересматривать свой выбор по мере выпуска AWS новых сервисов. Используйте панели CloudWatch, чтобы отслеживать процентили задержки p50, p90 и p99 (а не только средние значения, которые скрывают задержки в хвосте распределения). Используйте трассировки X-Ray, чтобы находить самые медленные участки цепочки запросов. Настройте обнаружение аномалий CloudWatch для автоматического построения базовой линии и оповещения об аномальных отклонениях производительности. Регулярно просматривайте объявления AWS: новые типы экземпляров часто обеспечивают более высокую производительность при меньшей стоимости.

Для достижения Performance Efficiency иногда приходится идти на компромиссы с другими пилларами. Добавление кэша (ElastiCache) повышает производительность, но увеличивает сложность эксплуатации (компромисс с Operational Excellence) и стоимость (компромисс с Cost Optimisation). Использование DynamoDB вместо RDS повышает производительность при масштабировании, но требует переработки модели данных (затраты усилий в рамках Operational Excellence). Фреймворк Well-Architected признаёт наличие таких компромиссов и предлагает принимать их осознанно, документируя обоснование. В вопросах экзамена ищите вариант, который достигает целей по производительности с наименьшими эксплуатационными затратами.

Проверьте, насколько хорошо Вы поняли концепции AWS Solutions Architect (SAA-C03) из этого урока.

В этом уроке Вы узнали, что Reliability требует автоматического восстановления, горизонтального масштабирования и регулярного тестирования сбоев, Performance Efficiency требует выбора подходящих вычислительных ресурсов, хранилища и типа базы данных для каждой рабочей нагрузки, а кэширование на нескольких уровнях снижает задержку и нагрузку на базу данных. Оба пиллара требуют непрерывного мониторинга и готовности пересматривать архитектурные решения. Далее мы рассмотрим пиллары Cost Optimisation и Sustainability.