Alex.Miller
New member
Год назад я увлёкся идеей перевести наш сервис на Serverless — мол, ну какой смысл держать серверы, если можно платить только за запросы? Звучало идеально: нет инфраструктуры, нет DevOps, платишь за фактическое использование. На старт я выбрал AWS Lambda с интеграцией в API Gateway, разделил логику на несколько функций и через пару недель выкатил всё на прод. Первые две недели я был в эйфории — счёт был копеечный, деплой стал быстрее, а мониторинг практически не требовал внимания. Но потом началась настоящая жизнь, и я понял, что Serverless — это не волшебная таблетка, а инструмент с характером.
Холодные старты стали первым серьёзным врагом. Наши функции написаны на Python, и при холодном старте система загружает весь runtime, что занимает от 800 миллисекунд до полутора секунд. Для фоновых задач это было терпимо, но для пользовательских запросов — катастрофа. Пользователи жаловались на «тормоза» в моменты, когда нагрузки были минимальными, и парадокс заключался именно в этом: чем реже запрос, тем дольше ожидание. Я пробовал provisioned concurrency, но это добавило в счёт столько, что экономия от Serverless превратилась в иронию. В итоге я уменьшил размер функций, убрал тяжёлые зависимости и вынес инициализацию в слой, но проблема не исчезла полностью — она просто стала менее болезненной.
Лимиты — это то, о чём никто не предупреждает достаточно жёстко. Девятая минута — и ваша функция умрёт, неважно, что вы уже на 80% пути. Я не раз ловил таймауты на больших выгрузках, которые в классическом серверном подходе заняли бы две минуты. Память тоже ограничена: 10240 МБ — потолок, и на этом уровне вы платите как за 10240 МБ, хотя реальная нагрузка может быть в разы меньше. Плюс лимиты на параллельные инвентарные экземпляры, лимиты на размер пакета, лимиты на размер ответа — всё это накапливается и в какой-то момент ты начинаешь писать код не для бизнес-логики, а чтобы уложиться в рамки платформы. Я потратил немало времени на оптимизацию, чтобы уместить обработку CSV-файла в 30 секунд и не превысить размер ответа в 6 МБ.
А теперь о том, что реально удивило — счёт. Я ожидал, что Serverless будет дешевле в 3-4 раза по сравнению с привычными VPS и EC2. Оказалось, что при стабильной нагрузке экономия составляет не более 20-30%, а при пиковых нагрузках счёт может вырасти в разы. Дело в том, что API Gateway, DynamoDB, SQS, EventBridge и все сопутствующие сервисы имеют свою тарификацию, и когда вы начинаете считать всё вместе, сумма приятно шокирует. У нас была ситуация, когда один неоптимизированный цикл вызывал другую функцию в цикле на 5000 элементов, и за одну ночь счёт вырос втрое — просто потому, что каждый вызов функции и каждый вызов API Gateway тарифицируются отдельно. Я до сих пор помню это ощущение, когда открыл биллинг-дашборд и не поверил глазам.
Из всего этого опыта я сформулировал несколько рекомендаций тем, кто только собирается идти в Serverless. Во-первых, не переносите монолит на Serverless один в один — сначала декомпозируйте логику и решите, что реально стоит делать асинхронно, а что можно оставить на обычном хостинге. Во-вторых, всегда считайте полный стек затрат, включая все периферийные сервисы, а не только сами функции. В-третьих, тестируйте холодные старты в условиях, максимально приближённых к продакшену, потому что локально они не воспроизводятся. И в-четвёртых, не игнорируйте лимиты — проектируйте архитектуру так, чтобы ваши бизнес-процессы не упирались в технические ограничения платформы.
Serverless — это не плохое решение и не лучшее. Это решение, которое идеально подходит для определённых сценариев: редкие задачи, спорадические нагрузки, прототипы, интеграции. Для стабильной нагрузки с постоянным потоком запросов я бы всё же рассмотрел гибридный подход, когда тяжёлые и частые операции живут на обычных серверах, а всё остальное — в Serverless. Главное — не романтизировать и не демонизировать технологию, а трезво оценивать её применимость к конкретной задаче.
А вы сталкивались с холодными стартами в продакшене? Какие приёмы помогли вам снизить их влияние на пользовательский опыт, и не пришлось ли вам в итоге отказаться от Serverless в пользу классической архитектуры?
Холодные старты стали первым серьёзным врагом. Наши функции написаны на Python, и при холодном старте система загружает весь runtime, что занимает от 800 миллисекунд до полутора секунд. Для фоновых задач это было терпимо, но для пользовательских запросов — катастрофа. Пользователи жаловались на «тормоза» в моменты, когда нагрузки были минимальными, и парадокс заключался именно в этом: чем реже запрос, тем дольше ожидание. Я пробовал provisioned concurrency, но это добавило в счёт столько, что экономия от Serverless превратилась в иронию. В итоге я уменьшил размер функций, убрал тяжёлые зависимости и вынес инициализацию в слой, но проблема не исчезла полностью — она просто стала менее болезненной.
Лимиты — это то, о чём никто не предупреждает достаточно жёстко. Девятая минута — и ваша функция умрёт, неважно, что вы уже на 80% пути. Я не раз ловил таймауты на больших выгрузках, которые в классическом серверном подходе заняли бы две минуты. Память тоже ограничена: 10240 МБ — потолок, и на этом уровне вы платите как за 10240 МБ, хотя реальная нагрузка может быть в разы меньше. Плюс лимиты на параллельные инвентарные экземпляры, лимиты на размер пакета, лимиты на размер ответа — всё это накапливается и в какой-то момент ты начинаешь писать код не для бизнес-логики, а чтобы уложиться в рамки платформы. Я потратил немало времени на оптимизацию, чтобы уместить обработку CSV-файла в 30 секунд и не превысить размер ответа в 6 МБ.
А теперь о том, что реально удивило — счёт. Я ожидал, что Serverless будет дешевле в 3-4 раза по сравнению с привычными VPS и EC2. Оказалось, что при стабильной нагрузке экономия составляет не более 20-30%, а при пиковых нагрузках счёт может вырасти в разы. Дело в том, что API Gateway, DynamoDB, SQS, EventBridge и все сопутствующие сервисы имеют свою тарификацию, и когда вы начинаете считать всё вместе, сумма приятно шокирует. У нас была ситуация, когда один неоптимизированный цикл вызывал другую функцию в цикле на 5000 элементов, и за одну ночь счёт вырос втрое — просто потому, что каждый вызов функции и каждый вызов API Gateway тарифицируются отдельно. Я до сих пор помню это ощущение, когда открыл биллинг-дашборд и не поверил глазам.
Из всего этого опыта я сформулировал несколько рекомендаций тем, кто только собирается идти в Serverless. Во-первых, не переносите монолит на Serverless один в один — сначала декомпозируйте логику и решите, что реально стоит делать асинхронно, а что можно оставить на обычном хостинге. Во-вторых, всегда считайте полный стек затрат, включая все периферийные сервисы, а не только сами функции. В-третьих, тестируйте холодные старты в условиях, максимально приближённых к продакшену, потому что локально они не воспроизводятся. И в-четвёртых, не игнорируйте лимиты — проектируйте архитектуру так, чтобы ваши бизнес-процессы не упирались в технические ограничения платформы.
Serverless — это не плохое решение и не лучшее. Это решение, которое идеально подходит для определённых сценариев: редкие задачи, спорадические нагрузки, прототипы, интеграции. Для стабильной нагрузки с постоянным потоком запросов я бы всё же рассмотрел гибридный подход, когда тяжёлые и частые операции живут на обычных серверах, а всё остальное — в Serverless. Главное — не романтизировать и не демонизировать технологию, а трезво оценивать её применимость к конкретной задаче.
А вы сталкивались с холодными стартами в продакшене? Какие приёмы помогли вам снизить их влияние на пользовательский опыт, и не пришлось ли вам в итоге отказаться от Serverless в пользу классической архитектуры?