eBPF 공부방-Parca

실전 사례 ①CPU 사용률은 정상인데, 성능은 느린 이유운영 중인 서버에서 다음과 같은 리포트를 받았다고 가정해 보자.CPU 사용률: 평균 40~50%Load Average: 정상메모리 여유 충분APM: 주요 API 응답 시간 “정상 범위”사용자 체감: “전체적으로 느림”이 상황은 의외로 매우 흔하다.그리고 가장 골치 아픈 유형이기도 하다.1. 문제의 핵심: “정상 지표”의 함정전통적 모니터링 지표CPU: 45%Memory: 62%Disk IO: 낮음Network: 정상→ 문제 없어 보인다.APM 지표/api/search 평균 110ms/api/order 평균 180ms에러율 0% → 역시 문제 없어 보인다.이 단계에서 흔히 나오는 결론은 이것이다.“일시적인 네트워크 문제였나 봅니다.”하지만 사용자는 여..

Flamegraph 제대로 읽기Parca UI 해석 가이드Parca를 처음 실행하면 대부분 이런 반응을 보인다.“그래프는 나오는데…이걸 어떻게 해석해야 하지?”Flamegraph는 직관적인 듯 보이지만,실제로는 매우 쉽게 오해되는 시각화다.이번 편의 목표는 단 하나다.Flamegraph를 ‘그림’이 아니라‘성능 설명 도구’로 읽게 만드는 것Flamegraph는 무엇을 보여주는가 (한 문장 정의)Flamegraph는CPU 시간이 어떤 함수 호출 경로에서얼마나 사용되었는지를 보여준다.여기서 핵심 단어는 세 가지다.CPU 시간함수 호출 경로 (call stack)누적 분포 Parca UI에서 보는 Flamegraph는 다음과 같은 규칙을 가진다.X축: 시간 비율 (가로 폭)가로 폭이 넓을수록→ CPU 시간을 ..

Parca와 기존 APM / 모니터링 에이전트 비교무엇이 같고, 무엇이 다른가Parca를 처음 접하면 많은 사람들이 이렇게 묻는다.“이거 APM이랑 뭐가 다른가요?”“기존 모니터링 에이전트랑 겹치지 않나요?”이 질문은 매우 자연스럽다.그리고 이 질문에 제대로 답하지 못하면Parca는 ‘굳이 써야 하나?’라는 도구로 남게 된다.이번 편에서는Parca, APM, 전통적 모니터링 에이전트를같은 테이블 위에 올려놓고 비교한다.먼저 한 문장 요약부터APM은 ‘요청’을 본다모니터링 에이전트는 ‘자원’을 본다Parca는 ‘CPU 시간의 실제 사용처’를 본다이 문장을 이해하면이번 글의 절반은 이미 이해한 셈이다.비교 대상 정리이번 글에서 비교할 대상은 다음 세 가지다.전통적 모니터링 에이전트CPU, Memory, Di..

Parca란 무엇인가eBPF 시대의 Continuous Profiling 입문서버 성능 문제를 다뤄본 개발자라면 한 번쯤 이런 상황을 겪어봤을 것이다.• CPU 사용률은 낮은데 서비스는 느리다• APM에는 특별한 트랜잭션 병목이 보이지 않는다• 로그도, 메트릭도 “이상 없음”인데 사용자는 불만을 제기한다이런 문제는 단순한 리소스 부족이 아니라,“어디에서 시간이 쓰이고 있는지”를 제대로 보지 못할 때 발생한다.이 지점에서 등장하는 도구가 바로 Parca다.⸻기존 성능 분석 방식의 한계1. 전통적 프로파일링 도구• gprof, perf, oprofile• 특정 시점에 직접 실행• 분석 대상 프로세스를 의도적으로 멈추거나 개입문제는 명확하다.• 장애는 항상 재현되지 않는다• 재현을 위해 프로파일링을 켜는 순간..