Cloud Run на VPS: когда постоянный процесс выгоднее serverless

Прежде чем открывать калькулятор цен, откройте график нагрузки своего приложения за сутки. Не среднее за месяц и не число запросов в сумме, а именно кривую: где она лежит почти ровно, где пустует, где подпрыгивает. Рекламная цена за миллион запросов описывает единицу измерения, а счёт определяется формой кривой. Два приложения с одинаковым числом запросов в месяц могут стоить на Cloud Run совершенно по-разному, и ровно так же по-разному они ведут себя на виртуальном сервере.

Эта статья про то, как прочитать такой график и понять, в какой момент постоянный процесс на VPS начинает выигрывать у модели «платим, пока обрабатываем». И в какой момент не начинает. Никаких готовых цен здесь не будет: тарифы меняются, а скидки бывают индивидуальными. Будут формы нагрузки, логика расчёта и список вопросов, ответы на которые вы возьмёте из собственных метрик и актуальных прайсов.

Две суточные кривые, у которых одинаковая сумма

Возьмём два условных приложения. Цифры ниже выдуманы для иллюстрации и не являются замерами: они нужны, чтобы увидеть механику.

Приложение А — внутренний портал и вебхуки. Днём, в рабочие часы, приходит несколько запросов в минуту, ночью тишина, иногда за секунду прилетает пачка вебхуков от внешней системы, после чего снова пауза. Каждый запрос выполняется за десятки миллисекунд. Из 24 часов процессор по-настоящему занят, допустим, несколько минут суммарно.

Приложение Б — API мобильного клиента с очередью. Запросы идут круглосуточно с умеренными колебаниями: днём чуть больше, ночью чуть меньше, но никогда не ноль. Параллельно крутится воркер, который забирает задачи из очереди, отправляет уведомления и пересчитывает агрегаты. Процессор занят заметную долю суток, и пауз, достаточных, чтобы что-то «остыло», практически нет.

Пусть суммарное число запросов у них в месяц одинаково. Для серверной модели с постоянным процессом это почти не важно: сервер у вас один и тот же, он стоит одинаково. Для модели, где платят за обработку, разница огромна: у приложения А оплачиваемого времени мало, потому что большая часть суток просто не тарифицируется, а у приложения Б оплачиваемое время растягивается почти на всю сутки.

Первый вывод простой: вопрос «что дешевле» некорректен без вопроса «когда приложение вообще что-то делает». Приложение А — классический кандидат на оплату по факту работы, приложение Б платит за простор, которым почти не пользуется, и постоянный процесс окупается.

Что на самом деле тарифицируется: запрос или жизнь экземпляра

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

Из этого следует практическая развилка, а не тонкость мелким шрифтом. Если ваш код после ответа клиенту продолжает что-то делать (досылает письмо, обновляет кэш, обрабатывает буфер), то вам нужна именно та модель, в которой процессор доступен вне запроса. А в ней вы платите за всё время жизни экземпляра, и дешёвое «платим только за миллисекунды» исчезает. Тем самым для приложения Б самый удобный для кода режим Cloud Run по логике оплаты приближается к аренде постоянного процесса, только с другой ценой за ресурс и с другими удобствами.

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

Прогрев, минимальные экземпляры и цена тишины

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

Для расчёта это даёт три разных режима жизни приложения.

• Минимум равен нулю. В тишине вы не платите за простаивающий экземпляр, но первый запрос после паузы приходит на свежий контейнер. Ему приходится ждать запуск вашего приложения. Для приложения А с вебхуками это обычно терпимо: внешняя система повторит запрос или подождёт. Для интерактивного интерфейса, где человек смотрит на крутилку, задержка заметна.
• Минимум больше нуля. Вы покупаете готовность: хотя бы один экземпляр уже стоит с запущенным процессом. Холодный старт на первом запросе уходит, но вы платите за тишину. Денежно это уже ближе к арендованному серверу, только без доступа к операционной системе и с другим набором ограничений.
• Резкий пик после паузы. Масштабирование не мгновенно: пока поднимаются новые экземпляры, часть запросов ждёт. Приложению с редкими, но синхронными всплесками (рассылка, открытие продаж по таймеру) нужен либо запас готовых экземпляров, либо терпимость к задержкам.

