Atlassian은 처음부터 서비스 팀에 메트릭 전송 방식을 변경하도록 요구하지 않고, OpenTelemetry Collector를 중심으로 메트릭 플랫폼을 재구축했다. 기존 파이프라인을 제거한 뒤 수천 개 서비스의 구성을 다시 작성하는 대신, 회사는 UDP를 통한 StatsD 인터페이스를 유지하면서 그 뒤의 집계, 처리, 라우팅 계층을 점진적으로 교체했다.
이전 플랫폼은 지난 10년 대부분 동안 gostatsd에 의존했다. gostatsd는 Atlassian이 개발하는 오픈 소스 StatsD 애플리케이션으로, 호스트에서 사이드카 에이전트로 작동하고 반대편에서는 집계 계층으로 작동했다. 서비스 수준 목표 99.95%와 낮은 지연 시간을 기준으로 이 플랫폼은 14개 리전에 분산된 약 10만 개 호스트에서 들어오는 메트릭을 처리했다.
계약은 유지한 채 엔진 변경하기
Atlassian 팀은 인프라를 변경하기 전에 모든 서비스를 OpenTelemetry SDK를 사용하도록 재구성하는 일이 수년에 걸리는 작업이며, 알림이 의존하는 데이터가 손실될 가능성도 있다고 판단했다. 이에 따라 플랫폼의 인터페이스와 내부 구성 요소를 분리했다. 서비스는 동일한 주소와 StatsD 형식으로 통신했고, 내부 계층은 OpenTelemetry Collector의 맞춤형 배포판으로 점진적으로 교체했다.
설계는 수집, 수신, 집계, 라우팅이라는 네 개의 독립적인 단계로 구성됐다. 또한 수집 계층은 StatsD와 OTLP를 동시에 수신할 수 있도록 했다. 이를 통해 팀에 클라이언트 라이브러리 교체를 요구하지 않고도 이전을 시작할 수 있었으며, OpenTelemetry로 처음 생성된 메트릭을 위한 길도 열었다.
실제로 무엇이 달라졌는가?
수집 단계에서는 기존에 트레이싱 팀이 사용하던 OpenTelemetry Collector 배포판으로 gostatsd 사이드카 에이전트를 교체하면서 애플리케이션은 이전 동작을 유지했다. 덕분에 각 호스트에서 두 개의 에이전트를 실행하는 대신 메트릭과 트레이싱을 하나의 사이드카 에이전트로 통합할 수 있었다.
Atlassian에 따르면 이러한 통합은 비용이 가장 높은 Micros 서비스에서 서비스당 평균 CPU 사용량을 약 3.9% 줄였으며, 이는 전체 플릿에서 사이드카 에이전트 비용을 약 30% 절감한 것과 같다. 또한 수집 계층이 OpenTelemetry 메트릭을 수신하고 직접 전달할 수 있도록 OTLP 수신기도 추가했다.
수신 단계에서는 시계열 상태가 핵심 문제였다. 동일한 시계열에 속한 모든 데이터 포인트를 하나의 집계기로 보내야 했다. 기존 시스템은 nomad라는 내부 에이전트를 통해 서비스와 환경의 쌍을 기준으로 분할했다. 그러나 서비스 규모의 차이로 인해 일부 집계기는 과부하 상태가 되고 다른 집계기는 낮은 사용률을 보였다.
Atlassian은 이를 OpenTelemetry 저장소의 loadbalancingexporter 구성 요소와 streamID, 즉 개별 시계열의 식별자를 기준으로 한 분할을 사용해 해결했다. 이 방식은 대규모 서비스의 데이터를 여러 집계기 그룹에 분산하면서도 하나의 시계열은 동일한 집계기에 유지하도록 했다. 그 결과 집계기 간 CPU 분포가 더욱 균등해졌고, 자동 확장 능력이 향상되었으며 높은 부하 알림이 감소했다.
집계 계층에서 데이터와 비용 줄이기
집계 계층은 분당 약 48억 개의 데이터 포인트를 처리하지만, 저장하는 포인트는 약 2억 2천만 개로 약 96%를 줄인다. 대부분의 메트릭이 delta temporality를 사용하고 기존 구성 요소가 사용자가 기대하는 방식으로 이러한 차분을 집계하지 않았기 때문에, Atlassian은 메트릭 델타를 집계하는 전용 프로세서를 개발했으며 이를 atlassian-labs 범위에서 오픈 소스로 공개했다.
이전 후 집계 계층에 필요한 CPU는 이전의 약 절반으로 줄었다. 소식통은 이러한 개선이 gostatsd 형식 분석을 제거하고 부하를 더욱 잘 분산했으며 OpenTelemetry 커뮤니티의 개선 사항을 활용한 여러 요인에 따른 것이라고 설명한다.
마지막 단계에서는 맞춤형 내부 라우터를 metrics-gateway라는 이름의 상태 비저장 Collector 배포판으로 교체했다. 이 배포판은 upstream 익스포터를 사용해 SignalFx와 S3 같은 여러 대상에 전송할 수 있으며, 재시도, 큐, 역압 제어 기능을 제공한다. 발표된 설계에 따르면 새로운 대상 추가는 별도의 통합 프로젝트가 아니라 구성 변경이 된다.
점진적 이전에서 얻은 교훈
- 적절한 팀부터 시작하라: Atlassian은 개발 및 테스트 환경과 문제가 가장 심했던 서비스를 선택해 민감도가 낮은 범위에서 조기에 피드백을 얻었다.
- 프로덕션을 지속적으로 관찰하라: 프로덕션 부하에서 수행한 프로파일링은 소규모 테스트나 인공적인 벤치마크로는 확인할 수 없었던 구성 요소의 동작과 비용을 드러냈다.
- 운영의 대칭성을 유지하라: 이전이 수개월 또는 수년 동안 두 시스템을 병렬로 운영하는 방식으로 진행될 수 있으므로, 회사는 공통 도구와 운영 절차를 가능한 한 유지할 것을 권고했다.
- 범위를 단계적으로 확대하라: 배포는 1%에서 시작해 10%, 50%, 마지막으로 100%에 이르는 점진적인 비율을 따랐으며, 중요한 경로보다 덜 민감한 서비스에서 먼저 문제를 검증했다.
이 접근 방식이 중요한 이유
이 경험은 인프라에서 새로운 표준을 도입한다고 해서 모든 소비자의 인터페이스를 동시에 변경해야 하는 것은 아님을 보여준다. 외부 계약을 유지함으로써 이전은 모든 팀이 참여하는 조직 프로젝트에서 인프라 플랫폼이 주도하는 프로젝트로 전환됐고, OTLP와 OpenTelemetry 구성 요소를 점진적으로 도입할 수 있게 됐다.
Atlassian은 gostatsd와 nomad가 함께 메트릭 클러스터의 CPU 요청 중 약 38%를 차지했으며, nomad만으로도 전체 리소스의 약 13%를 차지했다고 밝혔다. 따라서 이전의 효과는 도구 통합에만 국한되지 않는다. 비용이 많이 드는 맞춤형 구성 요소를 제거하고 내부적으로 유지 관리해야 하는 부분의 수를 줄이는 것과도 관련이 있다.
그렇다고 서비스 계측 자체의 이전이 완료됐다는 의미는 아니다. 회사가 언급한 다음 단계는 계측 도구 자체를 OpenTelemetry SDK로 이전하고, 아직 사용 중인 Datadog 및 DogStatsD 클라이언트와 내부 StatsD 라이브러리를 점진적으로 폐기하는 것이다. 또한 여기에 제시된 성능 결과와 수치는 Atlassian이 자사 환경에서 수행한 경험을 설명한 것이며, 모든 모니터링 아키텍처에서 동일한 값이 반복된다는 보장은 아니다.