eBPF 공부방-Parca

10편. Parca는 누구에게 필요한 도구인가– 도입 판단 가이드 & 정리

SysBPF — Sat, 20 Dec 2025 10:58:16 +0900

아래는 10편(최종편) 전체 본문 확장판 초안입니다.
이 편은 연재의 결론 + 도입 판단 가이드 역할을 하도록 구성했습니다.

“Parca가 좋은가?”가 아니라 “누가 써야 하는가”
기술적 적합성 + 조직적 적합성
도입해도 실패하는 경우까지 포함
CTO / SRE / 플랫폼 팀이 읽어도 설득되는 구조

Parca는 누구에게 필요한 도구인가

도입 판단 가이드 & 연재 정리

이 연재를 여기까지 읽었다면,
이제 질문은 단순해진다.

“Parca는 쓸 수 있는 도구인가?” ❌
“우리에게 필요한 도구인가?” ⭕

Parca는 좋은 도구다.
하지만 모두에게 필요한 도구는 아니다.

이번 마지막 편에서는
Parca 도입 여부를 판단할 수 있도록
사람·조직·문제 유형 기준으로 정리한다.

1️⃣ Parca는 어떤 문제를 푸는 도구인가

Parca가 푸는 문제는 매우 명확하다.

“CPU 시간은 정확히 어디에서 소비되는가?”

이 질문에 대한 답이 필요하지 않다면
Parca는 과분한 도구다.

Parca가 잘 푸는 질문들

CPU 사용률은 정상인데 왜 느린가?
커널과 유저 코드 중 어디에서 병목이 생겼는가?
배포 전/후 성능이 실제로 바뀌었는가?
컨테이너 수 증가가 CPU 경로에 어떤 영향을 줬는가?
APM으로 설명되지 않는 성능 저하의 원인은?

Parca가 풀지 않는 질문들

어떤 API가 느린가?
에러율이 왜 증가했는가?
특정 사용자 요청의 전체 흐름은?
비즈니스 트랜잭션은 어떻게 흘렀는가?

이 질문들은 APM의 영역이다.

2️⃣ Parca가 “잘 맞는 사람들”

① 시스템 프로그래머 / 플랫폼 엔지니어

C/C++ / Rust / Go
커널 함수, syscall, lock에 익숙
“왜?”를 파고드는 성향

이들에게 Parca는:

“CPU 내부를 그대로 보여주는 현미경”

이다.

② SRE / 인프라 팀

장애 재현이 어려움
문제 발생 시 이미 지나가 있음
숫자 지표만으로 설명 불가

Parca는 SRE에게 이렇게 말해준다.

“문제는 이미 지나갔지만,
흔적은 남아 있다.”

③ Kubernetes / 컨테이너 플랫폼 팀

노드 단위 성능 분석 필요
컨테이너 간 간섭 문제
cgroup / scheduling 이슈

Parca는:

컨테이너 추상화를 벗기고
실제 커널 실행 경로를 보여준다.

3️⃣ Parca가 “잘 맞지 않는 사람들”

이 부분은 솔직해야 한다.

① 애플리케이션 개발자 단독 사용

Flamegraph 해석 경험 없음
커널 함수에 익숙하지 않음
“이게 느린 건지?” 판단 어려움

이 경우 Parca는:

“멋있지만, 이해하기 어려운 그래프”

로 남을 가능성이 크다.

② APM 대체를 기대하는 조직

❌ Parca = APM
❌ Parca = Prometheus 대체

이 기대를 가지고 시작하면
도입은 거의 확실히 실패한다.

③ 규제/포렌식 목적 환경

모든 데이터를 빠짐없이 저장
특정 시점의 정확한 증거 필요

Parca는:

일부 샘플 손실 허용
통계적 정확성 기반

목적이 다르다.

4️⃣ 조직 기준 도입 판단 가이드

아래 질문에 “예”가 많을수록 적합

성능 문제 재현이 자주 실패하는가?
“느리다”는 말을 수치로 설명하기 어려운가?
커널/네이티브 코드 비중이 있는가?
Kubernetes 환경에서 노드 병목이 의심되는가?
APM + 메트릭만으로 부족함을 느끼는가?

3개 이상이면 도입 검토 가치 충분이다.

5️⃣ Parca의 이상적인 포지션

Parca는 이 위치에 있어야 한다.

Metrics  → “문제가 있다”
APM      → “요청은 정상이다”
Parca    → “CPU는 여기서 막히고 있다”

즉,

Parca는 마지막 퍼즐 조각이다.

6️⃣ PoC → 운영으로 가는 현실적인 경로

절대 피해야 할 시작 방식

❌ 전 노드 일괄 배포
❌ “일단 깔아보자”
❌ Flamegraph 교육 없이 공개

7️⃣ Parca 연재 전체 요약 (한 페이지)

Parca는 Continuous Profiling 도구
Push/Pull 이분법보다 profiling 전용 구조
eBPF + CO-RE로 운영 가능
Flamegraph는 “정답”이 아니라 “지도”
컨테이너 환경에서 특히 강력
도입 실패 원인은 대부분 기술이 아니라 기대

8️⃣ 이 연재의 결론

Parca는 성능을 “보여주는” 도구가 아니라
성능을 “설명할 수 있게 만드는” 도구다.

숫자를 넘어
그래프를 넘어
“왜 그런가”에 답하게 만든다

그 답이 필요하다면,
Parca는 충분히 도입할 가치가 있다.

에필로그: 언제 Parca를 배우면 좋은가

perf를 써봤지만 답답할 때
APM이 “정상”만 말할 때
Kubernetes 성능이 미스터리일 때
“느리다”는 말을 증명해야 할 때

그때가 바로
Parca를 써야 할 시점이다.

9편. Parca 도입 시 현실적인 고려사항– 운영, 보안, 성능 관점

SysBPF — Sat, 20 Dec 2025 10:55:25 +0900

Parca 도입 시 현실적인 고려사항

운영, 보안, 성능 관점

Parca를 어느 정도 이해한 뒤,
실무에서는 결국 이 질문으로 수렴한다.

“그래서… 운영 서버에 깔아도 되는가?”

이 질문에 정직하게 답하지 못하면,
Parca는 PoC에서 멈추거나
“위험한 도구”라는 낙인이 찍힌다.

이번 편에서는
Parca 도입을 결정하기 전에 반드시 검토해야 할
현실적인 체크 포인트를 정리한다.

1️⃣ 운영 관점: 항상 켜도 되는가?

Parca의 기본 전제

상시 활성화를 전제로 설계
장애 시에만 켜는 도구 ❌
평상시 데이터를 쌓아두는 도구 ⭕️

하지만 “설계상 가능”과 “우리 환경에서 가능”은 다르다.

운영에서 가장 중요한 질문 3가지

agent가 죽으면 서비스에 영향이 있는가?
server가 죽으면 서비스에 영향이 있는가?
네트워크가 끊기면 무슨 일이 벌어지는가?

답은 다음과 같다

상황서비스 영향

parca-agent 종료	❌ 없음
parca-agent 장애	❌ 없음
Parca Server 장애	❌ 없음
agent ↔ server 단절	❌ 없음 (데이터 유실만 발생)

Parca는 운영 서버의 ‘비필수 컴포넌트’다.

운영 설계 철학 요약

관측 도구는
관측 대상의 가용성을 위협하면 안 된다.

Parca는 이 원칙을 비교적 충실히 지킨다.

