TT Lab
블로그 시작하기
배우기 러닝패스 코스

프로파일링: 느린 요청 하나를 함수까지

지속 프로파일링: 시간 축 위의 프로파일

TT Lab 에서 이어서 보기

한 줄 요약

지속 프로파일링은 짧은 프로파일을 늘 받아 시간 축 위에 쌓아 두는 방식입니다. 「지금」이 아니라 「그때」를 볼 수 있고, 배포 전후처럼 원하는 시간 범위를 골라 합치거나 견줄 수 있습니다. 대가는 저장 공간과 수집 부담이고, 둘 다 잴 수 있습니다.

왜 이게 필요했나

프로파일을 받는 일은 대개 「지금 느리다」는 것을 안 뒤에 시작됩니다. 그런데 문제는 지나간 뒤에 보고되는 경우가 많습니다. 새벽 세 시에 20분 동안 느렸다는 보고를 아침에 받으면, 그때 받은 프로파일은 이미 평온한 서비스를 보여 줄 뿐입니다. 재현이 안 되면 원인은 영영 짐작으로 남습니다.

어떻게 동작하나

뼈대는 단순합니다. 5초나 10초짜리 CPU 프로파일을 끊김 없이 이어 받아 시작 시각과 함께 저장합니다. 그 위에 세 가지 질문을 던집니다.

질문 하는 일
언제부터 창마다 특정 함수의 비율을 계산해 시계열로 늘어놓는다
그 시간 동안 무엇이 원하는 범위의 창을 하나로 합친다(pprof 는 파일 여럿을 받으면 표본을 합친다)
무엇이 달라졌나 두 범위를 각각 합쳐 diff 한다

Grafana Pyroscope 는 이 일을 서비스로 합니다. 프로그램이 SDK 로 프로파일을 밀어 넣거나(push), 수집기(Grafana Alloy 의 pyroscope.scrape)가 pprof 엔드포인트를 주기적으로 긁어 갑니다(pull). 저장소는 프로파일을 레이블(service_name·버전·tenant)로 색인하고, 오래된 창은 합쳐 압축합니다. OpenTelemetry 쪽에서는 Elastic 이 기증한 eBPF 기반 프로파일러가 OTLP profiles 로 내보내는 길을 만들고 있습니다.

비용은 곱셈으로 늘어납니다. 5초 창은 하루 17,280개입니다. 창 하나가 20KB 라면 서비스 하나·인스턴스 하나·CPU 프로파일 하나에 하루 345MB 이고, 여기에 인스턴스 수와 프로파일 종류(heap·mutex…)를 곱합니다. 그래서 지속 프로파일러는 저장 단계에서 같은 스택을 합치고, 보관 기간을 짧게 잡습니다.

수집 부담은 「작다」고 소개되는 경우가 많습니다. Pyroscope 문서도 표본 기반이라 부담이 작다고 설명합니다. 하지만 내 서비스에서 얼마인지는 같은 부하를 켜고 끈 두 측정으로 재 봐야 압니다. 측정 잡음이 부담보다 크면 차이가 음수로 나오기도 하는데, 그것도 「이 정도면 잡음에 묻힌다」는 정보입니다.

현장에서 만나는 모습

지속 프로파일링이 가장 빛나는 장면은 배포 뒤 서서히 나빠지는 경우입니다. 배포 직후에는 아무 경보도 없다가 트래픽이 늘며 CPU 가 오릅니다. 시계열에서 특정 함수의 비율이 배포 시각부터 올라간 것이 보이면, 그 배포의 변경 목록에서 그 함수를 찾으면 됩니다. 증상과 원인 사이의 거리가 그만큼 짧아집니다.

수집기를 직접 만들어 보면 지속 프로파일러의 설계 선택이 보입니다. 창을 짧게 하면 시점을 정확히 말할 수 있지만 파일이 많아지고, 길게 하면 파일은 줄지만 「언제」가 흐려집니다. Pyroscope 와 Grafana Alloy 의 기본 수집 주기가 10초 안팎인 것도 이 저울질의 결과입니다. 창 사이에 빈틈이 생기면 그 사이의 일은 영영 기록되지 않으므로, 받은 창이 서로 이어지는지 확인하는 일도 수집기의 몫입니다.

같은 이유로 레이블 설계가 중요합니다. 창마다 service_name 과 버전, 환경을 붙여 두어야 「어느 배포 판에서」를 고를 수 있습니다. 이 실습은 pricing 이 요청마다 붙이는 coupon 레이블로 창 안을 다시 나눕니다.

흔히 틀리는 읽기

창의 시각을 파일을 받은 시각으로 착각하기 쉽습니다. 프로파일 안의 Time 은 창이 시작된 시각이고, 창은 그 뒤 5초를 덮습니다. 「배포가 14:00:03 에 끝났다」면 14:00:00 에 시작한 창에는 배포 전과 후가 섞여 있습니다. 그래서 원인이 처음 나타난 창 바로 앞 창의 비율도 함께 적어, 정말 그 사이에 바뀌었는지 확인합니다.

창마다 표본 수가 다르다는 점도 잊기 쉽습니다. 부하가 없던 창은 표본이 몇 개뿐이라 비율이 크게 흔들립니다. 그래서 표본이 너무 적은 창은 판단에서 빼거나, 비율과 함께 절대 수를 같이 봅니다. 이 실습의 「표본 50개 이상」 조건이 그 장치입니다.

다음 실습에서 할 것

5초 창을 이어 받는 수집기를 직접 만들고, 쿠폰 없는 부하 뒤에 쿠폰 부하를 주어 「배포 전후」를 흉내 냅니다. 원인 함수가 처음 나타난 창을 찾고, 그 뒤를 합치고, 창별 시계열과 하루 저장량, 수집 부담을 숫자로 냅니다.

English corner