Неожиданное узкое место клиента gRPC в сетях с низкой задержкой и способы его устранения

Цифровое искусство NFT Продажи токенов ICO

gRPC, как современный фреймворк для удалённого вызова процедур, заслуженно считается производительным и надёжным инструментом для взаимодействия между микросервисами и распределёнными системами. Основанный на HTTP/2, он обеспечивает мультиплексирование потоков и оптимальную передачу данных, что особенно важно для высоконагруженных приложений. Однако, как часто бывает в мире распределённых систем, реальные сценарии работы раскрывают неожиданные сложности, которые не всегда очевидны на первый взгляд. Одной из таких проблем стал заметный узкий элемент на стороне клиента при работе в сетях с очень низкой задержкой. Именно в этих условиях производительность gRPC клиентов оказывается далека от идеала, и ресурсный потенциал серверов остаётся недозагруженным.

Разберёмся, в чём корень проблемы и как можно эффективно её преодолеть. В основе gRPC лежит концепция каналов, каждый из которых поддерживает несколько параллельных RPC-запросов, работающих поверх HTTP/2 потоков. Обычно считается, что один канал устанавливает одну TCP-сессию с сервером, внутри которой мультиплексируются отдельные RPC. Проблема возникает именно из-за ограничения на количество одновременно активных потоков в рамках одной TCP-сессии, которое по умолчанию равно примерно 100. Когда число одновременных запросов достигает этого порога, дополнительные вызовы начинают накапливаться в очереди клиента, ожидая освобождения потоков.

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

Для глубокого анализа были использованы специально разработанные микробенчмарки в C++ с применением асинхронного API gRPC, имитирующие работу с очень простыми «ping» запросами без полезной нагрузки. Эксперименты проводились на реальных серверах с продвинутыми процессорами Intel Xeon Gold и тщательно настроенной привязкой потоков к NUMA-нодам, что позволяло убрать влияние внешних факторов на производительность. Основным инструментом расследования стали детальные замеры RTT запросов, анализ использования сетевых соединений и профилирование работы gRPC клиента. Со стороны сети и сервера проблем обнаружено не было. Пакеты передавались без потерь, задержки транспортного уровня минимальны, TCP-конфигурация оптимальна и подтверждена отсутствием буферизации, проблем задержек ACK и блокировок.

Сервер возвращал ответы быстро и в достаточном объёме. Тем не менее именно на клиенте наблюдалась пауза порядка 150-200 микросекунд между моментом получения последнего ACK и отправкой нового запроса. Именно этот интервал назвали главным источником увеличения задержки. И что важно — он возникал даже при минимальной нагрузке и простом сценарии обмена небольшими сообщениями. Корень проблемы оказался связан с тем, что при использовании одинаковых параметров при создании каналов, gRPC внутри реализует глобальный пул TCP-соединений, то есть все каналы фактически начинают использовать одно и то же физическое HTTP/2 соединение.

Такой подход приводит к конкуренции между потоками за ограниченный ресурс — число одновременных HTTP/2 стримов в одном соединении. В итоге, несмотря на кажущуюся параллельность, запросы происходят последовательно, что и вызывает негативное влияние на задержки и пропускную способность. Способы обхода этой проблемы связаны с обходом данной «пула TCP-подключений» или его перераспределением. В частности, использование отдельного канала с уникальными аргументами конфигурирования для каждого рабочего потока позволяет заставить gRPC создать отдельное TCP-соединение на каждый канал. Такая настройка избавляет от внутренней очереди на пользовательском уровне и обеспечивает реальную параллельность RPC вызовов без необходимости делить лимит на количество потоков в одном соединении.

Также доступен параметр GRPC_ARG_USE_LOCAL_SUBCHANNEL_POOL, который гарантирует, что в вашем клиенте не будет глобального разделяемого пула для подканалов и создастся изолированный пул на локальный канал. Практическая проверка показала значительный прирост производительности. Пропускная способность выросла почти в шесть раз для обычных RPC-запросов и примерно в 4.5 раза для стриминговых вызовов. При увеличении числа параллельно выполняемых запросов задержка при этом выросла значительно менее выраженно, что говорит об устранении главного узкого места в архитектуре клиента.

Такие результаты позволяют эффективно загружать серверные кластеры, даже имея ограниченное число узлов, и полностью использовать потенциал быстро работающей сети. Интересно, что при тестировании в сетях с высокой задержкой (около 5 миллисекунд) разница между подходом с одним TCP-соединением и многосоединительным решением оказалась менее ощутимой. При более высоких задержках сети накладные расходы на управление каналами и переключение контекста оказываются относительно менее значительными, чем задержка доставки пакета, поэтому оптимизация с распределением по нескольким TCP не критична. Однако для сетей с низким уровнем задержки и высокими требованиями к throughput подобная оптимизация становится ключом к масштабируемости. Данный опыт даёт ценный пример того, как реальные системы демонстрируют ограничения абстракций современного протокола и библиотек.

Выделение узких мест клиента — зачастую задача не менее сложная, чем оптимизация серверного кода или инфраструктуры. Хорошее понимание внутреннего устройства gRPC, HTTP/2 и тонкостей реализации каналов помогает избежать скрытых ловушек и добиться максимальной эффективности. Важно отметить, что рекомендация разделять нагрузку между несколькими каналами и создавать их с индивидуальными параметрами уже закреплена в официальных рекомендациях gRPC. Однако зачастую этот совет воспринимается как опция, а не как необходимая практика, что приводит к необоснованным проблемам в продуктивных кластерах. На примере YDB мы увидели, что лучше рассматривать эти методы как обязательный шаг для оптимизации работы клиентов при низких задержках.

Для инженеров и разработчиков систем, использующих gRPC, ключевыми выводами являются необходимость избегать моноканального подхода в условиях высоких нагрузок и низких задержек, а также уделять внимание параметрам создания каналов, чтобы гарантировать единственность TCP-соединения. При этом полезен мониторинг реального количества открытых TCP-сессий через системные инструменты и анализ поведения алгоритмов мультиплексирования HTTP/2, чтобы вовремя обнаруживать признаки сокрытых ограничений. Перспективы дальнейших улучшений включают изучение более глубоких оптимизаций клиента, таких как асинхронные вызовы с оптимизированным пулом потоков, уменьшение накладных расходов на переключение контекстов, а также возможное использование альтернативных низкоуровневых сетевых стэков. В то же время для сетей с высокой задержкой и менее ресурсоёмкими задачами простое использование одного канала останется приемлемым вариантом. gRPC продолжает развиваться, и примеры подобного рода дают разработчикам представление о тонкостях настройки систем и важности правильного применения архитектурных паттернов.

В итоге, успех масштабируемых распределённых приложений во многом зависит не только от качества серверной части, но и от грамотной реализации клиентского взаимодействия, что зачастую оказывается именно определяющим фактором качества. Учитывая современные вызовы и тенденции, выявление и устранение узких мест на стороне клиента должно стать стандартной частью процессов оптимизации и тестирования.