2️⃣ 성능 관점: 오버헤드는 정말 낮은가?

오버헤드를 만드는 요소

Parca agent의 오버헤드는 다음 요소의 합이다.

perf_event 인터럽트
eBPF 프로그램 실행
stack trace 수집
userspace 전달
gRPC 전송

왜 오버헤드가 낮은가

샘플링 기반
tracing 아님
고정된 짧은 eBPF 코드
낮은 기본 샘플링 빈도 (보통 19Hz)
aggregation은 server에서 수행

샘플링 빈도 조절 예시

parca-agent \
  --sampling-frequency=19 \
  --store-address=parca-server:7070

19Hz → 운영 기본값
49Hz 이상 → 분석용
수백 Hz → 운영에서는 비권장

실제 체감 오버헤드

CPU 사용량: 수 % 미만
latency 영향: 대부분 측정 불가
스루풋 영향: 거의 없음

하지만 ⚠️ 다음 경우는 주의해야 한다.

성능 리스크가 커지는 경우

초고빈도 샘플링
CPU 이미 포화 상태
context switch가 극단적으로 많은 워크로드
RT kernel / low-latency kernel

Parca는 문제를 만들기보다는
문제가 있는 곳에서 더 잘 보인다.

3️⃣ 보안 관점: eBPF는 안전한가?

이 질문은 반드시 나온다.

“eBPF는 커널에 코드를 올리잖아요.
보안상 괜찮나요?”

eBPF의 안전장치

verifier:
- 무한 루프 금지
- 메모리 접근 제한
- 스택 크기 제한
helper API 제한
권한 없는 사용자 로딩 불가

Parca는 이 위에서 동작한다.

요구 권한 (중요)

parca-agent는 보통 다음 권한이 필요하다.

CAP_BPF
CAP_PERFMON
(일부 환경) CAP_SYS_ADMIN

Kubernetes에서는 흔히:(yaml)

securityContext:
  privileged: true

를 사용한다.

보안팀이 가장 싫어하는 포인트

privileged container
hostPID 사용
커널 접근

이건 기술 문제가 아니라 조직 정책 문제다.

현실적인 대응 전략

Parca agent는:
- 노드 전용
- 접근 통제된 네임스페이스
- 외부 통신 최소화
RBAC / NetworkPolicy로 제어
Server 접근도 내부망 한정

4️⃣ 스토리지 관점: 생각보다 크다

많이들 간과하는 부분이다.

프로파일 데이터는 생각보다 크다.

왜 스토리지를 많이 쓰는가

단순 수치 ❌
call stack 트리 ⭕️
시간 축 누적 ⭕️
diff 비교 ⭕️

실무 기준 조언

장기 보존 ❌
최근 며칠~수주 ⭕️
“항상 6개월치” 같은 목표는 위험

보존 전략은 반드시 필요하다.

5️⃣ 언제 켜고, 언제 끄는가

항상 켜 두기 좋은 경우

성능 민감 서비스
커널/네이티브 코드 비중 높음
재현 어려운 문제 잦음
플랫폼/SRE 팀 관리 영역

상시 활성화가 부담스러운 경우

CPU 이미 포화
커널 변경 불가
보안 정책 매우 엄격
단발성 분석 목적

이 경우는 필요 시 단기 활성화가 현실적이다.

6️⃣ Parca를 도입하면 안 되는 경우

이건 명확히 말해야 한다.

❌ 반드시 모든 샘플을 보존해야 하는 환경
❌ 규제/감사 목적의 포렌식 시스템
❌ 커널 접근이 원천적으로 불가능한 환경
❌ “APM 대체”를 기대하는 경우

Parca는 정밀 포렌식 도구가 아니다.

7️⃣ 도입 전 체크리스트 (요약)

커널 BTF 지원 여부
eBPF 사용 정책 검토
agent 권한 승인 가능 여부
네트워크 단절 시 데이터 유실 허용 여부
스토리지 보존 정책
“대체”가 아니라 “보완”임을 조직이 이해하는가

이 편의 결론

Parca는 기술적으로 훌륭하지만,
조직적으로 준비되지 않으면 실패한다.

성능: 대부분 안전
안정성: 매우 높음
보안: 기술보다 정책이 관건
운영: “항상 켜두는 관측”이라는 사고 전환 필요

다음 편 (마지막) 예고

연재의 마지막 편에서는
이 질문에 답한다.

“그래서 Parca는 누구에게 필요한 도구인가?”

다음 편

10편. Parca는 누구에게 필요한 도구인가 – 도입 판단 가이드 & 정리

8편. CO-RE와 Parca – 커널 의존성 문제는 어떻게 해결되는가

SysBPF — Sat, 20 Dec 2025 10:50:44 +0900

아래는 8편 전체 본문 확장판 초안입니다.
이번 편은 Parca가 “운영 환경에서도 안전하게 eBPF를 쓰는 이유”를 설명하는 핵심 이론 편입니다.

왜 eBPF가 커널 버전에 취약했는지
CO-RE가 무엇을 해결했는지
Parca / parca-agent가 이를 어떻게 활용하는지
실무자가 반드시 알아야 할 한계까지 포함

CO-RE와 Parca

커널 의존성 문제는 어떻게 해결되는가

eBPF를 공부하다 보면
반드시 한 번은 이런 말을 듣게 된다.

“eBPF는 좋은데,
커널 버전 맞추는 게 너무 힘들다.”

이 말은 과거에는 사실이었다.
그리고 CO-RE(Compile Once – Run Everywhere)는
이 문제를 정면으로 해결하기 위해 등장했다.

Parca는 바로 이 CO-RE 위에 설계된
운영 환경 친화적 eBPF 프로파일러다.

1️⃣ eBPF의 오래된 문제: 커널 의존성

초기의 eBPF 프로그램은 다음 문제를 안고 있었다.

커널 버전마다 struct 레이아웃이 다름
배포판마다 config 옵션 상이
minor version 차이에도 offset 변경
커널 업데이트 시 프로그램 재빌드 필요

즉,

“이 서버에서는 잘 되는데,
저 서버에서는 verifier에서 터진다.”

운영 환경에서는 거의 재앙에 가까운 문제였다.

2️⃣ 전통적인 해결책의 한계

CO-RE 이전에는 보통 이런 방법을 썼다.

① 커널 버전별 빌드

kernel 5.4용
kernel 5.10용
kernel 5.15용 …

→ 현실적으로 관리 불가

② 런타임 offset 추정

kprobe로 주소 추적
fragile한 휴리스틱
커널 패치 하나에 무너짐

→ 유지보수 지옥

3️⃣ CO-RE란 무엇인가

CO-RE는 이름 그대로다.

Compile Once, Run Everywhere

핵심 아이디어는 단순하다.

“컴파일 시점이 아니라,
로드 시점에 커널 구조체에 맞춘다.”

이를 가능하게 하는 핵심 기술이 BTF다.

4️⃣ BTF (BPF Type Format)

BTF는 다음을 제공한다.

커널 내부 struct 정의
필드 이름
타입 정보
오프셋 정보

이 정보는:

커널 빌드 시 생성
/sys/kernel/btf/vmlinux에 포함

즉,

“커널이 스스로 자기 타입 정보를 제공한다.”

5️⃣ CO-RE의 동작 원리

CO-RE eBPF 프로그램은 다음과 같이 동작한다.

