Крупнейший российский логистический оператор СДЭК перенёс 95% своих вычислительных мощностей из Новосибирска в Москву за одни сутки — с полуночи 1 января по полуночь 2 января 2025 года. Причиной стала не нехватка кадров и не близость к европейским партнёрам, а банальный потолок роста: новые дата-центры в Сибири заполняются быстрее, чем появляются. О том, как перевезти 400 микросервисов без потери данных, почему облако оказалось невыгодным и что делать, если фура с серверами попадёт в аварию, — рассказывает Тимофей Нецветаев, руководитель департамента инфраструктурных сервисов СДЭК.
- Исторически штаб-квартира и ЦОД в Новосибирске были единым целым. Что именно стало триггером для решения о переносе 95% мощностей в Москву? Это было требование бизнеса по скорости доступа к западным партнерам, проблема кадрового голода в Сибири или унификация инфраструктуры?
- Скорость доступа к западным партнерам не была одним из критериев: наши системы могут работать из любой точки России, а близость к Европе сейчас не так актуальна. Кадрового голода в Сибири мы также не ощущаем: ядро команды по-прежнему находится в Новосибирске.
Основная причина заключается в том, что компания значительно выросла, и существующая площадка столкнулась с ограниченным потенциалом роста мощностей в регионе. Новые дата-центры в Новосибирской области запускаются, но быстро заполняются крупными игроками, что не дает необходимого объема ресурсов. Мы приняли решение провести миграцию сейчас и выйти на более зрелый и емкий рынок коммерческой инфраструктуры в Московском регионе, чтобы не столкнуться с этой проблемой через 3–5 лет и не решать ее в экстренном режиме.
- Рассматривали ли вы альтернативу –– не перевозить «железо», а арендовать мощности в Москве у облачных провайдеров (например, Yandex Cloud, MWS)? Если да, почему выбрали физический переезд, учитывая риски повреждения оборудования?
- Команда детально анализировала этот вариант и рассматривала «облако» даже как промежуточный этап для миграции. Однако расчеты показали, что полный перевод всей инфраструктуры в «чистую» облачную среду экономически нецелесообразен. Учитывая объем наших совокупных ресурсов и уже имеющийся парк оборудования, ежемесячная подписка оказалась бы крайне высокой. Даже с учетом экономии на команде и других преимуществах «облаков», модель инвестиций в собственное «железо» оказалась для нас более выгодной. Мы выбрали физический переезд, доверившись профессионализму специалистов компании: оборудование было надежно упаковано и застраховано, что позволило провести транспортировку без потерь.
- Насколько сильно специфика логистического бизнеса (микросервисы, трекинг в реальном времени, связка с терминалами) повлияла на решение сохранить собственное «железо»?
- Специфика логистики и архитектуры не повлияла на это решение напрямую –– выбор был продиктован исключительно экономической моделью. На наших объемах владение инфраструктурой позволяет эффективнее управлять инвестициями и капитальными затратами.
- Была ли у вас уже распределенная архитектура до переезда? Использовались ли системы балансировки между разными ЦОДами (Новосибирск и, возможно, другие города) или всё было в одном контуре?
- Да, до переезда у нас уже была распределенная инфраструктура, но в рамках Новосибирска — между двумя локальными площадками. Мы настраивали репликацию баз данных по схеме «мастер-реплика», организовывали кросс-бэкапы и балансировку трафика между ЦОДами с синхронизацией по каналам связи.
- Как готовили железо к физической транспортировке? Были ли потери или сбои при распаковке/подключении на новом месте?
- Подготовка шла по стандартной процедуре: оборудование упаковывалось в стретч-пленку, обрешетку, размещалось на палетах и страховалось. Мы согласовали логистику с принимающей стороной, оформили необходимые документы и отправили оборудование силами собственного логистического сервиса. Всего было выполнено более десяти рейсов, переезд прошел без инцидентов. В Москве оборудование распаковывалось, выдерживалось при комнатной температуре для акклиматизации и только потом подключалось.
- На время переезда у вас фактически работал «активный» ЦОД в пути и «принимающий» в Москве. Как решалась проблема консистентности данных? Использовали ли вы асинхронную репликацию, и если да, то как справлялись с конфликтами транзакций?
- Мы выбрали стратегию поэтапной миграции сервисов. Все наши системы изначально функционируют в асинхронном режиме через шину RabbitMQ, что дало нам необходимую гибкость.
Процесс переезда происходил постепенно. В первую очередь, в Москве разворачивалась реплика базы данных от мастера, оставшегося в Новосибирске. Затем модуль (один из 400) отключался на балансировщике, далее проводился деплой его версии в московский кластер Kubernetes, а модуль «догонял» данные из мастера. После этого мы разрывали репликацию и включали московский балансировщик, начиная принимать трафик уже на новой площадке.
Мы заранее подняли стек на базе Victoria Metrics + Grafana для отслеживания состояния систем в Москве в реальном времени. Сервис был недоступен 5–10 минут, что для большинства систем некритично. После переезда модуль в Москве продолжал ходить за данными в «старую» шину в Новосибирске.
Мы выбрали стратегию «Fix Forward» (исправление на месте). Откат в Новосибирск означал бы потерю прогресса и времени. При появлении проблем (например, сложности с запуском Kafka, ошибки в разделении DNS-зон, обнаружение забытых legacy-систем) мы решали их непосредственно в новой инфраструктуре. Возникавшие задержки были приемлемы: очереди немного росли, но бизнес-транзакции обрабатывались своевременно, а пользователи не заметили изменений.
- Какие каналы связи использовались для связки Новосибирска и Москвы во время переезда? Было ли это выделенное волокно, спутник (для резерва) или магистральные каналы с QoS? Какая реальная задержка (пинг) была достигнута и как вы ее компенсировали на уровне приложений?
- Мы использовали операторский сервис L2VPN. Реальный RTT (пинг) составил 50 мс –– это стандартное значение для этого расстояния, так как скорость света никто не отменял. Никакой специальной компенсации на уровне приложений не проводилось, кроме базового тестирования скоростей работы канала.
- Почему именно 1 января? Это было связано с минимальной нагрузкой на бизнес или с окнами в работе операторов связи и дата-центров?
- Дата была выбрана исключительно исходя из бизнес-нагрузки. 1 января — это день с минимальным количеством заказов как от клиентов, так и от бизнес-партнеров. Мы предупредили клиентов о технических работах заранее. Сам процесс миграции длился 24 часа — с полуночи 1-го января до полуночи 2-го января по московскому времени.
- Был ли в эти 24 часа момент полного «отключения» старых мощностей? Как происходила финальная синхронизация баз данных?
- В течение суток происходил деплой систем в Москве и переключение трафика на московские реплики. Новосибирская инфраструктура при этом оставалась нетронутой. Мы не удаляли виртуальные машины в Новосибирске еще долгое время после миграции. Финальной синхронизацией данных стал момент переезда последних систем. Полное отключение от старой площадки произошло только после того, как мы убедились в стабильной работе на новом месте.
- Какой была последняя команда? Был ли момент, когда вы физически выдернули кабель из старых стоек в Новосибирске и воткнули в новые в Москве? Как отслеживали, что пакеты не потерялись?
- Такого момента не было. Мы выбрали консервативный и безопасный путь: сначала перенесли виртуальную инфраструктуру и сервисы, убедились в их работоспособности, и только потом приступили к демонтажу физического оборудования. Процесс прошел вдумчиво, без спешки. Сейчас основная нагрузка СДЭК идет с московской площадки, но в Новосибирске еще остаются некоторые legacy и внутренние системы, которые мы продолжаем разбирать, высвобождая оборудование.
- После переезда в Москву, как изменилась логика работы периферии (терминалы в регионах, офисы)? Улучшилось ли качество соединения для западных направлений? Пришлось ли менять настройки BGP/пиринга после смены локации?
- Нашей главной задачей было сделать миграцию незаметной для бизнеса (за исключением технического окна 1 января). Никаких изменений в настройках BGP или логике работы периферии не потребовалось. Качество соединения для московских складов и в центральном регионе объективно выросло, но это стало приятным дополнительным эффектом, а не целью переезда.
- Теперь, когда ядро в Москве, какая судьба ждет площадку в Новосибирске? Останется ли она резервным ЦОДом (DRP), будет ли трансформирована в региональный хаб или законсервирована?
- Сейчас в Новосибирске остаются некоторые периферийные системы (например, почтовая система на Open Source, порталы документации, Task Tracker). К концу третьего квартала текущего года эта площадка будет полностью разобрана и отключена. Высвободившееся оборудование по мере готовности будет перевезено в новый ЦОД в Москве. Систему аварийного восстановления (DRP) мы планируем строить уже внутри московского региона, используя «темную оптику» для организации географической распределенности.
- Как бы вы сейчас, оглядываясь назад, посоветовали готовиться к такой миграции тем компаниям, у которых штаб-квартира и «железо» находятся в разных городах и которые задумываются о консолидации?
- Первое и главное — серьезно взвесить, действительно ли миграция необходима. Это требует серьезных инвестиций и несет определенные риски. Если решение принято, нужен четкий, детализированный план, учитывающий следующие параметры:
Первое: глубокое планирование. Четкое понимание последствий миграции для бизнеса и просчет сценариев от «идеального» до «аварийного».
Второе: Синхронизация с командой. Обязательно нужно обсуждать все планы и моделировать негативные сценарии с инженерами (DevOps, DBA, Network): в таких сложных проектах даже самые маловероятные кейсы могут стать реальностью.
Третье: выбор времени. Использование периодов наименьшей нагрузки (как мы использовали новогодние каникулы).
Четвёртое: шаблоны и автоматизация. Благодаря шаблонам виртуальных машин и ролям развертывание прошло быстро. Без автоматизации уложиться в 24 часа было бы невозможно.
Пятое: работа с legacy-системами. Необходимо быть готовыми к тому, что в процессе всплывут забытые системы. Важно заложить время на их поиск и интеграцию.
И шестое: техническое окно. Полностью без остановки (Zero Downtime) такую миграцию с обновлением ядра провести крайне сложно. Короткое техническое окно необходимо для качественного обновления платформ.
- Представьте ситуацию: во время перевозки фура с серверами попала в ДТП. Какой был План Б? Существовала ли возможность «отката» и запуска всех систем обратно в Новосибирске, или механизм был необратим?
- В этом сценарии мы бы потеряли оборудование, но не данные и не возможность работать. Техника перевозилась без систем: «железо ехало пустым». Благодаря слою виртуализации и платформам типа Kubernetes, восстановление работы в случае утраты оборудования свелось бы к получению страховой выплаты, закупке новых серверов и разворачиванию на них виртуальных машин и сервисов по каналам связи со старой площадки. Это ключевое преимущество современной инфраструктуры: мы перевозили не работающий сервис, а только вычислительные мощности для него.