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

Цифровое искусство NFT Новости криптобиржи

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

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

Такая архитектура отлично работает в большинстве сценариев, однако при высоком уровне нагрузки и особо коротких задержках выявляет определённые узкие места. Именно данная специфика стала причиной возникновения интересного эффекта в лабораторных испытаниях YDB. Разработчики заметили, что при уменьшении размера кластера баз данных и, соответственно, сокращении количества серверных узлов, общая нагрузка с клиента на сервер не повышается пропорционально ожиданиям. Более того, при сужении кластера их показатели клиентской задержки начали расти, а ресурсы на серверной части при этом оставались неиспользованными. Это противоречило традиционным представлениям о масштабировании и эффективности работы распределённых систем.

Детальный анализ производительности клиента gRPC Чтобы изучить данную проблему, команда YDB разработала микро-бенчмарк, симулирующий простые gRPC вызовы типа пинга без нагрузки на полезные данные. Бенчмарк состоял из клиента и сервера, запущенных на отдельных мощных серверных машинах со схожими характеристиками: процессоры Intel Xeon Gold с множеством ядер и быстродействующая сеть с пропускной способностью 50 Гбит/с и ничтожно малой задержкой порядка сотен микросекунд. Модель теста была замкнутым циклом с заданным числом параллельно выполняемых вызовов RPC. При этом каждый клиент использовал отдельный канал в обычной конфигурации. В ходе тестирования исследовалась зависимость пропускной способности от количества одновременных запросов, а также величина задержек (процентильные показатели P50, P90, P99 и так далее).

Результаты испытаний показали удивительное несоответствие теории и практики. Даже при малом числе параллельных запросов общая пропускная способность не масштабировалась линейно с ростом количества in-flight запросов, а задержка с увеличением нагрузки возрастала пропорционально и значительно превышала задержку сети, которая была практически минимальной. Анализы сетевого трафика с использованием tcpdump и Wireshark не выявили каких-либо проблем с TCP — не было ни потерянных пакетов, ни задержек из-за политики Nagle, ни проблем с окном TCP. Сервер отвечал молниеносно. Основной источник задержек оказался именно на стороне клиента.

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

Но на практике оказалось, что эти методы не всегда работают как альтернативы, а скорее являются последовательными шагами одного комплексного решения. Команда YDB нашла, что если каждому рабочему потоку клиента предоставить собственный gRPC канал с уникальными аргументами конфигурации, позволяющими gRPC создать отдельное TCP-соединение, производительность резко растёт. При этом задержки существенно снижаются, и общая пропускная способность возрастает почти в 6 раз для обычных RPC и в 4.5 раза для стриминговых вызовов. При этом рост задержки с увеличением числа in-flight запросов становится гораздо менее выраженным.

Дополнительно была выявлена альтернатива — использование специального параметра GRPC_ARG_USE_LOCAL_SUBCHANNEL_POOL, который управляет пулом подканалов и позволяет добиться похожей разгрузки соединений без необходимости создавать явно уникальные каналы вручную. Такая настройка грамотно распределяет нагрузку между отдельными TCP-соединениями и уменьшает внутренние блокировки и очереди в gRPC. Почему проблема особенно заметна в сетях с низкой задержкой Любопытно, что тестирование в сетях с существенной задержкой порядка 5 миллисекунд показало практически отсутствующую разницу между классическим единым каналом и многоканальной организацией клиентов. В таких условиях задержка сети доминирует и скрывает внутренние задержки реализации клиента gRPC. Ускорение работы благодаря мультиконнекту проявляется только при высоком числе одновременных запросов, и то в незначительной степени.

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

Следует учитывать, что установка уникальных параметров каналов необходима для гарантированного создания разных TCP-соединений. Без этого gRPC может объединять разные каналы в один сокет, что не снимает текущие ограничения. Также рекомендуется изучить особенности и возможности параметра GRPC_ARG_USE_LOCAL_SUBCHANNEL_POOL и в ряде случаев применять его, чтобы оптимизировать распределение нагрузки и использовать преимущества внутренних пулов соединений. Для эффективного тестирования и оценки производительности рекомендуется использовать закрытые циклы вызовов с разным уровнем одновременно выполняемых запросов, анализируя не только среднюю, но и процентильную задержку. При этом важна настройка прецизионного связывания потоков процессора (через taskset или аналогичные инструменты) для избежания дополнительных помех и искажений в измерениях.

Заключение Перспективы микросервисных архитектур и распределённых систем связаны с постоянным повышением требований к производительности и снижению задержек. gRPC, как современный протокол общения, способен удовлетворить эти запросы, но только при правильной конфигурации клиентской части. Опыт команды YDB показывает, что в средах с низкой сетевой задержкой редко замечаемые ранее внутренние механизмы multiplexing и ограничения на количество потоков в gRPC становятся узким местом. Выявление и последующее грамотное устранение этих ограничений обеспечивают существенный рост производительности и уменьшение задержек, что критично для современных высоконагруженных систем. Разработчикам, работающим с распределёнными базами данных, сервисами и масштабируемыми платформами, стоит уделить отдельное внимание внутренней организации gRPC клиентов.

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