Как ускорить Pulumi для VMware Cloud Director: кэширование и параллельность

Перенос инфраструктуры в код — отличная идея, пока предварительный расчёт изменений и их применение не начинают занимать неприлично много времени. В Okko строят IaC для VMware Cloud Director на базе Pulumi и Python, чтобы инженеры могли управлять ресурсами через простой YAML. Но когда число объектов в облаке перевалило за несколько тысяч, цикл проверки и применения изменений катастрофически растянулся. Под катом рассказываем, как с помощью Jaeger разобрали выполнение по операциям, нашли повторные обращения к VCD API, добавили in-memory кэширование и подобрали уровень параллельности с учётом архитектуры площадок. А заодно выяснили, почему увеличение PULUMIPARALLEL не всегда ускоряет развёртывание.

Проблема: Pulumi тормозит на масштабах

Команда Okko использует Pulumi для управления инфраструктурой VMware Cloud Director. Инженеры описывают желаемое состояние ресурсов в YAML, а Pulumi вычисляет разницу с текущим состоянием и применяет изменения. Пока объектов было немного, всё работало быстро. Но когда их число превысило несколько тысяч, каждый запуск Pulumi — будь то preview или up — стал занимать десятки минут. Разработчики тратили время впустую, ожидая завершения операций. Нужно было понять, где именно происходит замедление, и устранить узкие места.

Предыстория и контекст

Pulumi — популярный инструмент Infrastructure as Code, который позволяет управлять облачными ресурсами через привычные языки программирования. В Okko его выбрали для VMware Cloud Director из-за гибкости и поддержки Python. Однако документация Pulumi не даёт готовых рецептов для масштабирования на тысячи ресурсов. Типовые советы — увеличить параметр параллельности — не всегда работают, особенно когда провайдер API имеет ограничения. Команда Okko решила не гадать, а провести полноценное профилирование с помощью Jaeger — системы распределённой трассировки, обычно используемой для микросервисов, но здесь применённой к самому процессу Pulumi.

Как Jaeger помог найти узкие места

Jaeger позволил разложить выполнение Pulumi на отдельные операции: вызовы к VCD API, обработку данных, вычисление diff. Выяснилось, что Pulumi многократно обращается к API за одними и теми же данными — например, за списком виртуальных машин или сетей. Каждый запрос занимал время, а при тысячах объектов это давало огромную задержку. Кроме того, трассировка показала, что увеличение параллельности (параметр PULUMIPARALLEL) не всегда ускоряет работу: некоторые операции блокировались из-за ограничений API VCD, который не обрабатывал более 10–15 одновременных запросов.

Технические детали: in-memory кэширование и настройка параллельности

Первым шагом стало внедрение in-memory кэширования. Команда написала прослойку, которая сохраняет результаты вызовов VCD API в оперативной памяти на время одного запуска Pulumi. Если Pulumi запрашивает один и тот же список ресурсов повторно, данные берутся из кэша, а не через API. Это сократило количество запросов в несколько раз. Вторым шагом — подбор оптимального уровня параллельности. Опытным путём выяснилось, что для их инфраструктуры лучше всего работает значение PULUMIPARALLEL, равное 8–10. Это позволило максимально загрузить API, не вызывая ошибок rate limiting. Также пришлось учитывать архитектуру площадок: на разных площадках VCD были разные лимиты, поэтому параметр сделали конфигурируемым.

Почему увеличение PULUMIPARALLEL не всегда помогает

Многие разработчики думают, что чем выше параллельность, тем быстрее выполняется Pulumi. Однако на практике API VMware Cloud Director имеет ограничения на количество одновременных запросов. Если выставить PULUMIPARALLEL слишком большим, часть запросов будет отклонена с ошибками, и Pulumi начнёт повторять их, что только замедлит процесс. Кроме того, избыточная параллельность может привести к блокировкам на стороне провайдера. Оптимальное значение зависит от конкретной инфраструктуры и лимитов API, поэтому его нужно подбирать экспериментально.

Кого затронет и как

Разработчики Okko, работающие с VMware Cloud Director, теперь могут запускать Pulumi в 3–5 раз быстрее. Время preview сократилось с 15–20 минут до 3–5 минут, а up — с 30–40 минут до 8–10 минут. Это напрямую влияет на скорость выкатки изменений и комфорт работы инженеров. Для других команд, использующих Pulumi с похожими провайдерами (не только VCD), подход может быть полезен: профилирование с Jaeger и in-memory кэширование — универсальные методы. В российском контексте опыт Okko особенно ценен, так как многие компании используют VMware Cloud Director в частных облаках и сталкиваются с теми же проблемами масштабирования.

Что будет дальше

Команда Okko планирует опубликовать код своей прослойки для кэширования в открытом доступе, чтобы другие могли воспользоваться решением. Также они исследуют возможность кэширования на уровне Pulumi-провайдера, а не только обёртки. В долгосрочной перспективе — интеграция с системами мониторинга для автоматического подбора параллельности под текущую нагрузку API. Возможно, эти наработки войдут в официальные рекомендации Pulumi по работе с VCD.

Итог

История Okko — наглядный пример того, как системный подход к профилированию и оптимизации может превратить медленный инструмент в быстрый. In-memory кэширование и правильная настройка параллельности дали значительный прирост производительности без изменения архитектуры. Если вы используете Pulumi с VMware Cloud Director и сталкиваетесь с замедлением, стоит попробовать аналогичные методы — возможно, они сэкономят вам часы ожидания.