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

Альткойны Мероприятия

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

Во время тестирования и нагрузочного моделирования инженеры YDB заметили, что при уменьшении количества узлов в кластере производительность клиентов продолжала ухудшаться, что выглядело парадоксально: меньше узлов должно означать меньше нагрузки и, как следствие, меньшую задержку. Вместо этого, увеличивалось количество простаивающих ресурсов, а нервный показатель – латентность на стороне клиента – росла, несмотря на сокращение числа серверных элементов и свободные мощности на участке. Первым шагом к пониманию этой аномалии стала попытка собрать профиль использования TCP-соединений. Инспекция через системные средства показала, что независимо от количества параллельных запросов фактически использовалось единственное TCP-соединение между клиентом и сервером. Это оказалось неприятным сюрпризом, так как gRPC построен на основе протокола HTTP/2, позволяющего мультиплексировать десятки параллельных RPC (remote procedure calls) поверх одного соединения.

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

До недавнего времени официальные рекомендации gRPC советовали бороться с этим ограничением двумя путями. Первый предполагает создание отдельного канала для каждой зоны повышенной нагрузки, чтобы лимит по количеству параллельных стримов распределялся между каналами и не был насыщен. Второй – использование пулов gRPC-каналов с уникальными аргументами конфигурации, предотвращающими их агрегацию в одно TCP-соединение. Стандартные каналы с одинаковыми аргументами tend to aggressively reuse соединения, создавая узкие места при высокой конкуренции. Чтобы более детально изучить поведение клиента gRPC при различных конфигурациях, команда разработчиков YDB создала минимальный микро-бенчмарк, реализованный на C++ с использованием последней версии gRPC v1.

72.0. Эта конструкция имитирует простую функцию «ping», позволяя исследовать как задержки, так и общую пропускную способность в различных сценариях нагрузки. Тесты проводились на двух мощных серверах с двухпроцессорными конфигурациями Intel Xeon Gold 6338, оснащёнными современными технологиями, в том числе hyper-threading, а также с низколатентным сетевым оборудованием, способным выдавать скорость передачи до 50 Гбит/с. Результаты экспериментов в сценарии с одним каналом и обычными RPC продемонстрировали неидеальную масштабируемость.

При увеличении количества одновременных запросов внутренняя производительность клиента росла далеко не линейно. При этом задержка начала увеличиваться с каждым новым добавленным клиентом. Анализ tcpdump-сессий выявил, что на клиенте после получения ответа наблюдались кратковременные периоды тишины от 150 до 200 микросекунд, обусловленные задержками внутри самого gRPC-клиента, а не на уровне сети или сервера. Таким образом, именно клиентская реализация gRPC становилась узким горлышком. Перекличка различных вариантов – использование отдельных каналов для каждого рабочего процесса, каналов с одинаковыми аргументами и пулов каналов с разными аргументами – показала убедительный результат.

Единственные варианты, которые превосходили по производительности, включали создание каналов, отличающихся аргументами, либо использование альтернативной внутренней конфигурации клиента: флага GRPC_ARG_USE_LOCAL_SUBCHANNEL_POOL. Эти методы позволили разделить нагрузку по нескольким реальным TCP-соединениям, снизив очередь ожидающих потоков и уменьшив латентность. Дальнейшие тесты с мультиканальной конфигурацией продемонстрировали значительный прирост throughput – в 6 раз для обычных RPC и около 4.5 для стриминговых соединений. Латентность также росла гораздо медленнее при увеличении нагрузки в системе, что свидетельствовало об успешном устранении клиентского узкого места.

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

Ключ к повышению производительности заключается в использовании нескольких каналов с разными настройками или включении специальных опций, обеспечивающих распределение запросов по нескольким независимым TCP-соединениям. Эта особенность должна учитываться разработчиками и архитекторами систем, использующих gRPC, особенно при работе с распределёнными базами данных и микросервисами, где даже миллисекунды задержки могут существенно влиять на пользовательский опыт и время реакции системных компонентов. Инструменты анализа, профилирования и грамотное конфигурирование помогают выявить и успешно устранить узкие места, повышая стабильность, отказоустойчивость и производительность крупномасштабных распределённых решений. Несмотря на достигнутые успехи, авторы работы отмечают, что не исключены и иные скрытые оптимизации, связанных, например, с внутренними структурами данных gRPC, асинхронностью или планировщиками потоков. Сообщество заинтересованных специалистов приглашено продолжить исследования, обменяться опытом и внести вклад в улучшение инструментов и документации.

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