Boris Burkov

ПРО ЦОДЫ Вслед за складами Wildberries мы выяснили, что столь же уязвимыми являются огромные ЦОДы на десятки мегаватт. Почему они такие большие? Основная масса коммерческих ЦОДов в РФ, с которыми я сталкивался в эру облаков 2010-ых - это малые мегаватты. Типичная стойка ЦОДа - это 5-10 кВт потребления + еще 0.5-3 кВт теплоотведения, стоит в ней порядка 10 единиц оборудования (серверов, дисковых полок, коммутаторов…). Существует метрика PUE (Power Usage Effectiveness), равная отношению суммарного потребления ЦОДа к потреблению серверов. Например, если мегаваттный ЦОД тратит 800 киловатт на потребление и 200 киловатт на отведение/осушение (+ прочие накладные расходы), PUE равен 1000 / 800 = 1.25. Борьба за снижение PUE - одна из мотиваций для укрупнения ЦОДа. У сравнительно современных ЦОДов на несколько мегаватт, какие обычно размещают в городах вроде Москвы и Питера, PUE будет в районе 1.2-1.3, тогда как ЦОДы на десятки мегаватт дают ~1.1 и часто размещаются подальше. Мотивация эта понятна: если взять период амортизации классического сервера ~7 лет, опекс обычно прилично перевешивает капекс, т.е. стоимость самого сервера существенно ниже стоимости электричества, которое он потребит за время жизни. В этом смысле мне вообще непонятно, как в плане хостинга Европа может конкурировать с РФ, где, хотя серверы и дороже, электричество втрое дешевле (а поднять полный стек облачного софта спокойно может команда 3-5 человек). Еще есть большое исключение под названием Hetzner, которые используют не энтерпрайзное оборудование как другие крупные хостеры, а скорее high-end desktop, сопоставимый по надежности, но буквально в десятки раз более дешевый, потому что выдоить из розничного потребителя те же пять концов, что из корпоратов, интелы-AMD не могут, а рынок розницы все же большой. Поэтому даже с немецким электричеством и немецкими з/п и налогами ценники Hetzner’а буквально в 5-20 раз ниже AWS’ов, да и Yandex.Cloud’ов с Cloud.ru. Но на самом деле, если мы посмотрим на ценники облаков, большинство провайдеров могут позволить себе уж так не убиваться за опексы с капексами, потому что основную маржу они так или иначе извлекают из SaaS-решений, которые накатывают поверх железа, и она все равно велика. Чем современнее и дефицитнее стек технологий, которые они предлагают, тем больше можно наварить. Если раньше они продавали managed базы данных, кубернетесы, ELK, спарки, s3-хранилища и т.п., то понятно, что в последние 5 лет примерно все это стало лишь гарниром вокруг… ИИ-ИИ-ИИ-ИИ Второй и главной причиной кратного укрупнения ЦОДов стал он, да. Вся экономика ЦОДа в значительной мере изменилась с приходом эры видеокарт в 2020-ые. Если для горизонтального траффика в облачных задачах 10-гигабитной кластерной сети хватало за глаза, и лишь ядро сети было 100Gbps, то с видюхами этот номер больше не проходит. Нейронки с триллионами параметров требуют хотя бы тысяч или малых десятков тысяч GPU для обучения, все они должны быть связаны друг с другом через вдесятеро более дорогое сетевое оборудования с сотнями гигабит в секунду пропускной спосбоности, а это - тысячи классических стоек и десятки мегаватт потребления. Растащить по разным ЦОДам их просто нельзя. С прицелом на это дело Яндексы и строили свои ЦОДы на десятки гигаватт в европейской части страны, так что защитить их плотными кольцами московской ПВО не выйдет. Если с классическими облачными ЦОДами 2010-ых разукрупнение - вполне рабочий вариант (цена атаки тысячей дронов мегаваттного ЦОДа в Москве примерно равна его стоимости - ~$50M, так что если быстрая переброска сервисов в другую availability zone проверена и работает, ущерб примерно равен цене атаки), то ЦОДы 2020-ых с видеокартами на десятки мегаватт в нынешних обстоятельствах нужно зарывать под землю и заливать в бетон (или выводить из страны, что существующая законодательная база запрещает). Ну и отдельно нужно подумать о других бутылочных горлышках всей системы, которые, как все мы знаем, есть и весьма уязвимы. Как сами по себе, так и их пререквизиты - электростанции, подстанции 110/330/750 кВ, лучи электроснабжения и т.д.