Привет, Хабр! В двух предыдущих статьях здесь и тут мы рассказывали историю создания одного из компонентов платформы экспериментов в компании Okko — сервиса сплитования трафика. В тех статьях говорилось о множестве изменений и улучшений, которые претерпел Python-код, чтобы работать достаточно быстро. Но как бы качественно не был написан код, все усилия могут сойти на нет, если он будет запущен в неправильной среде. В этой статье продолжим рассказ об оптимизациях и улучшениях, но сейчас речь будет идти не столько об особенностях предметной области и решаемой бизнес-задачи, сколько о том, как мы архитектурно организовали работу сервиса для получения минимального времени ответа.
Напомним, что сервис сплитования трафика решает только одну задачу. А именно, отвечает на вопрос: "В каких A/B-экспериментах и в каких группах участвует пользователь?” Так же вспомним, что у сервиса серьёзные технические требования:
необходимо держать нагрузку в 5k rps;
время ответа должно быть меньше 10 мс;
uptime — 99.99%.
Однако в предыдущих статьях не говорилось о том, как именно устроен веб-сервер, обрабатывающий входящий трафик. А реализован он был в первой своей итерации довольно привычным для индустрии способом:
Flask как веб-фреймворк;
Gunicorn в качестве WSGI-сервера.
Все данные о пользователе сервис получал в запросе, а данные об экспериментах и других необходимых сущностях хранились и обновлялись в оперативной памяти. После вычисления ответа и перед его отправкой клиенту записывался результат в Kafka с помощью библиотеки kafka-python.
Ниже упрощённый пример того, как мы запускаем веб-сервер на Gunicorn.
Скрытый текст
def run_gunicorn(
num_workers: int,
app_port: int,
timeout: int,
) -> None:
app = create_app(Config)
init_db(app)
gunicorn_options = {
'bind': f'0.0.0.0:{app_port}',
'workers': num_workers,
'timeout': timeout,
}
server = GunicornServer(
app,
gunicorn_options,
worker_class=None,
)
server.run()Из интересного здесь то, что у нас есть небольшая надстройка над gunicorn.app.base.BaseApplication — GunicornServer, позволяющая нам решать некоторые задачи, суть которых для этой статьи не столько важна.
В предыдущих статьях было описано, как мы смогли достичь высокой скорости выполнения бизнес-логики. Время ответа сервиса замерялось при помощи middleware во Flask-приложении, и это время не включало в себя работу Flask и Gunicorn. Оценить реальное время ответа нашей команде помогли коллеги из отдела QA, проведя нагрузочные тесты. По их итогам выяснилось, что мы отвечаем за неприлично большое время – более чем за 15 миллисекунд в 99.9 процентиле. Мы поняли, что это неприемлемо и начали искать возможные пути уменьшения времени ответа.
Отметим, что исследования, о которых идёт речь в этой статье, во время реальной разработки приложения проводились параллельно с исследованиями, описанными в прошлых двух статьях. Но все схемы и графики представленные ниже специально были сделаны при лучшей из возможных конфигураций, чтобы исключить влияние остальных изменений на метрики.
Keep-alive
При проведении нагрузочного тестирования было замечено, что сервис постоянно закрывает соединения с балансировщиком. У нас используется HTTP версии 1.1. И объемы передаваемых данных были небольшие, около 0.5-1.0 Кб. Один небольшой запрос. Казалось бы, в чем проблема?
Если опуститься на уровень TCP, то окажется, что:
создается TCP-соединение;
передаются данные;
соединение закрывается.
С примерно такими задачами происходит обмен TCP-пакетами для обработки одного пользовательского запроса. Некоторые из пакетов — это полезная нагрузка. А другие пакеты, отвечающие за открытие и закрытие соединения, являются служебными. Именно от таких пакетов хотелось бы избавиться из-за их регулярного дублирования. Как здорово, что управление TCP-соединением можно кастомизировать через HTTP при помощи заголовка keep-alive. И было несколько удивительно видеть, что сервер Gunicorn, использующий SyncWorker, всегда закрывает соединения, и это невозможно контролировать. Вырезка из официальной документации:
Sync worker does not support persistent connections - each connection is closed after response has been sent (even if you manually add Keep-Alive or Connection: keep-alive header in your application).
Быстро решить эту проблему не удалось, и мы взяли её на заметочку. Однако получилось оценить ее влияние на сервис. По логам с балансировщика HAProxy удалось установить, что на инициализацию соединения уходило до 1 миллисекунды. Для нашего сервиса подобные издержки крайне нежелательны. Поэтому мы стали искать разные способы того, как можно получить возможность использовать keep-alive.
Начали с поиска альтернативы SyncWorker. В комплекте к Gunicorn идут thread-worker’ы и несколько асинхронных. Не хотелось бы их использовать только ради потенциальной возможности постоянных соединений, так как основная нагрузка в сервисе приходится не на сеть, а на процессор.
Далее мы искали варианты для worker’ов, которые не поставляются вместе с Gunicorn, но могут работать с ним. И познакомились с Meinheld, который очень похож по своему поведению на SyncWorker - вызывает синхронный код, годится для CPU-bound задач, каждый worker в своем процессе. Всего за полчаса нам удалось внедрить новый класс worker’а, и мы оказались готовы тестировать MeinheldWorker в нашем приложении. Запуск оказался практически идентичным первоначальному, за исключением буквально одной строчки:
worker_class='meinheld.gmeinheld.MeinheldWorker’На удивление, он дал хорошее улучшение во времени ответа. Но с чего такой прирост, если он во всем похож на SyncWorker? Ответ простой — он написан на C, в качестве бонуса есть возможность использования keep-alive.
На графике видно, что мы стали отвечать быстрее и MeinheldWorker хорошо себя проявил. Однако было проведено ещё одно нагрузочное тестирование и оно показало, что из-за сетевых задержек от клиента до нас, мы всё же не укладываемся в тайминг в 10 мс. Поэтому решили копать дальше и искать замену уже не SyncWorker, а самому Gunicorn.
Flask-server
Сперва было решено попробовать Flask-server, так как он идёт в комплекте с веб-фреймворком в качестве сервера для разработки и его внедрение не требовало серьёзных трудозатрат.
Запуск выглядел примерно так:
# flask не дает запустить flask-server как-либо из приложения, только из файла '__main__'
# так что снимаем flask с предохранителя
os.environ.pop('FLASK_RUN_FROM_CLI')
app.run(host='0.0.0.0', port=app_port, processes=num_workers, load_dotenv=False)И да, мы в курсе, что использовать его “в бою” не рекомендуется из соображений безопасности и производительности.
На удивление, Flask-server работает быстрее, чем мы ожидали, но всё ещё медленнее конкурентов. Вердикт ясен, Flask-server нам не подходит, поэтому использовать его в production мы не стали. Что ж, не очень-то и хотелось, если честно.
uWSGI
Далее мы решили попробовать uWSGI, так как он очень популярен и обладает большим множеством различных настроек. Для теста этого веб-сервера мы использовали самые обычные настройки, примерно такие:
uwsgi --http 0.0.0.0:8000 --master -p 2 -w api:app
uWSGI показал хорошее время, но не лучшее. Вдобавок к этому нам не особо подошла парадигма этого веб-сервера. Он сам создаёт все процессы и нам оказалось сложно интегрировать свои кастомные решения, о которых, возможно, мы ещё расскажем в будущем. Долго исследовать особенности uWSGI мы не стали, так как уже понимали, что вероятнее всего следующая библиотека нам будет более интересна.
Bjoern
Еще один WSGI-сервер, который был протестирован командой — Bjoern.
В сообществе он имеет репутацию самого быстрого веб-сервера для Python-приложений. Сам же разработчик заявляет:
Bjoern is the fastest, smallest and most lightweight WSGI server out there.
Single-threaded and without coroutines.
Full persistent connection ("keep-alive") support in both HTTP/1.0 and 1.1
Выглядит как то, что нам нужно. Как и Meinheld, Bjoern написан на C, поэтому ожидания от него были серьёзными.
Запуск выглядит следующим образом
Скрытый текст
def run_bjoern(
app: Flask,
num_workers: int,
app_port: int,
) -> None:
worker_pids = []
logger.info('running api with bjoern %s workers on port %s', num_workers, app_port)
bjoern.listen(app, '0.0.0.0', app_port, reuse_port=True)
for _ in range(num_workers):
pid = os.fork()
if pid > 0:
worker_pids.append(pid)
elif pid == 0:
try:
bjoern.run()
except KeyboardInterrupt:
pass
sys.exit()
try:
for _ in range(num_workers):
os.wait()
except KeyboardInterrupt:
for pid in worker_pids:
os.kill(pid, signal.SIGINT)
В итоге мы поняли — да, именно этот инструмент мы и искали. К сожалению, возможности конфигурации у этого веб-сервера минимальны, если не сказать, что отсутствуют. Потому пришлось написать свою обёртку для удобной конфигурации количества worker’ов, фоновых процессов, их рестартов, потоков и других привычных возможностей WSGI-сервера.
Внешние факторы
После внедрения Bjoern, время ответа было весьма неплохим. Около 5 миллисекунд при требовании в 10 миллисекунд. Но стоит учитывать, что это время, полученное из middleware. Между клиентом и нашим приложением есть некоторое физическое расстояние и несколько балансировщиков. На то, чтобы преодолеть эти преграды уходило около 4 миллисекунд. Итого, клиент получал результат наших вычислений примерно за 9 мс. Запас прочности сомнительный, да ещё и очень нестабильный, так как время ответа иногда всё же превышало 10 мс из-за большой дисперсии, которая могла составить более 10% от времени вычислений. И было принято решение попробовать ещё ускориться. Но как именно? Ведь мы уже вооружились самым быстрым веб-сервером из возможных. Изобретать свой велосипед, очевидно, не хочется. Слишком трудозатратно. Благо, у нас ещё было несколько идей, поэтому, спойлер, мы нашли выход.
Было решено взглянуть на процессно-потоковую архитектуру немного под другим углом.
GIL
Напомним, что у нас в Okko имеется некоторая экспертиза в работе с Python, мы знаем про GIL, его плюсы и недостатки. И, кажется, сейчас тот самый случай, когда GIL — это не благо, а проклятье. GIL присутствует во всех процессах, но если в главном процессе он не влияет на время ответа сервиса, так как он не обрабатывает входящие запросы, то в worker’ах это не так. А всё потому что в worker’ах, помимо основного потока имеется ещё один. Этот поток предназначен для отправки данных в Kafka, появляется из библиотеки kafka-python. Его задача - аккумулировать данные в себе, а затем партиями отправлять их. Задумка интересная, ведь отправка в Kafka состоит преимущественно из IO-операций.
Всё это звучит здорово, но есть нюанс… Когда основной поток обрабатывает запросы, поток с Kafka ждёт. При таком сценарии время ответа сервиса не страдает. Однако возможен кейс, что в то время, пока поток с Kafka занят отправкой данных, может прийти запрос. Тогда уже главный поток вынужден ждать своей очереди, что влияет на время ответа.
В Python есть параметр switch interval, с помощью которого можно управлять частотой переключения потоков. По умолчанию, он равен 5 миллисекундам. То есть, если во время обработки запроса происходит смена потоков, то это +5 мс ко времени ответа — значит клиент 100% не дождется ответа. Было предположение, что, если поставить интервал в 1 мс, это не решит хаотичные переключения потоков, но уменьшит разброс метрики времени ответа. Увы, это только предположение, в реальности получилось так, что каждую миллисекунду происходило переключение, и половину времени работал главный поток, а остальное время работал поток с Kafka. Увеличение интервала тоже не решало проблему. Отсюда следовало, что надо избавиться от влияния GIL вообще. Не слать данные в Kafka нельзя. Обмениваться данными по сети во время обработки входящего запроса — слишком долго. Делать это сразу после обработки — рискованно, так как есть шанс не успеть до прихода следующего запроса.
Получается выход только один — убрать сетевые операции из процесса, обрабатывающего запросы, и совершать их в соседних процессах.
Мы поступили следующим образом. Данные, предназначенные для Kafka, мы стали записывать в multiprocessing.Queue, использующую под капотом Pipe, сразу после того, как рассчитали их. С другой стороны мы создали процесс, который периодически опрашивает эту очередь, вычитывает появившиеся данные и отправляет в Kafka.
Это решение дало существенный результат. Мы довольно сильно уменьшили время ответа, и, что немаловажно, уменьшили дисперсию ответов с более чем 10% до примерно 3%. Таким образом, до клиента наш ответ стал доходить за 7.5 мс с весьма маленьким разбросом.
Nice
И теперь, когда все важные для бизнеса действия разложены по самостоятельным процессам, для более качественной утилизации ресурсов, решили ещё и поменять приоритеты процессов для планировщика операционной системы, воспользовавшись функцией nice из модуля os. Worker’ам оставили максимальный приоритет, процессу с отправкой результатов в Kafka — средний, а приоритет главного процесса был опущен до минимума. Выставляя такие настройки, мы рассчитывали на серьёзное увеличение процессорного времени для процессов, принимающих запросы, и, как следствие, существенное снижение времени ответа. Но этого, к сожалению, не случилось. Лишь немного уменьшилась дисперсия. Примерно до 1%.
GC
Как и положено после того, как нивелировали негативные стороны GIL, надо взглянуть на garbage collector. Мы попробовали поиграться с параметрами threshold, но спойлерить не будем, так как максимально подробно об этом расскажем в следующей статье.
Подведение итогов
Какой вывод, из всего описанного выше, мы можем сделать? В этой статье не шло речи о сути сплитования трафика. Мы не говорили о слоях, сегментах пользователей, обладающих общим набором характеристик, различных эвристиках решаемой задачи. Вместо этого мы упомянули особенности Python, некоторые библиотеки, возможности HTTP и операционной системы. Порой оказывается, для того, чтобы добиться существенных улучшений производительности не всегда обязательно досконально разбираться в предметной области. Иногда для достижения впечатляющих результатов можно воспользоваться только знаниями об используемых инструментах и на их основе провести несколько экспериментов.
