# Collector (데이터 수집 에이전트)

## 개요

**Collector**(컬렉터)는 분산 시스템, 클라우드 인프라, 또는 대규모 네트워크 환경에서 **데이터 수집 에이전트(Data Collection Agent)**의 역할을 수행하는 소프트웨어 컴포넌트 또는 아키텍처 패턴을 지칭합니다. 현대 IT 인프라에서 Collector는 서버의 메트릭(Metric), 로그(Log), 트레이스(Trace) 등 다양한 관측 가능성(Observability) 데이터를 생성 지점(Source)에서 실시간으로 포착하여 중앙 집중식 저장소나 분석 엔진으로 안정적으로 전송하는 핵심 역할을 합니다.

주로 Prometheus, Datadog, Elastic Stack(EFK/ELK), Splunk, AWS CloudWatch 등 주요 모니터링 및 로깅 솔루션에서 Collector는 클라이언트 측에서 실행되어 시스템의 상태 정보를 추출하고, 필요한 경우 전처리(필터링, 변환, 집계)를 수행한 후 백엔드로 전송합니다. 이는 실시간 모니터링, 이상 징후 감지, 비용 최적화, 보안 위협 탐지 등 현대 DevOps 및 SRE(Site Reliability Engineering) 활동의 기초가 됩니다.

## 주요 기능 및 역할

Collector의 핵심 임무는 데이터의 **수집(Collect)**, **전송(Send)**, 그리고 때로는 **전처리(Process)**입니다. 구체적인 기능은 다음과 같습니다.

### 1. 데이터 포착 및 추출
Collector는 호스트(OS), 컨테이너(Kubernetes/Docker), 애플리케이션, 또는 네트워크 장비에서 발생하는 원시 데이터를 추출합니다.
*   **메트릭 수집**: CPU 사용률, 메모리 점유율, 디스크 I/O, 네트워크 트래픽 등 정량적 지표를 주기적으로 또는 이벤트 기반으로 수집합니다.
*   **로그 수집**: 시스템 로그(`/var/log`), 애플리케이션 로그, 표준 출력(STDOUT) 등을 실시간으로 읽어들입니다.
*   **트레이스 수집**: 분산 시스템에서 요청이 여러 서비스를 거치며 생성된 실행 경로 데이터를 수집합니다.

### 2. 데이터 전처리 및 변환
네트워크 대역폭 절약 및 저장 효율성을 위해 Collector는 데이터 전송 전에 다음과 같은 전처리를 수행할 수 있습니다.
*   **필터링**: 불필요한 로그나 메트릭을 제거하여 전송량을 줄입니다.
*   **변환**: 데이터 형식을 표준화하거나, 민감 정보(PII)를 마스킹(Masking)하여 보안 규정을 준수합니다.
*   **압축**: 전송 효율성을 위해 데이터를 압축합니다.

### 3. 안정적 전송 및 버퍼링
네트워크 불안정이나 백엔드 서버의 일시적 과부하 상황에서도 데이터 유실을 방지하기 위해 **버퍼(Buffering)** 기능을 제공합니다. 로컬 디스크나 메모리에 데이터를 일시적으로 저장하다가 네트워크가 복구되거나 백엔드가 준비되면 재전송합니다. 이는 '최선 시도(Best-effort)'가 아닌 '최소 한 번(At-least-once)' 전송 보장 메커니즘의 핵심 요소입니다.

## 아키텍처 및 구현 방식

Collector의 구현 방식은 수집 대상과 요구 사항에 따라 다양하게 분류됩니다.

### 1. Sidecar 패턴
컨테이너 환경(Kubernetes 등)에서 주로 사용됩니다. 모니터링 대상 애플리케이션 컨테이너와 동일한 Pod에 Collector 컨테이너를 함께 배치하여 로컬 네트워크를 통해 효율적으로 데이터를 수집합니다.
*   **장점**: 격리된 환경에서도 데이터 접근이 용이함, 설정이 간단함.
*   **단점**: 리소스 중복 사용, 관리 복잡도 증가.

### 2. DaemonSet/Host Agent 패턴
클러스터의 모든 노드(호스트)에 Collector를 하나씩 배포하여 호스트 레벨의 메트릭과 로그를 수집합니다.
*   **장점**: 호스트 자원 사용량 파악에 최적화, 설정 관리가 비교적 용이함.
*   **단점**: 노드 추가 시 Collector 배포 자동화 필요.

### 3. Agentless(에이전트리스) 아키텍처
별도의 설치 에이전트 없이 클라우드 제공업체(CSP)의 API를 통해 데이터를 수집하는 방식입니다. AWS CloudWatch Agent, Azure Monitor Agent 등이 이에 해당하며, 일부는 에이전트 없이 API 호출만으로 메트릭을 제공합니다.
*   **장점**: 호스트 설치 관리 부담 없음, 빠른 설정.
*   **단점**: API 호출 제한(Rate Limit) 영향, 실시간성 부족 가능성.

