Как подружить новое ПО и старое «железо»?

Рано или поздно любая современная компания столкнется с необходимостью обновлять ПО. Для примера, самое частое проявление такой необходимости — обновление «1С». Но есть гораздо более сложные ситуации. Как правило, это обновление ПО для высоконагруженных операционных систем, которые невозможно отключить даже на пару минут.

Но помимо простого обновления ПО, нужно обновлять и «железо» плюс поддерживать работу всех коннекторов к другим системам компании. Рост сложности всего комплекса обновления растет в геометрической прогрессии в зависимости от объема компании и важности обновляемого ПО.

Я, Андрей Шишкин, СТО в группе компаний X-Com, поделюсь нашим опытом запуска нового ПО, разработанного подрядчиками по нашему ТЗ.

Сразу отмечу, что речь идет о программном комплексе, ответственным за работу всех наших интернет-магазинов. А это высокие нагрузки, бешеная динамика ценообразования и обновления остатков, обработка сотен тысяч сообщений в минуту.

Начало

Имеем довольно старую систему, написанную больше 10 лет назад, работающую на кластере в 18 серверов. На момент запуска этой системы разумнее было купить именно кластер серверов, чем несколько мощных машин. В современных реалиях ситуация уже чуть иная.

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

Ночью же запускаются фоновые работы по капитальному обновлению данных, резервированию, накатывание обновлений и прочие технические штуки. С одной стороны, ночь — это то самое время на обновления, а с другой — регламентные операции делать тоже нужно. Но, разумеется, баланс где-то посередине.

В начале 2022 года руководство приняло решение о необходимости запуска некоторого числа новых сервисов для клиентов. Но старое ПО этого не позволяло делать на уровне архитектуры. Да и планируемые нагрузки были кратно выше текущих. Поэтому я принял решение писать новую платформу, а переключение на нее делать поэтапным, по мере ввода соответствующих модулей.

Уверен, что такая же ситуация есть у многих компаний. Старое ПО не просто морально устарело, а перестает удовлетворять требованию бизнеса. У ИТ-отдела всегда возникает дилемма: внедрять «костыли» до последнего вздоха или вводить новое ПО. Я рекомендую поднимать вопрос нового ПО в следующих случаях:

в компании есть план развития, в котором прописаны показатели, не достижимые на текущем оборудовании; любая мелкая доработка в текущем ПО приводит к частому падению или большому числу ошибок; рост нагрузки невозможно компенсировать простым масштабированием «железа»; «соседние» модули ушли далеко вперед и вам сложно поддерживать коннектор к ним так же, как и устаревший фреймворк без официальной поддержки; высокие расходы на поддержание ПО; высокие риски зависимости работы ПО от третьих лиц (сотрудники, подрядчики и пр.), то есть существует риск потери ПО вместе с потерей этого человека; найдены критические уязвимости, особенно если они на уровне архитектуры.

Важно! Внедрение нового ПО должно опережать темп развития компании.

«Железо»

Если с этапами разработки ПО все было просто, то вот вопрос «железа» оставался не решенным до последнего.

Запускать на старом «железе» мы не могли. Оно по-прежнему функционирует под нагрузкой и обеспечивает работу бизнеса. Влезать в него ради проведения экспериментов слишком рискованно.

Чтобы понять, выдержит ли старое «железо» новую архитектуру и нагрузки, нам нужно было провести нагрузочные тесты. А для этого необходимо иметь и готовое ПО (или хотя бы имитацию этого ПО), и виртуальный образ текущих серверов.

Ни то, ни другое нам было недоступно, и вот что я решил.

Заказал разработку базы данных, приближенную к требованиям для новой системы, чтобы спрогнозировать нагрузки. Если смотреть на нагрузку в разрезе работы программного кода, то основной «затык» происходит именно на уровне БД. Поэтому мы путем нескольких заходов нашли ту архитектуру, которая нас устроила. К слову, я 10-кратно увеличил требования по нагрузкам относительно требований, которые были по бизнесу. Это позволяет заложить резервы и под рост бизнеса, и под наши ошибки в расчетах. Нагрузочные тесты делали через эмуляцию трафика.

По «железу» решение было следующим. Компания выделила бюджеты на закупку новых серверов. Но вот какие именно покупать — мы не знали. Просто так набрать мощности «пальцем в небо» мы не могли, слишком высоки риски приобрести не то и просто потратить несколько миллионов.

Единственным вариантом остается облако. Выбрали «Яндекс Облако». Мы в целом не так чтобы сильно анализировали рынок облачных решений, нам требовалось облако только для этапа разработки и на первое время после запуска всей платформы. Выбор на «Яндекс» пал только потому, что наш подрядчик имел опыт работы с ним.

Цель следующая — в облаке мы можем оперативно настраивать мощности по мере развития платформы и вывода готовых модулей в «боевую» нагрузку. А как только вся разработка закончится и будет проведена опытная эксплуатация, мы сможем понять, какое в итоге «железо» нам нужно закупать.

Что делать со старым «железом»?

Мы его не списываем. Часть серверов в итоге пойдет в работу в новую архитектуру. Разумеется, нам понадобится провести регламентные работы по его подготовке, проверить диски, память, возможно, поменять ЦП и т. п.

Часть серверов пустим для локальных нужд. Прокачаем среду разработки, заменим «железо» на других проектах, найдем иное применение. Ну а с частью «железа» все же простимся. Выбросим или продадим — еще не знаем. Это нам предстоит решить до конца 2023 года.

В целом подход обновления «железа» через работу в облаке применим практически во всех случаях, когда нужно что-то решить с текущим «железом». Это дает вам:

возможность привлекать подрядчиков с быстрым и распределенным доступом к вашему облаку; перенести все ваше ПО в облако на время работы по вашему «железу»; реализовать резервную копию для быстрого развертывания в случае проблем с основным «железом»; перераспределить нагрузку, в том числе обеспечить пиковые нагрузки.

И многое другое.

Но есть и ограничения. Например, если внутренняя политика компании запрещает хранить данные во внешней среде.

Также я пока не вижу смысла использовать облака для файлового хранилища. У нас есть выделенный сервер для хранения фототоваров. Его мы никуда переносить пока что не собираемся.

В итоге баланс между тем, что уносить в облако, надо ли уносить, как провести миграцию данных и т. п., нужно делать только после полного аудита текущей ситуации в компании.

Эксплуатация

Сейчас этот проект находится в завершающей стадии. Весь код уже написан. Облако настроено и работает штатно. Мы завершаем подготовительные этапы для одномоментного переключения рубильника. Самый волнительный этап. Ведь всегда кажется, что что-то где-то забыли.

И старое и новое ПО сейчас работают в параллели. Старое «железо» и облако также под параллельной нагрузкой. Это нам нужно для «боевой» имитации нагрузки, чтобы подготовить новое ПО к запуску в режиме рубильника.

Облако штатно держит всю нагрузку, в том числе пиковую в момент массовой работы парсеров. Единственное, что мы в облаке не стали делать, — хранить логи и прочие исторические данные. Это не выглядит разумно при текущей стоимости дисков в облаке.

Резерв по «железу» мы заложили с запасом. По текущим прогнозам, нам его хватит лет на пять. Но даже если бизнес будет расти с опережением, у нас остается возможность как горизонтального, так и вертикального масштабирования (заложили это и в архитектуре «железа», и в архитектуре программного кода).