Устранение распространенных проблем архитектуры AWS: решения и советы

Большинство проблем с архитектурой AWS на первый взгляд кажутся неясными: приложение работает медленно, частный экземпляр не может получить доступ к API AWS, балансировщик нагрузки не имеет исправных целей, или отказ базы данных произошел не так, как обещала схема. Самое быстрое устранение неисправностей обычно заключается в отслеживании одного пути запроса и проверке исправности каждого перехода, а не в изменении настроек во всей учетной записи.

Начните с трех вопросов: что изменилось, каков видимый пользователю симптом и где запрос перестает двигаться? Как только вы узнаете, является ли сбой проблемой производительности, подключения, доступности или авторизации, консоль AWS становится гораздо менее зашумленной.

Узкие места производительности

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

Выявление узких мест производительности

Мониторинг ключевых метрик: Используйте сервисы AWS, такие как Amazon CloudWatch, для отслеживания метрик ваших вычислительных ресурсов, хранилищ и баз данных. Обратите внимание на:
- Загрузка ЦП: Постоянно высокая загрузка ЦП на экземплярах EC2 может указывать на недостаточную вычислительную мощность или неэффективный код.
- Использование памяти: Высокое использование памяти может привести к подкачке (swapping), что снижает производительность. Память EC2 не входит в базовые метрики экземпляра по умолчанию, поэтому используйте агент CloudWatch или инструмент мониторинга приложений, если память важна для рабочей нагрузки.
- Сетевой трафик (входящий/исходящий): Всплески или устойчивый высокий сетевой трафик могут указывать на неэффективную передачу данных или возросшую нагрузку.
- Операции ввода-вывода диска (IOPS) и пропускная способность: Для таких сервисов, как Amazon EBS и Amazon S3, превышение установленных лимитов может вызвать замедления, связанные с хранилищем.
- Подключения к базе данных и задержка запросов: Отслеживайте производительность ваших экземпляров Amazon RDS или DynamoDB.
AWS X-Ray: Для распределенных приложений AWS X-Ray помогает визуализировать потоки запросов и выявлять проблемы с производительностью в конкретных вызовах сервисов.
Журналы потоков VPC: Анализируйте шаблоны сетевого трафика для выявления неожиданной или чрезмерной передачи данных.

Решения для узких мест производительности

Масштабирование ресурсов:
- Вертикальное масштабирование (Scale Up): Увеличьте размер экземпляра (ЦП, ОЗУ) ваших экземпляров EC2 или обновите класс экземпляра RDS. Используйте AWS Auto Scaling для автоматической настройки емкости в зависимости от спроса.
- Горизонтальное масштабирование (Scale Out): Добавьте больше экземпляров на уровень приложения (например, используя группы автоматического масштабирования EC2) или распределите нагрузку между несколькими репликами чтения базы данных.
Оптимизация кода приложения: Проверьте код приложения на наличие неэффективных алгоритмов, чрезмерного количества запросов к базе данных или утечек памяти.
Кэширование: Внедрите стратегии кэширования с помощью Amazon ElastiCache (Redis или Memcached) или Amazon CloudFront для статического контента, чтобы снизить нагрузку на внутренние сервисы.
Оптимизация базы данных: Настройте SQL-запросы, добавьте соответствующие индексы или рассмотрите возможность миграции на более производительное решение для баз данных, такое как Amazon Aurora.
Оптимизация хранилища: Выберите правильный тип тома EBS (например, gp3 для общих целей, io2 для высоких IOPS) или используйте Amazon S3 Intelligent-Tiering для оптимизации стоимости и производительности.

Пример: Диагностика высокой загрузки ЦП EC2

Проверьте метрики CloudWatch: Перейдите в CloudWatch, выберите EC2 и просмотрите метрику CPUUtilization для вашего экземпляра. Если она постоянно превышает 80-90%, проведите дальнейшее расследование.
Подключитесь к экземпляру по SSH: Используйте такие инструменты, как top, htop или ps, чтобы определить процессы, потребляющие больше всего ЦП.
Проанализируйте журналы приложения: Ищите ошибки или шаблоны в журналах приложения, которые могут коррелировать с высокой загрузкой ЦП.
Рассмотрите масштабирование: Если рабочая нагрузка является законной и не может быть оптимизирована дальше, рассмотрите возможность увеличения размера экземпляра или включения автоматического масштабирования EC2.

Проблемы с подключением