Теперь посмотрим на тот же вопрос со стороны VPS. Постоянный процесс прогрет всегда: соединения с базой открыты, кэши заполнены, интерпретатор или JIT уже разогнались. Холодного старта как явления нет, пока вы не перезапускаете процесс сами. Платите вы за то, что сервер занят целиком и всегда, независимо от того, пришёл ли хоть один запрос. Если нагрузка ровная, эта «вечная» плата распределяется на большой объём работы и удельная цена работы падает. Если нагрузка редкая, вы платите за пустую комнату.

Отсюда удобное правило для самопроверки. Выпишите, сколько часов в сутки при настройке «минимум больше нуля» вы бы держали готовые экземпляры. Если ответ «почти все», то аргумент «платим только за работу» уже не про вас, и дальше стоит считать честно, сравнивая два режима постоянной готовности.

Фоновая работа: где живёт то, что делается после ответа

Фоновые задачи — вторая причина, по которой нагрузка на график выглядит спокойнее, чем есть на самом деле. Запросов может быть мало, а процессор занят: пересчёт отчётов, обработка загруженных файлов, синхронизация с внешними API, периодические чистки.

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

1. Разделить. Веб-часть остаётся сервисом, а тяжёлые периодические операции переносятся в задания. Тогда редкая, но тяжёлая работа не заставляет держать дорогую постоянную готовность у сервиса.
2. Собрать в один процесс. Веб-сервер, воркер очереди и планировщик живут вместе на одном сервере. Это проще в отладке и эксплуатации, и на VPS такой вариант естественен: ресурсы одного сервера делятся между задачами, а пустое место одной задачи занимает другая.

Второй вариант выигрывает именно там, где пики разных задач не совпадают по времени. Ночью воркер пересчитывает агрегаты, днём тот же процессор обслуживает запросы. Вы оплачиваете один набор ядер, а использование его близко к равномерному. В модели с отдельными экземплярами под каждую роль вы платите за каждую роль по её собственной формуле, и общего «простоя, который закрыт чужой работой» нет.

Отдельно стоит учесть особенность файловой системы. Как указано в контракте контейнера, локальная файловая система в Cloud Run находится в памяти: записанное расходует память экземпляра и пропадает при его остановке. Если ваше приложение складывает временные файлы, кэш миниатюр или промежуточные выгрузки на диск, на Cloud Run это превращается в расход оперативной памяти, а долговечные данные придётся выносить во внешнее хранилище. На VPS у вас обычный диск, и такой же код работает без переделки. Это не плюс и не минус само по себе, но это строка в смете: перенос приложения с временными файлами в серверную модель часто убирает отдельную работу, а перенос в обратную сторону её добавляет.

Сколько ресурсов нужно собственному постоянному процессу

Допустим, график показал, что постоянный процесс имеет смысл. Как прикинуть размер сервера, не выдумывая бенчмарк? Исходить надо из собственных метрик, а не из чьих-то обещаний. Нужны четыре числа.

• Пиковая память одного процесса. Не среднее, а максимум под нагрузкой, включая кэши и буферы. Если приложение в контейнере ограничено лимитом памяти, этот лимит и есть первая оценка.
• Загрузка процессора в час пик. Сколько ядер реально занято, а не сколько выделено. Если в пике занято меньше одного ядра, большие конфигурации вам не нужны.
• Число одновременных процессов. Веб, воркер, планировщик, обратный прокси, база данных, если она стоит рядом. Складывайте их память, а не берите максимум.
• Запас. Операционной системе, обновлениям, журналам и вашему желанию спокойно подключиться по SSH во время пика нужна свободная память и процессор.

Пример с условными числами. Веб-процесс занимает в пике 400 МБ, воркер 300 МБ, обратный прокси около 50 МБ, система и служебные демоны ещё несколько сотен мегабайт. Суммарно получается порядка 1,2–1,5 ГБ при полной загрузке. Под такой профиль логично смотреть на конфигурацию с запасом по памяти относительно этой суммы, например с 2–4 ГБ. Это иллюстрация метода, а не рекомендация и не обещание ёмкости: настоящее число даёт ваш мониторинг.

Для ориентира: у VPS MAATRIX линейка конфигураций идёт от Ba (1 vCPU, 2 ГБ RAM, 40 ГБ NVMe) и Uab (2 vCPU, 4 ГБ, 80 ГБ) до Heka (4 vCPU, 8 ГБ, 160 ГБ), Maat (8 vCPU, 16 ГБ, 240 ГБ) и Djed (16 vCPU, 32 ГБ, 320 ГБ). Диски NVMe, процессоры AMD EPYC, доступ root. Эти параметры помогают сопоставить ваши замеры с вариантами, но не говорят, сколько запросов выдержит именно ваше приложение: это выясняется только нагрузочной проверкой на вашем коде и данных.

Полезно мыслить ступенями. Если приложение умещается в Ba или Uab с запасом, разница в абсолютной стоимости между облаком и сервером может оказаться небольшой, и решение примут удобство и привычки команды. Если вам нужны Heka и выше, а трафик ровный, разница в цене за единицу работы становится заметнее, и посчитать её стоит особенно аккуратно.

Предел одновременных запросов: почему он меняет число серверов

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

На VPS эту роль играет вы сами, и она проявляется в настройках процесса: число рабочих процессов или потоков веб-сервера, размер пула соединений с базой, длина очереди. Типичные ловушки здесь такие:

• слишком много рабочих процессов для объёма памяти: пик приходит, память кончается, система начинает убивать процессы;
• слишком большой пул соединений с базой, который задавит саму базу, если она стоит на том же сервере или в ограниченном по соединениям сервисе;
• слишком маленькое число рабочих процессов, из-за чего процессор простаивает, а запросы ждут в очереди.

Практичный способ подобрать значения: снять профиль одного запроса (сколько процессорного времени и сколько ожидания), прикинуть число рабочих процессов по числу ядер для процессорных запросов и сделать его заметно больше для запросов с ожиданием. Затем проверить под нагрузкой, держится ли память и что происходит с задержкой в хвосте распределения. Важный эффект: на одном сервере у вас есть жёсткий потолок, а в облаке потолок раздвигается ценой счёта. На ровной нагрузке потолок не мешает. На резком пике, кратно превышающем обычный уровень, потолок превращается в проблему: либо недозагруженный сервер большую часть времени, либо очередь в пик.

Обслуживание как строка сметы

Постоянный процесс на VPS означает, что за систему отвечаете вы. Это не обязательно тяжёлая работа, но она существует и должна попасть в расчёт честно, в виде времени, а не в виде нуля.

• Обновления операционной системы и зависимостей, перезагрузки с учётом простоя.
• Мониторинг: диск, память, процессор, жизнь процесса, срок действия сертификатов.
• Перезапуск процесса при сбое и политика, что делать, если сервер не отвечает.
• Резервные копии данных: в сведениях о предложении MAATRIX автоматические копии во всех тарифах не заявлены, поэтому план копирования и проверку восстановления нужно предусмотреть самостоятельно.

В облачной платформе значительная часть этих задач берёт на себя провайдер, и это реальная ценность, которую нельзя сводить к нулю в расчёте. Если у команды нет человека, который готов раз в месяц тратить час-два на сервер, а остальное время держать на связи, то экономия на аренде легко съедается стоимостью одного инцидента. Если такой человек есть и ему в целом нравится такая работа, добавленная стоимость обслуживания невелика.

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

Вычисления отдельно, данные отдельно

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

Когда вы переносите только вычислительную часть, нужно ответить на несколько вопросов:

• Где будет жить база. Если она остаётся в облачном управляемом сервисе, а процесс переезжает на VPS, добавляются сетевые задержки между площадками, возможная плата за исходящий трафик и вопросы доступа по сети. Если база переезжает вместе с процессом, вы получаете выигрыш в задержке, но принимаете на себя администрирование базы, её копии и обновления.
• Где лежат файлы пользователей. Раз локальная файловая система Cloud Run не сохраняет данные после остановки экземпляра, они, скорее всего, уже в объектном хранилище. Решите, переезжают ли они, и проверьте, во что обойдётся их вывод.
• Что происходит с очередями и расписаниями. Задания и триггеры, привязанные к платформе, придётся заменить на планировщик на сервере или на другой механизм.

