Анатомия высоких нагрузок. Как выстроить отказоустойчивую ИТ-инфраструктуру — от запроса до запуска

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

На этом пути они неизбежно сталкиваются с несколькими слоями требований: производительность, отказоустойчивость, безопасность, резервирование и дальнейшая эксплуатация.

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

От симптома к инженерной задаче

Клиент редко приходит с чётким запросом, который сразу можно переводить в архитектуру. Обычно всё начинается с «симптомов»:

• производительность сервисов проседает, особенно в пиковые часы;
• масштабироваться уже некуда или каждый новый сервис запускается с трудом;
• компания попадает под регуляторные требования: КИИ, ПДн, отраслевые нормы, внутренние политики безопасности;
• регулярно возникают сбои, восстановление занимает непредсказуемое время;
• нужно запустить новый сервис, направление или цифровой продукт, а текущая инфраструктура к этому не готова.

При этом один и тот же симптом может иметь разные причины.

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

Запрос на импортозамещение тоже редко ограничивается одним компонентом. Может потребоваться замена платформы виртуализации, серверов, СХД, сетевого оборудования, средств резервного копирования, мониторинга, защиты или базы данных.

Поэтому первый этап — разобраться, что именно болит, какие системы затронуты и какой результат нужен бизнесу.

Сбор параметров до проектирования

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

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

• текущий масштаб и динамика: сколько пользователей и сервисов сейчас, какой прирост ожидается за 1–2 года;
• профиль нагрузки: штатные и пиковые значения, запросы в секунду, чувствительность к задержкам, соотношение чтения и записи;
• где узкие места: горлышками могут быть приложение, база данных, сеть, хранение, интеграции, внешние API;
• какие сервисы критичны для денег, клиентов и операционной работы;
• допустимые простой и потери данных по разным системам (RTO/RPO);
• требования по безопасности и регуляторике: КИИ, ПДн, размещение данных;
• ограничения по совместимости, миграции и поддержке;
• какой уровень эксплуатации должна выдерживать команда после запуска.

Эти параметры определяют состав решения: достаточно ли расширить текущий контур, нужно ли менять СХД, усиливать сеть, добавлять балансировку нагрузки, выносить статический контент в CDN, пересматривать базу данных, внедрять кэширование, строить резервную площадку или добавлять DR-сценарий.

Из каких слоёв строится высоконагруженная инфраструктура

Высоконагруженная инфраструктура собирается как связанная система.

Вычисления
Серверы, кластеры, виртуализация, контейнерные платформы, запас ресурсов на рост и отказ отдельных узлов.

Хранение 
СХД, SDS, классы хранения, производительность под базы данных, прикладные системы, архивы и резервные копии.

Сеть 
Пропускная способность, задержки, резервирование каналов, разделение трафика управления, хранения, миграции, пользователей, репликации и бэкапов.

Балансировка нагрузки
Распределение трафика между узлами приложения, контроль состояния сервисов, переключение при отказе.

Базы данных 
Репликация, оптимизация запросов, разделение нагрузки на чтение и запись, масштабирование, шардирование при росте объёма данных и нагрузки.

Кэширование
Снижение нагрузки на БД и ускорение ответов для часто используемых данных.

Очереди сообщений 
Обработка фоновых операций, интеграций и пиковых событий без перегрузки основного сервиса.

CDN
Ускорение отдачи статического контента, файлов и медиа, снижение нагрузки на основной контур.

Информационная безопасность 
Защита периметра, сегментация сети, контроль доступа, управление привилегиями, журналирование событий, защита каналов, контроль уязвимостей и соответствие требованиям регуляторов.

Резервное копирование и DR
Политики бэкапов, репликация, резервная площадка, проверка восстановления и фактических RTO/RPO.

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

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

Так архитектура становится управляемой: каждый слой рассчитан под свою задачу, связан с остальными и контролируется в эксплуатации.

Пример

Дисклеймер: показываем логику построения, а не универсальный рецепт. Реальная архитектура всегда считается под задачу, нагрузку, бюджет, безопасность и эксплуатацию.

Внутренние сервисы и умеренная нагрузка

Допустим, компании нужно обновить инфраструктуру под внутренние системы: 1С, файловые сервисы, тестовые среды, внутренние порталы и несколько прикладных приложений.

Задача — получить стабильную платформу, запас ресурсов на рост и понятное восстановление. Часть сервисов допускает плановые окна, а простой в несколько часов не создаёт критичного риска для бизнеса.

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

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

Production-контур с критичными системами

Другой пример — инфраструктура под ERP, базы данных, биллинг, клиентские сервисы, личный кабинет, API и интеграции. Здесь считают общий запас мощности, IOPS, задержки, рост данных, сетевой трафик, окна резервного копирования, допустимый простой, допустимую потерю данных и поведение системы под пиковой нагрузкой.

В такой архитектуре появляются производительное хранение, разделение нагрузок по классам, отдельные сетевые контуры, балансировщики, несколько экземпляров приложений, кэширование, очереди сообщений, репликация баз данных, разные политики резервного копирования и расширенный мониторинг. При коротких RTO/RPO может потребоваться резервная площадка или DR-контур.

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

От архитектуры к реализации