Проблемы с подключением могут помешать пользователям получить доступ к вашим приложениям или затруднить связь между ресурсами AWS.

Распространенные сценарии подключения

Экземпляры EC2 недоступны: Экземпляры внутри VPC могут быть недоступны из интернета или других экземпляров.
Сбои меж-VPC подключения: Проблемы с подключением ресурсов в разных VPC.
Недоступность конечных точек сервисов: Невозможность подключиться к сервисам AWS (например, S3, RDS) из вашей VPC.

Шаги по устранению неисправностей

Проверьте конфигурацию сети VPC:
- Группы безопасности: Убедитесь, что группы безопасности, прикрепленные к вашим экземплярам, разрешают входящий трафик на требуемых портах с правильных исходных IP-адресов или групп безопасности. Помните, что группы безопасности являются stateful (отслеживают состояние).
- Сетевые ACL (NACL): Проверьте, что NACL, связанные с вашими подсетями, разрешают входящий и исходящий трафик. NACL являются stateless (не отслеживают состояние), поэтому вам нужны правила для обоих направлений.
- Таблицы маршрутизации: Проверьте таблицы маршрутизации для ваших подсетей, чтобы убедиться в правильной маршрутизации в интернет (через Internet Gateway или NAT Gateway), другие подсети или пиринговые VPC.
- Настройки подсети: Подтвердите, что экземпляры находятся в правильных подсетях и что подсети имеют соответствующие ассоциации таблиц маршрутизации.
Проверьте Internet Gateway (IGW) / NAT Gateway:
- IGW: Убедитесь, что ваши публичные подсети имеют маршрут к IGW для доступа в интернет.
- NAT Gateway: Если вашим экземплярам в частных подсетях нужен доступ в интернет, убедитесь, что NAT Gateway настроен правильно, связан с Elastic IP и имеет маршруты, указывающие на него из таблицы маршрутизации частной подсети.
Проверьте VPC Peering / Transit Gateway: Для связи между VPC подтвердите, что пиринговые соединения VPC или подключения Transit Gateway активны, а таблицы маршрутизации во всех задействованных VPC обновлены и включают маршруты к CIDR-блокам пиринговой VPC или Transit Gateway.
Проверьте разрешение DNS: Убедитесь, что ваша VPC настроена на использование DNS (например, AmazonProvidedDNS по адресу VPC_CIDR_PLUS_2) и что разрешение DNS работает правильно. Используйте dig или nslookup с экземпляра для тестирования.
AWS Network Reachability: Используйте AWS Reachability Analyzer для диагностики проблем с подключением между ресурсами AWS внутри вашей VPC или между VPC.

Пример: Экземпляр EC2 недоступен из интернета

Публичный IP-адрес: Имеет ли экземпляр EC2 назначенный публичный IP-адрес? Находится ли он в публичной подсети?
Группа безопасности: Проверьте группу безопасности, прикрепленную к экземпляру. Убедитесь, что существует входящее правило для порта приложения (например, порт 80 для HTTP, 443 для HTTPS), разрешающее трафик с 0.0.0.0/0 (или определенного диапазона IP).
Сетевой ACL: Проверьте NACL, связанный с подсетью экземпляра. Убедитесь, что он разрешает входящий трафик на порт приложения и исходящий трафик на эфемерные порты (1024-65535) для ответа.
Таблица маршрутизации: Проверьте, что таблица маршрутизации подсети имеет маршрут к Internet Gateway (0.0.0.0/0 -> igw-xxxxxx).
Состояние экземпляра: Запущен ли экземпляр?

Проблемы доступности сервисов

Обеспечение высокой доступности критически важно для приложений, выполняющих важные задачи. Простои могут привести к значительным бизнес-последствиям.

Стратегии обеспечения высокой доступности

Мульти-AZ развертывания: Развертывайте критически важные ресурсы, такие как базы данных (RDS Multi-AZ) и серверы приложений, в нескольких зонах доступности (AZ) в пределах региона. Если одна AZ выходит из строя, трафик может быть автоматически переключен на другую.
Балансировка нагрузки: Используйте Elastic Load Balancing (ELB) - Application Load Balancer (ALB), Network Load Balancer (NLB) или Classic Load Balancer (CLB) - для распределения трафика между несколькими экземплярами в разных AZ. Проверки работоспособности ELB автоматически удаляют неисправные экземпляры из ротации.
Автоматическое масштабирование: Внедрите EC2 Auto Scaling для автоматической замены неисправных экземпляров и масштабирования емкости вверх или вниз в зависимости от спроса и проверок работоспособности.
Приложения без состояния: Проектируйте приложения без состояния, чтобы упростить замену или масштабирование отдельных экземпляров без потери данных или прерывания работы.
Плавная деградация: Проектируйте ваше приложение так, чтобы оно функционировало, возможно, с ограниченными функциями, даже если некоторые зависимости недоступны.

