005. Как аналитику сделать API для прода и не облажаться — Александр Кучин

Создание API для продакшена: Руководство для аналитиков

В данном выступлении Александр Кучин, руководитель аналитики в Skyeng, делится опытом создания API для продакшена аналитиками, акцентируя внимание на практических аспектах и избежании распространенных ошибок.

1. Введение и контекст

• Проблема: В Skyeng существовала проблема с разрозненностью данных и экспериментов между множеством команд, что приводило к пересечению выборок и неэффективной коммуникации.
• Решение: Была разработана платформа для экспериментов, которая унифицировала процессы и данные.
• Фокус доклада: Сегодняшняя тема — создание API, являющегося ключевым компонентом этой платформы, для интеграции с продакшен-сервисами. API позволяет передавать информацию о статусе пользователя (свободен/занят в эксперименте) в продакшен-системы, предотвращая пересечение пользователей в экспериментах.

2. Зачем аналитикам создавать API?

• Необходимость: Аналитикам часто требуется интегрировать свои модели (например, рекомендательные системы) или сложные отчеты с продакшен-сервисами для предоставления результатов в реальном времени.
• Примеры:
  • Интеграция модели рекомендаций с продакшеном для выдачи результатов в реальном времени.
  • Предоставление сложных аналитических отчетов в продакшен в реальном времени.
  • Интеграция с внутренней платформой экспериментов для обеспечения взаимодействия с продакшен-сервисами.
• Общая черта: Все эти сценарии требуют обработки запросов в реальном времени, которые могут поступать как по одному, так и в тысячах экземпляров.

3. Создание простого API с помощью R

