Комментарии 8
Спасибо за туториал.
Я использую Serverless Containers в своем прод-сервисе, который генерирует картинку на основе архива с данными.
Сам генератор выполняется в группе ВМ и там настроено авто масштабирование при увеличении очереди. И сделано это из-за ограничения с диском в Serverless Container (его там нет, есть только tmpfs на 500 мб).
Все лето я потратил на тесты Serverless YDB, Serverless Containers и Message Queue и пришел к нескольким выводам по этой связке:
В базе могут быть долгие ответы (выше 1 секунды на селект по первичному ключу). В условиях 5 секунд на запрос, можно не успеть. Лучше работает Postgres в виртуалке 20% cpu (см. п. 3 про http веб-сервер). Держать pet-project на этой базе можно смело. Нагрузка меньше 1qps.
В очереди иногда долго отвечает SendMessage. Изначально в очередь писал http-сервис из Serverless Container. Потом перенес http-сервис в постоянную виртуалку с 20% cpu и стало реже долго отвечать SendMessage, но проблема полностью не ушла. Уже общаемся с поддержкой по этому поводу.
http веб-сервер работает хорошо, но иногда бывают то ли проблемы с сетью (она инициализируется медленнее, чем http веб-сервер на Golang), то ли с ресурсами (в логах биллится 5 сек, а первого сообщения в логах из функции main нет). Если вам критично, чтобы запрос отдавался за условные 5-10 сек, то Serverless Container не подойдет. Даже с подготовленным экземпляром (а он по цене примерно так же, как ВМ с 20% cpu). Для фоновых задач по крону или из очереди подходит на отлично.
С нетерпением жду фичу по монтированию s3 бакета в Serverless Container.
Спасибо ребятам, за то, что создали такое. Мощная работа. В РФ аналогов пока не нашел.
Спасибо за обратную связь! Про монтирование бакета - скоро будут апдейты, подключайтесь к трансляции нашего трека на https://scale.yandex.ru/
Насколько это дороже арендуемых VM? Спотовых?
В этом сценарии - несоизмеримо дешевле (почти наверняка бесплатно). А в целом сравнивать можно, если иметь чуть больше данных. Как правило, с serverless сервисами работает подход - если нагрузка плавающая и не очень хорошо прогнозируемая, то их использование часто будет дешевле.
Если нагрузка постоянная и хорошо прогнозируется, то экономическая целесообразность serverless считается заметно сложней, через TCO и потенциальную экономию в процессах разработки, а не в явном виде в инфраструктуре.
Настоятельно не рекомендую развёртывать в Serverless Containers критически важные компоненты системы.
На текущий момент сервис имеет множество багов, а поддержка работает неудовлетворительно: мой тикет остаётся без обновлений уже четыре месяца.
Первая проблема, с которой мы столкнулись — это развертывание приложения на Next.js. Прокси данного сервиса некорректно обрабатывает пути, содержащие специальные символы. В моём случае в URL используются квадратные скобки:
Даже если передавать путь в base64, как это автоматически делает клиент, до сервера доходит некорректный URL, в результате чего возникает ошибка “файл не найден”, хотя он действительно присутствует на сервере. Эту проблему до сих пор не решили.
Вторая проблема появилась на этой неделе. Наше приложение, которое работает с базой данных, стало периодически терять соединение с БД. На стороне приложения и базы данных проблем не было, так как простой редеплой на обычную виртуальную машину решил проблему. Однако саппорт настаивает, что на их стороне всё функционирует в штатном режиме.
UPD: по комментарию выше
Проблему с путями до сих пор не решили, тикет все еще в открытом статусе.
Кроме того, появилась еще одна новая проблема.
Мы развернули в Serverless Containers сервис, который должен динамически поднимать ВМ в Yandex Cloud. Сервис использует SA, который генерирует IAM-токен. Примерно раз в месяц стабильно получаем в логах сервиса ошибку: он не может сгенерировать IAM-токен из-за того, что API Яндекса недоступен с данной инфраструктуры.
Error: connect ETIMEDOUT 84.201.181.26:443
Навесили ретраи, но даже это не помогает. Все приходит в норму, когда делаешь передеплой контейнера. Видимо, после этого он попадает на другую ноду, и все начинает работать прекрасно :D
Похожая проблема была с Cloud Function, которая успешно работала в продакшене месяц, а потом внезапно начала писать в логи ошибку 499, как будто клиент разорвал с ней соединение. Возможно, клиент действительно рвет соединение, но, судя по всему, не с нашей стороны, а их Gateway, который располагается поверх Cloud Function. И снова, простой редеплой функции решил проблему.
Про саппорт даже писать не буду — их “очень полезные” рекомендации известны.
К сожалению, бессерверные сервисы, такие как Serverless Containers и Cloud Function, я не рекомендую использовать в вашей продакшен-среде. Это какое-то лол, кек, чебурек.
Либо обкладывайте эти сервисы со всех сторон механизмами полной отказоустойчивости.
Сижу, строчу комментарии в надежде, что автор поста их прочтет и сможет повлиять на улучшение качества сервиса, а он уже ушел в МТС cloud строить :D
Дёшево, сердито и не жмёт: как работает запуск контейнеров в Yandex Serverless Containers