OpenTelemetry로 비용 효율적인 멀티 클러스터 옵저빌리티 플랫폼 구축하기(1)
들어가며…
에스티씨랩은 수백만 명의 동시 접속 트래픽을 관리하는 넷퍼넬(NetFUNNEL), 봇매니저(BotManager) 솔루션을 개발해 제공합니다. 3초 만에 한정판 굿즈가 완판되거나, 200개국 이상 350만 명이 동시에 투표하는 극한의 트래픽에도 장애 없이 서비스를 유지하는 것이 에스티씨랩이 하는 일입니다.
2024년, 저희는 큰 결정을 내렸습니다. 자체 개발 솔루션을 온프레미스 아키텍처에 더해 쿠버네티스(Kubernetes) 기반의 글로벌 SaaS 플랫폼으로 완전히 새롭게 구축했습니다.
클라우드 네이티브로의 전환은 성공적이었지만, 모니터링 비용이 이슈였습니다. Datadog 청구서는 매달 천정부지로 치솟았습니다. 비용보다 더 큰 문제는, 비용 압박 때문에 개발 및 스테이징 환경의 APM을 꺼야 했고, 프로덕션 환경마저 전체 서비스의 5%만 샘플링하는 상황에 이르렀습니다. 또한, 성능 문제는 언제나 배포 후에야 발견되었습니다.
이 악순환을 끊어내기 위해, 저희는 OpenTelemetry(OTel)와 CNCF 생태계의 LGTM 스택(Loki, Grafana, Tempo, Mimir)으로 옵저버빌리티(Observability) 시스템을 전면 교체했습니다.
결과는 기대 이상이었습니다.
Datadog 대비 80% 비용 절감
100% APM 커버리지(비용 제약으로 인한 5% 커버리지에서 증가)
여러 개의 쿠버네티스 클러스터에서 통합 옵버저빌리티 구현
CNCF 오픈 표준으로 벤더 종속 제로 달성
이 글에서는 에스티씨랩의 SRE팀이 어떻게 이 거대한 전환을 성공시켰는지, 그 과정에서 마주한 기술적 난제들과 실제 적용한 튜닝 노하우, 그리고 설정 파일까지 구체적으로 공유합니다.
옵저버빌리티 아키텍처 개요
에스티씨랩은 OTel을 통합 수집 레이어로 하는 LGTM 스택을 채택했습니다.
기술 스택 결정: 왜 OTel과 LGTM이었나?
SaaS 전환 시 선택했던 Datadog은 강력했지만, 비용적인 한계를 안겨줬습니다. 우리는 ‘모든 환경’을 ‘비용 효율적으로’ 모니터링할 수 있는 방법을 원했고, 해답은 CNCF(Cloud Native Computing Foundation) 생태계에 있었습니다.
첫 번째 결정: 데이터 수집 표준, OpenTelemetry(OTel)
데이터 수집 계층은 고민 없이 OTel로 통일했습니다. OTel은 CNCF의 핵심 프로젝트이자, 사실상 클라우드 네이티브 옵저버빌리티의 표준입니다.
사용 방식: 애플리케이션에는 OTel 자동 계측(Auto-instrumentation)을 적용했습니다. 애플리케이션 코드는 단 한 줄도 건드리지 않고 APM을 활성화할 수 있었습니다.
배포: OTel Operator를 사용해 모든 노드에 Collector를 DaemonSet으로 자동 배포했습니다.
핵심 이점: OTel Collector는 단순한 데이터 전달자가 아닙니다. 백엔드로 데이터를 보내기 전, 멀티 테넌시 ID를 태깅하고, 데이터를 일괄 처리(Batching)하며, 샘플링을 수행하는 핵심 ‘처리 및 버퍼 레이어’ 역할을 합니다.
OTel을 표준으로 사용함으로써, 우리는 백엔드를 Tempo에서 Jaeger로 바꾸든, 혹은 다시 Datadog으로 돌아가든, 애플리케이션 코드 수정 없이 자유롭게 백엔드를 교체할 수 있는 유연성을 확보했습니다.
두 번째 결정: 백엔드, LGTM 스택
Prometheus는 익숙했지만, 수백만 동시 접속을 다루는 저희의 글로벌 SaaS 트래픽을 감당하려면 그 이상의 것이 필요했습니다. 그래서 LGTM 스택을 최종 선택했습니다.
클라우드 네이티브: 모든 컴포넌트가 쿠버네티스 환경에서 수평 확장이 가능하도록 설계됐습니다.
비용 효율성: 라이선스 비용이 없고, S3 같은 저렴한 오브젝트 스토리지를 백엔드로 사용해 스토리지 비용을 획기적으로 낮출 수 있습니다.
통합 경험: Grafana라는 단일 창구에서 메트릭(Mimir), 로그(Loki), 트레이스(Tempo)를 완벽하게 연동해 볼 수 있습니다.
벤더 종속 탈피: 무엇보다 CNCF 표준 기술을 사용함으로써 다시는 특정 벤더에 종속될 걱정을 하지 않아도 됩니다.
주요 설계 결정
기술 스택을 정한 뒤, 저희는 두 가지 핵심적인 아키텍처 원칙을 세웠습니다.
중앙 집중식 백엔드, 분산형 컬렉터
문제: 개발(Dev), 스테이징(Staging), 프로덕션(Prod) 등 수많은 쿠버네티스 클러스터마다 Mimir, Loki, Tempo 풀 스택을 개별로 설치하고 운영하는 것은 비효율적입니다.
해결책: 멀티 테넌시(Multi-tenancy)를 활용한 중앙 집중화
우리는 모든 텔레메트리 데이터를 단 하나의 중앙 관리(MGMT) 클러스터로 전송하는 모델을 선택했습니다.
작동 방식:
각 애플리케이션 클러스터에는 가벼운 OTel Collector만 배포하고, 중앙 백엔드(Mimir, Loki, Tempo)가
X-Scope-OrgID헤더를 기반으로 데이터를 격리(Isolate)하도록 했습니다.각 클러스터의 OTel Collector가 자신의 고유 ID(예:
scp-dev)를 헤더에 담아 텔레메트리를 전송합니다.중앙 백엔드는 이 헤더를 인식해 테넌트별로 데이터를 분리 저장합니다.
Grafana에서 데이터 소스를 설정할 때 이 테넌트 ID를 지정하면, 사용자들은 다른 환경의 데이터를 볼 필요 없이 자신의 데이터만 자동으로 필터링해서 볼 수 있습니다.
결과: Noisy Neighbor 문제 완벽 차단
이 설계의 가장 큰 성과는 테넌트별 속도 제한(Rate Limiting) 이 가능해진 것입니다.
예를 들어, Dev 클러스터에서 잘못된 배포로 인해 메트릭이 폭증하더라도, 중앙 Mimir는
scp-dev테넌트의 Ingestion Rate만 제한합니다. 덕분에scp-prod테넌트의 프로덕션 데이터는 단 1건의 유실도 없이 안정적으로 처리됩니다.
OpenTelemetry: 모든 데이터는 OTel로 통한다.
선택 이유 : '벤더 중립성' 확보
Collector의 핵심 역할: 확장 가능한 '중간 처리 레이어'
이 구조의 핵심은 OTel Collector입니다. Collector는 단순한 에이전트가 아니라, 저희 시스템의 핵심 '중간 처리 레이어' 역할을 합니다.
멀티 테넌시 태깅: 위(1번)에서 설명한
X-Scope-OrgID헤더를 추가합니다.Batch: 텔레메트리를 모아서 한 번에 보내 백엔드의 부하를 줄입니다.
버퍼링 및 재시도: 백엔드 장애 시 데이터를 잠시 들고 있다가 재시도하여 유실을 방지합니다.
Sampling: 트레이스에 대해 Tail Sampling을 적용하여 각 환경별(Dev, Prod)로 수집할 트레이스를 선별합니다.
확장성과 유연성
OTel Collector는 단순한 에이전트가 아닙니다. OTLP, Prometheus, Kafka, Filelog 등 거의 모든 데이터 형식을 수신(Receivers)하고, 원하는 대로 가공(Processors)하며, 모든 백엔드로 내보낼(Exporters) 수 있는 수많은 컴포넌트 생태계를 갖추고 있습니다.
대부분의 표준 컴포넌트는
opentelemetry-collector-contrib깃허브 저장소에서 찾을 수 있습니다.또한, Go 언어를 사용해 사용자가 직접 필요한 커스텀 컴포넌트를 만들어 붙일 수 있는 강력한 확장성을 제공합니다.
결과: 이 구조의 가장 큰 이점은 애플리케이션과 백엔드의 완벽한 분리입니다. 만약 우리가 2년 뒤 Tracing 백엔드를 Tempo에서 Jaeger나 다른 상용 솔루션으로 교체한다 해도, 애플리케이션 코드는 건드릴 필요가 없습니다. OTel Collector의
exporters설정 한 줄만 바꾸면 됩니다.
자세한 OTel Collector 상세 설정과 주요 시행착오 및 해결 방안에 대해서는 다음 글에서 자세히 다뤄보도록 하겠습니다.
결론
Datadog에서 OpenTelemetry 기반 오픈소스 LGTM 스택으로 마이그레이션한 후, 우리는 아래의 내용을 달성할 수 있었습니다.
막대한 비용 절감(72% 감소)
더 나은 커버리지(5% → 100% APM)
벤더 종속성 탈피(오픈 표준 기반)
팀 역량 강화(전체 옵저버빌리티 스택 직접 운영)
처음 OpenTelemetry Collector를 구축할 때는 레퍼런스가 거의 없었고, AI조차 큰 도움이 되지 않았습니다. 하지만 오픈소스 커뮤니티의 힘으로 이러한 성과를 달성할 수 있었습니다. 저희 에스티씨랩의 경험이 비슷한 여정을 시작하는 팀들에게 실질적인 도움이 되기를 바랍니다.
참고)
How to build a cost-effective observability platform with OpenTelemetry
- CNCF, 2025. 12. 16,
- Posted by Grace Park, DevOps Engineer, STCLab SRE Team