eBPF object는 논리적 필드 접근으로 작성
로드 시:
- 커널의 BTF 정보 로드
- 실제 struct layout 확인
필드 접근을 실제 offset으로 재배치(relocation)

CO-RE 스타일 코드 예시

struct task_struct *task = (struct task_struct *)bpf_get_current_task();

/* CO-RE field access */
u32 pid = BPF_CORE_READ(task, pid);

이 코드는:

kernel 5.4
kernel 5.10
kernel 6.x

모두에서 같은 바이너리로 동작한다.

CO-RE 이전 코드 (위험)

u32 pid = task->pid;  /* offset 고정 가정 */

→ 커널이 바뀌면 바로 깨진다.

6️⃣ Parca에서 CO-RE가 중요한 이유

Parca는 다음 특성을 가진다.

노드 수 많음
커널 버전 제각각
Kubernetes 환경
빈번한 커널 업데이트

이 상황에서:

“노드마다 agent를 다시 빌드한다”
→ 사실상 불가능

Parca의 선택

parca-agent는 CO-RE 기반 eBPF
하나의 바이너리로:
- Ubuntu
- RHEL
- Amazon Linux
- GKE / EKS / AKS

에서 동작

이게 바로 운영 가능성의 핵심이다.

7️⃣ CO-RE가 해결하는 것 vs 해결하지 못하는 것

해결하는 것

struct layout 변경
필드 offset 차이
커널 minor version 차이
배포판 간 config 차이 일부

해결하지 못하는 것

BTF가 없는 커널
너무 오래된 커널 (4.x 초반)
eBPF helper 자체가 없는 경우
verifier 정책 차이

즉,

CO-RE는 “만능”이 아니라
“운영 가능성의 기준선”이다.

8️⃣ Parca 운영 시 CO-RE 관련 체크 포인트

반드시 확인할 것

/sys/kernel/btf/vmlinux 존재 여부
커널이 CONFIG_DEBUG_INFO_BTF 활성화
parca-agent 로그에 CO-RE fallback 여부

실패 시 나타나는 증상

agent 기동 실패
verifier reject
“failed to load BPF program” 로그

이 경우:

커널 업그레이드
BTF-enabled 커널 사용

외에는 답이 없다.

9️⃣ 왜 CO-RE가 “게임 체인저”인가

CO-RE 이전:

eBPF는 전문가의 장난감
운영 투입 부담 큼

CO-RE 이후:

eBPF는 인프라 도구
Parca 같은 제품 가능

CO-RE는 eBPF를
“데모 기술”에서
“운영 기술”로 끌어올렸다.

10️⃣ 이 편의 핵심 요약

eBPF의 최대 약점은 커널 의존성
CO-RE + BTF가 이를 해결
Parca는 CO-RE 없이는 성립 불가
운영 환경에서 Parca가 안정적인 이유

다음 편 예고

다음 편에서는
Parca 도입 시 현실적인 고민들을 다룬다.

오버헤드
보안
언제 켜야 하고, 언제 끄는가
도입하면 안 되는 경우

다음 편

9편. Parca 도입 시 현실적인 고려사항 – 운영, 보안, 성능 관점

7편. 컨테이너·Kubernetes 환경에서의 Parca– PID, Namespace, cgroup 관점

SysBPF — Sat, 20 Dec 2025 10:46:11 +0900

아래는 7편 전체 본문 확장판 초안입니다.
이번 편은 Parca를 Kubernetes 환경에서 “제대로” 쓰기 위한 핵심 이론 편입니다.

컨테이너 환경에서 왜 profiling이 더 어려운지
PID / Namespace / cgroup 관점에서 Parca가 무엇을 보고 있는지
Flamegraph를 어디까지 믿어도 되는지
실무에서 가장 많이 헷갈리는 포인트 정리

컨테이너·Kubernetes 환경에서의 Parca

PID, Namespace, cgroup 관점

Parca를 Kubernetes 환경에 배포한 뒤
Flamegraph를 처음 보면 이런 생각이 들 수 있다.

“이게 어느 컨테이너 거지?”
“PID가 왜 이렇게 이상하지?”
“노드 커널 함수가 왜 이렇게 많이 보이지?”

이 혼란은 도구의 문제가 아니라,
컨테이너 실행 모델을 충분히 이해하지 못했기 때문이다.

이번 편에서는
Parca를 Kubernetes 환경에서 해석하기 위해
반드시 알아야 할 3가지 축을 정리한다.

PID Namespace
다른 Namespace들
cgroup

1️⃣ 컨테이너 환경에서 profiling이 어려운 이유

컨테이너는 “가상 머신”이 아니다.

커널은 호스트와 공유
프로세스는 Namespace로 분리
자원 사용량은 cgroup으로 제한

즉,

“하나의 커널 위에
여러 개의 논리적 세계가 겹쳐 있다.”

Parca는 이 겹침을 그대로 본다.

2️⃣ PID Namespace 관점에서의 Parca

컨테이너의 PID 1은 진짜 1이 아니다

컨테이너 안에서 보면:

$ ps -ef
PID 1  my-app

하지만 노드에서 보면:

$ ps -ef | grep my-app
PID 34721 my-app

컨테이너 내부: PID namespace 기준
노드/커널: 호스트 PID 기준

Parca는 어느 쪽을 보는가?

Parca는 커널이 보는 PID를 기준으로 샘플링한다.

즉:

Flamegraph에 보이는 PID = 호스트 PID
컨테이너 내부 PID와 일치하지 않는 것이 정상

실무에서의 오해 포인트

❌ “왜 PID 1이 안 보이지?”
⭕ “PID 1은 컨테이너 namespace 안의 논리적 번호다”

Parca는 컨테이너 환상을 벗겨낸 상태를 보여준다.

3️⃣ Namespace 관점: 격리는 “완전하지 않다”

컨테이너는 여러 namespace로 격리된다.

PID
Mount
Network
IPC
UTS
User

하지만 중요한 사실 하나:

CPU 실행은 namespace로 격리되지 않는다.

스케줄링
syscall
interrupt
context switch

이 모든 것은 호스트 커널 전역이다.

Flamegraph에 커널 함수가 많은 이유

Kubernetes 환경에서 Parca Flamegraph를 보면
다음이 자주 보인다.

__schedule()
do_syscall_64()
futex_wait()

이건 이상이 아니다.

컨테이너 수 증가
스레드 수 증가
락 / I/O 증가

→ 커널 비중 자연 증가

4️⃣ cgroup: 컨테이너를 구분하는 핵심 단서

여기서 Parca가 빛을 발한다.

컨테이너 구분의 핵심은 PID가 아니라 cgroup이다.

Parca는 cgroup 정보를 수집한다

parca-agent는 샘플링 시점에:

현재 task의 cgroup 정보
container / pod label

을 함께 태깅한다.

이 덕분에 Parca Server에서는:

pod 단위
container 단위
namespace 단위

로 Flamegraph를 필터링할 수 있다.

Kubernetes에서의 필터링 예

namespace = "production"
pod       = "api-server-7f9c8d"
container = "app"

→ 이 조건으로 보면
다른 컨테이너의 CPU 경로는 완전히 제거된다.

5️⃣ “PID 1”이 Flamegraph에 보일 때의 의미

Kubernetes 환경에서 흔히 보이는 장면이다.

PID 1
 └─ pause

이건 오류가 아니다.

pause 컨테이너의 역할

pod의 네트워크 namespace 유지
실제 workload 없음
하지만 namespace anchor 역할

