Когда пользователь попросил отменить платёж
На Хабре публиковались истории пользователей AWS, которые случайно «влетали» на тысячи долларов. Грубо говоря, просыпаешься на утро — а за ночь виртуальные машины масштабировались и накрутили сумасшедшие деньги. Или по итогам месяца неожиданно приходит дикий счёт.
По этой причине пользоваться облачными сервисами немного страшновато: вы не можете спрогнозировать нагрузку и расходы.
Казалось бы, ситуацию можно легко исправить, если установить лимит на максимальный бюджет или твёрдый лимит на ресурсы.
Но Amazon специально этого не делает, несмотря на жалобы клиентов. Проблема отслеживается ещё с 2011 года.
13 января 2011 года на форумах AWS пользователь задал вопрос о том, каков текущий статус по разработке функции ограничения на максимальный размер счёта:
Дорогой Amazon,
Вы делаете отличный сервис S3, он позволяет небольшим разработчикам использовать хранение мирового класса с оплатой по мере использования. Единственная часть, которой, на мой взгляд, не хватает, — это функции ограничения на максимальный размер счёта.
Сообщество просило об этом много раз, и вы обещали эту функцию, но она застряла на много лет. Я знаю, что ограничение счетов можно сделать путём программирования на нашей стороне (через проверку логов и/или подписанные URL), но я не считаю это подходящим решением. Это должна быть нативная функция.
Лимит на счета снизит риск для небольших разработчиков, которых хостинг S3 может буквально разорить. Такой контроль над счётом замкнёт логический цикл, и после этого я даже не могу придумать причину, почему кто-то откажется от использования S3.
Итак, мой вопрос сводится к следующему. Если функция запланирована, то когда она появится? Если она никогда не появится, мне очень жаль, но, пожалуйста, официально подтвердите это.
Заранее спасибо за любой ответ. Кстати, вот как эта функция может работать, на мой взгляд:
- Лимит устанавливается на максимальную сумму в месяц для бакета
- Когда достигается лимит, объекты из бакета прекращают выдаваться
- При первом достижении лимита в течение месяца пользователь получает уведомление
- Хотя объекты не выдаются, но входящие запросы всё равно генерируют трафик сами по себе. Поэтому вполне нормально продолжать взимать плату за каждую 1000 запросов.
Вопрос не отвечен до сих пор, то есть более десяти лет…
Очевидно, Amazon или не может, или не хочет разрабатывать эту функцию. С одной стороны, разработать биллинг в реальном времени практически невозможно. Биллинг всегда работает с опозданием.
С другой стороны, можно притвориться, что биллинг в реальном времени существует, внедрить функцию и решать все спорные вопросы в пользу клиента. То есть когда биллинг с опозданием регистрирует нагрузку сверх лимита, с клиента не возьмут лишних денег.
К чему приводит отсутствие лимита и как можно влететь на деньги — например, рассказывалось в статье «Как мы случайно сожгли $72 000 за два часа в Google Cloud Platform и чуть не обанкротились». Это типичная история, а не какой-то редкий случай. Google Cloud тут ничем не отличается от AWS в смысле отсутствия лимитов.
Вот как это было у автора:
И вдруг мы узнали о системе Cloud Run, у которой тогда был большой лимит бесплатного использования! Не разобравшись полностью, я попросил команду развернуть «тестовую» функцию Announce-AI в Cloud Run и оценить её производительность. Цель состояла в том, чтобы поиграться с Cloud Run для накопления опыта.
Поскольку у нас очень маленький сайт, то для простоты мы использовали БД Firebase, так как у Cloud Run нет никакого хранилища, а деплой SQL Server или другую БД слишком чрезмерен для теста.
Я создал новый проект GCP ANC-AI Dev, настроил бюджет облачного биллинга на 7 долларов, сохранил проект Firebase по бесплатному плану (Spark). Худший вариант, который мы представляли, — это превышение ежедневного лимита Firebase.
После некоторых модификаций мы подготовили код, сделали несколько запросов вручную, а затем оставили его работать.
Хотя в тестовый день система работала нормально, но Announce-AI продолжала генерировать запросы. Впоследствии было обнаружено много архитектурных изъянов в коде, из-за чего система начала быстро масштабироваться из-за экспоненциальной рекурсии в создании инстансов Cloud Run.
В общем, на следующий день произошёл автоматический апгрейд аккаунта Firebase на платный аккаунт. В сумме по итогу экспериментальная версия приложения на Cloud Run сделала 116 миллиардов операций чтения и 33 миллиона записей в Firestore. Стоимость операций чтения в Firebase: $0,06 за 100 000, так что получается $69 600 за операции чтения. Всё честно.
То же самое происходит на AWS с некоторыми сервисами — автоматический апгрейд на платный аккаунт. Для многих пользователей это происходит неожиданно. Добавьте экспоненциальный рост нагрузки — и вот результат.
Самое главное, что на AWS биллинговых лимитов не существует. Для сравнения, в Google Cloud они есть, на Azure тоже есть (не для всех аккаунтов). Хотя лимит срабатывает с опозданием примерно в сутки. Имеется в виду лаг между дорогой нагрузкой и записью её стоимости. Зачастую это критический лаг, потому что десятки тысяч долларов можно «спалить» за несколько часов, как в истории выше. Ну, а на AWS нет вообще никаких лимитов, даже с опозданием в сутки. Есть только лимиты по умолчанию на максимальное использование ресурсов, но они довольно большие и не спасут от тысячных счетов.
Можно, конечно, как-то защититься. Например, ограничить максимальный размер платежа по кредитной карте в банке. Но это не снимет с вас огромный долг перед AWS, см. обсуждение «Что будет, если не оплатить счет AWS?» в разделе вопросов и ответов на Хабре. Человек открыл бесплатный аккаунт, привязал карту с 1 долларом на счету, а вскоре обнаружил, что с него пытаются снять $1500.
В принципе, это хороший сценарий. Если такое произошло — закрываем аккаунт, блокируем карту и навсегда забываем об этой истории. Amazon точно не обратится в российский суд (или украинский, а тем более белорусский). А вот у резидентов западных стран могут возникнуть проблемы, наверное.
Таким образом, когда регистрируемся на AWS или Google Cloud, сразу предполагаем произвольный биллинг. Счёт может прийти совершенно дикий даже на бесплатном аккаунте. Лучше заранее подстраховаться от такого развития событий — см. выше про карту с 1 долларом.
Кроме того, полезно использовать мониторинг с оповещениями: у них задержка в пару минут, так что вы успеете среагировать на экстренное увеличение нагрузки.
По теме:
«Как я умудрился за 1 день задолжать Amazon 12000$»
«Как защититься от неожиданных счетов за AWS»
«Почему не следует пользоваться Google Cloud»
На правах рекламы
Подыскиваете VDS с прозрачной и понятной тарификацией для разработки и размещения своих проектов? Вы точно наш клиент :) Посуточная тарификация серверов, создавайте собственную конфигурацию в несколько кликов, антиDDoS включен в стоимость.
Подписывайтесь на наш чат в Telegram.
numitus2
Все просто. Эта фича уменьшит прибыли и поэтому нет смысла ее реализовывать
maxbl4
В очередной раз обсасывается эта тема. Да, если настроить неограниченное масштабирование можно попасть на деньги. Но даже в статье написана правда: практически невозможно сделать биллинг в реальном времени.
Вот у вас один маленький аккаунт S3, который стоит положим 0.001 цента за операцию и ваше маленькое приложение делает всего 100 операций в минуту. Это значит, что только для вашего приложения Амазон должен 100 раз в минуту сделать запись в базу биллинга, пересчитать сколько вы потратили и проверить ваши лимиты. То есть автоматом, ваш аккаунт начинает работать в среднем в два раза медленее (ведь надо и в аккаунт записать и в биллинг) и так во всех сервисах.
А теперь прикинем, что есть премиум аккаунты, которые должны уметь выдавать 100к операций в секунду. Физически невозможно, чтобы такие аккаунты выдавали метрику по цене на каждый запрос и чтобы эта метрика в реальном времени проверялась против лимита расходов.
Не знаю как в AWS, Azure для всех автомасштабирований требует указать лимит в единицах измерения сервиса. То есть для виртуальной машины в количестве ядер, для базы данных в гигабайтах и так далее. Может показаться, что это не столь удобно как в деньгах. Но это недоубно, только если вы пришли первый раз и хотите просто поиграться и сами не особо понимаете чего конкретно хотите. Если же вы создаёте даже маленькое, но приложение с конкретной целью, то вы более или менее представляете какие ресурсы будут нужны вашему приложению и наоборот удобнее указать лимиты в ресурсах. Azure вам сразу покажет сколько это примерно будет стоить в деньгах и будет списывать эту сумму равномерными долями
DaneSoul
maxbl4
На сколько я знаю, работа в этом направлении идёт и уже есть сервисы с поминутным биллингом
TheSprightlyDuke
Так ведь одна из веток поста о том, что у них уже лет 10, как идёт. Но для клиента воз и ныне там. Если не напутал ничего.
celebrate
Есть сервисы и с посекундным биллингом, только что толку, если этот самый биллинг станет доступен спустя сутки? Об этом статья.
numitus2
Нужна защита от дурака. Если я заказываю себе поменять дверь или окно за 200$ это не должно приводить к убыткам в десятки тысяч долларов из-за какой-то опечатки или непонимания. Пусть даже почасовая оплата будет. Даже так нельзя десятки тысяч долларов убытков получить. И должны быть вменчемые лимиты. А снятие лимитов должно происходить только после подписания договора с клиентом, а не для любого пользователя . Почему-то Амазон может выводить поминутную статистику использования лимитов. А вот умножить число инстансов на тариф не может. Как и все западные сервисы он оптимизирован для вытягивания денег, а не для удобства пользователя, поэтому описанные выше фичи не будут реализованы никогда
maxbl4
Amazon, как и другие облачные сервисы оптимизирован для больших клиентов, у которых траты в месяц тысячи долларов. Мелкие разработчики, с бюджетами в 10$ в месяц не дают никакой значительной прибыли. Не надо облака сравнивать с мобильными донат играми
OnYourLips
Однако многие будут внедрять в стартапы именно те облака, с которыми они знакомы.
Хоть месячные счета в таких кампаниях будут небольшими, в среднем в пару тысяч долларов, но их достаточно много.
N-Cube
Чтобы получить у Амазон виртуальную машину с 4TB+ оперативки надо писать в поддержку и пояснять, для чего потребовалось. Чтобы получить у Гугл больше 12 ядер на их бесплатном пакете в 300$ надо тоже писать… и все равно лимит не увеличат, даже если деньги на счету есть и этот стартовый пакет все равно не используется:) и так далее.
JSFilin
Да, но и на 3.99ТБ RAM можно быстро разориться.
saboteur_kiev
А что бы при масштабировании получить сотню виртуальных машин с 64 гб оперативки, ничего не надо.
darken99
Насколько я помню вы и одну машину на 64гб оперативки без поднятия лимита не запустите, что как раз и сделано для того, чтобы вы имея 2 бакса на карте не попали на пару десятков тысяч.
nixtonixto
Если вас выпустить из автошколы без инструктора, то вы можете устроить аварию или даже кого-то убить. Но это же не значит, что отныне вы должны всегда ездить с инструктором, и жить с мамой. Пора учиться брать ответственность на себя и решать проблему лавинообразного нарастания запросов на СВОЕЙ стороне — ежеминутно наблюдать за приложением, трафиком и балансом счёта, и немедленно исправлять обнаруженные ошибки. AWS за всеми вами тяжело уследить.
gecube
это чушь. Потому что входящий трафик вы не контролируете. Можно представить себе ситуацию, что конкуренты решили дешевыми инстансами нагенерить на своей стороне трафика и пустить его на ваш сервис — и ничего вас не спасет. Либо ваш сервис ляжет, либо Амазон вас отскалирует верх. Самый плохой сценарий — когда будет и то, и то (клиенты все равно будут недовольны, а Амазон срубит кучу денег). Вставать за защиту — вариант, но не абсолютный, увы.
saboteur_kiev
Так он это и так делает — счета то выставляются.
Тут надо не делать запись, а делать проверку, и ее можно делать даже не на каждое действие, а раз в 10 запросов, раз в 100 запросов, раз в час.
N-Cube
Как все быстро забыли, что еще 15-20 лет назад у всех или почти всех местечковых провайдеров интернет биллинг вообще раз в месяц считался. И если среди месяца провайдер звонил — значит, мы опять выбрали весь его лимит у вышестоящего провайдера и дело плохо. Впрочем, это обычно решалось балансировкой трафика — надо было восстановить нужное соотношение входящего к исходящему для обнуления тарифа. Так все мои друзья-админы тех времен сейчас облака манной небесной по удобству тарификации считают:) И я с ними согласен.
netch80
При наличии желания это решается очень просто. Например, на ресурс задаётся предел темпа потребления в деньгах или пропорциональных им условных попугаях. Дальше производится локальный для ресурса учёт, который проверяется по базе и сливается в неё раз в K минут. И опять же делается остановка потребления при снижении общего акаунта ниже некоторой предельной суммы (причём по умолчанию я бы вообще ставил ноль, и давал минус только при показе платёжеспособности...)
Да. Посмотрели на счёт — есть на ближайшие 5 минут ещё 300$? разрешили на такой темп. Есть только 20$? Разрешили только 20000 операций, а дальше стоп. Раз в 5 минут выдержит любой подобный биллинг.
Тут, конечно, интересный вопрос — что, если даже типов таких ресурсов штук 20 и проверка на каждом будет независимой. Но если дать ставить галочку "допускать только если денег есть на все ресурсы с гарантией" или "можно опускать с учётом всех запасов до -200$" — уже все пострадавшие и потенциально пострадавшие будут благодарны.
Если это не делают — как сказано в статье — причина одна: явное нежелание делать то, на чём потеряют возможность дрючить "лохов" (термин, увы, адекватный тут).
densol92
И повышает репутационные издержки, мотивирует разработчиков меньше пробовать продукты AWS. Я, например, прочитав много таких историй, никогда не пробую продукты которых не знаю, и большую часть времени работы с AWS пытаюсь понять сколько это будет стоить и где могу влететь на деньги.
Areso
Да такое много где есть, просто где-то больше, где-то меньше.
Я как-то влетел на деньги в GCP. Создал небольшой инстанс, всё было хорошо.
Потом пришли люди (боты?) из Китая, и внезапно оказалось, что с ВМ идёт трафик («в комплекте»), но у этого «в комплекте»* есть звездочка. И там, помимо прочих условий, указывались регионы, откуда (и куда) трафик всегда платный. Независимо от его количества. Китай, Океания, еще кто-то там…
Lexicon
Там есть подводный камень с тем, что истории обычно "хорошо" заканчиваются, поддержка amazon идет на встречу, причем не только к хардкорным компаниям, но даже разработчикам-одиночкам. В моем опыте прощали даже откровенно и точно пожранные нами ресурсы, в следствии ошибок devops или вовсе забытые.
Мой опыт с amazon напротив закрепил лояльность к ним, как частника и как представителя компании. Вроде как очевидно, что лимит решил бы ряд страхов, но с другой стороны такой уровень урегулирования и помощи предоставляет далеко не каждый провайдер.
Вот ценообразование и "калькулятор стоимости" жуть