Мультиоблако: к распределенной инфраструктуре без потерь
Публичные облака остаются важной частью развития ИТ-инфраструктуры в России. В 2024 г. объем рынка облачных услуг достиг ₽165,6 млрд - на 36% больше по сравнению с предыдущим годом. По оценкам, в 2025 г. рост продолжится и может составить еще 20–30%. Вместе с расширением рынка усиливается специализация: заказчики выбирают облачные решения под конкретные задачи и бизнес-сценарии.
Все чаще компании уходят от модели «одного облака» в сторону распределенной архитектуры, совмещающей локальные ресурсы и разные облачные платформы. Это позволяет не только повысить отказоустойчивость и гибкость, но и избежать зависимости от одного поставщика.
Источник: ИТ-маркетплейс CNewsMarket, 2025 г.
По оценкам, 89% корпоративных заказчиков в мире используют два и более облака от разных провайдеров. В России мультиоблако пока внедряется не столь широко, но его доля стабильно растет - как ответ на задачи импортозамещения, оптимизации затрат и повышения управляемости ИТ-инфраструктуры.
Мультиклауд и гибрид: не одно и то же
Понятия «гибридное облако» и «мультиоблако» часто воспринимаются как взаимозаменяемые, но это разные модели. Гибрид чаще всего предполагает сочетание собственной инфраструктуры (частного облака или ЦОДа) с одним публичным облаком. Под мультиоблаком, как правило, понимается использование нескольких независимых облачных платформ, которые могут включать как публичные, так и частные сервисы, не связанные между собой. Мультиоблако может быть частью гибридной архитектуры. Например, когда «одно плечо» остается в локальном ЦОДе, а другие выносятся в разные публичных облака.
Такая схема позволяет распределять нагрузку, резервировать компоненты инфраструктуры и получить сервисы, которых может не оказаться у одного из поставщиков услуг. Т.е. мультиоблако также помогает уйти от зависимости от одного провайдера: если, например, он меняет тарифы, уходит с рынка или ограничивает функциональность, ресурсы, особенно с учетом быстро меняющейся технологической и регуляторной среды, можно перераспределять.
Что нужно для работы мультиоблака
Чтобы управлять мультиоблачной средой - инфраструктурой, распределенной в разных облаках - необходим набор инструментов, которые работают как единая система.
В основе - единый управляющий слой, который позволяет работать с разными облаками и платформами как с одной средой, вне зависимости от того, где размещены ресурсы и на чем они развернуты. Через такой интерфейс администратор может запускать виртуальные машины, распределять мощности между командами или проектами, а также отслеживать текущее потребление ресурсов.
Учет и биллинг – в мультиоблачной среде ресурсы поступают от разных провайдеров, каждый из которых использует собственную модель тарификации. Система управления должна сводить эти данные в единое представление, позволяя контролировать потребление, прогнозировать затраты и выявлять неиспользуемые ресурсы.
Поддержка шаблонов развертывания и сценариев автоматизации упрощает запуск инфраструктуры под задачи разных команд. Интерфейсы самообслуживания позволяют пользователям заказывать ресурсы без участия ИТ, по утвержденным политикам.
Где и как работает мультиоблако
Мультиоблачная архитектура может выглядеть по-разному - в зависимости от задач бизнеса, зрелости инфраструктуры и подхода к миграции. Самый распространенный сценарий - использование сразу нескольких публичных облаков. Каждое может, например, отвечать за свою часть: одно - за хранение, другое - за вычисления, третье - за резервное копирование или ИИ-задачи.
Другой вариант - комбинация с собственной инфраструктурой. Это по сути гибридная модель, в которой часть ресурсов остается в локальном ЦОДе, а в облаках размещаются сервисы, требующие масштабируемости или высокой доступности или обеспечивающие работу при критичных нагрузках при сбоях или пиках.
В ИТ-ландшафте, где сложно заранее предсказать, какая платформа или сервис окажется критически важным, мультиоблако помогает избежать лишних трат и технических ограничений.
Когда человек не справляется: автоматизация и AIOps
Мультиоблачная архитектура почти всегда подразумевает высокую динамику: ресурсы запускаются и выключаются в разных средах, пользователи работают в десятках проектов, а потребление постоянно меняется. Поэтому в таких системах все чаще применяются технологии автоматизированного управления.
Во-первых, это шаблоны развертывания и инфраструктура как код - сценарии, по которым можно запускать типовые среды без участия администратора. Во-вторых, поддержка DevOps-практик - когда приложения и инфраструктура разворачиваются как единое целое, по заранее заданным сценариям. Такой подход позволяет быстрее запускать новые сервисы и сокращать число ошибок при обновлениях.
Отдельное направление - AIOps, автоматизация управления ИТ-инфраструктурой на основе анализа данных. Такие системы прогнозируют нагрузку, находят отклонения, автоматически масштабируют ресурсы, помогают снизить затраты и уменьшают число ложных тревог в мониторинге.
Некоторые системы предлагают предиктивную аналитику - прогнозы нагрузки и затрат по облакам. Это помогает заранее увидеть, где могут возникнуть перегрузки или перерасход, особенно если изменения у одного провайдера влияют на работу всей инфраструктуры.
Безопасность между облаками
Чем больше облаков используется, тем сложнее управлять безопасностью. У каждого провайдера - свои правила, доступы и инструменты защиты. Но требования по безопасности и соответствию регуляторным нормам одни для всей инфраструктуры - и их нужно соблюсти сразу во всех облаках.
Ключевая задача - централизовать управление доступом. Это означает, что правила для пользователей, ролей и проектов должны действовать одинаково во всех облаках. Также важно вести аудит действий и контролировать, кто и какие ресурсы использует.
Отдельный риск - расхождения в настройках безопасности между облаками. Если, например, в одном облаке виртуальная машина запускается с другими параметрами защиты или сетевыми правилами, это может создать уязвимость в общей системе.
Дополнительные сложности возникают, когда в мультиоблачной инфраструктуре задействованы данные разного уровня чувствительности. Компании, работающие с персональными данными, КИИ или государственными информационными системами, должны учитывать требования законодательства - например, ФЗ-152, нормативы ФСТЭК и отраслевые регламенты. Облачная среда должна быть настроена так, чтобы эти требования соблюдались во всех сегментах инфраструктуры.
Облачные платформы предлагают разные механизмы защиты: изолированные контуры, шифрование, защищенные каналы передачи данных. Но в мультиоблачной архитектуре важно, чтобы все эти меры работали согласованно. Поэтому нужна понятная система контроля - с правилами, кто и где размещает данные, какими политиками пользуется и как отслеживаются инциденты в разных облаках.
Как перейти к мультиоблаку и что может помешать
Переход к мультиоблачной архитектуре требует не только технических изменений, но и пересмотра процессов управления ИТ. Нужно заранее определить, какие системы можно перенести без изменений, какие придется адаптировать, и как будет организовано взаимодействие между облаками. Также важно понять, кто отвечает за ресурсы в каждом из облаков, как распределяются бюджеты и как соблюдаются требования по безопасности.
- Смена архитектуры (rearchitecting) - полная перестройка архитектуры с переходом на микросервисы, контейнеры и DevOps-подходы.
Мешать переходу к мультиоблаку может целый комплекс факторов. Многих компании сделали вложения в оборудование и локальные лицензии, которые может быть сложно списать на этом этапе. Часто не хватает специалистов с опытом работы в распределенных средах. Возникают сложности с интеграцией облаков между собой и с существующими системами. Не всегда заранее выстраивается понятная модель безопасности. А ожидания от перехода к мультиоблачной структуре могут оказаться завышенными - особенно если недооценены организационные изменения.
Даже при технической готовности проект может тормозиться из-за разного понимания целей со стороны ИТ, информационной безопасности и бизнеса. Без общего подхода мультиоблачная архитектура легко превращается в разрозненный набор решений.
Чаще всего переход проходит проще у тех компаний, которые уже работали в облаке или используют облачную платформу в качестве «второго плеча». В этом случае есть возможность сохраняя контроль над существующей инфраструктурой, постепенно включать другие облака в единый контур управления.