Parca Flamegraph에서 pause가 보인다면:

CPU를 썼다는 의미 ❌
namespace 경로상 등장했다는 의미 ⭕

6️⃣ DaemonSet으로 배포하는 이유

Parca Agent는 반드시 노드 단위로 배포해야 한다.

이유

eBPF는 노드 커널에 attach
컨테이너 하나에만 붙이면:
- 다른 컨테이너의 CPU 실행 경로 누락
- 커널 스택 왜곡

DaemonSet 예시(yaml)

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: parca-agent
spec:
  template:
    spec:
      hostPID: true
      containers:
      - name: parca-agent
        image: ghcr.io/parca-dev/parca-agent
        securityContext:
          privileged: true

hostPID는 선택이 아니라 필수에 가깝다

7️⃣ Kubernetes 환경에서 Flamegraph 해석 요령

반드시 지켜야 할 규칙
1. 필터부터 걸고 본다
  - namespace / pod / container
2. PID 번호에 집착하지 않는다
3. 커널 함수 비중을 정상으로 받아들인다
4. 단일 Flamegraph로 결론 내리지 않는다
자주 하는 잘못된 해석❌ “PID가 이상하니 Parca가 틀렸다”
⭕ “PID namespace를 이해해야 한다”
8️⃣ 이 편의 핵심 요약
- Parca는 컨테이너가 아니라 커널을 본다
- 컨테이너 구분은 PID가 아니라 cgroup
- Kubernetes에서 Parca는:
  - 더 강력해지고
  - 동시에 더 오해받기 쉽다
컨테이너는 추상화이고,
Parca는 그 추상화를 벗긴다.
다음 편 예고
- 커널 버전 차이를 어떻게 극복하는가
- BTF는 무엇인가
- 왜 운영 환경에서 중요한가
다음 편
8편. CO-RE와 Parca – 커널 의존성 문제는 어떻게 해결되는가
다음 편에서는
Parca의 또 다른 핵심 기술인 CO-RE를 다룬다.
❌ “커널 함수가 많으니 커널 문제다”
⭕ “컨테이너 수 증가로 커널 경로가 늘었다”

Datadog은 push 모델

SysBPF — Fri, 19 Dec 2025 07:02:35 +0900

1. Datadog의 기본 수집 방식 (Push)

Datadog은 호스트(또는 컨테이너)에 Datadog Agent를 설치하고,
이 Agent가 주기적으로 Datadog SaaS 백엔드로 데이터를 전송(push) 합니다.

흐름

[Application / OS / Container]
          ↓
     Datadog Agent
          ↓  (HTTPS, outbound)
     Datadog Backend

Agent가 수집하는 것
• 시스템 메트릭 (CPU, Memory, Disk, Network)
• 애플리케이션 메트릭
• 로그 (선택)
• APM Trace
• 프로파일링 데이터
• 컨테이너 / Kubernetes 메타데이터

→ 모두 Agent가 주도적으로 전송합니다.

⸻

2. Prometheus와의 결정적 차이

항목 Datadog Prometheus
수집 주체 Agent Prometheus Server
모델 Push (Agent → Backend) Pull (Server → Target)
네트워크 Outbound 위주 Inbound 필요
SaaS 친화성 매우 높음 상대적으로 낮음
방화벽 구성 단순 복잡해질 수 있음

Datadog이 대규모 SaaS 환경, 기업망, 클라우드에서 많이 쓰이는 이유 중 하나가 Push 기반이라 네트워크 제약이 적기 때문입니다.

⸻

3. “그런데 Pull처럼 보이는 경우” (예외적 요소)

Datadog 내부에는 Pull 성격을 가진 구성 요소도 일부 존재합니다.

1) Prometheus Integration
• Datadog Agent가 Prometheus exporter endpoint를 scrape
• 이 경우:
• Prometheus Server → Pull ❌
• Datadog Agent → Pull (scrape) ⭕

즉, Datadog 전체 아키텍처는 Push지만,
Agent 내부에서 특정 타겟을 Pull하는 구조는 존재합니다.

⸻

2) OpenMetrics / StatsD
• 애플리케이션 → Agent 로 Push
• Agent → Datadog Backend 로 Push

여전히 전체 흐름은 Push 기반입니다.

⸻

4. 한 문장 요약

Datadog은 전체 시스템 관점에서는 명확한 Push 모델이며,
Agent 내부에서만 제한적으로 Pull(scrape)을 사용한다.

⸻

5. eBPF·Parca·Prometheus를 같이 보는 관점에서

지금처럼 eBPF, Parca, Prometheus, Datadog을 함께 비교하는 상황이라면
구조를 이렇게 이해하면 정확합니다.
• Prometheus: Pull-first, TSDB 중심
• Datadog: Agent-centric Push-first SaaS
• Parca: Pull + eBPF profiling (Prometheus 생태계 친화)

Prometheus는 Pull 모델

SysBPF — Fri, 19 Dec 2025 06:23:45 +0900

Prometheus의 기본 수집 방식 (Pull)
• Prometheus 서버가 주기적으로(Target scrape interval)
각 대상(exporter, 애플리케이션)의 HTTP endpoint에 직접 요청합니다.
• 보통 /metrics 엔드포인트를 사용합니다.
• 대상이 제공하는 현재 시점의 메트릭 스냅샷을 가져옵니다.

Prometheus Server  --->  HTTP GET /metrics  --->  Target (Exporter/App)

이 구조가 Prometheus 설계의 중심입니다.

⸻

왜 Pull 모델을 선택했는가

Pull 모델은 Prometheus 철학과 잘 맞습니다.
1. 서비스 디스커버리와 궁합이 좋음
• Kubernetes, Consul, EC2 등에서 대상이 동적으로 변해도
• Prometheus가 “누구를 수집할지”를 스스로 결정
2. 장애 격리가 쉬움
• 대상이 죽어도 Prometheus는 scrape 실패로 인지
• 대상이 Prometheus 상태를 신경 쓸 필요 없음
3. 재현성과 디버깅
• 브라우저나 curl로 /metrics 직접 확인 가능
• “이 시점에 무엇이 노출되는가”가 명확

⸻

예외: Push 방식도 존재함 (Pushgateway)

Prometheus 생태계에는 예외적으로 Push 방식이 있습니다.

Pushgateway
• 짧게 실행되는 batch job을 위한 보조 컴포넌트
• job이 직접 Prometheus로 보내는 게 아니라,
Pushgateway에 push
• Prometheus는 Pushgateway를 pull

Batch Job  --->  Pushgateway  <---  Prometheus (pull)

중요한 점:
• Prometheus 자체는 여전히 Pull
• Pushgateway는 임시 저장소 역할

⸻

정리
• Prometheus 본체의 수집 모델은 Pull
• Push는 예외적 보완 수단
• 설계 철학상 Push 중심 모니터링 시스템과는 명확히 다름

한 줄 요약하면:

Prometheus는 Pull-first 시스템이며, Push는 특수한 경우에만 사용된다.

6편. 실전 사례 ① – CPU 사용률은 정상인데, 성능은 느린 이유

SysBPF — Thu, 18 Dec 2025 20:27:08 +0900

실전 사례 ①

CPU 사용률은 정상인데, 성능은 느린 이유

운영 중인 서버에서 다음과 같은 리포트를 받았다고 가정해 보자.

