1편. Parca란 무엇인가

Parca란 무엇인가

eBPF 시대의 Continuous Profiling 입문

서버 성능 문제를 다뤄본 개발자라면 한 번쯤 이런 상황을 겪어봤을 것이다.
• CPU 사용률은 낮은데 서비스는 느리다
• APM에는 특별한 트랜잭션 병목이 보이지 않는다
• 로그도, 메트릭도 “이상 없음”인데 사용자는 불만을 제기한다

이런 문제는 단순한 리소스 부족이 아니라,
“어디에서 시간이 쓰이고 있는지”를 제대로 보지 못할 때 발생한다.

이 지점에서 등장하는 도구가 바로 Parca다.

⸻

기존 성능 분석 방식의 한계

1. 전통적 프로파일링 도구
• gprof, perf, oprofile
• 특정 시점에 직접 실행
• 분석 대상 프로세스를 의도적으로 멈추거나 개입

문제는 명확하다.
• 장애는 항상 재현되지 않는다
• 재현을 위해 프로파일링을 켜는 순간, 상황이 달라진다
• 운영 환경에서는 상시 사용이 사실상 불가능하다

즉, “문제가 발생한 그 순간”의 데이터를 놓치기 쉽다.

⸻

2. APM(Application Performance Monitoring)

APM은 분명 강력하다.
• 트랜잭션 단위 분석
• 응답 시간, 에러율, DB 쿼리 추적
• 비즈니스 로직 관점에서의 가시성

하지만 APM에도 사각지대는 있다.
• CPU 내부에서 무엇이 실행되고 있는지는 알기 어렵다
• 커널 함수, 스케줄링 지연, lock 경합은 잘 보이지 않는다
• 샘플링 기반이 아닌 경우, 오버헤드가 커질 수 있다

APM은 “요청 흐름”에는 강하지만,
“실제 CPU 시간의 사용처”를 설명하는 데는 한계가 있다.

⸻

Continuous Profiling이라는 접근

여기서 나오는 개념이 Continuous Profiling이다.

기존 방식
• 문제가 발생하면 → 분석 도구 실행 → 원인 추적

Continuous Profiling
• 평상시부터 항상 프로파일링
• 문제가 발생하면 → 이미 쌓여 있는 데이터로 분석

즉,
“문제가 생겼을 때 수집을 시작하는 것”이 아니라
**“항상 수집하고, 필요할 때 본다”**는 발상이다.

이 접근을 가능하게 만든 핵심 기술이 바로 eBPF다.

⸻

eBPF가 바꾼 게임의 규칙

eBPF 이전에는 커널 수준의 관측이 쉽지 않았다.
• 커널 모듈 작성 필요
• 시스템 안정성 리스크
• 운영 환경 적용이 부담스러움

eBPF는 이 흐름을 완전히 바꿨다.
• 커널에 코드를 안전하게 주입
• 검증(Verifier)을 통한 안정성 확보
• 런타임에 동적 로딩/제거 가능
• 낮은 오버헤드

Parca는 이 eBPF를 기반으로,
**“상시 CPU 프로파일링”**을 현실적인 선택지로 만든 도구다.

⸻

Parca란 무엇인가

Parca는 eBPF 기반 Continuous Profiling 시스템이다.

핵심 목표는 단순하다.

“프로세스와 컨테이너가
CPU 시간을 어디에서 소비하는지
항상, 낮은 오버헤드로 보여준다.”

이를 위해 Parca는 다음과 같은 특징을 가진다.
• 샘플링 기반 CPU profiling
• 유저 공간 + 커널 공간 스택 모두 수집
• Flamegraph 중심의 시각화
• 장시간 데이터 보존 및 비교 가능

중요한 점은,
Parca가 트레이싱 도구도, APM도 아니라는 것이다.

⸻

Parca는 관측성(Observability) 도구인가?

결론부터 말하면 그렇다.

하지만 전통적인 의미의 관측성과는 조금 다르다.
• Metrics: “얼마나 사용 중인가”
• Logs: “무슨 일이 발생했는가”
• Traces: “요청이 어떻게 흘렀는가”
• Parca: “CPU 시간은 정확히 어디에 쓰였는가”

Parca는
**시스템 내부의 시간 분해능(time attribution)**을 제공한다.

즉,
• CPU 80% 사용 → ❌
• CPU 80% 중 35%는 특정 함수,
   20%는 커널 스케줄링,
   15%는 lock 대기 → ⭕

이 차이는 매우 크다.

⸻

Parca가 풀어주는 질문들

Parca를 사용하면 다음과 같은 질문에 답할 수 있다.
• CPU가 바쁜 이유는 무엇인가?
• 특정 배포 이후 CPU 사용 패턴이 달라졌는가?
• 유저 코드와 커널 코드 중 어디에서 시간이 쓰이는가?
• 컨테이너별로 CPU hot path는 무엇인가?
• “느린데 이유를 설명할 수 없는” 문제의 원인은?

이 질문들은
기존 메트릭이나 APM만으로는 답하기 어려운 것들이다.

⸻

Parca는 무엇을 대체하지 않는다

중요한 점 하나를 짚고 가자.

Parca는:
• APM을 대체하지 않는다
• 기존 모니터링 에이전트를 없애지 않는다
• 로그 분석을 대신하지 않는다

Parca는 추가되는 관측 축이다.

특히 다음과 같은 경우에 강력하다.
• 성능 민감한 서버
• 시스템 프로그래밍 영역
• 커널/네이티브 코드 비중이 높은 환경
• 컨테이너 기반 인프라

⸻

이 연재에서 다룰 것

이 연재에서는 다음을 목표로 한다.
• Parca를 “설치하는 법”이 아니라
   “이해하고 해석하는 법”
• Flamegraph를 보는 눈
• eBPF 기반 profiling의 실제 의미
• APM과 Parca를 어떻게 함께 쓸 것인가

다음 편에서는
**Parca의 전체 아키텍처(Server, Agent, Storage)**를 그림 없이도 머릿속에 그릴 수 있도록 정리해 보겠다.

⸻

다음 편 예고

2편. Parca 아키텍처 한눈에 보기 – Server, Agent, Storage 구조