개요
Signoz는 하나의 플랫폼에서 애플리케이션의 성능 모니터링(APM)과 로그, 트레이스를 통합하여 관찰 가능성을 제공하는 도구다.
복잡한 MSA(MicroService Architecture) 환경에서
1. 분리된 모니터링 툴로 인해 근본 원인 분석 지연.
2. 높은 상용 SaaS 비용과 벤더 종속성 문제 발생.
에 대한 해결책으로, 이러한 파편화된 관측 환경을 통합하고 성능 및 비용 효율성을 높이기 위해 만들어졌다.
SigNoz는 OpenTelemetry 네이티브 설계, ClickHouse 기반 단일 저장소를 기존 도구들의 차별점으로 삼는다.
| 특징 | SigNoz | 기존 도구 (Prometheus/Jaeger/Loki 조합) |
| OTel 네이티브 | 처음부터 내장 (벤더 종속성 제로) | OTel 통합 모델을 중심으로 구축되지 않음 |
| 통합 플랫폼 | 메트릭 + 트레이스 + 로그 (단일 UI/저장소) | 개별 도구 및 분리된 저장소 |
| 데이터베이스 | ClickHouse (컬럼형 OLAP) | Elasticsearch, Prometheus, Loki 등 이질적 저장소 |
| 상관관계 | 신호 간 네이티브 연결 (원클릭 전환) | 수동 연결 필요 / 제한적 |
1) OpenTelemetry 네이티브 설계: 벤더 종속성 제로
- OTel 표준 기반이라 독점 에이전트가 필요 없음
- 계측(Instrumentation)은 한 번만 하면 되고, 백엔드는 Datadog 등 OTel 지원 백엔드로 쉽게 갈아탈 수 있음
2) ClickHouse: 성능 & 비용 혁신
- Elasticsearch 대비 로그 수집 속도 2.5배, 집계 쿼리 13배 빠름
컬럼형 저장 방식이라 압축률이 높고 스토리지 비용이 낮음
고카디널리티 데이터도 효율적으로 처리함
3) 통합 관측성 & 상관관계
- 메트릭/트레이스/로그가 모두 ClickHouse 하나에 저장됨
- 메트릭에서 이상 징후 확인 → 원클릭으로 해당 시간대의 트레이스 → 관련 로그로 이어지는 흐름이 자연스러움
4) 비용 모델 및 경제성
- 라이선스 비용이 없어서 상용 SaaS 대비 확실히 저렴함
- 단, ClickHouse를 직접 운영해야 하므로 운영 복잡성이 생김
SigNoz 구성요소
1. APM (Application Performance Monitoring)
APM은 애플리케이션의 성능 문제를 감지, 진단하고 사용자 경험을 보장하기 위한 모든 활동이다.
현대의 APM은 단순한 Health check를 넘어서, '왜 느린가?', '어떤 사용자가 영향을 받았는가?'를 추적하며, 관측 가능성(Observability)의 3요소를 기반으로 한다.
| 신호 | 역할 | 문제 해결 |
| Metrics | 징후 감지 | 언제 문제가 발생했는가? (ex. CPU 90%) |
| Traces | 위치 식별 | 어디서 병목이 발생했는가? (ex. A->B 호출 5초) |
| Logs | 원인 파악 | 왜 문제가 발생했는가? (ex. NullPointerException) |
APM 툴은 이 세 가지 데이터를 수집하고, 서로 유기적으로 연관시켜 문제 해결 시간을 단축시킨다.
2. OTel (OpenTelemetry)
OpenTelemetry(OTel)는 로그, 메트릭, 트레이스 데이터를 생성, 수집, 전송하는 방식을 표준화하는 오픈소스 프레임워크다.
목적:
- 벤더 종속성(Vendor Lock-in) 해결
- OTel 표준에 맞춰 한 번만 계측(Instrumentation)하면, 백엔드를 SigNoz, Datadog, Jaeger 등 원하는 툴로 자유롭게 변경 가능.
주요 구성 요소:
- API & SDK: 애플리케이션 코드에 설치되어 데이터를 생성하는 라이브러리
- Collector: 모든 데이터를 수신하는 관문(Gateway). 데이터 필터링, 가공, 샘플링 후 백엔드로 전송.
- OTLP: OTel 컴포넌트 간 표준 통신 프로토콜.
3. ClickHouse
ClickHouse는 실시간 분석(OLAP)을 위해 설계된 오픈소스 컬럼 기반(Columnar) DBMS다.
역할:
- 수십억 건의 행을 몇 초 만에 처리하는 압도적인 성능으로 APM 데이터(로그, 메트릭, 트레이스)를 저장하고 실시간 집계/분석한다.
주요 차이점 (저장 방식):
- RDBMS (MySQL 등): 행(Row) 기반. 트랜잭션(OLTP) 처리에 최적화. (예: 사용자 ID 1001의 모든 정보)
- ClickHouse: 열(Column) 기반. 분석(OLAP)에 최적화. (예: 모든 사용자의 '응답 시간' 열만 읽음)
컬럼 기반의 장점:
- 속도: 분석에 필요한 열만 읽어 디스크 I/O를 획기적으로 줄입니다.
- 비용: 동일 타입 데이터가 연속 저장되어 압축률이 매우 높아(Elasticsearch 대비) 스토리지 비용이 절감됩니다.
| 신호 | 역할 | 문제 해결 |
| Metrics | 징후 감지 | 언제 문제가 발생했는가? (ex. CPU 90%) |
| Traces | 위치 식별 | 어디서 병목이 발생했는가? (ex. A->B 호출 5초) |
| Logs | 원인 파악 | 왜 문제가 발생했는가? (ex. NullPointerException) |
데이터베이스 구조 유형 비교 ▼
데이터베이스 구조 유형 비교
| 구조 | 대표 시스템 | 저장 방식 | 기능 |
| 컬럼 기반 저장소 (Columnar) | ClickHouse \(OLAP) | 데이터를 열(Column) 단위로 저장 | 대규모 데이터 분석/집계(GROUP BY, SUM), 높은 데이터 압축률 |
| 행 기반 저장소 (Row-Oriented) | MySQL, PostgreSQL (OLTP) | 데이터를 행(Row) 단위로 저장 | 트랜잭션 처리(OLTP), 빠른 데이터 삽입/수정, 정형화된 데이터 관리 |
| 역 인덱스 구조 | Elasticsearch | 문서의 단어를 추출하여 "단어 → 문서 목록" 형태로 색인 | 전문(Full-text) 검색, 텍스트 기반 필터링 및 로그 탐색 |
| 키-값 저장소 (Key-Value) | Redis, DynamoDB | 데이터 고유 키와 값(Key-Value) 쌍으로 저장 | 매우 빠른 읽기/쓰기, 캐싱, 세션 관리 |
| 문서 저장소 (Document) | MongoDB, Couchbase | 데이터를 JSON 형태의 문서로 저장 | 구조가 유연(스키마리스), 복잡한 계층 구조 저장 |
| 그래프 저장소 (Graph) | Neo4j | 데이터를 노드와 에지(관계) 형태로 저장 | 복잡한 관계 및 연결 패턴 분석, 소셜 네트워크, 추천 시스템 |
| 시계열 저장소 (Time-Series) | Prometheus, InfluxDB | 데이터를 시간 순서대로 저장하고 인덱싱 | 시간 기반 추세 분석, 지속적으로 발생하는 메트릭 데이터 기록/집계 |
시스템 아키텍처 및 워크플로우
SigNoz는 OTel 표준을 기반으로 데이터를 수집, 처리, 저장, 시각화한다.
[애플리케이션 (OTel SDK)] → [SigNoz Collector] → [ClickHouse] → [SigNoz Backend] → [Web UI]
| 단계 | 구성 요소 | 역할 |
| 데이터 생성 | App (OTel SDK) | 애플리케이션 내에서 Metrics, Traces, Logs 데이터를 OTLP 표준으로 생성 및 전송. |
| 데이터 수집 |
OTEL Agent |
생성된 데이터를 가장 가까운 OTEL Collector (Agent 모드)로 내보냄. |
| 수집 및 처리 | OTel Collector | (관문 역할) 데이터 수신, 필터링, 샘플링(비용 제어), 일괄 처리(Batching) 수행. |
| 데이터 저장 | ClickHouse | Collector로부터 받은 모든 데이터(M/T/L)를 단일 저장소에 컬럼 기반으로 저장. |
| 클러스터 관리 | Zookeeper | (HA 구성 시) ClickHouse 클러스터의 분산 구성 및 데이터 복제 일관성을 관리. |
| 조회 및 시각화 | Query Service (Backend) |
ClickHouse에서 데이터를 조회하여 API로 제공. |
| 경고 및 알림 | Alert Manager | 임계값 초과 시 알림 생성 (Slack, Email 연동). |
| 사용자 | Web UI (Frontend) | API 데이터를 받아 대시보드로 시각화. |