CPU 사용률: 평균 40~50%
Load Average: 정상
메모리 여유 충분
APM: 주요 API 응답 시간 “정상 범위”
사용자 체감: “전체적으로 느림”

이 상황은 의외로 매우 흔하다.
그리고 가장 골치 아픈 유형이기도 하다.

1. 문제의 핵심: “정상 지표”의 함정

전통적 모니터링 지표

CPU: 45%
Memory: 62%
Disk IO: 낮음
Network: 정상

→ 문제 없어 보인다.

APM 지표

/api/search 평균 110ms
/api/order 평균 180ms
에러율 0%

→ 역시 문제 없어 보인다.

이 단계에서 흔히 나오는 결론은 이것이다.

“일시적인 네트워크 문제였나 봅니다.”

하지만 사용자는 여전히 느리다고 말한다.

2. 문제를 다시 정의하기

여기서 질문을 바꿔야 한다.

❌ “CPU가 얼마나 쓰이고 있는가?”
⭕ “CPU가 실제로 무엇을 하고 있는가?”

이 질문은
기존 메트릭이나 APM으로는 답할 수 없다.

이 지점에서 Parca를 투입한다.

3. Parca로 본 Flamegraph 첫 화면

Flamegraph를 처음 보면 이런 특징이 보인다.

전체 폭은 넓지 않다 (CPU 사용률이 낮으니)
그런데 커널 함수 비중이 유난히 크다
__schedule() / futex_wait() 가 반복 등장

이 화면이 말해주는 메시지는 명확하다.

CPU는 계산을 안 하고,
기다리는 데 시간을 쓰고 있다.

4. Flamegraph 해석 단계별 사고 과정

1단계: 바닥부터 보기

바닥(entry)에 다음과 같은 경로가 반복된다.

sys_futex
 └─ futex_wait
     └─ __schedule

이 패턴은 거의 공식처럼 해석할 수 있다.

“스레드가 락을 기다리며 잠들었다.”

2단계: 유저 코드와의 연결점 찾기

커널 스택 위쪽을 따라 올라가면
유저 공간 함수가 보이기 시작한다.

pthread_mutex_lock
 └─ cache_update()
     └─ handle_request()

이제 그림이 그려진다.

요청 처리 중
특정 cache_update 로직에서
mutex lock 대기 발생
스레드가 잠들며 context switch

5. 왜 CPU 사용률은 낮았는가?

이 질문이 핵심이다.

CPU 사용률이 낮다는 것은:

CPU가 놀고 있다 ❌
실행할 준비가 된 스레드가 없다 ⭕

락 대기로 스레드들이 잠들어 있으면
CPU는 놀게 된다.

즉,

CPU 사용률은 낮지만
시스템은 느릴 수 있다.

6. APM으로는 왜 보이지 않았을까?

APM의 관점은 “요청”이다.

요청 시작
DB 쿼리
비즈니스 로직
응답 반환

락 대기는 보통 이렇게 보인다.

Business logic: 180ms

APM은 말하지 않는다.

그 180ms 중
몇 ms가 락 대기인지
몇 ms가 실제 계산인지

Parca는 이 공백을 메운다.

7. 코드 레벨에서의 문제 예시

문제의 원인이 된 코드를 단순화하면 다음과 같았다.

pthread_mutex_lock(&cache_lock);

/* cache 갱신 */
update_global_cache(req);

pthread_mutex_unlock(&cache_lock);

문제는 이 코드가:

모든 요청 경로에서
동일한 전역 락을 사용
cache update 빈도가 높음

결과적으로:

요청 수 증가
락 경합 증가
스레드 대기 증가
체감 성능 저하

8. Parca가 아니었다면?

이 문제를 Parca 없이 찾으려면:

perf 수동 실행
문제 시점 재현 시도
운 좋게 같은 상황 발생
커널 스택 해석

운영 환경에서는 거의 불가능에 가깝다.

Parca는 이미 문제 시점의 흔적을
저장해 두고 있었다.

9. 개선 후 Diff Flamegraph

개선은 단순했다.

전역 mutex 제거
shard 기반 lock 분리
cache update 최소화

배포 전/후 Diff Flamegraph 비교

Parca의 Diff Flamegraph는
두 시점(또는 두 배포 버전)의 CPU 실행 경로 변화를 색상으로 직관적으로 보여준다.

빨간색: CPU 사용이 증가한 경로
파란색: CPU 사용이 감소한 경로
회색/중립: 큰 변화 없음

배포 전 (Before)

__schedule()
futex_wait()
pthread_mutex_lock()

경로가 넓고 반복적으로 등장
→ 스레드가 자주 잠들고 깨어남
→ 락 경합 + 스케줄링 오버헤드

배포 후 (After)

커널 스케줄링 경로 파란색으로 감소
유저 함수 실행 경로 상대적으로 증가
Flamegraph의 “톱니형 분기” 감소

이는 다음을 의미한다.

CPU가 기다리는 시간은 줄고,
실제 일을 하는 시간은 늘어났다.

이 Diff 화면이 주는 결정적 가치

이 한 장의 Diff Flamegraph만으로도 다음을 동시에 설명할 수 있다.

왜 체감 성능이 개선되었는지
왜 CPU 사용률이 크게 변하지 않았는지
왜 APM 지표는 큰 변화가 없었는지

즉,

“성능 개선이 실제로 CPU 실행 경로를 바꿨다”
는 증거가 된다.

10. 이 사례가 주는 교훈

이 사례의 핵심은 이것이다.

CPU 사용률은 결과일 뿐
원인은 실행 경로에 있다
APM과 메트릭은 충분조건이 아니다

Parca는 다음 질문에 답해준다.

“CPU 시간이 왜 그렇게 쓰였는가?”

체크리스트: 비슷한 증상을 만났다면

CPU 사용률은 정상인데 느리다
APM은 정상인데 체감이 나쁘다
요청 수가 늘수록 더 느려진다
컨텍스트 스위치가 많아 보인다

→ Parca로 커널 스택부터 확인하라

이 편의 결론

“느리다”는 말은 감정이지만,
Flamegraph는 증거다.

Parca는
설명하기 어려운 성능 문제를
말로 설명 가능하게 만들어 주는 도구다.

다음 편 예고

다음 편에서는
이번보다 한 단계 더 들어가서,

컨테이너 환경
Kubernetes
PID / namespace / cgroup

에서 Parca를 어떻게 해석해야 하는지를 다룬다.

다음 편

7편. 컨테이너·Kubernetes 환경에서의 Parca – PID, Namespace, cgroup 관점

5편. Flamegraph 제대로 읽기– Parca UI 해석 가이드

SysBPF — Thu, 18 Dec 2025 20:15:05 +0900

Flamegraph 제대로 읽기

Parca UI 해석 가이드

Parca를 처음 실행하면 대부분 이런 반응을 보인다.

“그래프는 나오는데…
이걸 어떻게 해석해야 하지?”

Flamegraph는 직관적인 듯 보이지만,
실제로는 매우 쉽게 오해되는 시각화다.

이번 편의 목표는 단 하나다.

Flamegraph를 ‘그림’이 아니라
‘성능 설명 도구’로 읽게 만드는 것

Flamegraph는 무엇을 보여주는가 (한 문장 정의)

Flamegraph는
CPU 시간이 어떤 함수 호출 경로에서
얼마나 사용되었는지를 보여준다.

여기서 핵심 단어는 세 가지다.

