DNS routing для gRPC стал узким местом при экстремальном росте соединений. Один выбор политики в Route 53 определил, выдержит ли система нагрузку.
Когда 121 миллион мобильных устройств одновременно открывают persistent gRPC connections, поведение DNS перестаёт быть “фоновым”. В этой архитектуре CloudFront выступал как edge, а за ним стоял пул Network Load Balancer (NLB) с EKS workloads. Проблема проявилась в момент резкого старта: трафик вырос до 110K+ RPS за секунды, и система начала деградировать. Ошибки между CloudFront и origin достигали критического уровня, доходя до массовых HTTP 500 при пике в 14 миллионов соединений.
Корень проблемы оказался не в capacity и не в compute. Route 53 с политикой Weighted routing возвращал только один IP на DNS-запрос. При масштабе CloudFront это означало, что все edge-ноды резолвили один и тот же origin на время TTL. Возникал классический thundering herd: один NLB получал почти весь трафик, пока остальные простаивали. Добавление новых NLB не помогало. Причина простая: распределение происходило не на уровне соединений, а на уровне DNS-ответа, который оставался единичным.
Решение выглядело минималистично, но изменяло поведение системы. Вместо Weighted routing выбрали Multi-Value Answer routing. Этот режим возвращает до 8 IP-адресов на один DNS-ответ и поддерживает health checks на уровне записей. В результате CloudFront edge-ноды начали распределять соединения сразу между несколькими origin. Это убрало точку концентрации на старте соединений. Trade-off здесь очевиден: Multi-Value требует работы с IP-адресами (Elastic IP) и не поддерживает Alias-записи, а значит усложняет конфигурацию. Но выигрыш в распределении нагрузки оказался критичным.
Имплементация не потребовала изменений кода или архитектуры приложений. Это был чистый инфраструктурный сдвиг. Для каждого NLB были назначены статические IP, затем созданы Multi-Value записи с health checks. Важное ограничение: Route 53 не позволяет смешивать политики для одной записи, поэтому старые Weighted записи пришлось удалить. После обновления DNS CloudFront начал получать сразу несколько IP и распределять gRPC-соединения при первом же резолве, а не после истечения TTL.
Ключевой нюанс связан с природой gRPC. В отличие от коротких HTTP-запросов, здесь используются long-lived connections. Ошибка в распределении на старте не “размазывается” со временем, а накапливается. Это усиливает даже небольшую асимметрию в DNS routing. То, что для stateless трафика выглядело как допустимое отклонение, здесь превращалось в перегрузку одного узла.
После переключения на Multi-Value Answer routing система изменила поведение сразу. На следующем пике не было зафиксировано ни одной ошибки соединения на стороне origin. Финальный тест — 121 миллион устройств и стабильные 110K+ RPS — прошёл без server-side ошибок. Метрики latency или распределения нагрузки не раскрываются, но факт устранения ошибок указывает на устранение bottleneck на уровне DNS.
Этот кейс хорошо показывает, что DNS routing — это часть data plane, а не только control plane. При работе с CloudFront и persistent протоколами вроде gRPC или WebSocket, выбор политики Route 53 напрямую влияет на load distribution. Weighted routing даёт предсказуемое распределение на уровне запросов, но не подходит для long-lived connections. Multi-Value Answer — более прагматичный выбор в таких сценариях, так как он распределяет нагрузку уже на этапе первого резолва.
В индустрии подобные ограничения известны, но часто проявляются только под экстремальной нагрузкой. Здесь архитектура была изначально корректной: edge, балансировка, масштабируемые origin. Но поведение DNS стало скрытым узким местом. Исправление не потребовало масштабирования — только изменения точки принятия решения.