ТЕХНИЧЕСКОЕ ЗАДАНИЕ: Реализовать cache warming

1. Цель задачи

Научиться проектировать и реализовывать механизм предварительного заполнения кэша (cache warming) после деплоя нового инстанса или перезапуска сервиса. Это позволит избежать холодного старта (cold start) и резкого падения производительности, обеспечивая hit rate не ниже целевого порога в течение первых минут работы. Задача развивает навыки работы с кэширующими хранилищами, CI/CD и мониторингом метрик.

Ключевой результат Скрипт и CI-шаг, которые гарантируют рост hit rate с 0% до как минимум 40% за первые 5 минут после деплоя.

2. Исходные данные

Перед началом необходимо иметь или симулировать:

Если нет реального инструмента — симулируем:

1. Развернуть Redis: docker run -d -p 6379:6379 --name redis-cache redis:7-alpine
2. Написать простое FastAPI-приложение, которое при GET /popular/{id} проверяет кэш (ключ query:{id}) и вычисляет hit/miss.
3. Создать файл popular_queries.json со 100 разными id и частотой запросов (например, имитация распределения Zipf).
4. Написать скрипт generate_traffic.py, который шлёт запросы по заданному распределению, считает попадания.

3. Технологический стек

4. Этапы выполнения

Этап 1: Подготовка окружения и сбор статистики запросов (30 мин)

Действия

1. Развернуть Redis, FastAPI-приложение, Prometheus (опционально).
2. Собрать или сгенерировать историю запросов
   Пример скрипта для генерации popular_queries.json:

   import json, random
   ids = list(range(1, 1001))
   weights = [1/(i**0.7) for i in ids]  # Zipf-like
   top_100 = sorted(random.choices(ids, weights=weights, k=100), key=lambda x: -weights[x])[:100]
   with open('popular_queries.json', 'w') as f:
       json.dump([{'id': idx, 'count': int(1000 * weights[idx])} for idx in top_100], f)
   

3. Реализовать эндпоинт /popular/{id}, который:
   • Проверяет ключ popular:{id} в Redis.
   • Если ключ есть — hit, возвращает данные из кэша (HTTP 200).
   • Если нет — miss, генерирует данные “медленно” (time.sleep(0.1)) и сохраняет в кэш с TTL (например, 60 секунд).
   • Логирует hit/miss в stdout или метрику Prometheus.

Ожидаемый результат этапа

• Redis запущен, приложение отвечает на /popular/{id}.
• Файл popular_queries.json с топ-100 популярными id.

Этап 2: Разработка скрипта cache warming (1 час)

Действия

1. Создать warm.py, который:
   • Читает popular_queries.json.
   • Посылает GET-запросы на /popular/{id} для каждого id (параллельно, с ограничением числа соединений, например, 10 воркеров).
   • Дожидается, пока все запросы завершатся (функция asyncio.gather).
   • Выводит количество успешно прогретых ключей.
2. Реализовать конфигурацию через переменные окружения (URL приложения, путь к файлу, параллелизм, TTL).
3. Добавить обработку ошибок (timeout, connection error) — повтор до 3 раз с задержкой.
4. Написать unit-тесты (mock Redis, проверка, что после warming ключи существуют).

Пример каркаса скрипта:

import asyncio, aiohttp, json, os

async def warm_query(session, url, query_id, retries=3):
    for attempt in range(retries):
        try:
            async with session.get(f'{url}/popular/{query_id}', timeout=aiohttp.ClientTimeout(total=5)) as resp:
                if resp.status == 200:
                    return True
        except Exception:
            await asyncio.sleep(0.5 * attempt)
    return False

async def main():
    with open('popular_queries.json') as f:
        queries = json.load(f)
    url = os.getenv('APP_URL', 'http://localhost:8000')
    async with aiohttp.ClientSession() as session:
        tasks = [warm_query(session, url, q['id']) for q in queries]
        results = await asyncio.gather(*tasks)
        print(f"Warmed {sum(results)}/{len(results)} keys")

if __name__ == '__main__':
    asyncio.run(main())

Ожидаемый результат этапа

• Скрипт warm.py, который успешно заполняет кэш популярными запросами.
• Тесты (например, pytest) подтверждают корректность.

Этап 3: Интеграция с процессом деплоя (1 час)

Действия

1. Встраиваем скрипт в CI/CD pipeline
   Для GitHub Actions:

   - name: Cache Warming
     run: |
       pip install aiohttp
       export APP_URL="http://$(kubectl get svc my-app -o jsonpath='{.status.loadBalancer.ingress[0].ip}')"
       python warm.py
   

