Continuous profiling, Давид Джалаев, PythoNN

Transcript

1. Непрерывное профилирование сервисов на python Давид Джалаев Бэкенд-разработчик
2. 2 Немного о спикере github.com/davidromanovizc Давид Джалаев • Разработчик • Опенсурсер • Хакатонщик • Начинающий спикер
3. 3 О чем доклад • Зачем оно надо? • Киты наблюдаемости • Профайлинг и eBPF • Демонстрация на Pyroscope
4. 4 Зачем?
5. 5 Зачем? • Точно отражает производительность в продакшене • Позволяет оперативно вычислить первопричину проблемы с производительностью • Позволяет выявлять редкие или специфические проблемы
7. 7 Киты наблюдаемости
8. 8 База наблюдаемости • Метрики – загрузка CPU, RAM, сети и д.р. • Логи – события приложений и инфраструктуры • Трейсы – путь запроса через распределенную систему
9. 9 Профиль как сигнал • Добавлены в OTLP v1.3.0 как новый тип сигнала • Пока статус unstable, но прогресс большой • Общая спецификация и семантические конвенции • Теперь профили часть Observability, а не отдельный тул source: The State of Profiling | OpenTelemetry
10. 10 Добавляется еще один • Профили – где именно код потребляет, например, CPU • Профилирование отвечает на вопрос: почему код работает медленно или нестабильно, а не только где это заметно
11. 11 Профиль и профилирование
12. 12 Профайлинг • Профиль – состояние/стектрейс + метрики • Профилирование – процесс сбора таких профилей ◦ Режимы (когда): ▪ Ручное – запускаем профайлер ▪ Непрерывное – профайлер работает в фоне ◦ Виды (как): ▪ Ручная разметка – с помощью изменения кода ▪ Сэмплирующие – периодическое снятие стека вызова
13. 13 А чем собирать профили?
14. 14 Что такое eBPF source: What is eBPF
15. 15 Почему это важно • Без вмешательства в код • Минимальный overhead (~2%) • Понимает K8s и Docker • Поддержка continuous profiling • Интеграции с Collector, Grafana, Pyroscope source: What is eBPF
16. 16 Как работает? • Снимает стеки процессов и ядра • Привязывается к хукам (syscalls, tracepoints) • Не требует менять приложение source: What is eBPF
17. 17 Но есть нюансы • Требуются привилегированные поды ◦ CAP_BPF, BPF_PROG_TYPE_PERF_EVENT, CAP_SYS_ADMIN • Уязвимости: ◦ CVE-2021-31440 – контейнер escape через eBPF verifier bug ◦ CVE-2022-42150 – eBPF cross-container атаки • CPython-стек без user-code
18. 18 Как их избежать
19. 19 Как их избежать • Использовать готовые операторы • Использовать Sidecar или Node Agent, но с наименьшими правами (Это медленнее) • Давать минимум привилегий • Использовать py313, улучшает раскрутку стека, но все еще beta
20. 20 Как обстоят дела с тулзами?
21. 21 Как обстоят дела с тулзами? • Elastic apm • Datadog • Sentry • Grafana pyroscope • Yandex Perforator • Parca.dev • Coroot
22. 22 Общие проблемы инструментов • Нет единого встроенного стандартного решения • Overhead чуть выше, чем у нативных и VM/JIT-языков, но остаётся незначительным • Зачастую доступен только один вид профилей (CPU)
23. 23 source: pydantic using abc which can have memory and performance issues def create_standard_order_template(): class StandardOrderType(StandardOrder): pass return StandardOrderType def create_premium_order_template(): class PremiumOrderType(PremiumOrder): pass return PremiumOrderType def process(self, order) -> None: if isinstance(order, StandardOrder): self.standard_orders += 1 elif isinstance(order, PremiumOrder): self.premium_orders += 1
24. 24 source: pydantic using abc which can have memory and performance issues @router.post("/v1/process_orders") async def process_orders_old(orders, processor = Depends(get_order_processor_old)): order_instances = [ create_standard_order_template()(--.) if order.type -= "standard" else create_premium_order_template()(--.) for order in orders ] for order in order_instances: processor.process(order) return {"standard_orders": processor.snt_ord, "premium_orders": processor.prem_ord}
26. 26 На чем тестировали • VM на Ubuntu 22.04 • 4 RAM • 4 CPU • 40 GB NVME • Python 3.11 • FastAPI 0.109.1 • Pydantic v2.11 • pyroscope-io/pypprof
27. 27 Grafana Pyroscope
28. 28 Grafana Pyroscope • Обычно низкий overhead: ~50 МБ памяти на pod, CPU ~1-5% • Поддерживает push и pull модели • Open Source решение, можно развернуть у себя в контуре • Если упадет сам Pyroscope, наш сервис никак не пострадает
29. 29 Как работает?
30. 30 Доступные типы профилей Instrumentation with SDKs
31. 31 pyroscope-io Python SDK for Pyroscope pyroscope.configure( application_name = "backend.python.app", server_address = "http:-/pyroscope:4040", sample_rate = 128 * 1024, tags = { "region": f'{os.getenv("REGION")}', } )
32. 32 pyroscope-io Python SDK for Pyroscope with pyroscope.tag_wrapper( { "controller": "slow_controller_i_want_to_profile" } ): slow_code()
33. 33 async def pyroscope_middleware(request, call_next): path = request.url.path if path.startswith("/healthcheck"): return await call_next(request) route = request.scope.get("route") template = getattr(route, "path_format", getattr(route, "path", path)) tags = { "endpoint": f"{request.method}:{template}", "method": request.method, } with pyroscope.tag_wrapper(tags): response = await call_next(request) return response
34. 34 pypprof • Для django есть django-pypprof • Для flask есть flask-pypprof • Есть базовая штука, предоставляющая интерфейс pprof – pypprof • Но для этого нам надо использовать pull модель, взять еще alloy, потому что не рекомендуют грузить pyroscope Configure the client to send profiles
35. 35 pyroscope.scrape "python_backend" { targets = [ {"-_address-_" = "backend:8081", "service_name" = "backend"}, ] scrape_interval = "30s" delta_profiling_duration = "15s" profiling_config { profile.process_cpu {} profile.memory { enabled = true path = "/debug/pprof/heap" delta = false } } forward_to = [ pyroscope.write.default.receiver ] } pyroscope.write "default" { endpoint { url = "http:-/pyroscope:4040" } }
36. 36 def main() -> None: app = create_app() with ThreadPoolExecutor(max_workers=1, thread_name_prefix="uvicorn") as ex: ex.submit(run_uvicorn, app) os.environ.setdefault("PYPROF_PORT", "8081") os.environ.setdefault("MEMORY_PROFILER_ENABLED", "true") import mprofile mprofile.start(sample_rate=524288) from pypprof.net_http import start_pprof_server port = int(os.environ["PYPROF_PORT"]) start_pprof_server(host="0.0.0.0", port=port)
37. 37 Flamegraph
40. 40 Comparison View
43. 43 Diff View
45. 45 Что имеем? • Основная точка нагрузки по CPU и по памяти – это __subclasscheck__ /__instancecheck__ • В профилях видно, что именно process_orders_old • Diff сравнения baseline vs нагрузка подтверждает: основная причина роста из-за pydantic
46. 46 Что-то типа заключения
47. 47 Что потенциально мы получаем • Сокращение MTTR, MTTD • Возможность сравнивать разные релизы • Экономия на инфраструктуре • Более спокойный on-call, если есть такая практика • Снижение downtime и latency
48. 48 Подводные камни • Профили тяжелые, требуют места и продуманной ретенции • Есть определенный overhead хоть и незначительный • Нативно только CPU-профили. Остальное требует танцы с бубном • Есть риски связанные с уязвимостями • Pprof-профили могут содержать чувствительные данные
49. 49 Это инвестиция в будущее
50. 50 Вопросы? Оценить доклад