## 주요 오픈소스 및 상용 Collector 도구

| 도구 이름 | 특징 및 주요 용도 |
| :--- | :--- |
| **Fluentd / Fluent Bit** | 유연한 데이터 파이프라인 도구. Fluentd는 강력한 플러그인 생태계를, Fluent Bit는 경량화된 C 기반의 빠른 처리를 특징으로 함. |
| **Telegraf** | InfluxData社의 오픈소스 플러그인 기반 메트릭 수집기. 다양한 입력/출력 플러그인을 지원하여 다중 데이터 소스 통합에 강점. |
| **Prometheus Node Exporter** | 리눅스 호스트의 하드웨어 및 커널 관련 메트릭을 Prometheus 형식으로 노출하는 표준 도구. |
| **Filebeat** | Elastic社의 경량 로그 수집기. Elasticsearch, Logstash, Kafka 등으로 로그를 직접 전송하는 데 최적화됨. |
| **Datadog Agent** | Datadog 플랫폼 전용 에이전트. 메트릭, 로그, 트레이스, 이벤트 등을 통합 수집하며, 자동 발견(Auto-discovery) 기능 제공. |

## 고려 사항 및ベスト 프랙티스

Collector를 운영할 때 다음과 같은 사항을 고려해야 합니다.

1.  **리소스 오버헤드 최소화**: Collector 자체가 시스템 자원을 과도하게 소모하면 모니터링 대상의 성능에 영향을 줄 수 있습니다. 특히 로그 수집 시 파일 디스크립터(FD) 제한과 메모리 사용량을 주의 깊게 모니터링해야 합니다.
2.  **데이터 유실 방지**: 네트워크 단절 시 로컬 버퍼의 용량을 적절히 설정하고, 디스크 공간 부족 시 경고 메커니즘을 마련해야 합니다.
3.  **보안 및 규정 준수**: 수집되는 데이터에 개인정보나 민감한 비즈니스 정보가 포함될 수 있으므로, 전송 중 TLS 암호화 및 저장 시 암호화를 필수로 적용해야 합니다. 또한 GDPR 등 데이터 프라이버시 규정에 따라 특정 데이터는 수집 전 제거하거나 익명화해야 합니다.
4.  **확장성(Scalability)**: 노드 수가 증가하거나 데이터 양이 기하급수적으로 늘어날 때 Collector가 이를 처리할 수 있도록 수평적 확장(Horizontal Scaling) 또는 계층적 아키텍처(Edge Collector -> Central Aggregator)를 고려해야 합니다.

## 관련 문서 및 참고 자료

*   [Observability (관측 가능성)]
*   [Prometheus (모니터링 시스템)]
*   [Elastic Stack (로그 분석 플랫폼)]
*   [Kubernetes DaemonSet (노드별 배포 리소스)]
*   [Sidecar 패턴 (소프트웨어 아키텍처 패턴)]

---
*본 문서는 데이터 수집 에이전트인 Collector의 개념, 기능, 아키텍처, 그리고 주요 도구에 대해 기술하였습니다. 실제 구현 시에는 특정 클라우드 환경이나 모니터링 솔루션의 공식 문서를 참조하여 설정을 구성하시기 바랍니다.*

## Garbage Collection 및 메모리 관리

Collector는 대량의 데이터를 실시간으로 처리하며 수많은 일시적 객체(Short-lived objects)를 생성하므로, 효율적인 메모리 관리와 Garbage Collection(GC) 전략이 필수적입니다.

### 메모리 파편화 및 힙 누적 문제
데이터 수집 과정에서 가변 길이의 로그 메시지를 처리하거나 복잡한 JSON 파싱을 수행할 때, 힙(Heap) 영역에 작은 객체들이 빈번하게 생성되고 소멸합니다. 이는 다음과 같은 문제를 야기합니다.
*   **메모리 파편화**: 객체 할당과 해제가 반복되면서 메모리 공간이 조각나, 실제 여유 공간이 있음에도 큰 객체를 할당하지 못하는 현상이 발생합니다.
*   **힙 누적**: 버퍼링 설정이 과도하거나 전송 지연이 발생할 경우, 큐(Queue)에 쌓인 데이터가 힙 메모리를 점유하여 `OutOfMemoryError`를 유발할 수 있습니다.

### GC 전략 및 최적화 메커니즘
이를 해결하기 위해 최신 Collector들은 다음과 같은 전략을 채택합니다.
*   **객체 풀링(Object Pooling)**: 빈번하게 사용되는 버퍼나 데이터 구조를 미리 생성해 두고 재사용함으로써 GC 발생 빈도를 낮춥니다.
*   **Zero-copy 전송**: 커널 공간과 사용자 공간 사이의 데이터 복사를 최소화하여 CPU 부하와 메모리 할당량을 줄입니다.
*   **Off-heap 버퍼링**: JVM 기반 Collector의 경우, 힙 외부 메모리(Direct Memory)를 사용하여 GC 대상에서 제외함으로써 Stop-the-world(STW) 시간을 단축합니다.

## 리소스 제약 환경에서의 GC 최적화

Collector의 구현 언어와 런타임에 따라 메모리 관리 방식과 튜닝 관점이 크게 다릅니다.

### 경량 Collector vs 무거운 Collector 비교
C 기반의 경량 Collector(Fluent Bit)는 수동 메모리 관리를 통해 예측 가능한 성능을 제공하는 반면, Ruby/JVM 기반의 Collector(Fluentd, Logstash)는 GC에 의한 성능 변동성이 존재합니다.

| 비교 항목 | Fluent Bit (C 기반) | Fluentd (Ruby/CRuby 기반) |
| :--- | :--- | :--- |
| **메모리 관리** | 수동 할당/해제 (Manual) | 자동 Garbage Collection (GC) |
| **메모리 점유** | 매우 낮음 (수 MB ~ 수십 MB) | 높음 (수백 MB ~ GB 단위) |
| **GC 오버헤드** | 없음 (Deterministic) | 존재 (Non-deterministic) |
| **처리 성능** | 매우 높음 (Low Latency) | 보통 (GC 발생 시 지연 발생) |
| **주요 리스크** | 메모리 누수(Memory Leak) | Stop-the-world (STW) 지연 |

### 런타임별 GC 튜닝 관점
*   **JVM 기반 (Go/Java)**: 힙 크기를 적절히 제한하고, G1GC 또는 ZGC와 같은 저지연 GC를 사용하여 STW 시간을 최소화해야 합니다.
*   **Go 기반**: `GOGC` 환경 변수를 통해 GC 트리거 임계값을 조정하여 CPU 사용량과 메모리 사용량 사이의 트레이드오프를 최적화합니다.

## 버퍼링과 GC 부하의 상관관계

데이터 수집기의 버퍼링 과정은 안정성을 높이지만, 동시에 GC 부하를 가중시키는 원인이 됩니다.

### Stop-the-world(STW) 유발 메커니즘
버퍼에 데이터가 급증하면 힙 메모리에 대량의 객체가 생성됩니다. GC가 이를 정리하기 위해 모든 애플리케이션 스레드를 일시 정지시키는 **Stop-the-world** 현상이 발생하며, 이 기간 동안 Collector는 데이터를 수집하거나 전송하지 못해 **데이터 수집 지연(Ingestion Lag)**이 발생합니다.

### GC 튜닝 전후 지연 시간 비교 (Conceptual Graph)
GC 튜닝(예: Off-heap 적용 및 힙 크기 최적화)을 통해 Tail Latency(P99)를 획기적으로 개선할 수 있습니다.

```text
Latency (ms)
^
|      |---|  <-- 튜닝 전: 빈번하고 긴 STW 발생 (Spike)
|      |   |
|  ____|   |____
| /             \  <-- 튜닝 후: 일정한 응답 시간 유지 (Flat)
|/_______________\________________> Time
```

## 리소스 모니터링 및 성능 최적화 설정

단순한 CPU/메모리 점유율 모니터링을 넘어, GC로 인한 **Tail Latency** 증가와 애플리케이션 간섭 문제를 관리해야 합니다.

### Stop-the-world 방지를 위한 구체적 설정값 (예시)
사용하는 런타임에 따라 다음과 같은 설정값을 적용하여 GC 부하를 제어할 수 있습니다.

**1. JVM 기반 Collector (G1GC 적용 시)**
*   `-XX:MaxGCPauseMillis=200`: 최대 GC 중단 시간을 200ms로 제한하여 지연 시간 예측 가능성을 높입니다.
*   `-XX:InitiatingHeapOccupancyPercent=45`: 힙 점유율이 45%에 도달했을 때 조기에 동시 마킹(Concurrent Marking)을 시작하여 Full GC를 방지합니다.

**2. Go 기반 Collector**
*   `GOGC=100`: 기본값이며, 메모리 사용량이 100% 증가할 때 GC를 수행합니다. 메모리 여유가 있다면 이 값을 높여(예: 200) GC 빈도를 줄이고 CPU 효율을 높일 수 있습니다.
*   `GOMEMLIMIT=2GiB`: 소프트 메모리 한계를 설정하여 런타임이 한계치에 도달하기 전 공격적으로 GC를 수행하게 함으로써 OOM(Out of Memory)을 방지합니다.