CPU 시간
함수 호출 경로 (call stack)
누적 분포

Parca UI에서 보는 Flamegraph는 다음과 같은 규칙을 가진다.

X축: 시간 비율 (가로 폭)

가로 폭이 넓을수록
→ CPU 시간을 많이 사용
좌우 위치 자체에는 의미 없음
폭만 의미가 있다

Y축: 호출 깊이 (세로)

아래 → 위로 갈수록
→ 더 깊은 함수 호출
맨 아래는 진입점 (entry)
맨 위는 실제 실행 지점 (hot code)

가장 흔한 오해 ①

“위에 있는 함수가 범인이다?”

❌ 틀렸다.

Flamegraph에서 위에 있다는 사실 자체는 중요하지 않다.

중요한 것은:

얼마나 넓은 경로의 ‘끝’에 있는가

잘못된 해석 예

맨 위에 custom_hash_lookup() 이 있음
→ 이 함수가 문제다

이 해석은 위험하다.

올바른 질문은 이것이다.

“custom_hash_lookup() 이
전체 CPU 시간 중 몇 %의 경로에 포함되는가?”

Inclusive Cost vs Exclusive Cost

Flamegraph를 이해하는 핵심 개념이다.

Inclusive Cost (포함 비용)

어떤 함수 +
그 함수가 호출한 모든 하위 함수
Flamegraph의 가로 폭

Exclusive Cost (자기 비용)

해당 함수 자체 실행 시간
Flamegraph에서는 직접 보이지 않음
툴팁이나 diff로 해석

예시 사고 흐름

A()
 └─ B()
     └─ C()

C가 느리면
→ A, B, C 모두 넓게 보인다
A가 넓다고 해서
→ A가 문제인 것은 아니다

Flamegraph를 읽는 올바른 순서

많은 사람들이 위에서 아래로 본다.
하지만 정답은 반대다.

1단계: 바닥부터 본다

맨 아래 함수는 무엇인가?
entry point는 어디인가?
- syscall?
- 런타임?
- application main loop?

2단계: 넓은 “기둥”을 찾는다

특정 함수 위로
지속적으로 넓은 폭이 유지되는가
중간에 폭이 갑자기 좁아지지 않는가

3단계: 분기 지점을 본다

한 함수에서
여러 갈래로 나뉘는가?
특정 분기만 유난히 넓은가?

이 지점이 의사결정 포인트다.

커널 스택 vs 유저 스택 구분하기

Parca Flamegraph의 강력한 점은
커널과 유저 스택을 함께 보여준다는 것이다.

커널 함수가 넓게 보이는 경우

__schedule()
mutex_lock()
futex_wait()

의미하는 바는 보통 다음 중 하나다.

락 경합
스레드 대기
스케줄링 지연
과도한 context switch

이 경우 애플리케이션 코드만 보면 답이 없다.

유저 함수가 넓게 보이는 경우

parse_json()
custom_hash_lookup()
compress_block()

이 경우는 비교적 단순하다.

알고리즘 문제
데이터 구조 문제
캐시 미스
불필요한 반복

실전 예제 ①

“CPU 사용률은 높은데, 일은 안 한다”

Flamegraph 특징

__schedule() 폭이 매우 넓음
여러 경로에서 반복 등장
유저 함수는 상대적으로 얇음

해석

CPU는 바쁘지만
실제 계산은 거의 하지 않는다

→ 락/동기화 문제

APM으로는 거의 잡히지 않는 유형이다.

실전 예제 ②

“특정 배포 이후 느려졌다”

이럴 때 Parca의 진가는 **비교(diff)**에서 나온다.

Diff Flamegraph의 의미

빨간색: 증가한 CPU 경로
파란색: 감소한 CPU 경로

custom_hash_lookup() +12%
old_cache_lookup()   -8%

이 한 화면으로
**성능 회귀(regression)**를 설명할 수 있다.

Flamegraph는 “원인 후보 지도”다

중요한 관점 하나를 강조하자.

Flamegraph는
“정답”을 알려주지 않는다
“의심 지점”을 알려준다

왜 넓은가?
왜 이 경로가 많아졌는가?
왜 이전에는 없었는가?

이 질문은
사람이 해야 한다.

Parca UI에서 꼭 봐야 할 포인트

시간 범위를 좁혀서 본다
배포 시점 전/후 비교
label(node, pod, container) 필터 적극 활용
하나의 Flamegraph로 결론 내리지 않는다

자주 하는 치명적 실수 정리

❌ “위에 있는 함수 = 범인”
❌ “한 장의 Flamegraph로 결론”
❌ 커널 스택 무시
❌ 폭이 좁은데 이름만 보고 의심

이 편의 결론

Flamegraph를 제대로 읽을 수 있게 되면:

CPU 사용률 숫자는 의미를 잃는다
“느리다”는 말을 설명할 수 있게 된다
성능 문제 논의가 감정이 아니라 근거가 된다

Parca의 가치는
Flamegraph를 이해하는 순간부터 시작된다.

다음 편 예고

다음 편에서는
Flamegraph를 실제 장애·성능 이슈에 적용하는
실전 사례 중심 편으로 넘어간다.

다음 편

6편. 실전 사례 ① – CPU 사용률은 정상인데, 성능은 느린 이유

4편. Parca와 기존 APM / 모니터링 에이전트 비교– 무엇이 같고, 무엇이 다른가

SysBPF — Thu, 18 Dec 2025 20:08:03 +0900

Parca와 기존 APM / 모니터링 에이전트 비교

무엇이 같고, 무엇이 다른가

Parca를 처음 접하면 많은 사람들이 이렇게 묻는다.

“이거 APM이랑 뭐가 다른가요?”
“기존 모니터링 에이전트랑 겹치지 않나요?”

이 질문은 매우 자연스럽다.
그리고 이 질문에 제대로 답하지 못하면
Parca는 ‘굳이 써야 하나?’라는 도구로 남게 된다.

이번 편에서는
Parca, APM, 전통적 모니터링 에이전트를
같은 테이블 위에 올려놓고 비교한다.

먼저 한 문장 요약부터

APM은 ‘요청’을 본다
모니터링 에이전트는 ‘자원’을 본다
Parca는 ‘CPU 시간의 실제 사용처’를 본다

이 문장을 이해하면
이번 글의 절반은 이미 이해한 셈이다.

비교 대상 정리

이번 글에서 비교할 대상은 다음 세 가지다.

전통적 모니터링 에이전트
- CPU, Memory, Disk, Network
- node_exporter, collectd, custom agent 등
APM (Application Performance Monitoring)
- New Relic, Datadog APM, Elastic APM 등
Parca (Continuous Profiling)

관점 1: “무엇을 관측하는가”

전통적 모니터링 에이전트

관측 대상은 리소스 수치다.

CPU 사용률 (%)
Load Average
Memory 사용량
Disk I/O
Network throughput

예시:

CPU usage: 82%
Load average: 5.6

하지만 여기에는 중요한 정보가 없다.

“82%가 왜 발생했는가?”

APM

APM은 요청(Request) 중심이다.

트랜잭션 응답 시간
API별 latency
DB 쿼리 시간
에러율

예시 (개념):

GET /api/order
  total: 420ms
    ├─ DB query: 210ms
    ├─ Cache lookup: 20ms
    └─ Business logic: 190ms

APM은 다음 질문에는 강하다.

어떤 API가 느린가?
어느 쿼리가 병목인가?

