Лабораторная работа 11: Chaos Engineering для data-систем

Цель работы

Научиться тестировать отказоустойчивость data pipeline с помощью методов Chaos Engineering.

Что такое Chaos Engineering?

Chaos Engineering = Контролируемое создание хаоса в системе

Это как вакцинация для вашего приложения:

• 💉 Вводим небольшой "вирус" (проблему)
• 🏥 Смотрим как "организм" (система) реагирует
• 🛡️ Укрепляем слабые места
• ✅ Система становится устойчивее к реальным проблемам

Мы намеренно ломаем систему в контролируемых условиях, чтобы сделать её надежнее!

Структура проекта

lab11/
├── chaos_framework.py          # Framework для chaos экспериментов
├── resilient_pipeline.py       # Устойчивый data pipeline
├── resilience_monitor.py       # Система мониторинга устойчивости
├── run_chaos_system.py         # Главный файл для запуска системы
├── cloud_client.py             # Клиент для работы с AWS (LocalStack)
├── start_localstack.py         # Утилита для запуска LocalStack
├── docker-compose.yml          # Конфигурация LocalStack
├── requirements.txt            # Зависимости проекта
├── tests/
│   └── test_chaos_engineering.py  # Тесты
└── README.md                   # Этот файл

Установка и запуск

1. Установка зависимостей

2. Запуск LocalStack

Или используйте скрипт:

3. Запуск отдельных компонентов

Chaos Framework

Устойчивый пайплайн

Мониторинг устойчивости

Полная система

4. Запуск тестов

Реализованные Chaos эксперименты

1. Network Latency (Сетевая задержка)

Эмулирует задержки в сети, добавляя искусственные задержки к операциям загрузки данных.

2. Service Failure (Отказ сервиса)

Эмулирует отказ сервисов S3 или SQS, заменяя их методы на методы, которые всегда падают.

3. High CPU Load (Высокая нагрузка на CPU)

Создает искусственную нагрузку на процессор для тестирования производительности системы.

4. Memory Pressure (Давление на память)

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

5. Data Corruption (Коррупция данных)

Эмулирует различные типы коррупции данных:

• Null значения
• Дубликаты
• Неправильный формат
• Обрезанные данные

6. Chaos Monkey

Автоматически запускает случайные эксперименты через заданные интервалы времени.

Устойчивый пайплайн

Реализованные паттерны

1. Retry механизм - автоматические повторные попытки при ошибках с экспоненциальной backoff задержкой
2. Circuit Breaker - блокировка операций после множественных ошибок
3. Dead Letter Queue (DLQ) - очередь для обработки неудачных операций
4. Валидация данных - проверка данных перед обработкой

Компоненты пайплайна

• Raw Data Bucket - хранилище сырых данных
• Processed Data Bucket - хранилище обработанных данных
• Dead Letter Queue - очередь для ошибок

Система мониторинга

Мониторинг собирает следующие метрики:

• Успешность выполнения пайплайна
• Время выполнения операций
• Количество retry попыток
• Ошибки в Dead Letter Queue
• Количество chaos экспериментов

Генерируемые отчеты

1. chaos_report.json - отчет по chaos экспериментам
2. resilience_report.json - отчет об устойчивости системы
3. resilience_metrics.png - визуализация метрик

Результаты тестирования

Тесты

Все тесты находятся в

• ✅
  test_network_latency
  - тест сетевой задержки
• ✅
  test_service_failure
  - тест отказа сервиса
• ✅
  test_data_corruption
  - тест коррупции данных
• ✅
  test_resilient_pipeline
  - тест устойчивости пайплайна
• ✅
  test_retry_mechanism
  - тест механизма повторных попыток
• ✅
  test_circuit_breaker
  - тест Circuit Breaker
• ✅
  test_chaos_monkey
  - тест Chaos Monkey
• ✅
  test_report_generation
  - тест генерации отчетов

Выводы и рекомендации

Что работает хорошо

1. Retry механизм эффективно справляется с временными сбоями
2. Circuit Breaker предотвращает каскадные отказы
3. Dead Letter Queue позволяет отслеживать и обрабатывать ошибки
4. Валидация данных предотвращает обработку некорректных данных

Рекомендации по улучшению

1. Увеличить количество retry попыток для критических операций
2. Добавить мониторинг в реальном времени с использованием инструментов типа Prometheus/Grafana
3. Реализовать автоматическое восстановление после сбоев
4. Добавить rate limiting для защиты от перегрузки
5. Реализовать graceful degradation - упрощенный режим работы при сбоях

Метрики устойчивости

Система считается устойчивой, если:

• ✅ Успешность выполнения ≥ 85% - ВЫСОКАЯ УСТОЙЧИВОСТЬ
• ⚠️ Успешность выполнения ≥ 70% - СРЕДНЯЯ УСТОЙЧИВОСТЬ
• ❌ Успешность выполнения < 70% - НИЗКАЯ УСТОЙЧИВОСТЬ

Безопасность

⚠️ ВАЖНО: Chaos Engineering должен выполняться только в тестовой среде!

✅ Безопасно:

• Локальные эксперименты
• Ограниченные ресурсы
• Короткое время
• Контролируемые сбои

❌ Опасно:

• Продакшен среда
• Длительные эксперименты
• Критические системы
• Без мониторинга

Автор

Лабораторная работа выполнена в рамках курса по Data Engineering.

Лицензия

Учебный проект.