애플리케이션의 성능을 모니터링할 때 가장 직관적이면서도 중요한 지표는 무엇일까요? 바로 ‘얼마나 많은 사용자가 접속해 있는가(Active User)’입니다. 비즈니스의 성공을 가늠하는 척도이자 시스템 장애를 예측하는 핵심 신호이기 때문입니다.

하지만 수천만 건의 트래픽이 몰리는 환경에서 중복 없이 실시간으로 사용자 수를 집계하는 것은 결코 쉬운 일이 아닙니다. 오늘 포스팅에서는 APM 에이전트가 어떻게 메모리 효율과 정확도라는 두 마리 토끼를 잡았는지, 그 핵심 기술인 HyperLogLog(HLL) 알고리즘과 데이터 처리 아키텍처를 심층적으로 살펴보겠습니다.

사용자 수를 세기 전, 가장 먼저 해결해야 할 과제는 ‘누구를 동일 인물로 볼 것인가’입니다. APM 에이전트는 환경에 따라 세 가지 추적 모드(user.tracking.mode)를 제공합니다.

• Mode 2 (KHANUSER 쿠키 – 권장): 에이전트가 브라우저에 고유 ID 쿠키를 직접 발급합니다. 만료 기간이 반영구적이라 브라우저가 바뀌지 않는 한 가장 정확한 ‘순수 방문자(Unique Visitor)’ 추적이 가능합니다.

• Mode 1 (JSESSIONID): WAS의 기본 세션 쿠키를 활용합니다. 구현은 간단하지만 세션 만료 시 새로운 사용자로 인식되는 한계가 있어 단기 분석에 적합합니다.

• Mode 0 (IP 주소): 쿠키 사용이 불가능한 환경의 차선책입니다. 다만, NAT 환경이나 프록시 서버를 거칠 경우 여러 사용자가 하나의 IP로 묶일 수 있는 리스크가 있습니다.

전통적인 방식인 COUNT(DISTINCT user_id)로 1,000만 명을 집계하려면, 시스템은 1,000만 개의 ID를 모두 메모리에 올리고 대조해야 합니다. 이는 메모리 점유율을 기하급수적으로 높여 정작 애플리케이션 성능을 떨어뜨리는 주객전도 상황을 초래합니다.

여기서 APM은 ‘확률적 데이터 구조(Probabilistic Data Structure)’라는 영리한 선택을 합니다. 100%의 정확도를 약 1%의 오차와 맞바꾸는 대신, 극소량의 메모리만으로 수조 개의 데이터를 처리하는 전략입니다.

APM 에이전트 내부에서 작동하는 HyperLogLog(HLL) 알고리즘의 원리는 의외로 단순한 확률 법칙에 기반합니다.

• 해싱: 사용자 ID를 무작위 이진수 값으로 변환합니다.

• 확률적 관찰: 이진수 앞자리에 0이 연속으로 몇 개 나오는지 확인합니다. 동전을 던져 앞면이 10번 연속 나올 확률이 희박하듯, 0이 길게 이어질수록 “아, 정말 많은 사용자가 다녀갔구나”라고 추정하는 원리입니다.

• 평균화: 우연한 오차를 줄이기 위해 데이터를 여러 개의 ‘레지스터’로 나눠 담고, 그 값들의 조화 평균을 내어 최종 카디널리티를 계산합니다.

APM 에이전트는 HyperLogLogPlus(14, 0) 설정을 사용합니다. 이는 16,384개의 레지스터를 사용해 약 0.81%의 오차율을 유지하면서도 단 16KB의 메모리만 점유함을 의미합니다.

에이전트가 2초마다 전송하는 데이터는 단순한 숫자가 아닌, 사용자 정보의 ‘스케치(Hex 문자열)’입니다. 이 스케치는 Merge(병합)가 가능하다는 강력한 장점이 있습니다.

• 인스턴스 간 병합: 여러 대의 WAS(WAS-1, WAS-2…)에 분산 접속한 동일 사용자를 하나로 합칩니다.

• 시간적 롤업: 2초 단위의 데이터 조각들을 모아 1분, 5분, 1시간 단위의 통계로 재구성합니다.

특히 대시보드에서 보는 ‘액티브 사용자’는 매분마다 계산되는 ‘최근 5분간의 스냅샷’입니다. 롤링 윈도우 방식이 아닌 고정 구간 집계 방식을 통해 대규모 분산 환경에서도 시스템 부하 없이 일관된 지표를 제공합니다.

APM의 사용자 집계 기술은 단순히 숫자를 세는 도구를 넘어, ‘자원의 효율성’과 ‘데이터의 유용성’ 사이의 완벽한 균형을 보여줍니다.

16KB라는 작은 공간 속에 수백만 명의 행동을 담아낼 수 있기에, 우리는 성능 저하 걱정 없이 비즈니스의 현재를 실시간으로 통찰할 수 있습니다.

지금 운영 중인 서비스의 액티브 사용자 수 뒤에는, 이처럼 정교한 확률 통계 알고리즘과 분산 처리 아키텍처가 숨쉬고 있습니다.