하지만 이 질문에는 약하다.

“그 190ms 동안 CPU는 무엇을 하고 있었는가?”

Parca

Parca의 관측 대상은 완전히 다르다.

CPU 시간이 실제로 소모된 함수 호출 경로

즉,

요청 ❌
리소스 총량 ❌
실행 경로 ⭕

Parca는 이렇게 말한다.

CPU 시간의 27%는 함수 A
CPU 시간의 18%는 커널 스케줄링
CPU 시간의 12%는 lock contention

관점 2: 수집 방식의 차이

항목모니터링 에이전트APMParca

수집 방식	주기적 폴링	코드 계측	샘플링
개입 수준	낮음	중~높음	매우 낮음
커널 관측	거의 없음	제한적	핵심
상시 활성화	가능	부담 있음	가능

APM의 코드 계측(Instrumenation)

APM은 보통 이런 방식이다.

@Trace
public Order createOrder(...) {
    ...
}

코드에 개입
프레임워크 의존
언어별 구현 필요

장점은 명확하다.

비즈니스 흐름을 정확히 안다

단점도 분명하다.

네이티브 코드, 커널 영역은 블랙박스
계측이 많아질수록 오버헤드 증가

Parca의 샘플링 방식

Parca는 코드를 전혀 수정하지 않는다.

“지금 이 CPU는 어떤 스택 위에 있는가?”

이 질문을
초당 수십 번, 무작위 시점에 묻는다.

이 방식의 결과는 다음과 같다.

코드 수정 없음
언어 독립적
커널/유저 스택 모두 관측

관점 3: 문제 유형별 적합성

이런 문제는 APM이 강하다

특정 API가 느리다
DB 쿼리가 병목이다
에러율이 증가했다
사용자 요청 흐름을 보고 싶다

이런 문제는 Parca가 강하다

CPU 사용률은 높은데 이유를 모르겠다
특정 배포 이후 성능이 애매하게 나빠졌다
Lock, syscall, scheduling 이 의심된다
커널 비중이 높은 서비스다
“느린데 설명이 안 된다”

실전 사례 비교

상황

CPU 사용률: 75%
APM: 모든 API 정상
사용자: “전체적으로 느림”

APM이 보여주는 것

/api/search 평균 응답시간: 120ms (정상)
/api/order 평균 응답시간: 180ms (정상)
에러율: 0%

→ 판단 불가

Parca가 보여주는 것

CPU 시간 분포:
- __schedule(): 22%
- mutex_lock(): 17%
- custom_hash_lookup(): 14%

→ 락 경합으로 인한 스케줄링 병목

이 순간 Parca의 존재 이유가 드러난다.

“중복되는 지표”에 대한 오해

자주 나오는 말이 있다.

“CPU 사용률은 기존 에이전트도 보잖아요?”

맞다.
하지만 ‘사용률’과 ‘사용처’는 전혀 다르다.

CPU 80% ❌
CPU 80% 중 무엇이 80%인가 ⭕

Parca는 지표를 하나 더 추가하는 도구가 아니다.
차원을 하나 더 추가하는 도구다.

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

다시 한 번 강조하자.

Parca는 APM을 대체하지 않는다
Parca는 Prometheus를 대체하지 않는다
Parca는 로그 시스템을 대체하지 않는다

Parca는 이렇게 쓰일 때 가장 강력하다.

Metrics  → “문제가 있다”
APM      → “요청은 정상이다”
Parca    → “CPU는 여기서 막히고 있다”

함께 쓸 때 가장 이상적인 조합

목적도구

시스템 상태	Prometheus / node exporter
요청 분석	APM
CPU 병목	Parca
원인 확증	perf / bpftrace

Parca는 **“마지막 퍼즐 조각”**에 가깝다.

이 편의 결론

Parca는:

모든 문제를 해결하는 도구가 아니다
하지만 특정 문제에는 대체 불가능하다
특히 시스템 프로그래머, 플랫폼 팀, SRE에게 강력하다

“왜 느린지 설명할 수 있을 때,
비로소 성능 문제는 해결된다.”

Parca는
그 “설명”을 가능하게 해 주는 도구다.

다음 편 예고

다음 편에서는
Parca의 핵심 결과물인 Flamegraph를 다룬다.

Flamegraph는 왜 이런 모양인가
X축과 Y축의 정확한 의미
Inclusive / Exclusive 비용
흔히 저지르는 치명적인 오해

다음 편

5편. Flamegraph 제대로 읽기 – Parca UI 해석 가이드

3편. parca-agent 내부 구조 분석 – eBPF 기반 수집 메커니즘

SysBPF — Thu, 18 Dec 2025 19:49:48 +0900

parca-agent 내부 구조 분석

eBPF 기반 수집 메커니즘

Parca를 “설치해 보는 도구”가 아니라
신뢰할 수 있는 성능 분석 도구로 받아들이기 위해서는
반드시 한 번은 짚고 넘어가야 할 질문이 있다.

parca-agent는 정확히 무엇을,
어떤 방식으로,
얼마나 자주 수집하는가?

이번 편에서는 이 질문에 답한다.

parca-agent의 역할 다시 정리

먼저 역할을 다시 명확히 하자.

parca-agent는:

CPU 사용량을 계산하지 않는다
병목을 판단하지 않는다
Flamegraph를 만들지 않는다

parca-agent가 하는 일은 단 하나다.

“CPU가 인터럽트된 순간의
실행 스택을 샘플링한다.”

모든 분석은
이 단순한 행위의 반복 위에 쌓인다.

전체 수집 흐름 한눈에 보기

parca-agent의 내부 동작을 흐름으로 단순화하면 다음과 같다.

CPU 주기적 인터럽트
        ↓
perf_event 발생
        ↓
eBPF 프로그램 실행
        ↓
유저 스택 + 커널 스택 수집
        ↓
stack trace ID 생성
        ↓
user space(agent)로 전달
        ↓
protobuf 직렬화
        ↓
Parca Server 전송

핵심은
**“이 모든 과정이 커널 안전성 검증 하에서,
짧은 시간 안에 끝난다”**는 점이다.

perf_event 기반 샘플링

왜 타이머가 아니라 perf_event 인가?

parca-agent는 CPU profiling을 위해
Linux의 perf_event 서브시스템을 사용한다.

이 방식의 장점은 다음과 같다.

하드웨어 성능 이벤트와 자연스럽게 연계
커널 스케줄링과 정합성 유지
이미 검증된 고성능 인터페이스

개념적으로는 다음과 같다.

“CPU가 일정 주기마다
‘지금 뭐 하고 있니?’ 하고 묻는다”

perf_event 설정 개념 예시 (단순화)

struct perf_event_attr attr = {
    .type = PERF_TYPE_SOFTWARE,
    .config = PERF_COUNT_SW_CPU_CLOCK,
    .sample_freq = 19,
    .freq = 1,
};

sample_freq = 19
→ 초당 약 19회 샘플링
이 값이 parca-agent의 기본 철학을 보여준다
(정밀함보다 지속성)

eBPF 프로그램은 언제 실행되는가?

perf_event가 발생하면
연결된 eBPF 프로그램이 실행된다.

이 eBPF 프로그램은 매우 짧고 단순해야 한다.

이유는 명확하다.

커널 컨텍스트에서 실행
verifier 제한
실행 시간 상한 존재

스택 트레이스 수집의 핵심

1. 커널 스택 수집

