Для чего нужен google cloud
История о том, как мы оказались на грани банкротства, не успев даже запустить первый продукт, как нам удалось выжить и какие уроки мы извлекли.
В марте 2020 года, когда COVID поразил весь мир, наш стартап Milkie Way тоже сильно пострадал и почти закрылся. Мы сожгли 72 000 долларов во время изучения и внутреннего тестирования Cloud Run с Firebase в течение нескольких часов.
Я начал разработку сервиса Announce в ноябре 2019 года. Главная цель состояла в выпуске минимально функциональной первой версии продукта, поэтому код работал на простом стеке. Мы использовали JS, Python и развернули наш продукт на Google App Engine.
С очень маленькой командой мы сосредоточились на написании кода, разработке пользовательского интерфейса и подготовке продукта. Я практически не тратил времени на управление облаком — потратил ровно столько, чтобы поднять систему и обеспечить базовый процесс разработки (CI/CD).
Десктопный Announce
Первая версия была не очень удобной, но мы просто хотели выпустить версию для экспериментов, а потом уже работать над нормальной. В связи с COVID мы подумали, что сейчас хорошее время для запуска, поскольку государственные службы по всему миру могут использовать Announce для публикации оповещений.
Разве не здорово сгенерировать на платформе немного данных, когда пользователи ещё не закачали свою информацию? Эта мысль привела к появлению другого проекта Announce-AI для генерации контента. Богатые данные — это различные события, такие как оповещения о землетрясениях и, возможно, релевантные местные новости.
Некоторые технические детали
Для начала разработки Announce-AI мы использовали Cloud Functions. Поскольку наш бот для скрапинга был ещё на начальной стадии, мы решили взять эти легковесные функции. Но при масштабировании возникли проблемы, потому что у облачных функций тайм-аут около 9 минут.
И вдруг мы узнали о системе Cloud Run, у которой тогда был большой лимит бесплатного использования! Не разобравшись полностью, я попросил команду развернуть «тестовую» функцию Announce-AI в Cloud Run и оценить её производительность. Цель состояла в том, чтобы поиграться с Cloud Run для накопления опыта.
Google Cloud Run
Поскольку у нас очень маленький сайт, то для простоты мы использовали БД Firebase, так как у Cloud Run нет никакого хранилища, а деплой SQL Server или другую БД слишком чрезмерен для теста.
Я создал новый проект GCP ANC-AI Dev, настроил бюджет облачного биллинга на 7 долларов, сохранил проект Firebase по бесплатному плану (Spark). Худший вариант, который мы представляли, — это превышение ежедневного лимита Firebase.
После некоторых модификаций мы подготовили код, сделали несколько запросов вручную, а затем оставили его работать.
Кошмар начинается
В день тестирования всё прошло нормально, и мы вернулись к разработке Announce. На следующий день после работы ближе к вечеру я пошёл слегка вздремнуть. Проснувшись, я увидел несколько писем из Google Cloud, все с интервалом в несколько минут.
Первое письмо: автоматический апгрейд нашего проекта Firebase 
Второе письмо: бюджет превышен 
Третье письмо: карта отклонена 
Проблема была в том, что с каждой минутой счёт продолжал расти.
К этому времени мы с командой были на телеконференции, я был в полном шоке и не имел абсолютно никакого понятия, что делать дальше. Мы отключили биллинг, закрыли все сервисы.
Поскольку во всех проектах GCP мы рассчитывались одной картой, все наши учётные записи и проекты были приостановлены.
Кошмар продолжается
Все наши облачные проекты приостановлены, разработка остановлена
Как только разум смирился с новой реальностью, в полночь я решил нормально разобраться, что же произошло. Я начал составлять документ с подробным расследованием инцидента… и назвал его «Глава 11» [это глава из закона о банкротстве — прим. пер.].
Двое коллег, участвовавших в эксперименте, тоже не спали всю ночь, исследуя и пытаясь понять, что произошло.
На следующее утро, в субботу 28 марта, я позвонил и написал письма десятку юридических фирм, чтобы записаться на приём или поговорить с адвокатом. Все они были в отъезде, но я смог получить ответ от одного из них по электронной почте. Поскольку детали инцидента настолько сложны даже для инженеров, объяснить это адвокату на простом английском языке было само по себе непросто.
К этому времени я уже хорошо изучил 7-ю и 11-ю главы закона о банкротстве и мысленно готовился к тому, что может произойти дальше.
Некоторая передышка: лазейки GCP
GCP и Firebase
1. Автоматический апгрейд аккаунта Firebase на платный аккаунт
Мы такого не ожидали, и об этом нигде не предупреждалось при регистрации на Firebase. Наш биллинг GCP был подключён к исполнению Cloud Run, но Firebase шла под бесплатным планом (Spark). GCP просто ни с того ни с сего провела апгрейд на платный тариф и взяла с нас необходимую сумму.
Оказывается, этот процесс у них называется «глубокая интеграция Firebase и GCP».
2. Биллинговых «лимитов» не существует. Бюджеты запаздывают минимум на сутки
Выставление счетов GCP фактически задерживается как минимум на сутки. В большинстве документов Google предлагает использовать бюджеты и функцию автоматического отключения облака. Но к тому времени, когда сработает функция отключения или пользователю пришлют уведомление, ущерб уже будет нанесён.
Синхронизация биллинга занимает около суток, именно поэтому мы заметили счёт на следующий день.
3. Google должен был взять 100 долларов, а не 72 тысячи!
Поскольку с нашего аккаунта до сих пор не проходило никаких платежей, GCP должен был сначала взять плату в размере 100 долларов в соответствии с платёжной информацией, а при неуплате — прекратить услуги. Но этого не произошло. Я понял причину позже, но это тоже не по вине пользователя!
4. Не полагайтесь на панель управления Firebase!
Не только биллинг, но и обновление панели управления Firebase заняло более 24-х часов.
Согласно документации Firebase Console, цифры в панели управления могут «незначительно» отличаться от отчётов биллинга.
В нашем случае они отличались на 86 585 365,85%, или 86 миллионов процентных пунктов. Даже когда пришёл счёт, панель управления Firebase Console ещё показывала 42 000 операций чтения и записи в месяц (ниже дневного лимита).
Новый день, новый вызов
Отработав шесть с половиной лет в Google и написав десятки проектных документов, отчётов с расследованиями событий и много другого, я начал составлять документ для Google, описывая инцидент и добавляя лазейки со стороны Google в отчёт. Команда Google вернётся на работу через два дня.
Поправка: некоторые читатели предположили, что я использовал свои внутренние контакты в Google. На самом деле я ни с кем не общался и выбрал путь, по которому пошёл бы любой нормальный разработчик или компания. Как и любой другой мелкий разработчик, я проводил бесчисленные часы в чате, за консультациями, составлением длинных электронных писем и сообщений об ошибках. В одной из следующих статей, посвящённой составлению отчётов об инцидентах, я покажу документы, которые отправил в Google.
Последний день в Google
Кроме того, нужно было понять наши ошибки и разработать стратегию развития продукта. Не все в команде знали об инциденте, но было совершенно ясно, что у нас большие неприятности.
В Google я сталкивался с человеческими ошибками ценой в миллионы долларов, но культура Google спасает сотрудников (за исключением того, что инженерам приходится потом сочинять длинные отчёты). На этот раз Гугла не было. На карту поставлен наш собственный маленький капитал и наша тяжёлая работа.
Стойкие Гималаи нам говорят…
В то время у меня работала команда из семи инженеров и стажёров, и Google требовалось около десяти дней, чтобы ответить нам по поводу этого инцидента. Тем временем мы должны были возобновить разработку, найти способ обойти приостановку счетов. Несмотря на всё, мы должны были сосредоточиться на функциях и нашем продукте.
Стихотворение «Стойкие Гималаи нам говорят»
Почему-то у меня в голове постоянно крутилось одно стихотворение из детства. Это была моя любимая книга, и я помнил её слово в слово, хотя в последний раз читал более 15 лет назад.
Что мы на самом деле сделали?
Будучи очень маленькой командой, мы хотели как можно дольше воздержаться от расходов на аппаратное обеспечение. Проблема Cloud Functions и Cloud Run заключалась в тайм-ауте.
Один инстанс будет постоянно скрапить URL-адреса со страницы. Но через 9 минут наступит тайм-аут.
Тогда вскользь обсудив проблему, я за пару минут набросал на доске сырой код. Теперь понял, что у того кода была масса архитектурных недостатков, но тогда мы стремились к быстрым циклам исправления ошибок, чтобы стремительно учиться и пробовать новые вещи.
Концепт Announce-AI на Cloud Run
Чтобы преодолеть ограничение тайм-аута, я предложил использовать POST-запросы (с URL в качестве данных) для отправки заданий в инстанс и — запускать параллельно несколько инстансов, а не составлять очередь для одного. Поскольку каждый инстанс в Cloud Run скрапит только одну страницу, тайм-аут никогда не наступит, все страницы будут обрабатываться параллельно (хорошее масштабирование), а процесс высоко оптимизирован, поскольку использование Cloud Run происходит с точностью до миллисекунд.
Скрапер на Cloud Run
Если присмотреться, в процессе не хватает нескольких важных деталей.
Сводка транзакций на конец месяца для GCP
116 миллиардов операций чтения и 33 миллиона записей
Экспериментальная версия нашего приложения на Cloud Run сделала 116 миллиардов операций чтения и 33 миллиона записей в Firestore. Ох!
Стоимость операций чтения на Firebase:
16 000 часов работы Cloud Run
После тестирования из остановки логов мы сделали вывод, что запрос умер, но на самом деле он ушёл в фоновый процесс. Поскольку мы не удалили сервисы (мы первый раз использовали Cloud Run, и тогда действительно не понимали этого), то несколько сервисов продолжали медленно работать.
За 24 часа все эти службы на 1000 инстансах отработали в общей сложности 16 022 часа.
Все наши ошибки
Деплой ошибочного алгоритма в облаке
Уже обсуждалось выше. Мы действительно обнаружили новый способ бессерверного использования POST-запросов, который я не нашёл нигде в интернете, но задеплоили его без уточнения алгоритма.
Деплой Cloud Run с параметрами по умолчанию
При создании службы Cloud Run мы выбрали в ней значения по умолчанию. Максимальное число инстансов 1000, а параллелизм — 80 запросов. Мы не знали, что эти значения на самом деле наихудший сценарий для тестовой программы.
Если бы мы выбрали max-instances=2, затраты были бы в 500 раз меньше.
Если бы установили concurrency=1, то даже не заметили бы счёт.
Использование Firebase без полного понимания
Кое-что понимаешь только на опыте. Firebase — это не язык, который можно выучить, это контейнерная платформа. Её правила определены конкретной компанией Google.
Кроме того, при написании кода на Node.js нужно подумать о фоновых процессах. Если код уходит в фоновые процессы, разработчику нелегко узнать, что служба работает. Как мы позже узнали, это ещё и стало причиной большинства таймаутов наших Cloud Functions.
Быстрые ошибки и быстрые исправления — плохая идея в облаке
Облако в целом похоже на обоюдоострый меч. При правильном использовании он может быть очень полезен, но при неправильном — пеняй на себя.
Если посчитать количество страниц в документации GCP, то можно издать несколько толстенных томов. Чтобы всё понять, в том числе тарификацию и использование функций, требуется много времени и глубокое понимание, как работают облачные сервисы. Неудивительно, что для этого нанимают отдельных сотрудников на полный рабочий день!
Firebase и Cloud Run действительно мощны
На пике Firebase обрабатывает около миллиарда считываний в минуту. Это исключительно мощный инструмент. Мы играли с Firebase уже два-три месяца — и всё ещё открывали новые аспекты, но до того момента я понятия не имел, насколько мощная это система.
То же самое относится и к Cloud Run! Если установить количество параллельных процессов 60, max_containers == 1000, то при запросах по 400 мс Cloud Run может обрабатывать 9 миллионов запросов в минуту!
Для сравнения, поиск Google обрабатывает 3,8 миллиона запросов в минуту.
Используйте мониторинг
Хотя Google Cloud Monitoring не остановит биллинг, он отправляет своевременные оповещения (задержка 3-4 минуты). Поначалу не так просто освоить терминологию Google Cloud, но если вы потратите время, то панель мониторинга, оповещения и метрики немного облегчат вашу жизнь.
Эти метрики доступны только в течение 90 дней, у нас они уже не сохранились.
Мы выжили
Фух, пронесло
Изучив наш длинный отчёт об инциденте, описывающий ситуацию с нашей стороны, после различных консультаций, бесед и внутренних обсуждений, Google простила нам счёт!
Спасибо тебе, Google!
Мы схватили спасательный круг и использовали эту возможность, чтобы завершить разработку продукта. На этот раз — с гораздо лучшим планированием, архитектурой и намного более безопасной реализацией.
Google, моя любимая технологическая компания, — это не просто отличная компания для работы. Это также отличная компания для сотрудничества. Инструменты Google очень удобны для разработчиков, имеют отличную документацию (по большей части) и постоянно расширяются.
(Примечание: это моё личное мнение как индивидуального разработчика. Наша компания никоим образом не спонсируется и не связана с Google).
Что дальше?
После этого случая мы потратили несколько месяцев на изучение облака и нашей архитектуры. За несколько недель моё понимание улучшилось настолько, что я мог прикинуть стоимость скрапинга «всего интернета» с помощью Cloud Run с улучшенным алгоритмом.
Инцидент заставил меня глубоко проанализировать архитектуру нашего продукта, и мы отказались от той, что была в первой версии, чтобы построить масштабируемую инфраструктуру.
Во второй версии Announce мы не просто создали MVP, мы создали платформу, на которой могли быстрыми итерациями разрабатывать новые продукты и тщательно тестировать их в безопасной среде.
Это путешествие заняло немало времени… Announce запущен в конце ноября, примерно через семь месяцев после первой версии, но он очень масштабируемый, берёт лучшее из облачных сервисов и высоко оптимизирован.
Мы также запустились на всех платформах, а не только в интернете.
Более того, мы повторно использовали платформу для создания нашего второго продукта — Point Address. Он тоже отличается масштабируемостью и хорошей архитектурой.
Путеводитель по экосистеме Google Cloud
Содержание
В семейство Google Cloud входят приложения для совместной работы команды, множество сервисов для создания цифровых продуктов, аренды виртуальных мощностей или построения гибридной инфраструктуры. Кроме того, сторонними разработчиками созданы готовые решения, дополняющие это семейство. Запутаться легко. В этой статье вы сможете узнать, из каких именно частей состоит экосистема Google Cloud.
G Suite
Пакет облачных сервисов, который включает все, что может потребоваться рядовому сотруднику. Это полностью готовое рабочее место, доступное удаленно с любого устройства.
В состав G Suite входят:
Инструменты для общения
Функционал для совместной работы
Решения для хранения информации и ее поиска
Инструменты управления
Google Cloud Platform GCP
Облачная инфраструктура Google Cloud Platform. Является базой для таких высокоскоростных глобальных сервисов, как Gmail, Карты, YouTube и Поиск, а также дает возможность работать с различными инструментами для вычислений и хостинга. Google Cloud Platform (GCP) состоит из трех самостоятельных направлений: GCP как Iaas, GCP как PaaS и Google Maps Platform.
Сервисы для создания цифровых продуктов и разработки GCP как PaaS
Большинство из них базируется на технологии нейронных сетей.
Auto ML Vision
API-сервис, позволяющий создавать модели для распознавания изображений, в котором от пользователей не требуется знаний специфических алгоритмов машинного обучения. В основе технологии – предобученные нейронные сети. На основе имеющихся данных происходит автоматическое определение и классификация новых признаков.
Google Speech API
Сервис распознавания голоса, который позволяет преобразовать речь в текст. Этот сервис используется как прикладной для функции голосового ввода в GoogleDocs и G-suite, популярный Google Assistant на смартфонах также основан на этой технологии. Инструмент считается лучшим в своей области.
Cloud video intelligence
Сервис для поиска и обнаружения медиаконтента. Позволяет распознавать большие объемы видео, точно определять кто, что и на какой минуте появилось в кадре. Осуществляет поиск по видеокаталогу, анализирует видеоархив и расставляет тэги по запросу.
Google Dataprep
Служба, позволяющая обрабатывать и структурировать большое количество данных для их анализа. В графическом интерфейсе отображается искомая информация по заданным критериям.
Cloud spanner
Управляемая реляционная база данных как сервис – полностью консистентная и горизонтально масштабируемая. Если раньше поиск по базе данных осуществлялся легко, только если она была локальной, то в данном сервисе получать актуальные данные можно в любое время в любых частях света.
Apigee
Сервис для управления API. Сервис берет на себя роль посредника между разработчиком и пользователями, позволяет управлять созданными API.[ЯЛ4]
Корпоративная экосистема Chrome
Партнерские приложения
Приложения и системы, созданные сторонними разработчиками с учетом особенностей экосистемы Google Cloud и дополняющие ее функционал. Таких приложений бесконечно много. В качестве примера можно привести CRM-систему Salesforce и сервис для создания корпоративных порталов LumApps.
SalesForce
Одна из наиболее популярных CRM-систем, показывающая отличные результаты при работе с облачными решениями Google. Интеграционное решение позволяет взаимодействовать с клиентами Gmail непосредственно в Salesforce и сопоставлять данные из двух систем, чтобы быстрее обслуживать клиентов. Работа в календаре, таблицах, документах, встречи в Hangouts, происходят в общей облачной среде и не требуют от менеджеров постоянного переключения между сервисами.
Порталы LumApps
Облачное корпоративное пространство, которое объединяет сотрудников компании. Оно отображает актуальную информацию, необходимую для работы, представляет из себя главный центр коммуникации в компании. На портале размещаются корпоративные новости, личная информация, социальные сообщества и командные проекты.
Почему не следует пользоваться Google Cloud
Дополнение (2 июля 2018 г): сотрудники поддержки Google Cloud Platform (GCP) заверили, что такое больше не повторится. Их слова: «Многие люди (в рамках GCP) заинтересованы в том, чтобы улучшить ситуацию не только для вас, но для всех клиентов».
Примечание: это пост не о качестве облачных сервисов Google. Они превосходны, наравне с AWS. Речь идёт о «резких движениях без предупреждения», когда они полностью отключают все ваши системы, если сотрудники (или машины) вдруг решили: что-то не так. C нами это случилось второй раз.
Предыстория
Что случилось
Сегодня рано утром (28 июня 2018 года) я получил предупреждение от аптайм-бота, что весь сайт ушёл в офлайн. Шквал писем от Google, в которых говорится, что обнаружена некая «потенциальная подозрительная активность» и все мои системы были отключены. ВСЁ ВЫКЛЮЧЕНО. МАШИНА ОТКЛЮЧИЛА НАС БЕЗ ПРЕДУПРЕЖДЕНИЯ. Сайт не работает, движок приложений и базы данных недоступны, несколько сообщений от Firebase говорят, что меня понизили и поэтому произошло превышение лимитов.
Одинокое облачко
Чат поддержки клиентов выключен. Телефона у нас нет. Пришло электронное письмо с просьбой заполнить форму, загрузить фотографию кредитной карты и ID государственного образца с фотографией владельца карты. Отлично, разбудим финансового директора, который является владельцем карты.
Мы удалим проект в течение трёх рабочих дней
«Мы удалим ваш проект, если владелец счёта не исправит нарушение, заполнив форму подтверждения аккаунта в течение трёх рабочих дней. Эта форма подтверждает вашу личность и право собственности на платёжный инструмент. Непредставление запрошенных документов может привести к окончательному закрытию счёта».
Что делать, если владелец карты в отпуске и недоступен в течение трёх дней? Мы потеряли бы всё — годы работы — миллионы долларов дохода.
Я заполняю форму с деталями и, к счастью, в течение 20 минут все сервисы начали возвращаться к жизни. Когда это случилось в первый раз, даунтайм продлился несколько часов. В целом мы потеряли доступ ко всей информации примерно на час. Приходит автоматическое письмо с извинениями за причинённые неудобства. К сожалению, у машины нет понятия о количестве «неудобств».
Нельзя просто всё отключить, а затем попросить объяснений
Я понимаю, что Google нужно отслеживать и предотвращать подозрительную активность. Но важно, что именно вы делаете после обнаружения подозрительной активности. Здесь необходимо человеческое участие — то, что не заменяется ни на какое количество кода или систему ИИ. Нельзя просто всё отключить, а затем попросить объяснений. Нужно делать наоборот.
Это первый проект, который мы полностью построили на Google Cloud. Все предыдущие работали на AWS. По нашему опыту, AWS гораздо гуманнее справляется с проблемами выставления счетов. Они предупреждают вас о подозрительной деятельности и дают время, чтобы объяснить и разобраться. Они не пинают тебя с лестницы.
Надеюсь, что команда GCP прислушается и поменяет ситуацию к лучшему. До тех пор я никогда не буду размещать никакие проекты на GCP.