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

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

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

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

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

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

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

---

먼저 한 문장 요약부터

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

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

---

비교 대상 정리

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

1. 전통적 모니터링 에이전트
   • CPU, Memory, Disk, Network
   • node_exporter, collectd, custom agent 등
2. APM (Application Performance Monitoring)
   • New Relic, Datadog APM, Elastic APM 등
3. 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 해석 가이드