커널 스택은 비교적 단순하다.

bpf_get_stackid(ctx, &stack_map, BPF_F_KERNEL_STACK);

현재 CPU가 커널 모드라면
syscall, scheduler, lock 경로 등이 잡힌다

2. 유저 스택 수집

유저 스택은 훨씬 까다롭다.

bpf_get_stackid(ctx, &stack_map, BPF_F_USER_STACK);

문제는 여기서 발생한다.

프레임 포인터가 없을 수 있음
JIT 언어 (Go, Java)는 스택 구조가 다름
심볼 해석은 커널에서 불가능

parca-agent는 이 문제를 역할 분리로 해결한다.

eBPF는 “주소만” 수집
심볼 해석은 user space에서

eBPF Map의 역할

eBPF 프로그램은 다음과 같은 map을 사용한다.

stack trace map
count / histogram map
temporary aggregation map

개념적 구조는 다음과 같다.

struct {
    __uint(type, BPF_MAP_TYPE_STACK_TRACE);
    __uint(max_entries, 16384);
} stack_map SEC(".maps");

이 map은:

동일한 call stack을 하나의 ID로 관리
중복 저장 방지
메모리 사용량 제한

user space(parca-agent)에서 하는 일

eBPF는 여기까지다.
이제 baton은 user space로 넘어간다.

parca-agent(user space)는 다음을 수행한다.

stack ID 수신
주소 목록 조회
심볼 정보 매핑
label(node, pid, container 등) 부착
protobuf 변환
서버 전송

중요한 점은:

agent는 “분석”을 하지 않는다

그저 구조를 보존한 채 전달할 뿐이다.

샘플링 기반이라는 것의 의미

여기서 흔히 나오는 질문이 있다.

“샘플링이면 정확하지 않은 것 아닌가?”

답은 다음과 같다.

단일 샘플 → 의미 없음
수천, 수만 샘플 → 통계적으로 매우 강력

Parca는:

순간의 정확성 ❌
시간 축의 누적 정확성 ⭕

을 선택했다.

오버헤드는 왜 낮은가?

parca-agent의 오버헤드가 낮은 이유는 구조적이다.

항상 같은 짧은 eBPF 코드
조건 분기 거의 없음
락 없음
메모리 접근 제한적
낮은 샘플링 빈도

일반적인 운영 환경에서:

CPU 오버헤드: 수 % 미만
latency 영향: 측정 불가 수준
장애 유발 가능성: 극히 낮음

이 때문에 상시 활성화가 가능하다.

왜 tracing이 아니라 profiling인가?

중요한 철학적 차이도 짚고 가자.

구분TracingProfiling

접근	이벤트 기반	샘플링 기반
비용	상대적으로 높음	낮음
정밀도	매우 높음	통계적
지속성	제한적	상시 가능

Parca는 의도적으로 profiling을 선택했다.

“항상 켜 두어야 의미가 있기 때문”

이 구조가 주는 실무적 의미

이제 Parca가 왜 이런 구조를 가지는지 보인다.

커널 안정성 유지
운영 환경 적용 가능
장애 시 blame 없음
장시간 비교 분석 가능

즉, parca-agent는

“운영 서버에 깔아도
죄책감이 들지 않는 eBPF 프로그램”

이라는 목표에 충실하다.

다음 편 예고

다음 편에서는
이렇게 수집된 데이터가 어떻게 Flamegraph로 변하는지,
그리고 사람이 어떻게 읽어야 하는지를 다룬다.

Flamegraph의 진짜 의미
Inclusive / Exclusive 비용
흔히 저지르는 해석 실수
“보이는 것”과 “중요한 것”의 차이

다음 편

4편. Flamegraph 제대로 읽기 – Parca UI 해석 가이드

eBPF 공부방-Parca

10편. Parca는 누구에게 필요한 도구인가– 도입 판단 가이드 & 정리

Parca는 누구에게 필요한 도구인가

도입 판단 가이드 & 연재 정리

1️⃣ Parca는 어떤 문제를 푸는 도구인가

Parca가 잘 푸는 질문들

Parca가 풀지 않는 질문들

2️⃣ Parca가 “잘 맞는 사람들”

① 시스템 프로그래머 / 플랫폼 엔지니어

② SRE / 인프라 팀

③ Kubernetes / 컨테이너 플랫폼 팀

3️⃣ Parca가 “잘 맞지 않는 사람들”

① 애플리케이션 개발자 단독 사용

② APM 대체를 기대하는 조직

③ 규제/포렌식 목적 환경

4️⃣ 조직 기준 도입 판단 가이드

아래 질문에 “예”가 많을수록 적합

5️⃣ Parca의 이상적인 포지션

6️⃣ PoC → 운영으로 가는 현실적인 경로

추천 도입 순서

절대 피해야 할 시작 방식

7️⃣ Parca 연재 전체 요약 (한 페이지)

8️⃣ 이 연재의 결론

에필로그: 언제 Parca를 배우면 좋은가

9편. Parca 도입 시 현실적인 고려사항– 운영, 보안, 성능 관점

Parca 도입 시 현실적인 고려사항

운영, 보안, 성능 관점

1️⃣ 운영 관점: 항상 켜도 되는가?

Parca의 기본 전제

운영에서 가장 중요한 질문 3가지

답은 다음과 같다

운영 설계 철학 요약

2️⃣ 성능 관점: 오버헤드는 정말 낮은가?

오버헤드를 만드는 요소

왜 오버헤드가 낮은가

샘플링 빈도 조절 예시

실제 체감 오버헤드

성능 리스크가 커지는 경우

3️⃣ 보안 관점: eBPF는 안전한가?

eBPF의 안전장치

요구 권한 (중요)

보안팀이 가장 싫어하는 포인트

현실적인 대응 전략

4️⃣ 스토리지 관점: 생각보다 크다

왜 스토리지를 많이 쓰는가

실무 기준 조언

5️⃣ 언제 켜고, 언제 끄는가

항상 켜 두기 좋은 경우

상시 활성화가 부담스러운 경우

6️⃣ Parca를 도입하면 안 되는 경우

7️⃣ 도입 전 체크리스트 (요약)

이 편의 결론

다음 편 (마지막) 예고

다음 편

8편. CO-RE와 Parca – 커널 의존성 문제는 어떻게 해결되는가

CO-RE와 Parca

커널 의존성 문제는 어떻게 해결되는가

1️⃣ eBPF의 오래된 문제: 커널 의존성

2️⃣ 전통적인 해결책의 한계

① 커널 버전별 빌드

② 런타임 offset 추정

3️⃣ CO-RE란 무엇인가

4️⃣ BTF (BPF Type Format)

5️⃣ CO-RE의 동작 원리

CO-RE 스타일 코드 예시

CO-RE 이전 코드 (위험)

6️⃣ Parca에서 CO-RE가 중요한 이유

Parca의 선택

7️⃣ CO-RE가 해결하는 것 vs 해결하지 못하는 것

해결하는 것

해결하지 못하는 것

8️⃣ Parca 운영 시 CO-RE 관련 체크 포인트

반드시 확인할 것

실패 시 나타나는 증상

9️⃣ 왜 CO-RE가 “게임 체인저”인가

10️⃣ 이 편의 핵심 요약

다음 편 예고

다음 편

7편. 컨테이너·Kubernetes 환경에서의 Parca– PID, Namespace, cgroup 관점

컨테이너·Kubernetes 환경에서의 Parca