application-performance-monitoring

디스코드의 엘릭 (새 탭에서 열림)

Discord는 Elixir의 강력한 동시성 메커니즘을 활용하여 각 서버(길드)를 독립적으로 운영함으로써 수억 명의 사용자에게 실시간에 가까운 채팅 경험을 제공합니다. 그러나 급격한 트래픽 증가로 시스템 자정 능력이 한계에 도달할 때, 기존의 메트릭이나 자체 개발한 메모리 기반 분석 도구만으로는 복잡한 성능 병목 현상과 사용자 경험의 실질적인 저하 원인을 파악하는 데 한계가 있었습니다. 이를 해결하기 위해 Discord는 Elixir 환경에 맞춤화된 분산 추적(Distributed Tracing) 시스템을 직접 구축하여 서비스 중단 없이 시스템 전반의 가시성을 확보하는 데 성공했습니다. **기존 관측 도구의 한계와 실무적 어려움** * **지표와 로그의 한계:** 대시보드는 엔진 온도계처럼 시스템의 상태를 보여주지만, 온도가 높을 때 사용자가 느끼는 실제 주행 경험(지연 시간의 체감 등)이나 구체적인 결과까지는 설명해주지 못합니다. * **길드 타이밍(Guild Timings) 도구:** 길드별 작업 소요 시간을 분 단위로 메모리에 기록하는 커스텀 도구를 사용해왔으나, 데이터 양이 너무 방대하여 대형 길드를 제외하고는 데이터를 빠르게 순환(Rotation)시켜야 하므로 과거 이력 분석이 어렵습니다. * **다운스트림 효과 파악 불가:** 기존 도구들은 개별 작업의 소요 시간은 보여주지만, 해당 작업이 연쇄적으로 일으키는 다운스트림 서비스의 영향과 전체적인 실행 흐름을 시각화하지 못하는 단점이 있었습니다. **Elixir 환경에서의 분산 추적 도입 과정** * **분산 추적(APM)의 필요성:** 작업의 구성 요소별 소요 시간을 한눈에 파악할 수 있는 분산 추적 기술을 통해 시스템 내부의 복잡한 상호작용을 투명하게 확인하고자 했습니다. * **기술적 난관:** 일반적인 추적 도구는 HTTP 헤더와 같은 메타데이터 레이어를 통해 추적 정보를 전달하지만, Elixir의 기본 통신 도구들에는 이러한 메타데이터 레이어가 내장되어 있지 않았습니다. * **커스텀 메타데이터 레이어 구축:** 서비스 간 통신 방식에 추적 정보를 함께 전달할 수 있는 자체 메타데이터 전달 메커니즘을 설계하여 문제를 해결했습니다. * **무중단 통합:** 서비스 간의 통신 방식을 근본적으로 변경하는 작업임에도 불구하고, 철저한 설계를 통해 시스템 가동 중단(Downtime) 없이 새로운 추적 시스템을 성공적으로 통합했습니다. 복잡한 분산 시스템에서 단순한 성능 지표만으로는 문제의 근본 원인을 파악하기 어렵습니다. 특히 Elixir와 같이 특수한 통신 구조를 가진 환경에서는 표준적인 APM 도구를 그대로 적용하기보다, 시스템의 특성에 맞춰 메타데이터 전달 계층을 직접 구현함으로써 인프라 전반의 흐름을 명확히 파악할 수 있는 분석 환경을 구축하는 것이 중요합니다.

결함 있는 배포 탐지: 라벨링되지 않은 데이터에서 지도 학습까지의 여정 (새 탭에서 열림)

배포는 소프트웨어 개발의 핵심이지만, 구글 SRE에 따르면 전체 장애의 약 70%가 배포와 관련되어 있을 만큼 위험 요소가 큽니다. Datadog은 APM(Application Performance Monitoring) 데이터를 활용해 결함이 있는 배포를 신속히 식별하는 '자동 결함 배포 탐지' 기능을 개발했으며, 이를 위해 레이블이 없는 대규모 데이터셋에서 시작해 정교한 모델을 구축했습니다. 이 과정에서 비지도 학습과 반복적인 프레임워크를 도입하여 데이터 불균형과 서비스별 다양성 문제를 성공적으로 해결했습니다. **결함 배포 탐지의 주요 장애물** - **데이터 레이블의 부재**: 서비스마다 '결함'에 대한 기준이 다르고 명확한 정답 데이터(Ground Truth)가 없어 일반적인 지도 학습 모델을 적용하기 어려웠습니다. - **데이터 불균형**: 결함 배포는 전체 배포 중 극히 일부에 불과한 희귀 이벤트이므로, 단순히 무작위 샘플링을 통해 모델을 학습시키는 방식은 정밀도가 매우 낮았습니다. - **서비스의 다양성**: 트래픽의 계절성, 낮은 트래픽 빈도, 잦은 배포 주기 등 애플리케이션마다 다른 프로필을 가지고 있어 일관된 기준을 적용하기 까다로웠습니다. **결함 배포를 정의하는 세 가지 핵심 속성** - **영향도(Impact)**: 전체 오류 수가 기준치보다 충분히 높아야 하며, 이전 버전들과 비교했을 때 오류율 증가가 유의미하게 높아야 합니다. - **시간적 상관관계(Temporal Correlation)**: 관찰된 오류율의 증가가 새로운 버전의 배포 시점과 명확하게 일치하는지 검증합니다. - **지속성(Persistence)**: 배포 과정에서의 일시적인 노이즈를 배제하기 위해, 증가한 오류율이 일정 시간 동안 안정적으로 유지되는지 확인합니다. **반복적 프레임워크를 통한 모델 고도화** - **통계적 규칙 결합**: 배포 후 60분간의 데이터를 바탕으로 오류율 변화를 비교하는 단순 규칙에서 시작하여, 점차 복잡한 통계적 체크 항목을 늘려나갔습니다. - **만장일치 투표 방식의 앙상블 모델**: 여러 통계적 체크 항목이 모두 결함이라고 판단할 때만 최종적으로 결함 배포로 분류하는 방식을 채택하여 정밀도를 높였습니다. - **반복적 개선 프로세스**: 초기에는 높은 재현율(Recall)을 목표로 설정한 뒤, 수동 레이블링을 통해 오탐(False Positive)을 분석하고 이를 걸러낼 새로운 체크 항목을 추가하며 정밀도를 보정했습니다. - **데이터 피드백 루프**: 탐지되지 않은 결함(False Negative)을 찾기 위해 실제 발생한 인시던트 데이터와 버전 롤백 이력을 활용하여 모델의 임계값을 지속적으로 튜닝했습니다. 실제 환경에서 결함 탐지 모델을 구축할 때는 완벽한 레이블을 기다리기보다, 영향도·상관관계·지속성이라는 핵심 지표를 설정하고 반복적인 피드백 루프를 통해 비지도 학습 모델을 정교화하는 전략이 매우 효과적입니다.