Опыт MWS Cloud Platform: оптимизация CEL для работы с Protobuf
Х@habr_comмедиа / агрегатор
1 месРазбор эксперимента MWS Cloud Platform по внедрению ленивого парсинга Protobuf в CEL для снижения потребления памяти при обработке событий k8s.
Оптимизация работы с данными в высоконагруженных системах требует баланса между производительностью и поддержкой кода.
- Полная десериализация Protobuf-сообщений создает избыточную нагрузку на память при частичной валидации.
- Ленивый парсинг позволяет радикально снизить потребление ресурсов, но усложняет архитектуру.
- Технически эффективные решения могут быть отвергнуты из-за проблем с поддержкой, безопасностью или сложностью интеграции.
Как засунуть Protobuf в CEL и выиграть (или проиграть): опыт MWS Cloud Platform
Представьте поток событий k8s, которые сыплются в микросервис без остановки, и каждое надо прогнать через валидацию на CEL. И тут же выясняется неприятное. Чтобы движок проверил жалкие два-три поля, компактный Protobuf распаковывается целиком, память улетает под всё дерево объектов ради пары значений. Большая часть распакованных данных интерпретатору просто не нужна.
Раз так, почему бы не отдать CEL сырые байты и не научить его выдёргивать поля лениво, ровно в момент обращения. Команда MWS Cloud Platform залезла во внутренности обоих форматов, собрала ленивый парсер и запустила бенчмарки. На тяжёлых манифестах аллокации памяти рухнули в 15-20 раз. Мечта. А потом этот код взяли и выкинули...
Узнаем, что заставило отказаться от решения с идеальными цифрами.
Кратко (AI)
Команда MWS Cloud Platform столкнулась с избыточным потреблением памяти при валидации событий k8s через CEL из-за полной распаковки Protobuf-сообщений. Инженеры разработали ленивый парсер, который позволил сократить аллокации памяти в 15-20 раз, однако в итоге отказались от этого решения. Статья анализирует причины, по которым технически эффективный подход был отвергнут.
Обсуждение
0Пока тихо. Будь первым — или подожди, пока подтянутся наши боты 🤖