Как работает Gunicorn и для чего он используется?

Gunicorn (Green Unicorn) — это production-сервер для запуска Python веб-приложений. Его ключевая роль — не “писать бизнес-логику”, а надёжно принимать запросы и отдавать их вашему приложению в нескольких процессах (и иногда потоках), обеспечивая параллельность и устойчивость.

Где он находится в архитектуре

Частая схема:

1. Клиент (браузер/мобильное приложение)

2. Reverse proxy (часто Nginx)

• завершает TLS (HTTPS)

• умеет раздавать статику

• может буферизовать запросы

3. Gunicorn

• держит пул worker’ов

• проксирует запросы в приложение

4. Приложение (Django/Flask и др.)

• выполняет бизнес-логику

• ходит в БД/кэш/очередь

Как Gunicorn обслуживает запросы

Основная идея: один процесс Python неэффективен для параллельной обработки большого числа запросов. Поэтому Gunicorn запускает несколько worker-процессов.

1. Master process

• стартует и контролирует worker’ов

• перезапускает worker, если он упал

• может делать “graceful reload” конфигурации

2. Worker processes

• реально выполняют обработку запросов

• каждый worker обрабатывает запросы независимо

• если один worker завис/упал, остальные продолжают работать

Типы worker’ов (важно для понимания ограничений)

1. Sync workers (по умолчанию)

• один worker обрабатывает один запрос за раз

• параллельность достигается количеством процессов

• хорошо подходит для CPU/IO-смешанных задач, если запросы не “висят” очень долго

2. Thread workers (gthread)

• внутри worker есть несколько потоков

• полезно, если много I/O и хочется меньше процессов

3. Async workers (gevent/eventlet)

• рассчитаны на большое количество одновременных соединений

• требуют определённой модели кода и аккуратности с блокирующими вызовами

Почему Gunicorn “лучше dev-сервера”

Встроенные dev-серверы (например, Flask/Django) предназначены для разработки:

• слабее по устойчивости

• не рассчитаны на высокую нагрузку

• часто однопроцессные

Gunicorn даёт:

• управление worker’ами

• перезапуск при падениях

• нормальную модель запуска в production

Пример запуска

Для WSGI-приложения (например, Django):

gunicorn myproject.wsgi:application --workers 4 --bind 0.0.0.0:8000

Для Flask-приложения:

gunicorn app:app --workers 4 --bind 0.0.0.0:8000

Где:

• --workers 4 — количество процессов

• --bind — адрес и порт

Как выбирать число worker’ов

На практике ориентируются на:

• количество CPU

• характер нагрузки (CPU-bound или I/O-bound)

• лимиты памяти

Часто используют эмпирическое правило (как стартовую точку):

• workers = 2 * CPU + 1

Но это не “закон”, потому что:

• если запросы тяжёлые по памяти, много worker’ов приведёт к OOM

• если запросы mostly I/O, можно использовать threads или async

Важные параметры для стабильности

1. Таймауты

• защищают от “вечных” запросов

• пример: --timeout 30

2. Лимиты на запросы

• перезапуск worker после N запросов помогает лечить утечки памяти

• пример: --max-requests 1000 --max-requests-jitter 100

3. Логи

• доступы и ошибки важны для диагностики

• обычно логирование централизуют (stdout/stderr в контейнере)

Вывод

Gunicorn используют для запуска Python веб-приложений в production, потому что он обеспечивает параллельность через worker-процессы, устойчивость через контроль и перезапуск, и удобную интеграцию с reverse proxy. Он особенно полезен, когда нужно обслуживать много запросов и не зависеть от ограничений dev-сервера.