Устранение проблем доступности

Проверки работоспособности:
- Проверки работоспособности ELB: Убедитесь, что конфигурации проверок работоспособности ELB точны и тестируют правильную конечную точку и порт.
- Проверки работоспособности EC2 Auto Scaling: Проверьте, что проверки работоспособности Auto Scaling настроены правильно.
- Конечные точки работоспособности приложения: Внедрите выделенные конечные точки проверки работоспособности в ваших приложениях, которые можно отслеживать.
Анализируйте оповещения CloudWatch: Настройте оповещения CloudWatch для критических метрик (например, высокий уровень ошибок, низкое дисковое пространство, высокая задержка) и оперативно расследуйте любые сработавшие оповещения.
Проверьте AWS Health: Проверьте AWS Health Dashboard на наличие событий сервисов, затрагивающих вашу учетную запись или регион. Для широких публичных событий также проверьте публичную страницу статуса AWS Health.
Тестирование отказоустойчивости: Регулярно проводите тестирование отказоустойчивости (например, завершение работы экземпляра в одной AZ), чтобы убедиться, что ваша стратегия высокой доступности работает должным образом.

Пример: Приложение не отвечает из-за сбоя экземпляра

Проверки работоспособности ELB: При использовании ALB проверьте работоспособность целевой группы. ALB должен автоматически пометить отказавший экземпляр как нездоровый и прекратить отправлять на него трафик.
Автоматическое масштабирование: Если экземпляр был частью группы автоматического масштабирования, группа должна обнаружить нездоровый экземпляр (с помощью проверок работоспособности ELB или EC2) и запустить заменяющий экземпляр.
Метрики CloudWatch: Отслеживайте такие метрики, как HealthyHostCount и UnHealthyHostCount в CloudWatch для вашего ALB. Также проверьте CPUUtilization и NetworkIn/Out для оставшихся исправных экземпляров, чтобы увидеть, справляются ли они с возросшей нагрузкой.
Журналы: Изучите журналы отказавшего экземпляра (если возможно) и нового экземпляра, чтобы понять, почему произошел сбой.

Лучшие практики безопасности для предотвращения проблем

Хотя это и не прямое устранение неисправностей, соблюдение лучших практик безопасности упреждающе предотвращает многие распространенные архитектурные проблемы.

Принцип минимальных привилегий: Предоставляйте только необходимые разрешения пользователям IAM, ролям и сервисам.
Сегментация сети: Используйте VPC, подсети, группы безопасности и NACL для изоляции ресурсов и ограничения радиуса поражения при нарушении безопасности.
Регулярное обновление исправлений: Поддерживайте операционные системы и приложения на ваших экземплярах EC2 в актуальном состоянии с помощью исправлений.
Шифрование: Шифруйте данные в состоянии покоя (например, тома EBS, объекты S3, базы данных RDS) и при передаче (с помощью TLS/SSL).
Журналирование и мониторинг: Включите детальное журналирование (CloudTrail, VPC Flow Logs) и настройте мониторинг и оповещение о подозрительных действиях.

Создайте небольшой Runbook

Для каждой рабочей нагрузки в производственной среде ведите короткий runbook, в котором указан реальный путь запроса: DNS, CDN, балансировщик нагрузки, вычислительный уровень, база данных, кэш, очереди, объектное хранилище и внешние зависимости. Добавьте конкретные метрики CloudWatch, целевые группы, группы безопасности, таблицы маршрутизации и панели мониторинга, которые ваша команда должна проверять в первую очередь. "Проверить AWS" — это не runbook; "проверить работоспособность целевой группы ALB, события сервиса ECS, Performance Insights RDS и недавние изменения CloudTrail за окно инцидента" — это полезно в 2 часа ночи.

Устранение неисправностей AWS становится гораздо спокойнее, когда вы отделяете сетевые сбои от сбоев IAM, сравниваете хорошие и плохие временные окна и сопротивляетесь изменению нескольких слоев одновременно. Следуйте за запросом, найдите первый сломанный переход и исправьте этот слой, прежде чем двигаться дальше.