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

 

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

운영, 보안, 성능 관점

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

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

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

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

---

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

Parca의 기본 전제

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

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

---

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

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

---

답은 다음과 같다

상황서비스 영향

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는 누구에게 필요한 도구인가 – 도입 판단 가이드 & 정리