ПОВЫШЕНИЕ ЭФФЕКТИВНОСТИ ОБМЕНА ДАННЫМИ В МИКРОСЕРВИСНЫХ АРХИТЕКТУРАХ НА ПРИМЕРЕ СЕРВИСА ПОИСКА ВОДИТЕЛЕЙ

1. Введение

Каждый день потребление трафика все увеличивается - создаются новые облачные сервисы, появляются новые устройства интернета вещей. Особенно остро эта проблема стоит в сфере транспортной логистики, где тысячи водителей и клиентов обмениваются данными в реальном времени. При этом наращивать пропускную способность сети становится все сложнее и дороже. Поэтому бэкенд индустрия сталкивается с новым вызовом - повышение эффективности обмена данными в условиях текущей сети.

Сегодня существуют два основных подхода передачи данных: REST поверх HTTP/1.1 с JSON и gRPC на основе HTTP/2 использующий protocol buffers. REST это архитектурный стиль, направленный на простое взаимодействие как между микросервисами, так и с внешними клиентами. Но его преимущества порождают недостатки такие как: head-of-line blocking, увеличенный объем передаваемых метаданных и медленный парсинг JSON.

Цель работы - оценить разницу в производительности между gRPC и REST запросом в условиях ограниченной полосы пропускания, а также выработать практические рекомендации по их применению.

2. Методика тестирования

Для создания условий приближенных к реальной нагрузке было создано MVP микросервисная бэкенд система для такси. Она состоит из двух основных сервисов: сервиса геопозиционирования и сервиса поиска водителей.

Сервис геопозиционирования отвечает за получение и обновление геопозиции водителей находящихся на линии.

Сервис поиска водителей является stateless сервисом, преобразующим поступающие запросы от клиента в запросы для сервиса геопозиционирования.

Также был создан отдельный контроллер для запуска бенчмарка. Бенчмарк позволяет измерить задержку выполняемых запросов по 50-му, 95-му и 99-му перцентилям, измерить и сравнить основное тело сообщения и измерить нагрузку на CPU во время парсинга сообщения.

3. Исследовательский эксперимент

Эксперимент проводился на двух отдельных стендах соединенных маршрутизатором. На маршрутизаторе было включено ограничение на отправку/получение пакетов, эмулирующее ограниченную полосу пропускания. Сервис геопозиционирования и управления поездками размещен на стенде AMD Ryzen 3 3100 с 16 гигабайтами оперативной памяти. Сервис поиска водителей и бенчмарк размещен на стенде Intel Core I5-1135-G7 с 16 гигабайтами оперативной памяти.

Сравнение размеров ответа от сервиса

Прежде чем тестировать сервис на реальной задаче, следует провести сравнение размеров ответов от gRPC и REST. Для этого производится симуляция ответа от сервиса поиска водителей в виде одного найденного водителя. В результате gRPC ответ занял 76 байт трафика, а ответ REST подхода занял целых 681 байт, что в почти 9 раз больше gRPC эквивалента. На текущий момент это может показаться несущественным, но при нагрузке в 50 водителей эти цифры превратятся в 3800 и 34050 байт соответственно. Также стоит заметить, что в gRPC заголовки сжимаются в HPACK и передаются только при установлении соединения.

Рисунок 1. График сравнения размера ответа от сервиса

Сравнение времени требуемого на парсинг ответа

Некоторая часть времени обработки запроса тратится на демаршалинг объектов. Демаршалинг это процесс преобразования данных из JSON, protobuf и т.д. в структуру данных привычной для программы. gRPC использует бинарный формат для передачи данных в отличие от REST использующий строки. Это должно повысить производительность и потенциально снизить задержки выполнения запросов. После прохождения тестирования демаршалинг protobuf занял 11 миллисекунд против 35 со стороны JSON, что в 3 раза медленнее. Таким образом, демаршалинг 50 водителей с gRPC займет 550 миллисекунд, а с REST почти 2 секунды.

Рисунок 2. График сравнения времени требуемого на парсинг ответа

Сравнение задержек запроса

Теперь после теоретического сравнения, следует провести тестирование в реальной задаче. Для тестирования была выбрана бизнес задача поиска водителя для клиента, т.к. она позволяет масштабировать нагрузку со стороны клиентов.

При нагрузке имитирующей реальную городскую среду  (50 одновременных подключений) показало, что медианное время отклика (50-й перцентиль) составило 79 миллисекунд в случае gRPC и 123 миллисекунд в случае с REST, что в 1.5 раза быстрее. Аналогичная тенденция наблюдается и с 95 перцентилем.

При имитации нагрузки в час пик (100 пользователей) значение 50-й перцентиля для gRPC составило 156 миллисекунд, а для REST 247 миллисекунд. На данном этапе REST становится менее стабильным, демонстрируя увеличение задержки в 1.6 раза.

При стресс тестировании (1000 пользователей) производительность REST усугубляется еще больше, медианное время достигает 2.5 секунд по сравнению с 941 миллисекундой в случае gRPC. Критичным является рост задержки для 95 перцентиля. Для Rest задержка составила почти 3 секунды, тогда как в gRPC не превышает 1.5 секунды.

Рисунок 3. График сравнения производительности подходов

4. Вывод

В ходе исследования было проведено сравнение производительности архитектурных подходов gRPC и REST в условиях ограниченной полосы пропускания, на основе разработанной MVP-системы сервиса такси.

Результаты исследования подтверждают высокую эффективность gRPC в задачах чувствительных к объему трафика. Также преимущество gRPC многократно возрастает при увеличении интенсивности запросов.

Таким образом, исследование доказывает, что для систем требующих высокую пропускную способность, gRPC позволяет обеспечить стабильную работу инфраструктуры.