После выбора архитектурной модели её нужно привязать к конкретной инфраструктуре: серверам, хранилищу, сети, платформе виртуализации, базам данных, балансировщикам, средствам защиты, резервному копированию и мониторингу.

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

Для умеренного контура под внутренние сервисы конфигурация может включать:

• 3–4 физических сервера в кластере;
• общий пул вычислительных ресурсов под виртуальные машины;
• 512 ГБ – 1 ТБ RAM на сервер, в зависимости от количества и профиля ВМ;
• СХД или SDS под рабочие нагрузки;
• резервированные сетевые подключения;
• 10/25 GbE для пользовательского и служебного трафика;
• отдельную сеть управления;
• репозиторий для резервных копий;
• базовый мониторинг серверов, ВМ, дисков, сети и бэкапов.

Такой контур закрывает задачу стабильной платформы: разместить внутренние сервисы, выдержать отказ отдельного узла, централизованно управлять ВМ, выполнять резервное копирование и сопровождать инфраструктуру без избыточной сложности.

Для production-контура требования выше. Архитектуру нельзя считать только по количеству серверов и виртуальных машин. Для базы данных критичны задержки и профиль операций чтения/записи. Для клиентского сервиса — время ответа, балансировка и поведение под пиком. Для API — устойчивость к всплескам запросов, лимиты, очереди и контроль внешних интеграций. Для восстановления — скорость доступа к резервным копиям, порядок запуска зависимых систем и фактическое время возврата сервиса в работу. 

Поэтому техническая реализация всегда собирается вокруг нагрузки, отказоустойчивости, безопасности и дальнейшей эксплуатации. Железо, ПО, сеть и бэкапы подбираются как части одного рабочего контура.

Совместимость и импортозамещение
При импортозамещении меняется целая связка. На схеме задача может выглядеть как замена одного компонента. В реализации приходится проверять весь контур.

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

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

Подробно о выборе связке компонентов при испортозамещении виртуализации писали тут.

Миграционный план

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

Для критичных систем нужен другой уровень подготовки:
– карта зависимостей между ВМ, базами данных, приложениями, API и внешними интеграциями;
– отдельные окна миграции для связанных сервисов;
– тестовый перенос;
– проверка производительности после миграции;
– план отката;
– контроль резервных копий до начала работ;
– проверка восстановления после переноса;
– временное усиление мониторинга на период миграции;
– поэтапное переключение трафика через балансировщик или DNS;
– проверка работы кэша, очередей и репликации.

Хорошая реализация оставляет после себя управляемый контур. Команда понимает, где размещаются нагрузки, какие ресурсы зарезервированы, как работает бэкап, кто видит алерты, как добавляются мощности и что происходит при отказе сервера, канала, хранилища, базы данных, приложения или площадки.

Проверка перед запуском

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

1. Нагрузочное тестирование
В контуре с базами данных, ERP, биллингом, клиентскими сервисами или API нужно смотреть на CPU, RAM, IOPS, задержки, пропускную способность, очереди на дисках, загрузку сетевых интерфейсов, время отклика приложений, поведение СХД во время бэкапов, состояние кэша, очередей, репликации и балансировщиков.

Отдельно проверяют пересечение нагрузок. Миграция ВМ, резервное копирование, репликация, пользовательский трафик, запросы к БД и фоновые задачи могут начать конкурировать за одни и те же ресурсы.

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

2. Проверка отказоустойчивости
Резервирование нужно проверить действием: отключением сервера, потерей сетевого линка, недоступностью одного пути до СХД, сбоем ВМ, отказом узла приложения, проблемой балансировщика, деградацией базы данных или проблемой канала между площадками.

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

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

3. Проверка восстановления
RTO и RPO подтверждают практикой: засекли время, восстановили систему, проверили данные, зафиксировали результат.

Важно пройти весь сценарий: восстановить ВМ из резервной копии, поднять базу данных, проверить целостность данных, запустить зависимые сервисы в правильном порядке, проверить доступ пользователей или интеграций и сравнить фактическое время восстановления с целевым RTO.
Для критичных систем такие проверки нужно повторять регулярно. Инфраструктура меняется: появляются новые ВМ, растут базы, обновляются приложения, меняются сетевые правила и добавляются интеграции.

4. Передача в эксплуатацию и поддержка
После проверки инфраструктуру передают в эксплуатацию: фиксируют архитектурные схемы, настройки, регламенты, доступы, политики резервного копирования, сценарии восстановления и зоны ответственности.

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

На выходе должно быть понятно:
– какие пределы есть у системы;
– какие аварийные сценарии уже проверены;
– сколько реально занимает восстановление;
– какие риски остаются;
– какие метрики нужно контролировать постоянно;
– что нужно доработать после запуска.

После таких проверок устойчивость можно подтвердить фактами: результатами тестов, временем восстановления и понятным порядком действий команды.

Итоги

Устойчивая высоконагруженная инфраструктура строится от задачи: какие сервисы критичны, какая нагрузка ожидается, какие данные обрабатываются, какой простой допустим и как система будет восстанавливаться после сбоя.

От этого зависят архитектура, оборудование, ПО, сеть, хранение, балансировка, базы данных, безопасность, резервирование, бюджет и модель сопровождения.

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

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

Заполните форму на сайте — мы свяжемся с вами и поможем разобрать задачу.