• Инструмент: Пакет plumber в R Studio позволяет легко создавать API.
• Процесс:
  1. Создание нового R-проекта.
  2. Написание кода с использованием специальных комментариев-аннотаций (#*) перед функциями, которые будут являться эндпоинтами API.
  3. Определение параметров эндпоинта (например, user_id).
  4. Запуск тестового API.
• Пример (упрощенный):
  • Задача: Случайным образом разыгрывать приз среди миллиона пользователей ежедневно.
  • Эндпоинт /user: Принимает user_id, загружает всех пользователей, находит нужного и определяет, является ли он победителем.
  • Примечание: Автор признает, что данный пример неоптимален, так как можно было бы просто хранить победителя, а не перебирать всех пользователей. В реальной задаче Skyeng решалась проблема определения статуса пользователя (свободен/занят в эксперименте).

4. Развертывание API в Docker

• Проблема: API, запущенное в RStudio, доступно только пока RStudio запущено. Для продакшена требуется более надежное решение.
• Решение: Контейнеризация с помощью Docker.
  • Docker: Позволяет упаковать все окружение (операционную систему, зависимости) в контейнер, который может быть запущен независимо от рабочей машины.
• Шаги по созданию Docker-образа:
  1. Создание скрипта для запуска API: Простой R-скрипт, который запускает API на определенном порту (например, 8700) с помощью plumber.
  2. Создание Dockerfile:
     • Использование готового образа R (например, rocker/r-ver).
     • Установка необходимых R-пакетов (например, plumber, dplyr).
     • Копирование файлов проекта (скрипт API, данные) в контейнер.
     • Открытие порта для доступа к API.
     • Определение точки входа (команда для запуска скрипта API при старте контейнера).
  3. Сборка Docker-образа: Команда docker build.
  4. Запуск Docker-контейнера: Команда docker run.
     • Привязка томов (volumes): Позволяет монтировать файлы с хост-машины в контейнер (например, файл с данными пользователей), обеспечивая взаимодействие между контейнером и внешней средой.
     • Проброс портов: Сопоставление порта внутри контейнера с портом на хост-машине.
• Проверка: После запуска контейнера API доступно по указанному порту.

5. Оптимизация производительности API

• Проблема: Первоначальная версия API может работать медленно (например, более 1 секунды на запрос), что неприемлемо для продакшена.
• Этапы оптимизации:
  1. Оптимизация чтения данных:
     • Вместо чтения всего большого DataFrame, читать только необходимые данные (например, данные конкретного пользователя).
     • Использование функции saveRDS() с параметром compress = FALSE для ускорения сохранения и чтения данных (хотя это увеличивает размер файла).
  2. Оптимизация поиска:
     • Использование базового синтаксиса R для поиска может быть медленным.
     • Применение пакета data.table для более эффективного поиска по ключу.
     • Использование хэш-таблиц (реализованных через new.env() в R) для поиска по user_id с O(1) сложностью.
• Результат: Достижение времени ответа в пределах 200 миллисекунд.

6. Обработка нагрузки и масштабирование

• Проблема: Даже если один запрос выполняется быстро, большое количество одновременных запросов может привести к перегрузке.
• Инструмент: Пакет locust для нагрузочного тестирования.
  • Позволяет симулировать нагрузку и генерировать отчеты о производительности.
• Масштабирование:
  • Балансировщик нагрузки (например, Nginx): При высокой нагрузке автоматически запускает дополнительные экземпляры контейнера с API. При снижении нагрузки — удаляет лишние экземпляры.

7. Безопасность и логирование

• Авторизация:
  • Реализация через фильтры plumber (например, проверка наличия токена в списке разрешенных). Фильтр может как пропускать запрос дальше, так и возвращать ошибку.
• Логирование:
  • Реализация через фильтры plumber, которые записывают информацию о запросах в лог-файлы, не останавливая выполнение запроса. Это позволяет собирать статистику и анализировать обращения.

8. Заключение и выводы

• Легкость создания: Создать базовое API для продакшена с помощью R и plumber относительно легко.
• Сложность эффективности: Написать по-настоящему эффективный код, который будет быстрым, выдерживать нагрузку и иметь базовую безопасность, гораздо сложнее, особенно для аналитиков.
• Ключевые аспекты: Скорость ответа, устойчивость к нагрузке, безопасность и логирование.
• Рекомендация: Если есть возможность, лучше делегировать разработку API профессиональным разработчикам. Однако, для аналитиков, которым нужно быстрое решение, создание API своими силами с использованием готовых инструментов является жизнеспособным вариантом.

Вопросы и ответы

• Причина медленного API: Неоптимизированные DataFrame и медленный поиск.
• Websocket API: Автор не смог дать рекомендацию по пакетам для Websocket API, так как это выходит за рамки его опыта.
• Преимущества перед ClickSense/Power BI: API предназначено для внутренней интеграции с продакшен-системами, а не для создания отчетов, как BI-инструменты.
• Тестирование и вывод в продакшен: Процесс тестирования был длительным, включал взаимодействие с разработчиками, использование платформы для тестирования и автоматизированные тесты. API работает стабильно уже несколько месяцев.
• Время разработки аналитиком vs. разработчиком: Создание базового API аналитиком занимает меньше времени, чем оформление ТЗ для разработчика. Однако, создание эффективного API требует значительных усилий.
• Риски безопасности и нагрузки: Автор признает эти риски и подчеркивает важность их учета.

Key Concepts

• API (Application Programming Interface): Интерфейс, позволяющий различным программам взаимодействовать друг с другом.
• Plumber: R-пакет для создания API.
• Docker: Платформа для контейнеризации приложений.
• Dockerfile: Файл с инструкциями для сборки Docker-образа.
• Docker-образ: Шаблон для создания Docker-контейнера.
• Docker-контейнер: Изолированная среда для запуска приложения.
• Volumes (в Docker): Механизм для монтирования файлов и директорий между хост-системой и контейнером.
• Data.table: R-пакет для быстрой обработки данных.
• Hash Table (Хэш-таблица): Структура данных, обеспечивающая быстрый поиск по ключу.
• Load Testing (Нагрузочное тестирование): Процесс проверки производительности системы под высокой нагрузкой.
• Locust: Инструмент для нагрузочного тестирования.
• Load Balancer (Балансировщик нагрузки): Устройство или программа, распределяющая сетевой трафик между несколькими серверами.
• Authorization (Авторизация): Процесс проверки прав доступа пользователя к ресурсу.
• Logging (Логирование): Запись информации о событиях в системе.