Cloud run что это
Cloud Run VS Cloud Functions: What’s the lowest cost?
In my previous story, Gabriel Flores asked me about cost comparison. Indeed, choosing a solution from a technical point of view is important, but the cost of a service isn’t to forget because, in auto scaling environment, it can blow up without warning.
The comparison performed in only based on the pricing and Quotas & limits of each product. The performance of processing are supposed equals in both solutions.
Cloud Functions
Cloud functions pricing is based on the vCPU in GHz/s and the memory in Gb/s, rounded up to the nearest 100ms. The specificity of functions is that you can adjust the memory and the CPU speed, but not separately. Both are linked, increase the memory if you want more MHz and vice versa
Cloud Run (managed)
Cloud Run pricing is based on vCPU/s and the memory in Gb/s, rounded up to the nearest 100ms. It’s not possible to use partial vCPU per instance. Your instance has always 1 vCPU assigned. Memory can be adjusted from 128Mb to 2Gb
An instance can handle up to 80 concurrent request. Thereby, for a given instance, you are only charged when at least one request is being processed by the instance.
Network egress is based on Network Premium Tier pricing after 1Gb of free tier.
Summary
Cloud Functions allow to adjust the vCPU speed accordingly with the memory used. But can handle only 1 request per instance.
Cloud Run always use 1 vCPU; you can only adjust the memory. But Cloud Run can process concurrent requests on the same instance.
Finally the cost of the number of requests is strictly the same.
By the way, we can consider 2 main cases of comparison: With only 1 concurrent request, and with several concurrent requests.
I built a GSheet for playing with memory, concurrency and process requirement values.
One concurrent request case
In this case, only the processing of 1 request is compared. In this case, Cloud Run and Cloud Functions have exactly 1 instance up for processing this unique request, and thus only this instance is charged.
This case can happen if you set the currency to 1 in Cloud Run, or if you have sparse and sequential requests to your service.
Thereby, in the same condition, with 1 vCPU (2.4Ghz) and 2Gb of memory, the pricing and the performance are strictly the same between Cloud Run and Cloud Functions.
Several concurrent requests case
Most of time, a service handles several requests in the same time. Cloud Run has the capability to handle up to 80 concurrent requests with the same instance.
At the opposite, Cloud Functions create as many instances as the concurrent requests.
Thereby, more you can process request concurrently with Cloud Run, cheaper is the service
What to consider?
The best choice depends on what you want to optimize, your use-cases and your specific needs.
Lowest latency
If your objective is the lowest latency, choose Cloud Run.
Indeed, Cloud Run use always 1 vCPU (at least 2.4Ghz) and you can choose the memory size from 128Mb to 2Gb.
With Cloud Functions, if you want the best processing performance (2.4Ghz of CPU), you have to pay 2Gb of memory. If your memory footprint is low, a Cloud Functions with 2Gb of memory is overkill and cost expensive for nothing.
Lowest cost
Cutting cost is not always the best strategy for customer satisfaction, but business reality may require it. Anyway, it highly depends of your use-case
Both Cloud Run and Cloud Function round up to the nearest 100ms. As you could play with the GSheet, the Cloud Functions are cheaper when the processing time of 1 request is below the first 100ms. Indeed, you can slow the Cloud Functions vCPU, with has for consequence to increase the duration of the processing but while staying under 100ms if you tune it well. Thus less Ghz/s are used and thereby you pay less.
For example, with a low processing requirement (20Mhz required) that required only 128Mb of memory, you have:
Sure, Cloud Functions is 10 times cheaper, but your customers wait 10 times more. And this pricing comparison is true ONLY if you have sequential requests.
In this example, with more than 10 concurrent requests, Cloud Run is cheaper! Indeed, Cloud Run handles up to 80 concurrent requests on the same instance before creating (and billing) a new one.
At opposite, Cloud Functions handles concurrent requests on different instances, and thus, you have to pay each running instance in addition of the cold start overcost for each instance created.
There is an other case where Cloud Functions are cheaper and where it’s a good idea to slow the vCPU: When an app calls APIs and waits the responses. Having a function with 200Mhz is enough and a full vCPU of Cloud Run is overkill (for no or few processing) and thereby expensive.
Instance limitation
In the Limitation and Quota page of each product, the number of parallel instances is limited to 1000.
However, it’s possible to set a custom upper bound to limit the number of parallel instances. Initially released for limiting resource usage (for example, database connection), it’s also a great functionality to limit expenses and to set the upper bound of your service cost. But always with a negative impact on user satisfaction in case of saturation.
Events handling
Cloud Functions can be triggered by HTTP requests (called HTTP Functions) but also by events triggered on the Google Cloud environment (called Background Functions)
At the opposite, Cloud Run containers can be only called by HTTP requests. However, it’s possible to use PubSub push subscription for pushing PubSub events to be processed by Cloud Run. In addition, it’s also possible to publish Storage event to PubSub topic and thus, to process Storage events with Cloud Run again through a PubSub push subscription. But, no more.
Thereby, except for PubSub and Storage events, Cloud Functions are unavoidable for all others types of events. No choice possible.
VPC connection requirement
Your serverless app can require some private resources only available in your VPC. For example, a memory store for low latency key-value storage, or a VPN/direct connect access for reaching external resources (OnPremise or on other cloud).
Cloud Functions allow to set up a VPC connector for connecting your serverless functions to your VPC, and thus to route the traffic as required.
Until now, it’s not possible with managed Cloud Run but it will change in 2020.
What to choose?
Before my conclusion, I would like to add some additional considerations, not directly linked to the platform pricing, but also in the whole process of development, serving, and monitoring.
Additional thoughts on cost
When you choose a technical solution, it’s important to take into account all the pieces of the project, and first of all your human resources. Cloud Functions seem cheaper because your use case fit them well. But, is your team is able to develop functions in the available languages?
In my company, our legacy stack (and expertise) was PHP and C++ and this not fit with Cloud Functions capability. That’s why, containers were our choice, even before Cloud Run product exists.
All these reasons are, most of time, far more expensive than the cloud provider cost.
Application criticality
In November 2019, Cloud Run turns to GA after 6 month of Beta.
Cloud Functions are in GA for Python 3, Node 8 and Go 1.11
Apparently, there no difference in term of Google commitment between the 2 products. However, if your app run on Python 3.8, Node 10/12 or Go 1.12/1.13, there is no GA version on Cloud Functions (or even not support at all!). With Cloud Run, the GA commitment is applied on all containers, independently of the version of the language in it.
Limits and Quotas
There is few differences between the 2 services but they can imply organizational change or technical solution design redesign. This is indirect cost but to take into account if you plan to deploy hundreds of Cloud Functions with a high rollout velocity.
Indeed, Cloud Functions are limited to 1000 functions per project, and to 120 minutes of compilation per days and per project.
In Cloud Run, there is no limit on compilation because it’s performed outside the platform, and there is the same limit of 1000 services per project. BUT a service can serve several endpoints.
Other limits are hard to compare or are not relevant for a large majority of projects.
Conclusion
As you can see, the cost comparison between Cloud Functions and Cloud Run goes further than simply comparing a pricing list. Moreover, on your projects, you often will have to use the 2 solutions for taking advantage of their strengths and capabilities.
My first choice for development is Cloud Run. Its portability, its testability, its openess on the libraries, the languages and the binaries confer it too much advantages for, at least, a similar pricing, and often with a real advantage in cost but also in performance, in particular for concurrent requests. Even if you need the same level of isolation of Cloud functions (1 instance per request), simply set the concurrent param to 1!
In addition, the GA of Cloud Run is applied on all containers, whatever the languages and the binaries used.
However, some reasons, VPC capabilty or eventing, can force you to choose Cloud Functions, but, most of time, it won’t be for a pricing reason.
Finally, the variety of use-cases, differences in organization and the complexity of human resources (skills, wishes, motivations) generate too many combinaisons and I can only provide tips, and things not to forget in your decision process. It’s not possible to provide a unique answer.
In any case, be sure to choose the right partner, with an external point of view, to help you in this journey, talk with your teams and try by yourself for finding the best answer to your use cases!
Google Cloud Run — Deploying Containerized Applications to a Serverless Environment ⚡
Cloud Run is a managed compute platform that enables you to run stateless containers.
Cloud Run is serverless: it abstracts away all infrastructure management, so you can focus on what matters most — building great applications.
It is built from Knative, letting you choose to run your containers either fully managed with Cloud Run, or in your Google Kubernetes Engine cluster with Cloud Run on GKE.
In this article, we would:
Setup Cloud Shell
I will be using Google Cloud Shell to manage resources on Google Cloud Platform with an assumption that you have it installed on your PC.
is your GCP project ID.
Demo Project files and Dockerfile
Feel free to use your own project files.
We would not be building our Docker image on our PC, Google Cloud Build allows us to build a Docker image using a Dockerfile, which we already have and then pushes the image to Container Registry 😊
Build Docker Image with Cloud Build and Push to Google Container Registry
Let’s use Google Cloud Build to build our Docker image and push the image to Container Registry. Both can be done by simply running the following command:
That’s it! We have our Docker image built and now on Container Registry.
Deploy to Cloud Run from Google Container Registry
We could either deploy from Cloud Shell or directly from Container Registry Interface.
Deploying from Cloud Shell
We’ll be asked to input Service name and some other options. On success, you’ll get the Service URL 😀
Deploying from Container Registry Interface
Click on the Image Name and Deploy the latest by selecting Deploy to Cloud Run on the list of options.
We’ll also need to define the Service name and authentication option.
Cloud Run does not charge when the service is not in use.
You can use a custom domain rather than the default address that Cloud Run provides for a deployed service.
Cloud Run also runs on Google Kubernetes Engine — this gives you more flexibility on managing your infrastructure. The tweet below gives more insights on this.
Thanks for reading through! Let me know if I missed any step, if something didn’t work out quite right for you or if this guide was helpful.
История о том, как мы оказались на грани банкротства, не успев даже запустить первый продукт, как нам удалось выжить и какие уроки мы извлекли.
В марте 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. Он тоже отличается масштабируемостью и хорошей архитектурой.