Почему низкая задержка критически важна в облачных B2B-сервисах
Когда речь заходит об облачных сервисах для бизнеса, вопрос задержки (latency) выходит на первый план. Пропускная способность (ширина канала) важна, но именно время отклика нередко определяет удобство и возможность работы в облаке в реальном времени. Представьте: инженер пользуется виртуальным рабочим столом (VDI) в облаке для 3D-моделирования, или команда одновременно редактирует видеофайл, или сотрудники компании работают с корпоративным приложением, развернутым в удаленном ЦОД. Во всех этих случаях даже доли секунды имеют значение для комфортной работы.
Опыт показывает, что человек очень чувствителен к задержкам интерфейса. Например, при работе через VDI пользователь неосознанно начинает печатать медленнее, если время отклика приближается к ~100 мс. А при задержке более 150 мс уже явно ощущается лаг клавиатуры и мыши. Высокая latency влечет за собой подтормаживания в приложениях реального времени, сбои в видеоконференциях, задержки в системах IP-телефонии. Для бизнеса это означает падение производительности и недовольство сотрудников или клиентов. Именно поэтому низкая задержка — не роскошь, а необходимость для таких сервисов, как виртуальные рабочие места, системы видеонабора и стриминга, решения для финансовых торгов, удаленное управление производственным оборудованием, и многих других критичных приложений.
Архитектура дата-центров: что влияет на latency
Как же обеспечить минимальное время отклика? Начнем с дата-центров (ЦОД) — основы любой облачной инфраструктуры. Современные российские ЦОД проектируются таким образом, чтобы внутренняя архитектура не добавляла лишних миллисекунд задержки. На что мы обращаем внимание:
- Расположение и связность оборудования. Внутри ЦОД физическое расстояние между серверами и сетевыми коммутаторами минимизируется: оборудование располагается компактно, в пределах нескольких рядов стоек, а магистральные линии связи проложены кратчайшим путем. Это кажется очевидным, но играет роль: лишние десятки метров кабеля добавляют микросекунды, а множество промежуточных устройств добавляет миллисекунды. Мы используем современную сетевую топологию spine-leaf, где каждый серверный коммутатор (leaf) напрямую связан с магистральными коммутаторами (spine), чтобы пакеты проходили с минимальным числом промежуточных узлов (hops).
- Высокопроизводительное сетевое оборудование. Провайдеры в РФ чаще всего выбирают сетевое железо класса Data Center, рассчитанное на низкие задержки, — это коммутаторы с высокой пропускной способностью и минимальным временем переключения. Например, в инфраструктуре Облакотеки задействованы решения Mellanox, Juniper, Huawei, Brocade — они обеспечивают быструю обработку трафика. Важно также, что сети внутри ЦОД не перегружаются, так как спроектированы с запасом. Например, внутренние оптические линии и коммутаторы способны пропускать трафик с запасом. Загрузка каналов не должна приближаться к пределам (обычно не более ~70% от максимума на пике). Это позволяет избежать очередей и потерь пакетов, а значит, и скачков задержки.
- Изоляцию разных типов трафика. Внутри дата-центра течет разный трафик: между виртуальными машинами, обращения к системам хранения данных (СХД), внешний трафик к интернету. Если все они перемешаны, может возникать конкуренция за ресурсы сети и непредсказуемые задержки. Лучше разделять эти потоки: для каждого типа предусмотреть свою выделенную сеть или VLAN. Например, трафик хранения данных изолирован от клиентского, трафик «внешнего интернета» отделен от внутренних обменов. Благодаря этому интенсивная запись на диск или бэкап не вызовет роста latency для, скажем, пользовательского RDP-сеанса.
- Скорость систем хранения данных. Задержка проявляется не только в сетях, но и в доступе к данным. Если виртуальная машина ждет отклика от медленного диска, пользователь тоже почувствует тормоза. Именно поэтому современные облачные провайдеры переходят на all-flash хранилища и распределенные системы хранения. В нашем опыте отличные результаты дает гиперконвергентная архитектура с SSD-накопителями: технология Microsoft Storage Spaces Direct в связке с NVMe-накопителями позволила минимизировать задержки операций ввода-вывода. Быстрые диски и оптимизированные алгоритмы кеширования обеспечивают мгновенный отклик при работе с базами данных, файлами и т. д. Для чувствительных к задержке нагрузок (например, ERP-системы или высоконагруженной 1С) мы предлагаем размещение на таких скоростных пулах хранения.
Наконец, сами сервера: используем современные CPU с поддержкой технологий виртуализации, достаточным объемом RAM, чтобы избежать свопинга, и высокоскоростные интерфейсы (10–100 Гбит/с) для подключения к сети. Каждый узел в кластерной облачной платформе резервируется (N+1 или N+2), чтобы даже при сбое оборудования сервис мигрировал на соседний узел без долгого простоя, — это больше про отказоустойчивость, но косвенно влияет и на стабильность времени отклика (нет резких скачков или пауз в обслуживании).
Сетевые решения между дата-центрами и регионами: гонка за миллисекундами
Одна из главных причин задержек — это расстояние между пользователем и сервером. Россия — страна огромная, приходится учитывать географию: сигнал от Владивостока до московского сервера идет тысячи километров, и даже в идеальных условиях скорость света по оптике накладывает ~50–70 мс задержки туда-обратно. Что же делают облачные провайдеры, чтобы минимизировать network latency на больших расстояниях?
География
Крупные игроки стараются иметь инфраструктуру в разных регионах. Например, государственные и крупнейшие коммерческие облака разворачивают дополнительные площадки в Сибири, на Дальнем Востоке, юге России — поближе к конечным пользователям. Наш подход пока иной: мы сконцентрированы на московских локациях, где традиционно сосредоточен бизнес, но при этом обеспечиваем качественное подключение из регионов. В перспективе, конечно, рассматриваем расширение географии, но это должно быть подкреплено спросом. Пока же наша стратегия — соединить существующие площадки максимально быстрыми каналами и оптимизировать маршруты для региональных клиентов.
Мы объединили два московских дата-центра оптическими каналами L2 с резервированием по схеме N+1. По сути, два физически разнесенных ЦОД работают у нас как единая «облачная фабрика»: ресурсы находятся в одной локальной сети, можно прозрачно переносить виртуальные машины между площадками, строить геораспределенные кластеры без ощутимого увеличения задержки. Это важно: клиенту не нужно выбирать площадку с лучшим пингом — система сама оптимизирует размещение. Если нагрузка требует минимального отклика и резервирования, мы можем развернуть ее одновременно в двух ЦОД. При выходе одного из строя второй продолжит обслуживание, и всё это с практически единым адресным пространством и минимальным дополнительным временем на сетевое взаимодействие между ними.
Магистральные сети и пиринг (peering)
Чтобы пакеты данных путешествовали по кратчайшему маршруту, провайдеры стремятся напрямую обмениваться трафиком друг с другом и с операторами связи. Мы присутствуем на ключевых точках обмена трафиком, таких как Dataline-IX и ММТС-9 (M9) в Москве. M9 — это своего рода сердце Рунета, узел, где пересекаются многие сети. Наше присутствие там означает, что трафик от облака Облакотеки может напрямую передаваться в сети большинства российских операторов и интернет-провайдеров, минуя длинные цепочки посредников. Пиринг снижает задержки, так как сокращает число промежуточных маршрутизаторов и нередко географически более оптимален. Например, если клиент находится в сети условного провинциального оператора, а наш облачный узел имеет пиринг с этим оператором на ближайшей точке обмена, путь данных будет буквально «через дорогу», а не через Москву. В последние годы в РФ активно развиваются региональные IX (точки обмена) — это хорошая тенденция для снижения задержек внутри страны.
Для корпоративных клиентов с особыми требованиями мы предлагаем выделенные каналы связи. Это может быть L2VPN или MPLS-туннель от офиса заказчика прямо до нашего облака. По сути, мы создаем «прямую проволоку», минуя публичный интернет. Такой канал безопаснее и уменьшает время отклика и разброс задержки (jitter). В Москве и области прокладка таких каналов дает латентность всего в единицы миллисекунд, сравнимую с локальной сетью. Даже между удаленными городами партнерские магистрали позволяют достичь впечатляющих результатов. Например, пинг корпоративного софта у компании из Екатеринбурга после перехода с обычного VPN на прямой канал снизился почти вдвое.
Выбор маршрутов и мониторинг
Хорошие провайдеры постоянно отслеживают качество сетевых путей. Нужен мониторинг latency и потерь пакетов по всем основным направлениям: если какой-то внешний канал начинает давать задержки (например, из-за перегрузки или аварии у магистрального оператора), динамически трафик перенаправляется на альтернативный путь. Благодаря наличию нескольких аплинков (у нас это «Гарс Телеком», WestCall, «РЕКОНН» и др.) можно балансировать нагрузку и обходить проблемные участки. Здесь уже вступают в игру протоколы маршрутизации (BGP с настройками LocalPref, коммутация трафика на L2-уровнях и пр.) — всё это за кадром для клиента, но напрямую влияет на его опыт. Мы даже выработали свои «карты задержек» по стране: зная, через какие узлы лучше пускать трафик в тот или иной регион, чтобы было быстрее. Например, трафик на Дальний Восток оптимальнее отправлять через Новосибирск, минуя перегруженные европейские части сети, и так далее.
Импортонезависимый стек: как мы работаем без западных решений
Отдельно хочется отметить, как на нашей инфраструктуре сказались геополитические и рыночные изменения последних лет. Тема импортозамещения в IT сейчас звучит отовсюду, и low-latency не исключение. Еще несколько лет назад многие облачные провайдеры полагались на решения мировых вендоров: сервера известных брендов, проприетарные системы виртуализации (VMware, Microsoft), сетевое оборудование Cisco/Juniper и т. д. Однако в текущих реалиях (после 2022 года) доступность обновлений, поддержки и новых поставок такого оборудования под большим вопросом. Нам, как и многим в отрасли, пришлось пересмотреть подход и обеспечить независимость инфраструктуры и не потерять в производительности.
Наша облачная платформа сейчас работает на открытом программном обеспечении без иностранного проприетарного ПО. В основе — гипервизор KVM, оркестрация на базе OpenStack и собственных наработок, Linux везде, где это возможно. Это дало нам два плюса: независимость от «внешних» вендоров и гибкость в оптимизации. Мы настроили сетевые стеки под наши нужды, убрав всё лишнее. Например, отказ от черных ящиков позволил снизить накладные расходы: мы знаем, как обрабатываются пакеты внутри виртуального свича, можем изменить параметры очередей, балансировку IRQ на ядрах процессора и т. д. В итоге latency в виртуальной сети под управлением OpenStack/KVM у нас сопоставима с показателями Hyper-V/VMware, а в некоторых сценариях даже лучше, потому что нет лишних прослоек.
В плане оборудования сложнее полностью уйти от зарубежного железа — мир серверов и коммутаторов глобален. В нашем парке есть решения от разных производителей, в том числе из стран Азии. Сетевое оборудование Huawei, которое мы использовали наряду с прочим, зарекомендовало себя производительным и надежным. Мы стараемся брать такие сервера, которые поддерживают open source экосистему без ограничений. Существуют и российские производители серверов и СХД, некоторые наши коллеги по рынку начали их внедрять — это интересное направление, мы следим за ним. Пока же делаем акцент на том, что вся логика и интеллект-системы — в софте, который под нашим контролем. То есть, даже используя импортное железо, мы не зависим от его производителей ни функционально, ни юридически.
Независимость от импорта дала и неожиданный бонус: мы стали теснее общаться с сообществом, перенимать лучший мировой опыт open source. В плане задержек это выразилось, например, в экспериментах с открытыми сетевыми ОС (типа SONiC на коммутаторах), с кастомными прошивками для SSD, с отечественными разработками мониторинга. Всё это в итоге служит одной цели — держать наш сервис быстрым и устойчивым.
Вызовы рынка и взгляд в будущее
Создание низколатентной облачной инфраструктуры — это постоянная гонка со временем, в прямом и переносном смысле. Российский рынок тут имеет свои особенности. Отмечу несколько вызовов, с которыми мы, как провайдер, сталкиваемся:
- Огромные расстояния и неравномерность развития регионов. Как я упомянул, обеспечить одинаково малые задержки по всей стране очень сложно. В регионах меньше крупных клиентов, а значит, экономически трудно оправдать строительство дорогих дата-центров или укладку новых магистралей только ради снижения пинга. В результате где-то инфраструктура избыточна, а где-то, наоборот, недостаточна. Многие региональные ЦОД полупустые, и это тормозит развитие edge-облаков. Наш подход — пока концентрировать ресурсы в центре, но давать хороший доступ по сети. Однако в будущем отрасли предстоит придумать, как покрыть страну «облачными островками» экономически эффективно.
- Импортозамещение vs высокие технологии. В целом по рынку есть риск, что отсутствие новых поставок топового оборудования замедлит прогресс. Например, новейшие коммутаторы 400G, серверные CPU последнего поколения — со всем этим сейчас труднее. Нужно искать баланс: либо ждать появления отечественных или дружественных аналогов, либо использовать инновационные схемы (например, программно-определяемые сети, кластеризацию вместо покупки одного мощного девайса). Это и вызов, и стимул к развитию собственных инженерных решений. Я вижу, как в России растет экспертиза в open source платформах, и верю, что мы сможем нивелировать эти ограничения.
- Безопасность и регуляторы. Low-latency инфраструктура должна уживаться с требованиями безопасности и закона. Шифрование трафика, фильтрация, инспекция — всё это потенциально увеличивает задержки. Приходится внедрять решения, которые и защищают, и минимально влияют на скорость. К счастью, современные отечественные решения (например, некоторые российские межсетевые экраны, системы DPI) уже могут работать на гигабитных скоростях практически без дополнительных задержек. Мы внимательно тестируем такие вещи, прежде чем пускать в продакшен, чтобы не было сюрпризов.
А что дальше?
Будущее низких задержек я связываю с несколькими направлениями. Первое — это еще большая распределенность, вплоть до edge computing. Через несколько лет, возможно, облако будет ближе к конечному пользователю буквально на уровне района или города: небольшие модульные ЦОД рядом с вышками 5G, на предприятиях, в кампусах. Тогда можно будет добиться минимального ping в десятки микросекунд для локальных задач.
Второе — оптимизация протоколов и софта. Не исключено, что появятся новые сетевые протоколы, заточенные под сверхнизкие задержки, или улучшения в существующих (например, более умные алгоритмы маршрутизации или транспортные протоколы для быстрого восстановления пакетов без увеличения RTT). Уже сейчас крупные игроки экспериментируют с технологиями типа QUIC, UDP-базированных VPN для ускорения. Такие вещи постепенно станут мейнстримом и в корпоративных сетях.
Третье — аппаратные инновации. Мир не стоит на месте: грядет эра оптических соединений внутри серверов, возможно, появятся квантовые коммуникации (там вообще другие порядки задержек). Даже сегодня уже есть сетевые адаптеры с поддержкой RDMA, GPU, прямиком подключенные по NVLink, — всё это сокращает задержку в специфических вычислениях (например, ИИ-модели в облаке). В России, чтобы не отстать, нужно интегрировать такие технологии. Мы планируем, например, тестировать в ближайшем будущем RDMA-сети в нашем облаке для нужд некоторых клиентов, кто работает с высокопроизводительными вычислениями.
Подводя итог: low-latency инфраструктура — это целый комплекс мер. Нельзя взять один волшебный компонент и убрать все задержки. Это и правильный выбор места и архитектуры ЦОД, и качественные сети между ними, и умное программное обеспечение, и чуткое управление. В конце концов, цель проста — чтобы облако работало так, как будто все сервера стоят у вас под столом, даже если на самом деле они за тысячу километров.
Спасибо за внимание! Если у вас есть вопросы или идеи по теме минимизации задержек — буду рад обсудить. Ведь обмен опытом среди профессионалов помогает всем нам строить более быстрый и эффективный IT-ландшафт в России.
