AWS невнятно бормочет о своей сетевой технологии, сбивающей расходы, хотя должна кричать о ней

Aws сети дата-центры экономия облако инновации theregister.com

Узнайте, куда AWS направляет миллиардную экономию от собственных сетевых инноваций. Цены на старые SKU не растут, а новые продукты получают фиксированные тарифы. Разбираемся, как почти случайная сеть экономит до 40% энергии и почему неоклауды пока не дотягивают.

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

Я не был готов к пустому взгляду в ответ, хотя, по идее, должен был. И нет, не потому что шутка была несмешной (мои шутки уморительны), а потому что мир, на который она ссылалась, для них больше не существует. Стойки приходят уже собранными, и, судя по всему, в дата-центрах AWS сейчас никто вручную не вкручивает железо. Это был взгляд за кулисы мира, который питает всё, что мы делаем в облаке, но о существовании которого замечательно мало кто знает.

Мой коллега из Reg Томас Клабёрн уже был в этой лаборатории и подробно разобрал статью AWS на эту тему. Если кратко: «плоская одноуровневая сеть, соединённая по намеренно почти случайному принципу, даёт гораздо более отказоустойчивую сеть, которая стоит гораздо дешевле в эксплуатации», — и теперь вы в курсе.

Та часть, которая, как мне показалось, не получила должного внимания (и именно поэтому я напросился на экскурсию в объект AWS, к немалому удивлению самой AWS), — это экономическая сторона и то, как она влияет на клиентов AWS. Короче говоря, их новый сетевой подход может быть на 40 процентов энергоэффективнее, и он используется по умолчанию в большинстве новых дата-центров (и, дорогой читатель, они строят их сейчас очень много), оставаясь при этом совершенно незаметным как внутри, так и за пределами стен крупнейшего в мире книжного магазина.

Экономия и эффективность затрат реальны — так куда же они деваются?

Эффективность затрат повсюду

Семнадцать лет назад старший вице-президент Amazon Джеймс Гамильтон вышел на сцену и указал [PDF], что сетевые вендоры вели бизнес с маржой, напоминающей маржу производителей мейнфреймов, которые, в свою очередь, напоминали голодных свиней у корыта (моя красочная метафора, но… не лишённая смысла).

Его главная претензия сводилась к «они стоят у меня на пути», и он вместе со своей командой решил что-то с этим сделать. Оказалось, что «сделали они» ни много ни мало — перестроили весь сетевой стек самостоятельно на базе товарного оборудования.

Это подводит нас к нескольким годам назад. Их эффективность затрат на сетевую инфраструктуру была уже гораздо ниже, чем если бы они работали на традиционных сетевых вендорах, а затем их схема Resilient Network Graph shufflebox нанесла очередной удар по стоимости сетей. Итак… куда же делась эта экономия за последние несколько лет?

Я спросил прямо, справедливо ли будет сказать, что они оставили улучшение маржи себе, а не передали его клиентам.

Их ответ был недвусмысленным: «С точки зрения затрат? По сути, да».

Экономика облака AWS

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

(Да, стоимость блоков ёмкости GPU повышалась ежеквартально, но, видимо, так и было задумано, наподобие медленной версии Spot Instances. И да, пару лет назад они начали взимать плату за каждый публичный IPv4-адрес.)

Вы можете зайти и запустить тот же инстанс с 64 ГБ RAM, что и в 2020 году, и заплатить ту же цену сегодня; это даже не повышение цены с учётом инфляции! И хотя переход с Graviton4-based c8g.2xlarge на эквивалентный инстанс c9g.2xlarge на Graviton5 обходится на 9 процентов дороже, никто не заставляет вас обновляться. Честно говоря, учитывая рост стоимости компонентов, я более чем удивлён, что им удалось удержать повышение на уровне 9 процентов.

Более того, несмотря на сводящий с ума уровень детализации в счетах AWS с миллионами SKU, стоит отметить, что каждый SKU сам по себе скрывает головокружительную сложность. Инстанс EC2 взимает плату за час (да, тарификация посекундная; не пишите мне), но эта одна плата покрывает CPU, RAM, объединительную панель, электропитание, физическую безопасность здания, компоненты безопасности IAM, которые не дают ему превратиться в общедоступный компьютер/нечто из Microsoft Azure, сотрудников, необходимых для сборки и эксплуатации этих систем, и невероятное количество сетевой магии.

Кардинальное изменение подхода

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

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

Выгружать данные из AWS значительно дороже.

Их ныне снятое с производства семейство устройств Snowball позволяло пересылать данные в AWS и обратно. Отправка устройства в AWS стоила фиксированной платы, а отправка обратно — этой платы плюс плата за гигабайт. Раздражает, правда?

