Больше 1 млн AWS Lambda, тысячи клиентских аккаунтов и простой дешевле одного доллара в месяц на аккаунт. AWS рассказала, как ProGlove, производитель промышленных носимых устройств, довела свою SaaS-платформу до таких масштабов без перехода в режим «сначала тушим пожар, потом считаем счет». Для русскоязычной IT-аудитории это не просто красивая облачная байка, а вполне прикладной кейс о том, что в serverless-архитектуре лимиты, автоматизация и стоимость наблюдаемости начинают управлять дизайном системы гораздо раньше, чем кажется.
О схеме ProGlove сообщает InfoQ: компания разнесла клиентов по отдельным AWS-аккаунтам и в итоге получила платформу, где более 1 млн AWS Lambda распределены по тысячам выделенных tenant-окружений. Подход не новый в теории, но на практике он быстро превращается в операционную мясорубку, если его вовремя не автоматизировать. AWS прямо указывает, что после отметки в 50 аккаунтов ручное управление уже начало тормозить релизы и упираться в сервисные квоты.
Архитектурный выбор ProGlove был жестким, но понятным: один аккаунт на клиента вместо общей многопользовательской среды. Цена вопроса — дополнительная операционная сложность. Выигрыш — более сильная изоляция, отдельные квоты сервисов и прозрачная привязка затрат к конкретному заказчику. Для B2B-платформы, особенно работающей с промышленными сценариями и корпоративными клиентами, это выглядит не как прихоть архитекторов, а как прагматичный обмен: меньше риска по безопасности и биллингу, больше боли у платформенной команды. Внутри каждого клиентского аккаунта жило несколько микросервисов, обычно от пяти до пятнадцати Lambda-функций. Их координировала машина состояний AWS Step Functions: она принимала данные со сканеров, сохраняла их в Amazon DynamoDB и отправляла бизнес-события в общий Amazon EventBridge, который уже потреблял аналитический контур ProGlove.
Пока аккаунтов немного, такую конструкцию еще можно поддерживать на дисциплине и кофеине. Но на масштабе в тысячи tenant-окружений это перестает работать. Инженеры ProGlove собрали единый конвейер на AWS Organizations, Step Functions и CloudFormation StackSets, который создает и обновляет все клиентские аккаунты централизованно. По сути, речь о платформенном управлении инфраструктурой как продуктом: не «у нас есть IaC», а «любой аккаунт должен рождаться и меняться одинаково, из одного пайплайна, без ручной магии». Позже, по данным AWS, совместная работа с инженерами облачного провайдера позволила повысить пропускную способность StackSets, чтобы те могли раскатывать изменения по тысячам аккаунтов, где суммарно и работают те самые 1 млн AWS Lambda.
Где масштаб бьет не по CPU, а по процессам
Самая показательная часть истории — проблемы начались не только из-за числа функций. Один из ранних механизмов планирования запускал одинаковые cron-подобные задания во всех аккаунтах одновременно. Результат AWS описывает без лишней дипломатии: самострел в виде DDoS против собственной платформы. Это хороший холодный душ для команд, которые думают, что serverless по умолчанию сглаживает все пики. Нет, не сглаживает, если вы синхронно будите тысячи одинаковых ворклоадов в одну секунду. ProGlove ушла от жестких таймеров к окнам выполнения с jitter и более событийной модели запуска. Это позволило выровнять региональную нагрузку без reserved concurrency и без заранее зарезервированных мощностей.
Вторая неприятная математика всплыла там, где ее часто замечают слишком поздно, — в observability. Каждая Lambda пишет логи и метрики, и на уровне одной функции это выглядит почти бесплатно. На уровне тысяч аккаунтов и сотен тысяч вызовов такая «почти бесплатность» уверенно превращается в одну из крупнейших статей расходов. ProGlove централизовала критичные сбои в общую dead-letter queue и убрала неиспользуемые очереди Amazon SQS. В результате, по данным AWS, стоимость простоя на аккаунт удалось удержать ниже 1 доллара США в месяц. Для платформы с сильной tenant-изоляцией это важная цифра: она показывает, что модель «аккаунт на клиента» не обязана быть экономическим самоубийством, если idle-cost контролируется так же жестко, как и продовая нагрузка.
Здесь полезен контекст. InfoQ напоминает, что похожие операционные проблемы уже описывали и другие крупные игроки. Capital One говорила о необходимости стандартизировать деплой, наблюдаемость и governance, если организация хочет стабильно эксплуатировать большие Lambda-нагрузки. DoorDash в заметках о миграции в serverless тоже подчеркивала роль дисциплинированной автоматизации, чтобы десятки миллионов API-вызовов в день не уткнулись в concurrency-лимиты. Иными словами, тренд уже читается: на зрелом масштабе serverless — это не только про «меньше серверов», а про предельно скучную, но жизненно важную стандартизацию платформенных практик.
Что из этого вынесут разработчики и бизнес
Для разработчиков кейс ProGlove интересен тем, что он ломает популярную иллюзию о бесконечной эластичности облака. Облако действительно масштабируется, но вместе с ним масштабируются квоты, задержки rollout-процессов, стоимость логов и вероятность случайно устроить себе перегрузку расписанием. Если архитектура строится вокруг изоляции клиентов, автоматизация должна закладываться не после первых проблем, а в самом начале. После сотни аккаунтов чинить это поздно, после тысячи — уже дорого, а после нескольких тысяч любое ручное исключение превращается в техдолг с ежемесячной подпиской. Для платформенных и DevOps-команд вывод простой: tenant model, IaC и наблюдаемость нельзя обсуждать в разных комнатах, это одна и та же инженерная тема.
Для бизнеса урок не менее прагматичный. Отдельный аккаунт на клиента часто выглядит избыточным до тех пор, пока не приходит первый серьезный разговор о безопасности, аудитах, квотах или модели затрат. ProGlove фактически показывает, что более строгая изоляция может окупаться не только с точки зрения риска, но и с точки зрения управляемости бизнеса: проще объяснить клиенту его стоимость владения, проще локализовать сбой, проще держать границы ответственности. Да, приходится мириться с компромиссами. AWS признает, что раскатка через StackSets медленнее, чем обычный CloudFormation в одном аккаунте, а централизация логов частично снижает детализацию на уровне отдельных tenant-окружений. Но если альтернатива — хаос из тысяч почти одинаковых инфраструктур, компромисс выглядит вполне взрослым.
Главный вопрос теперь не в том, можно ли разогнать serverless-платформу до такого масштаба. Уже можно. Вопрос в другом: сколько команд готовы проектировать систему так, будто ограничения по квотам, rollout-скорости и стоимости телеметрии важны с первого дня, а не после первого неприятного счета. История ProGlove подсказывает неприятную, но полезную мысль: в больших облачных системах настоящая масштабируемость начинается не там, где у вас много функций, а там, где вы заранее научились управлять их количеством, шумом и ценой.