2. Гарантируем, что warming не блокирует трафик.
   • Запуск после успешного развёртывания (после smoke-тестов).
   • Добавить таймаут (например, 60 секунд на весь warming).
3. Проверяем мониторинг hit rate
   • Создать дашборд (PromQL):
     rate(hit_count_total[1m]) / (rate(hit_count_total[1m]) + rate(miss_count_total[1m])) * 100
   • Убедиться, что после warming hit rate поднимается выше 40 % в течение 5 минут.

Ожидаемый результат этапа

• Конфигурация CI/CD с шагом cache warming.
• Автоматический запуск warming при каждом деплое.

Этап 4: Тестирование и замеры (1 час)

Действия

1. Симулировать холодный старт
   • Удалить существующие ключи: redis-cli KEYS 'popular:*' | xargs redis-cli DEL.
   • Убедиться, что hit rate = 0.
2. Запустить warming-скрипт
3. Сразу после warming запустить нагрузочный тест (например, wrk -t4 -c20 -d2m http://localhost:8000/popular/{id} с распределением из popular_queries.json).
4. Собрать метрики
   • Через 1, 3, 5 минут зафиксировать hit rate.
   • Записать в таблицу Excel / markdown.
5. Проверить, что через 5 минут hit rate >= 40 %.
   Если нет — увеличить количество прогреваемых запросов или TTL.

Ожидаемый результат этапа

• График роста hit rate, подтверждающий выполнение ключевого результата.
• Возможно, доработки (добавление ретраев, увеличение concurrent запросов).

Этап 5: Документирование и финальная сдача (30 мин)

Действия

1. Написать README.md в репозитории, описывающий:
   • Как запустить warming локально и в CI.
   • Формат файла с популярными запросами.
   • Ожидаемое влияние на hit rate.
2. Закоммитить все артефакты (warm.py, файл с популярными запросами, конфигурацию CI, дашборд Grafana).
3. Создать простой самопроверочный скрипт (например, verify_warming.py), который после деплоя проверяет hit rate через API мониторинга и сообщает об успехе/неудаче.

Ожидаемый результат этапа

• Репозиторий с полным кодом и документацией.
• Возможность воспроизвести warming на новом окружении за 15 минут.

5. Критерии приемки (Definition of Done)

• После деплоя на новом инстансе hit rate достигает ≥40% ровно через 5 минут (замеряется по метрикам).
• Скрипт warming запускается автоматически в CI/CD после шагов деплоя.
• Скрипт не вызывает ошибок 5xx при параллельном выполнении (обработка таймаутов).
• Популярные запросы хранятся в конфигурационном файле, обновляются при смене трафика.
• Написаны модульные тесты для warm.py (mock Redis, mock HTTP).
• Документация описывает, как обновлять список популярных запросов в продуктиве.
• Метрики (hit_count, miss_count) доступны в Prometheus и отображаются в Grafana.

6. Ожидаемый результат

Основной артефакт скрипт warm.py, который загружает топ-100 популярных запросов в Redis перед запуском основного трафика.

Дополнительные артефакты

• Файл popular_queries.json (или CSV) с популярными id и частотами.
• CI-шаг (.github/workflows/warm.yml или эквивалент).
• README.md с инструкцией по настройке мониторинга и запуску.
• Тестовый набор (tests/test_warm.py) с mock-объектами.
• Скрипт проверки hit rate после деплоя (verify_warming.py).

Содержание warm.py:

• асинхронное выполнение запросов (asyncio + aiohttp),
• поддержка переменных окружения (APP_URL, QUERIES_FILE, CONCURRENCY),
• логирование количества ошибок и успешных прогреваний,
• повторные попытки при временных сбоях.

7. Возможные сложности и их решение

8. Бюджет времени (оценка)

Примечание Для первого раза (при незнакомстве с asyncio и Redis) закладывайте до 6 часов. CI-интеграция может потребовать дополнительной отладки.

9. Связанные вопросы из базы знаний

10. Чек-лист самопроверки

• Я развернул Redis, приложение и проверил, что в холодном состоянии hit rate = 0%.
• Мой скрипт warm.py успешно заполняет кэш и не падает с ошибками при повторном запуске.
• После запуска warming через 5 минут я измеряю hit rate и он >=40% (при условии, что нагрузка идёт по тому же распределению).
• Я добавил шаг warming в CI и убедился, что он запускается после деплоя, а не блокирует его.
• Написал README с понятными примерами использования и настройки.