Когда пользователь попросил отменить платёж
На Хабре публиковались истории пользователей 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.
Автор: Анатолий Ализар