Рабочий приём: составьте две таблицы. В первой только вычисления: процессор, память, время работы, запас. Во второй всё остальное: данные, хранилище, трафик, резервные копии, мониторинг. Сравнивайте варианты построчно, а не итоги. Нередко выясняется, что вычисления занимают небольшую долю общего счёта, а настоящая дискуссия идёт о хранении и трафике, где смена платформы для процесса ничего не меняет.

Тот же ход рассуждения хорошо показан в материале о мифе про дешевизну serverless по сравнению со своим сервером: там акцент на том, что простое утверждение «дешевле» не работает без привязки к нагрузке.

Что меняется, когда трафик растёт

Вернёмся к двум приложениям и подвинем обе кривые вверх. Пусть трафик вырос в несколько раз.

Приложение А сначала почти не заметит роста с точки зрения счёта: часть суток по-прежнему тишина, а оплачиваемое время растёт примерно пропорционально работе. Но постепенно ночные паузы сокращаются, а дневная кривая поднимается. В какой-то момент минимум экземпляров придётся поднять выше нуля, чтобы убрать задержки первого запроса, и модель «платим за работу» плавно превращается в «платим за готовность». Это и есть точка, где расчёт стоит повторить. Она наступает не при определённом числе запросов, а когда пустые окна на графике становятся короче, чем вам удобно ждать холодного старта.

Приложение Б уже живёт в режиме готовности, поэтому рост нагрузки для него сначала означает загрузку уже оплаченных ресурсов. На VPS это работает очень выгодно, пока запас не исчерпан: стоимость сервера постоянна, а работы он делает больше. Затем наступает ступенька: ядер и памяти не хватает, нужна следующая конфигурация или второй сервер. Ступенька в цене на VPS заметна, а в облаке рост плавнее, потому что платформа добавляет экземпляры по одному. Для ровно растущего трафика это означает, что сравнение нужно делать не в одной точке, а вдоль кривой роста, помечая места, где у сервера ступеньки.

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

Если вы решили запускать постоянный процесс самостоятельно, VPS даёт для этого нужный набор: root-доступ, NVMe-диск, процессоры AMD EPYC и линейку конфигураций, которую можно менять по мере роста. В публичном предложении MAATRIX перечислены локации UK, US, RU и FR, оплата картой РФ и через СБП, а сервер создаётся автоматически через пару минут после оплаты. Наличие нужной операционной системы или готового образа в конкретной локации проверяйте в форме заказа. Подробности и конфигурации собраны на странице аренды VPS.

Как принять решение по своей кривой

Если свести рассуждение в короткий порядок действий, получится так.

1. Снимите суточную и недельную кривую запросов и загрузки процессора. Отметьте пустые окна, пики и их повторяемость.
2. Определите, делает ли приложение работу вне запроса. Если да, посмотрите, можно ли вынести её в задания по расписанию.
3. Решите, допустим ли холодный старт. Если нет, считайте облачный вариант с ненулевым минимумом экземпляров.
4. Прикиньте ресурсы для постоянного процесса по собственным пиковым метрикам и заложите запас.
5. Разделите смету на вычисления и данные, добавьте время на обслуживание сервера и план копирования.
6. Повторите расчёт для трафика, увеличенного в несколько раз, и найдите ступеньки.

Если после этого кривая выглядит как у приложения А (долгая тишина, короткие всплески, никаких долгоживущих воркеров), Cloud Run остаётся разумным выбором: вы платите за то, что реально работает, и не занимаетесь администрированием. Если кривая похожа на приложение Б (ровная круглосуточная работа, фоновые процессы, состояние в памяти), постоянный процесс на VPS чаще оказывается ближе к стоимости реально потребляемых ресурсов. А для многих проектов правдой окажется середина: часть нагрузки удобнее в облаке, часть на сервере. Решает не принцип, а форма вашего графика и то, кто будет следить за сервером в три часа ночи.