полгода назад ко мне пришли с вопросом, мол, есть какой-то сервис что-то про «ембеддинги», я особо не разбирался: ну еще какой-то микросервис где-то, хотим масштабирование «scale to 0». вводная при этом звучала конкретно: скейлиться нужно на основе кастомной метрики очереди — в очереди есть сообщения, значит поднимаем сервис, нет сообщений — 0. ну и я в общем-то почти не думая сразу вкинул про Keda, обрисовал что такое как работает и зачем.
я еще пару раз слышал, что с этим вопросом еще разбираются, попутно удивляясь, почему так долго: ведь очередь есть, сообщения там есть, сервис есть.. осталось лишь воткнуть ScaledObject и все.. но не так то просто! как я тогда это понял: есть queue-driven workload, которому просто не хватает autoscaler’а.
Проходит 8 месяцев, в репо Helm чарт (там большой umbrella chart с одной зависимостью в виде default chart) вижу MR, в котором добавлена возможность описать «сайдкар» для того самого сервиса «ебмеддинг». я слегка охуев от такой задумки, пошел разбираться че за хуйня.
Выяснилось: сервис «ембеддинг» не работает с Amqp, а идея была скейлиться на основе очереди, а значит был написан сервис адаптер на пайтоне, который читает очередь и отправляет запросы в ембеддинг. а работают они в одном поде, чтобы таким образом балансировать нагрузку.
Я в очередной раз ахуев, пошел смотреть что это за сервис такой у них, и тут оказалось что это модель с hugging face которая сервится через тулкит на Rust, который называется text embedding inference, в который просто посылают http запросы и который по сути обычный прикол из интернета third-party (по сути готовый inference server, а не наш бизнес-сервис), а его воткнули в в релизный цикл со всеми другими разрабатываеми сервисами.
Как же важна легкая осведомленность! Я взял Knative Serving, выкинул тот MR, добавил включение/выключение knative на описанном сервисе, перевел этот инференс на knative service, настроив масштабирование от нуля и все заработало. и внезапно задача, которая 8 месяцев обрастала адаптерами и сайдкарами, схлопнулась до нормального serverless HTTP-serving паттерна менее чем за сутки, а то и несколько часов.
24
6
5
4
2
6
5
4
2May 30, 2026 744 8 4
