Мультиоблако: где заканчивается диверсификация и начинается хаос
Мультиоблачная стратегия стала почти обязательным пунктом в ИТ-повестке крупных компаний. Но между «правильной диверсификацией» и «неуправляемым зоопарком» – тонкая граница, которую легко пересечь. Объясняет Тимур Чубарин, генеральный директор mt cloud, где эта граница проходит и какие решения, принятые сегодня, компании вспомнят с сожалением.
Облако – оно не для всех одинаково
Облачная инфраструктура хорошо работает для компаний, для которых ИТ не является профильной деятельностью. Небольшой бизнес – клининг, автосервис, локальный ритейл – обычно не держит собственную ИТ-команду и не занимается закупками оборудования: это ему невыгодно и неинтересно. Для них облако – очевидное решение.
Крупные компании рассуждают иначе. Их привлекает идея бесконечной эластичности: позвонил менеджеру, попросил ещё сто петабайт или десять тысяч процессорных ядер – и всё появилось. Этот образ нередко расходится с реальностью: в одних облаках ресурсы в таком масштабе могут быть доступны, а в других мощностей в нужный момент может не хватить. Одна из причин, по которой часть крупных компаний со временем переходит к собственной инфраструктуре, – возможность самостоятельно контролировать рост и закупочные процедуры.
При этом стороннее облако у крупных компаний никуда не исчезает. Оно просто занимает свою нишу: тестовые среды, внезапные проекты, когда ресурсы нужны сейчас, а собственное оборудование уже заказано, но ещё не поступило. Для сложных нестандартных задач с высокими требованиями к надёжности крупные компании выбирают специализированных провайдеров – тех, кто строит инфраструктуру именно под такие нагрузки. Выбор провайдера и модели потребления становится отдельной областью принятия решений – не менее важной, чем сама архитектура.
Два провайдера – норма, три – часто перебор
Мультиоблачная архитектура имеет смысл. Но слово «мульти» не означает «чем больше, тем лучше».
Оптимальная формула – два провайдера. Причём принципиально важно, чтобы они находились в разных дата-центрах. Если оба провайдера работают в одном здании, диверсификация превращается в иллюзию: один инцидент на площадке – и оба облака недоступны одновременно.
Третий провайдер – это, часто, уже зоопарк. Появляются три набора соглашений об уровне обслуживания, три разных API и набора инструментов, которые всем этим управляют, дополнительные каналы. Сложность может расти быстрее, чем ценность диверсификации. В этом и проходит граница: второй провайдер снижает риск зависимости от одной площадки, а третий может добавить больше управленческой сложности, чем устойчивости.
Третье облако бывает уместным – но не как «ещё один провайдер на всякий случай». Оно оправдано, когда закрывает конкретный риск или требование, которое не покрывают первые два: например, отдельную географию, регуляторные ограничения, уникальный сервис, независимый контур для критичной нагрузки или требования заказчика.
Переподписка: норма, которая ломается о форс-мажор
Все облачные провайдеры продают ресурсов чуть больше, чем у них есть. Это нормальная практика – клиенты никогда не используют все выделенные ресурсы одновременно. При правильном управлении это работает без сбоев.
Критические сбои дают о себе знать именно в ситуациях форс-мажора. 2022 год стал для рынка показательным примером. Привычные цепочки поставок оборудования разрушились внезапно. Вендоры ушли. Новые цепочки ещё не выстроились. Провайдеры, которые переподписались чуть сильнее расчётного, столкнулись с нехваткой мощностей – потому что пополнить запасы в привычном темпе стало невозможно.
После того урока рынок стал аккуратнее. Для провайдеров, ориентированных на нагрузки с высокими требованиями к производительности и надёжности, особенно важно не допускать агрессивной переподписки: даже кратковременная просадка ресурсов в таких задачах может быть критична. Системы хранения данных сейчас, как правило, вовсе не переподписываются. По вычислительным ресурсам переподписка сохраняется, но в пределах разумного. В отличие от хранилищ, кратковременная просадка вычислительной производительности – не катастрофа: всегда есть манёвр ресурсов – нагрузку можно перераспределить.
Именно здесь мультиоблачная стратегия показывает обе свои стороны. Второй провайдер даёт пространство для манёвра: просадку у одного можно компенсировать ресурсами другого. Но защита работает только тогда, когда оба партнёра управляют переподпиской осознанно. Если оба переподписаны агрессивно, риск не делится, а удваивается. Поэтому в мультиоблаке важно не просто количество провайдеров, а их инженерная зрелость.
Нагрузки ИИ ломают привычное планирование
ИИ-задачи создали новый профиль потребления инфраструктуры. Нагрузка непредсказуема: длительные простои сменяются резкими пиками. Стандартные модели планирования мощностей под такой профиль не рассчитаны.
Единственный способ с этим работать – держать большие горячие резервы. Оборудование, которое уже установлено, запущено и готово к немедленной работе. Не в складских запасах, а именно в горячем резерве. Это, как правило, затратно, но других способов, пожалуй, нет.
Именно здесь мультиоблачная стратегия может дать передышку: распределение пиков между двумя провайдерами позволяет держать меньший горячий резерв на каждой площадке. Но эта экономия работает только при единой оркестрации – без неё разные GPU-стеки и API не создадут синергию, а лишь удвоят инфраструктурный хаос.
Отдельная проблема – нагрузки ИИ создают новый класс потребления хранилищ. Данные могут месяцами не запрашиваться, а потом потребоваться с мгновенной отдачей. Классическая архитектура «горячего» и «холодного» хранения с такой логикой не всегда справляется. Рынок движется в сторону NVMe и нового класса накопителей, которые сочетают ёмкость с быстрым произвольным доступом.
Мониторинг – не статья экономии
Есть соблазн сэкономить на мониторинге – особенно когда инфраструктура стабильна и инцидентов давно не было. Но именно в мультиоблаке цена такого решения растёт: чем больше площадок и поставщиков использует компания, тем более важно держать в поле зрения всю инфраструктуру целиком. Без единой картины можно пропустить проблему на одной площадке, пока внимание сосредоточено на другой.
Техника выходит из строя. Это случается и неизбежно. Вопрос в том, как быстро это обнаружено и насколько быстро запущено восстановление. Каждая единица оборудования и программного обеспечения должна мониториться круглосуточно. На каждый сигнал тревоги должен быть человек, готовый немедленно отреагировать и поднять дежурного инженера. Экономить на этом – значит экономить на способности вовремя узнать, что что-то сломалось.
Директор по инфраструктуре каждое утро должен видеть два показателя: все активные аварии и остаток мощностей. Когда ресурсы заканчиваются – нужно действовать заранее, а не тогда, когда клиенты уже почувствовали проблему.
О чем пожалеют через три года
Через три года компании могут пожалеть о том, что приняли наличие нескольких провайдеров за гарантию диверсификации. Дефицит памяти и дисков уже формируется: ведущие производители законтрактованы до конца 2028 года, а спрос продолжает расти под влиянием ИИ-задач. Следующим ограничением могут стать энергетические мощности дата-центров – строительство новых площадок занимает годы, а доступная энергетическая ёмкость ограничена.
В такой ситуации граница между диверсификацией и хаосом смещается. Пока у компании есть возможность распределять нагрузку между площадками, второй провайдер действительно снижает риски. Когда свободных ресурсов становится мало на всём рынке, несколько облаков могут сохранить видимость выбора, но уже не гарантировать реальной возможности быстро получить нужные мощности.
Именно это может стать главным сожалением через три года: построить мультиоблачную инфраструктуру ради самой диверсификации, но не оценить, насколько она сохраняет свободу манёвра в условиях дефицита. Чем меньше доступных ресурсов на рынке, тем важнее становится не количество облаков, а способность всей архитектуры оставаться управляемой и предсказуемой. Поэтому мультиоблачную стратегию стоит строить не только вокруг количества провайдеров, но и вокруг планирования мощностей: заранее понимать будущую потребность, условия резервирования, доступный запас ресурсов и порядок действий при его исчерпании. Задача провайдера в этой модели – не просто предоставить ещё одну площадку, а дать компании предсказуемость роста и понятный сценарий на случай дефицита.