Всё изменилось за последний год с появлением AWS Interconnect — multicloud, который не взимает плату за гигабайт, а только почасовую плату за порт. Существует бесплатный уровень — один порт 500 Мбит/с на провайдера, что сводит к нулю затраты AWS на передачу этого трафика в GCP, Oracle и скоро Azure. Для сравнения: отправка месячного насыщения этого порта через открытый интернет обошлась бы примерно в 12 000 долларов.

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

«Мы знаем, что клиентам не нравится повременная оплата сетевых услуг, потому что сложно прогнозировать затраты, поэтому мы переходим на фиксированные тарифы для новых сетевых продуктов».

Ну, ударьте меня током и спрячьте одежду; я был бы меньше удивлён, если бы Мэтт Гарман произнёс свой следующий ключевой доклад на re:Invent пятистопным ямбом.

За этим стоит следить; для меня интереснее всего то, что это происходит в то время, когда цены растут, а не падают.

Насколько это сложно? Очень сложно

Проблема в том, что многое из того, что делает AWS, невидимо. Например, почему я рассказываю вам об этом, а не сама AWS?

AWS признаёт, что в целом плохо умеет рассказывать свою историю, но явно хочет это делать. Исторически они перекладывали эту задачу на клиентов, полагая, что выгода вернётся к ним.

Вот мой любимый пример: сложность почти случайной сети заключается не столько в кабелях, сколько в маршрутизации. Каждый протокол, о котором вы слышали (BGP, OSPF, пара специфических протоколов Cisco, которые никто в здравом уме не использует, и т.д.), вычисляет кратчайшие пути, и «кратчайший путь» теряет смысл, когда между любыми двумя точками существуют примерно тысячи эквивалентных маршрутов. AWS решила эту проблему с помощью протокола SIDR (Scalable Intent-Driven Routing, произносится «сайдер», как метод CIDR для выделения IP-адресов, потому что эти люди злонамеренны в именовании), который управляет плоскостью управления, в то время как Spraypoint обрабатывает фактический путь пересылки.

Они публично представили SIDR на re:Invent в 2023 году, а затем снова осветили его на ключевом докладе «Monday Night Live» на re:Invent в 2024 году. Затем они опубликовали статью о RNG, в которой SIDR вообще не упоминается. Насколько я могу судить, никто за пределами компании никогда не связывал протокол с сетью, которую он делает возможной. Мне пришлось спросить на всякий случай, не упускаю ли я чего-то. Я прав. Это не секрет! Они просто не удосужились упомянуть, насколько он важен для работы всей системы.

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

Многие сети дата-центров управляются абсолютными клоунами. Я это знаю; я сам был одним из таких клоунов, пока не обрёл веру / не обнаружил, что могу платить облачному провайдеру, чтобы сделать эти проблемы проблемой Мэтта Редера. AWS настолько преуспела в том, чтобы сделать сетевую магию невидимой, что мы даже не задумываемся о том, насколько это дико — получить почти полную линейную скорость между любыми двумя точками в AWS, и это просто работает. В дата-центрах, которые строите вы или я, приходится беспокоиться о таких забавных вещах, как «коммутатор наверху стойки может пропустить только определённый объём трафика, поэтому не все узлы могут общаться на полной скорости одновременно». Я ни разу не сталкивался с реальной ситуацией, когда это было бы проблемой в AWS. В результате, когда люди решают построить собственные дата-центры, они не знают, чего не знают, после поколения, когда эта сложность была от них скрыта, и подходят к этому с чувством «насколько это может быть сложно?»

Это чрезвычайно сложно, и у меня мало уверенности в том, что неоклауды, запускающие новые объекты дата-центров за одну ночь, обращают на это внимание. Я прямо спросил Редера, не идут ли «объекты дата-центров для ML», которые AWS запускает в таких местах, как Миссисипи, на компромиссы, поскольку у GPU-нагрузок могут быть другие требования. Он посмотрел на меня так, будто я сошёл с ума; каждый дата-центр, который они строят, соответствует одним и тем же спецификациям.

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

Скромное бормотание

Люди, с которыми я говорил в AWS об этом, создали нечто, о существовании чего большинство их собственных клиентов никогда не узнают, и их это, похоже, вообще не беспокоит. Я нахожу это более достойным восхищения, чем ожидал; это само определение неблагодарной работы, и AWS здесь блистает. Работа невидима просто потому, что она успешна. И они так скромны в этом! Они вежливо хмыкнули над моей шуткой про кейдж-гайки, когда поняли, о чём речь, а я вежливо хмыкнул над их шуткой о том, что каждый год новый коммутатор красят в цвет Pantone «Цвет года», который, как оказалось, вообще не был шуткой.

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

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

Они просто не умеют рассказывать об этом миру. ®

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

Похожие новости: