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

Когда COVID появился на рынке в марте 2020 года, наш стартап Milkie Way также сильно пострадал и был практически закрыт. Мы сожгли 72 000 долларов за несколько часов, изучая и проводя внутреннее тестирование Cloud Run с Firebase.

Я начал разработку Announce https://announce.today в ноябре 2019 года, когда у меня появилась идея. Целью было создать функциональную «MVP» версии 1 продукта, поэтому наш код был основан на простом стеке. Мы используем JS, Python и развертываем наши продукты в Google App Engine.

Наша команда очень маленькая, и мы сосредоточены на написании кода, разработке пользовательского интерфейса и подготовке продукта. Я потратил минимальное время на управление облаком, которого было достаточно, чтобы запустить нас и провести базовый процесс разработки (cicd).

Пользовательский опыт в веб-приложении V1 был не самым плавным, но мы просто хотели сделать что-то, что наши пользователи могли бы опробовать, пока мы создавали улучшенную версию Announce. Поскольку Covid достигает мира, мы подумали, что это идеальное время для внесения изменений, поскольку правительства могут использовать Announce для объявлений по всему миру.

Разве не было бы здорово иметь на платформе богатые данные, даже если пользователи вообще не создают контент? Эта идея привела к созданию другого проекта под названием Announce-AI. Цель — создать богатый контент для автоматической публикации. Богатые данные == события, предупреждения о безопасности, такие как землетрясения, и, возможно, новости местного значения.

0

Некоторые уроки по техническим деталям

Чтобы начать разработку Announce-AI, мы использовали Cloud Functions. Поскольку наши боты еще не умеют сканировать Интернет, мы решили, что облегченные облачные функции — это лучший вариант. Однако когда мы решили масштабироваться, мы столкнулись с проблемой, поскольку у облачных функций был тайм-аут около 9 минут.

До сих пор мы узнали об Cloud Run, который имеет огромный уровень бесплатного использования. Не до конца понимая это, я попросил свою команду развернуть объявленную «тестовую» функцию искусственного интеллекта в Cloud Run и посмотреть, как она работает. Наша цель — поэкспериментировать с Cloud Run, чтобы мы могли по-настоящему изучить и изучить его.

Google Cloud Run

Для простоты, поскольку наш эксперимент проводится для очень небольшого сайта, мы используем Firebase для хранения базы данных, поскольку у Cloud Run нет хранилища, и развертываем ее на SQL Server или любой другой базе данных для тестового запуска. убийство.

Я создал новый проект GCP ANC-AI Dev, установил бюджет облачных счетов в размере 7 долларов США и оставил проект Firebase на бесплатном плане (Spark). Если мы потерпим неудачу, худшее, что мы можем себе представить, — это превышение бесплатного дневного лимита Firestore.

Повозившись с некоторым кодом, мы развернули его и потратили полдня вручную, делая несколько запросов, проверяя логи, выставляя счет за несколько минут его запуска, а затем начался настоящий ад.

1

Кошмар начинается

В день тестирования все прошло хорошо, и мы вернулись к стадии анонса разработки. На следующий день, закончив работу, я вздремнул ближе к вечеру. Проснувшись, я прочитал несколько писем от Google Cloud, отправленных с разницей в несколько минут.

Первое письмо: Автоматические обновления для проектов Firebase

Второе письмо: Превышение бюджета

К счастью, на моей карте установлен лимит расходов в 100 долларов. В результате обвинения были сняты, а Google приостановила работу всех наших аккаунтов.

Третье письмо: Карта отклонена.

Я вскочил с кровати, вошел в систему Google Cloud Billing и увидел счет на сумму около 5000 долларов. Очень напряженный и неуверенный в том, что происходит, я огляделся вокруг, пытаясь понять, что происходит. Я также начал думать о том, что могло произойти и как мы могли бы «возможно» оплатить счет в 5 тысяч долларов.

Проблема в том, что счет растет с каждой минутой.

Через 5 минут на счете было 15 000 долларов, а через 20 минут - 25 000 долларов. Я не уверен, где это заканчивается. Может быть, это не остановится?

Два часа спустя его цена составила чуть менее 72 000 долларов.

К этому времени я и моя команда разговаривали по телефону, и я был в состоянии полного шока и совершенно не представлял, что делать дальше. Во время этого процесса мы отключили выставление счетов и отключили все услуги.

Поскольку мы используем одну и ту же карту компании для всех проектов GCP, все наши учетные записи и проекты были заблокированы Google.

2

Кошмар продолжается

Это произошло вечером в пятницу, 27 марта, за три дня до запланированного выпуска Announce V1. Поскольку Google приостановил все проекты, связанные с одной и той же кредитной картой, наши усилия по разработке продуктов зашли в тупик. Мой моральный дух был низким, а будущее нашей компании было неопределенным.

Разработка всех наших облачных проектов приостановлена;

Как только мой разум примирился с этой новой реальностью, около полуночи, я сел, чтобы разобраться в том, что происходит. Я начал писать документ с подробным описанием всех расследований... Я назвал этот документ «Глава 11».

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

На следующий день, в субботу, 28 марта, я позвонил и написал по электронной почте дюжине юридических фирм, чтобы назначить встречу/пообщаться с некоторыми адвокатами. Все они ушли, но мне удалось получить ответ от одного из них по электронной почте. Поскольку детали происшествия настолько сложны даже для инженера, объяснить это юристу на простом английском языке — само по себе непростая задача.

Как самофинансирующаяся компания, мы не смогли собрать 72 тысячи долларов.

К этому времени я уже хорошо разбирался в главе 7 и главе 11 закона о банкротстве и был полностью готов к тому, что может произойти дальше.

3

Дыхание Дыхание: уязвимость GCP

В субботу после того, как я написал своему адвокату по электронной почте, я начал читать больше и изучать каждую страницу документации GCP. Мы допустили ошибку, но не имеет смысла, что Google раньше стоил нам 72 000 долларов, даже не заплатив.

GCP и Firebase

1. Автоматически обновите учетную запись Firebase до платной.

Когда мы подписывались на Firebase, об этом никогда не думали, и это никогда не было показано. В нашем проекте GCP для выполнения Cloud Run подключена оплата, но для Firebase используется бесплатный план (Spark). GCP сразу обновила его и взяла с нас столько, сколько нам было нужно.

Оказывается, это их процесс из-за «глубокой интеграции Firebase и GCP».

2. Платежный «лимит» не существует. Бюджет задерживается как минимум на один день.

Фактически законопроект GCP был отложен как минимум на день. Google рекомендует использовать бюджеты и облачные функции автоматического отключения в большей части своей документации. Ну, угадайте, что к тому времени, когда сработает функция прерывания или пользователь облака будет уведомлен, ущерб уже может быть нанесен.

Расчет занимает около суток, поэтому списание мы заметили на следующий день.

3. Google должен взимать с нас 100 долларов, а не 72 тысячи долларов!

Поскольку на сегодняшний день оплата по нашему счету не произведена, GCP должна сначала снять с вас 100 долларов США на основании платежной информации, а затем прекратить предоставление услуги, если оплата не будет произведена. Но это не так. Позже я понял причину, но это все равно не вина пользователя!

Первый счет на нашем счету составил примерно 5000 долларов. Цена следующей продажи составит 72 000 долларов.

В нашем аккаунте порог платежа составляет 100 долларов США.

4. FirebaseПанель управления возможнаОченьненадежный

На обновление не только биллинга, но и панели управления Firebase ушло более 24 часов.

Согласно документации Firebase Console, номер панели управления Firebase Console может немного отличаться от отчета «Биллинг».

В нашем случае разница составляет 86 585 365,85%, или 86 миллионов процентных пунктов. Даже после получения уведомления о счете на панели управления консоли Firebase по-прежнему сообщалось, что за месяц было выполнено 42 000 операций чтения и записи (ниже дневного лимита).

4

Новый день, новые задачи

Проработал около 6,5 лет в Google и написал многочисленные проектные документы, отчеты о вскрытии, а затем документ, который был передан в Google, в котором описывается инцидент и суммируются уязвимости со стороны Google постфактум. Команда Google возобновит работу через 2 дня.

РЕДАКТИРОВАТЬ: Некоторые читатели предложили мне использовать свои внутренние контакты в Google. Дело в том, что я ни с кем не поддерживал связь и использовал методы, которые использовал бы любой нормальный разработчик/компания. Как и любой другой небольшой разработчик, я провожу бесчисленные часы в чатах, запросах, длинных электронных письмах и ошибках. В моей следующей статье о том, как справиться с инцидентом, я хотел бы поделиться документацией и отчетом о вскрытии, отправленными в Google во время этого инцидента.

Последний день Google

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

Как сотрудник Google, я сталкивался с ошибками команд, которые стоили Google миллионы долларов, но культура Google спасала сотрудников (инженерам приходилось писать длинные отчеты об инцидентах). На этот раз Google нет. Наши собственные ограниченные средства и наш тяжелый труд находятся под полной угрозой.

5

Что мы на самом деле сделали?

Как небольшая команда, мы хотим оставаться как можно более бессерверными. Проблема бессерверных решений, таких как Cloud Functions и Cloud Run, заключается в тайм-аутах.

В любой момент экземпляр будет постоянно сканировать веб-страницу по этим URL-адресам. Но вскоре через 9 минут время истекает.

После обсуждения проблемы и приема кофеина, через несколько минут у меня на доске появился сухой код, и теперь я увидел множество проблем с дизайном, но в то время мы были больше сосредоточены на неудачах, быстром обучении и попытке чего-то нового.

Версия ИИ «Hello World» анонсирована на Cloud Run

Чтобы преодолеть ограничение по времени ожидания, я рекомендую отправлять задание в один экземпляр с помощью запроса POST (с URL-адресом в качестве данных) и использовать несколько экземпляров параллельно вместо последовательного использования одного экземпляра. Поскольку каждый экземпляр Cloud Run обрабатывает только одну страницу, время его обработки никогда не истекает, все страницы обрабатываются параллельно (масштабируются), а поскольку использование Cloud Run выполняется с точностью до миллисекунды, оно также высоко оптимизировано.

Парсер развернут в Cloud Run

Если присмотреться, в этом процессе отсутствуют некоторые важные части.

1. Экспоненциальная рекурсия без перерывов: у экземпляра нет времени перерыва, поскольку нет оператора прерывания.
2. POST-запросы могут иметь один и тот же URL-адрес. Если есть обратная ссылка на предыдущую страницу, сервис Cloud Run застрянет в бесконечной рекурсии, но что хуже всего, эта рекурсия растет в геометрической прогрессии (у нас максимальное количество экземпляров установлено на 1000!).

Как вы можете себе представить, это приводит к тому, что 1000 экземпляров отправляют запросы и записывают данные в базу данных Firebase каждые несколько миллисекунд. Глядя на события публикации данных, мы видим, что скорость чтения Firebase в какой-то момент составляла около 1 миллиарда запросов в минуту!

Сводка транзакций на конец месяца для платежного аккаунта GCP

116 миллиардов операций чтения и 33 миллиона операций записи

Запустив эту версию развертывания Hello World в Cloud Run, она прочитала 116 миллиардов раз и записала 33 миллиона раз в Firestore. Ой!

Прочтите об эксплуатационных расходах на Firebase:

（0.06 / 100,000）* 116,000,000,000 = 69,600

16 000 часов компьютерного времени в облаке

После тестирования мы предположили, что запрос завершился, поскольку прекратилось логирование, но на самом деле он ушел в фоновый процесс. Поскольку мы не удалили службу (это был наш первый раз, когда мы использовали Cloud Run и в то время мы мало что знали о ней), многие службы продолжали работать медленно.

В течение 24 часов эти версии службы были масштабированы до 1000 экземпляров каждая, что потребовало 16 022 часа.

6

все наши ошибки

Развертывание ошибочных алгоритмов в облаке

Уже обсуждалось выше. Мы нашли новый способ использования бессерверных технологий через POST-запросы, который я не смог найти нигде в Интернете, но он был реализован без улучшения алгоритма.

Развертывание облачного запуска с использованием параметров по умолчанию

При создании сервиса Cloud Run мы выбрали в сервисе значение по умолчанию. Для max-instances установлено значение 1000, а для параллелизма — 80. Вначале мы понятия не имели, что эти значения на самом деле являются худшим случаем для тестовой программы.

Если мы выберем max-instances как «2», то наша стоимость уменьшится в 500 раз. На купюре в 72 000 долларов первоначально было написано: 144 доллара.

Если мы выберем «1» для одновременных запросов, мы можем даже не заметить счет.

Использование Firebase без полного понимания Firebase

Некоторым вещам можно научиться только с большим опытом. Firebase — это не язык, который можно выучить, это контейнерная платформа, предоставляемая Google. У него есть правила, которые определяются ими, а не законами природы или тем, что может подумать конкретный пользователь.

Также при написании кода на Node.js необходимо уделять внимание фоновым процессам. Если код переходит в фоновый процесс, у разработчиков нет простого способа узнать, что служба работает, но это может занять значительное время. Как мы узнали позже, именно поэтому время ожидания большинства наших облачных функций также истекает.

Быстро терпит неудачу и быстро учиться через облако — плохая идея

Облако в целом похоже на палку о двух концах. Он может быть полезен при правильном использовании, но может иметь последствия при неправильном использовании.

Если посчитать количество страниц в документации GCP, то, вероятно, их больше, чем в нескольких романах. Понимание цен и использования не только отнимает много времени, но и требует глубокого понимания того, как работают облачные сервисы. Неудивительно, что для этой цели существуют штатные вакансии!

Firebase и Cloud Run действительно мощные инструменты

На пике своего развития Firebase могла обрабатывать примерно 1 миллиард операций чтения в минуту. Это невероятно мощно. Мы играем с Firebase уже 2-3 месяца и до сих пор изучаем его, но до сих пор я совершенно не представлял, насколько он мощный.

То же самое касается Cloud Run! Concurrency == 60, max_containers == 1000, каждый запрос занимает 400 миллисекунд, а количество запросов Cloud Run может обрабатывать 9 миллионов запросов в минуту!

60 * 1000 * 2,5 * 60 = 9 000 000 запросов в минуту

Для сравнения, поисковые запросы Google получают 3,8 миллиона запросов в минуту.

Использование облачного мониторинга

Хотя Google Cloud Monitoring не прекращает выставление счетов, он отправляет оповещения своевременно (с задержкой примерно в 3–4 минуты). Для понимания архетипа/структуры именования Google Cloud требуется некоторое обучение, но как только вы потратите на это некоторое время, информационные панели, оповещения и показатели сделают жизнь проще.

Эти метрики доступны только в течение 90 дней, и мы потеряли их из-за этого инцидента (в наши дни использование Firebase и Cloud Run кардинально меняется), в противном случае я был бы рад поделиться ими в этой статье.

7

мы все еще живы

Но это очень тревожно, слишком тревожно

Внимательно прочитав отчет об этом инциденте, а также после серии консультаций, обсуждений и внутренних исследований, Google напрямую отказался от нашего счета!

Спасибо, Гугл!

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

Google — моя любимая технологическая компания не только потому, что в ней приятно работать, но и потому, что к ней много сочувствия. Google предоставляет инструменты, удобные для разработчиков, серьезно относится к качеству документации (по большей части) и постоянно развивается. (Примечание автора: это всего лишь мой личный опыт как независимого разработчика программного обеспечения, и это ни в коем случае не мягкая статья или намеренная лесть.)

8

Что дальше?

После этого инцидента мы потратили несколько месяцев на понимание облака и нашей архитектуры. Через несколько недель мое понимание настолько улучшилось, что я прикинул стоимость парсинга «всей сети» с помощью Cloud Run с улучшенным алгоритмом.

Этот инцидент заставил меня глубоко проанализировать архитектуру продукта и отказаться от версии V1 продукта, чтобы создать масштабируемую инфраструктуру для поддержки продукта.

В Announce V2 мы не просто создали MVP; Мы создали платформу, на которой мы можем быстро итеративно разрабатывать новые продукты и тщательно тестировать их в безопасной среде.

Этот процесс занял у нас некоторое время... объявлено в конце ноября, примерно на 7 месяцев позже, чем мы решили для версии 1, но она хорошо масштабируется, получает лучшие облачные сервисы и ориентирована на использование с высокой оптимизацией.

Мы также запустились на всех платформах, а не только в Интернете.

Что еще более важно, мы повторно использовали всю платформу для создания нашего второго продукта — Point Address. Оба продукта не только масштабируемы, имеют отличную архитектуру и эффективность, но также построены на платформе, которая позволяет нам быстро создавать идеи и воплощать их в работающий продукт.

Перепечатка от: Судип Чаухан