Комментарии 58
В очередной раз обсасывается эта тема. Да, если настроить неограниченное масштабирование можно попасть на деньги. Но даже в статье написана правда: практически невозможно сделать биллинг в реальном времени.
Вот у вас один маленький аккаунт S3, который стоит положим 0.001 цента за операцию и ваше маленькое приложение делает всего 100 операций в минуту. Это значит, что только для вашего приложения Амазон должен 100 раз в минуту сделать запись в базу биллинга, пересчитать сколько вы потратили и проверить ваши лимиты. То есть автоматом, ваш аккаунт начинает работать в среднем в два раза медленее (ведь надо и в аккаунт записать и в биллинг) и так во всех сервисах.
А теперь прикинем, что есть премиум аккаунты, которые должны уметь выдавать 100к операций в секунду. Физически невозможно, чтобы такие аккаунты выдавали метрику по цене на каждый запрос и чтобы эта метрика в реальном времени проверялась против лимита расходов.
Не знаю как в AWS, Azure для всех автомасштабирований требует указать лимит в единицах измерения сервиса. То есть для виртуальной машины в количестве ядер, для базы данных в гигабайтах и так далее. Может показаться, что это не столь удобно как в деньгах. Но это недоубно, только если вы пришли первый раз и хотите просто поиграться и сами не особо понимаете чего конкретно хотите. Если же вы создаёте даже маленькое, но приложение с конкретной целью, то вы более или менее представляете какие ресурсы будут нужны вашему приложению и наоборот удобнее указать лимиты в ресурсах. Azure вам сразу покажет сколько это примерно будет стоить в деньгах и будет списывать эту сумму равномерными долями
Это значит, что только для вашего приложения Амазон должен 100 раз в минуту сделать запись в базу биллингаДа хотя бы раз в минуту проверяли состояния счета и блокировали если нет средств. Счета на десятки тысяч долларов все-таки на за 1 минуту обычно набегают.
Amazon, как и другие облачные сервисы оптимизирован для больших клиентов, у которых траты в месяц тысячи долларов. Мелкие разработчики, с бюджетами в 10$ в месяц не дают никакой значительной прибыли. Не надо облака сравнивать с мобильными донат играми
Чтобы получить у Амазон виртуальную машину с 4TB+ оперативки надо писать в поддержку и пояснять, для чего потребовалось. Чтобы получить у Гугл больше 12 ядер на их бесплатном пакете в 300$ надо тоже писать… и все равно лимит не увеличат, даже если деньги на счету есть и этот стартовый пакет все равно не используется:) и так далее.
Если я заказываю себе поменять дверь или окно за 200$ это не должно приводить к убыткам в десятки тысяч долларов из-за какой-то опечатки или непонимания.
Если вас выпустить из автошколы без инструктора, то вы можете устроить аварию или даже кого-то убить. Но это же не значит, что отныне вы должны всегда ездить с инструктором, и жить с мамой. Пора учиться брать ответственность на себя и решать проблему лавинообразного нарастания запросов на СВОЕЙ стороне — ежеминутно наблюдать за приложением, трафиком и балансом счёта, и немедленно исправлять обнаруженные ошибки. AWS за всеми вами тяжело уследить.
Пора учиться брать ответственность на себя и решать проблему лавинообразного нарастания запросов на СВОЕЙ стороне — ежеминутно наблюдать за приложением, трафиком и балансом счёта, и немедленно исправлять обнаруженные ошибки.
это чушь. Потому что входящий трафик вы не контролируете. Можно представить себе ситуацию, что конкуренты решили дешевыми инстансами нагенерить на своей стороне трафика и пустить его на ваш сервис — и ничего вас не спасет. Либо ваш сервис ляжет, либо Амазон вас отскалирует верх. Самый плохой сценарий — когда будет и то, и то (клиенты все равно будут недовольны, а Амазон срубит кучу денег). Вставать за защиту — вариант, но не абсолютный, увы.
Это значит, что только для вашего приложения Амазон должен 100 раз в минуту сделать запись в базу биллинга
Так он это и так делает — счета то выставляются.
Тут надо не делать запись, а делать проверку, и ее можно делать даже не на каждое действие, а раз в 10 запросов, раз в 100 запросов, раз в час.
Как все быстро забыли, что еще 15-20 лет назад у всех или почти всех местечковых провайдеров интернет биллинг вообще раз в месяц считался. И если среди месяца провайдер звонил — значит, мы опять выбрали весь его лимит у вышестоящего провайдера и дело плохо. Впрочем, это обычно решалось балансировкой трафика — надо было восстановить нужное соотношение входящего к исходящему для обнуления тарифа. Так все мои друзья-админы тех времен сейчас облака манной небесной по удобству тарификации считают:) И я с ними согласен.
Вот у вас один маленький аккаунт S3, который стоит положим 0.001 цента за операцию и ваше маленькое приложение делает всего 100 операций в минуту. Это значит, что только для вашего приложения Амазон должен 100 раз в минуту сделать запись в базу биллинга, пересчитать сколько вы потратили и проверить ваши лимиты.
При наличии желания это решается очень просто. Например, на ресурс задаётся предел темпа потребления в деньгах или пропорциональных им условных попугаях. Дальше производится локальный для ресурса учёт, который проверяется по базе и сливается в неё раз в K минут. И опять же делается остановка потребления при снижении общего акаунта ниже некоторой предельной суммы (причём по умолчанию я бы вообще ставил ноль, и давал минус только при показе платёжеспособности...)
А теперь прикинем, что есть премиум аккаунты, которые должны уметь выдавать 100к операций в секунду.
Да. Посмотрели на счёт — есть на ближайшие 5 минут ещё 300$? разрешили на такой темп. Есть только 20$? Разрешили только 20000 операций, а дальше стоп. Раз в 5 минут выдержит любой подобный биллинг.
Тут, конечно, интересный вопрос — что, если даже типов таких ресурсов штук 20 и проверка на каждом будет независимой. Но если дать ставить галочку "допускать только если денег есть на все ресурсы с гарантией" или "можно опускать с учётом всех запасов до -200$" — уже все пострадавшие и потенциально пострадавшие будут благодарны.
Если это не делают — как сказано в статье — причина одна: явное нежелание делать то, на чём потеряют возможность дрючить "лохов" (термин, увы, адекватный тут).
Я как-то влетел на деньги в GCP. Создал небольшой инстанс, всё было хорошо.
Потом пришли люди (боты?) из Китая, и внезапно оказалось, что с ВМ идёт трафик («в комплекте»), но у этого «в комплекте»* есть звездочка. И там, помимо прочих условий, указывались регионы, откуда (и куда) трафик всегда платный. Независимо от его количества. Китай, Океания, еще кто-то там…
Там есть подводный камень с тем, что истории обычно "хорошо" заканчиваются, поддержка amazon идет на встречу, причем не только к хардкорным компаниям, но даже разработчикам-одиночкам. В моем опыте прощали даже откровенно и точно пожранные нами ресурсы, в следствии ошибок devops или вовсе забытые.
Мой опыт с amazon напротив закрепил лояльность к ним, как частника и как представителя компании. Вроде как очевидно, что лимит решил бы ряд страхов, но с другой стороны такой уровень урегулирования и помощи предоставляет далеко не каждый провайдер.
Вот ценообразование и "калькулятор стоимости" жуть
На генерируемое уведомление о превышении бюджета можно назначить произвольные обработчики, которые удалят или остановят что требуется, или даже заблокируют биллинг для проекта, что автоматически приведет к удалению всех платных ресурсов. Например, для облака гугл первая же ссылка в их поисковике выдает исчерпывающие инструкции: How do I set a cost limit in Google Developers Console Аналогично у всех облачных провайдеров делается.
Уведомления поступают с задержкой и счет выставляется по факту. Ребятам из процитированной статьи этого хватило чтобы попасть на десятки тысяч долларов.
Билинг в реальном времени нельзя сделать по вполне объективным причинам. Если пообещать жесткие лимиты в пользу клиента, то это не только станет поощрением халатности новичков, но и откроет большой простор для злоупотреблений. Поэтому в текущем виде решение выглядит как некий консенсус. Можно сказать это плата за обучение.
И сейчас есть много хостингов с балансом в реальном времени. Вот только инстанс нужно руками из админки создавать + подниматься он будет в течении часа-двух.
К примеру, у Digital Ocean было 25 машин лимитом по-умолчанию. Скейлимся в лимит — упираемся — дальше лимита ресурсов не скейлимся — счёт на больше, чем лимит ресурсов * на их цену не придёт.
В Gcloud тоже сразу показывается. И хотя и у гугла и у амазона я наизусть помню цены нужных мне инстансов и намного чаще из консоли скриптом их запускаю, но все равно приятно, что не надо на каждый чих прайс гуглить.
По поводу урока. Как-то создал инстанс на амазоне чтобы потренировать нейронную сеть. И то-ли я не выключил то ли был какой-то глюк и не выключился но в итоге в конце месяца мне пришел счет на 600$. Это очень неприятный урок, в то время, когда я рассчитывал на 10$
я тоже так случайно влетел на фритир гугла и бонусными 300$. Кто ж знал, что айпишники платные и при удалении ресурсов, ты за айпишник все равно "платишь". Благо сумма была небольшая, но осадочек остался
А у амазон эту цену надо фиг знает где искать
потому что у амазон цена зависит от региона размещения. нормальный вариант, когда Орегон ~в два раза дешевле Франкфурта.
Огромная задержка оповещений именно у Амазона, насколько я понимаю. Мне от них оповещения вообще как-то рандомно приходили. У других провайдеров попроще. А еще можно выставить кучу лимитов вроде доступных вычислительных ядер и прочее, чтобы оставаться в разумных пределах. Не знаю, как насчет сложных сервисов типа BigQuery AutoML, где заранее вычислить затраты не получится и с лимитами может быть сложно разобраться, но с базовыми сервисами задача вполне решаема.
Если пообещать жесткие лимиты в пользу клиента, то это не только станет поощрением халатности новичков, но и откроет большой простор для злоупотреблений.
Microsoft Azure имеет жесткие лимиты. В том числе именно так работают «виртуальные» 120$ в месяц для MSDN-подписчиков.
Немного неудобно, что оно не восстанавливается само в начале нового периода а надо вручную перестартовать-передеплоить… вот это плата за обучение.
Уверен, что все резко стало бы возможным, появись правильный закон или прецендент в суде против скотов. Вспомнилось, как американские авиапроизводители обещали космические удорожания и утяжеления самолётов при добавлении регулировок в сидения и органы управления в истребители, чтобы удобно было большинству пилотов. Но, когда минобороны безальтернативно потребовало это, как условие для контракта, вдруг, все производители нашли способ решить вопрос дешево и без особого доп веса.
Технически реально сделать достаточно точный биллинг, если резервировать деньги чуть с запасом. Условно, есть глобальный сервис, который резервирует деньги, попутно проверяя лимит + даёт грубый прогноз по использованию на, например, минуту вперед.
Каждый сервис синхронно берет себе среднеминутный лимит, локально его уменьшает, и при окончании берет ещё. Тогда нетфликс будет откусывать на свои S3 по $1000 за раз, а стартапер Вася по $0.001
Уверен, что все резко стало бы возможным, появись правильный закон или прецендент в суде против скотов.
Да уже сейчас всё возможно, если это нужно сервису. На любом бесплатном, условно-бесплатном или триальном плане умеют точный биллинг и ни байта сверху не подарят. А когда можно выставить счёт — так уже разучились.
Все можно.
И есть широко известный пример.
Сотовая телефония.
Был постоплатный биллинг раз в месяц.
Но сейчас имеем как норму — посекундную тарификацию.
Просто оказалось выгодно найти решение.
А насчет облачных сервисов — у Selectel'а ж было облако и с посекундной тарификаций cpu и (насколько помню) учетом операций ввода-вывода с диском по одному запросу.
Вот и сотовые операторы утверждали, что "нельзя сделать". А после прецедента с Мегафоном как-то исхитрились и биллинг стал обновляться почаще, чем раз в неделю.
Наказание рублем почему-то сразу открывает новые технические возможности.
А в РФ амазон работал бы иначе, судя по https://gazeta.ru/business/2011/02/24/3535105.shtml
Интересно, есть ли уже какие-то решения, которые отслеживают биллинг/провиженинг в реальном времени, чтобы если не остановить сервисы, то хотя бы уведомить клиента?
В том же GCP, насколько знаю, биллинговые данные попадают в bigquery, оттуда можно как-то мониторить. Ну и тот же cloud pub/sub с уведомлениями — но опять же, насколько вовремя они туда попадают?
Вообще выглядит все так (особенно после прочтения статьи по ссылке) не стоит пользоваться сервисами, у которых возможности явно указать верхний лимит по апскейлу (если вы не мегакорпорация, которая готова платить миллионы за обработку скачкообразной нагрузки).
Те же кубы и виртуалки вполне себе легко посчитать + явно задаются лимиты автоскейлинга. А вот эти модно-молодежные лямбды и фаербейзы — работа "по волшебству" имеет две стороны медали — нужно меньше Ops, но и не понятно, когда сколько реального потребления и сколько придется заплатить.
Вопрос: а почему бы не подключить тариф с безлимитной или пакетной лимитной нагрузкой, а не с оплатой за операции поштучно?
Интересно, есть ли уже какие-то решения, которые отслеживают биллинг/провиженинг в реальном времени, чтобы если не остановить сервисы, то хотя бы уведомить клиента?
Насколько понимаю, все внешние решения пользуются billing data от хостера, то есть быстрее не получится.
А вот эти модно-молодежные лямбды и фаербейзы — работа «по волшебству» имеет две стороны медали — нужно меньше Ops, но и не понятно, когда сколько реального потребления и сколько придется заплатить.
+1
Да, конечно есть. Наша компания как раз этим и занимается. Одним из первых фичеров который зашёл нашим клиентам был как раз «риал-тайм» биллинг. Мы динамически опрашивали прайсинг амазона и считали на нашей стороне сколько сжигает клиент и оповещали об аномалиях. Название компании публиковать не буду, чтобы не подумали что это реклама
Переписка с саппортом успехом не увенчалась. Вариантов решения от них всего два. Либо потанцевать со сменой имейла на потребительском аккаунте, что б получить доступ к оригинальному AWS. Либо заблокировать платежи в банке, типа аккаунт автоматически закроется. С аккаунтом что-либо делать на своей стороне они наотрез отказались. Видите ли требования безопасности такие. *тут меня уже трясти начинает*
Но вскоре банковскую карту пришлось заблокировать по другому поводу. И вот тут началось самое интересное. Амазон исправно каждый месяц шлет, что я им должен 80 центов. И если я не оплачу, то аккаунт закроется. А аккаунт не закрывается. После переписки с саппортом, в которой они опять мне предлагали потанцевать со ссменой имейла, до них таки дошло, что у них система сбоит. Пообещали исправить, но опять пришли письма об оплате. Я их переслал саппорту. Но надежды нет. Скорее всего поставлю спам фильтр.
Тех. поддержка некоторых корпораций просто ужасна. С одной стороны у вас товар примут обратно без вопросов, без чека, в любом состоянии, даже если возврату не подлежит. А с другой стороны «Компьютер говорит нет».
С корпорациями всё понятно — штат разработчиков и админов, которые и посчитают, и настроят, и код напишут без ошибок, приводящих к увеличению биллинга (на самом деле нет). Но главное — $70k для них мелочь, заплатят ни не поперхнутся, ну разве что лишат премии виновника.
А вот у середнячков и мелочи все иначе — задачи, требования и возможности там иные. Во многих случаях хватило бы и On-Premise и VDS. К тому же экономическая выгода и окупаемость для небольших проектов, мягко говоря, не очевидны. Но реклама настаивает, что весь цивилизованный мир давно в облаках, открой бесплатный аккаунт, мол не пожалеешь.
В общем, смысл такой — нужно определиться заранее где облако необходимо, а где без него можно (и нужно) обойтись.
Нет, это НЕ интересный вопрос. Какой-то странный образ у вас "облаков". Вы вообще с ними работали?
Суть моего поста — есть некий проект Х, что для него выгоднее — использовать инфраструктуру On-Premise, либо развернуть VDI с необходимой инфраструктурой у хостера с фиксированной оплатой, либо развернуть тот же VDI в Azure/AWS, либо использовать специфические облачные механизмы (типа того же Serverless/Lambda), которые вне облака уже использовать невозможно.
Готовы сходу дать такую экспертизу по любому проекту?
Подобные заявления были бы к месту 10-20 лет назад, но не когда этот вопрос обсосан со всех сторон и с позиции практически каждого провайдера. Не знаю кому и что вы там писали, но вопрос даже близко не от человека который хотя бы просто знаком с этой сферой.
VDI своими силами точно будет разворачивать сильно дороже.
Это взрослые штуки для взрослых компаний, с юристами бухгалтериами кучей спецов и тд. например нетфликс.
Конечно это крайне неудобно и несправедливо!!! А кто обещал справедливость?
Куча бизнесов работаю по схемам похлеще этой, продажа бутилированной воды из под крана например.
Реклама, в том числе и проф кругах сделала свое дело все считают амаон = дешево… =)))))))))
Ник то же не хочет платить деньги(например админу, не говоря уже о том что бы сервер купить), вот вас и разводят на деньги супер професионалы, акулы бизнеса.
«Плати сколько скажут». Вопрос по ограничению счёта AWS остаётся неотвеченным 10 лет