보물찾기 엔진: 확장된 서버를 위협하는 시한폭탄

우리가 실제로 해결하려 했던 문제
우리가 처음에 해결하고자 했던 것은 운영 환경 (production environment)에서의 성능 모니터링 (performance monitoring)이라는 오래된 과제였습니다. 클러스터 (cluster)가 확장됨에 따라, 병목 현상 (bottlenecks)을 추적하고 리소스를 최적화하기 위한 직관적인 인터페이스가 필요했습니다. 우리 팀은 검색 기반의 보물찾기 엔진 (treasure hunt engine)이 숨겨진 역량을 끌어내어, 복잡한 문제에 대해 "건초더미 속의 바늘 (needle in the haystack)"과 같은 솔루션을 제공할 것이라고 확신했습니다.

우리가 처음 시도했던 것 (그리고 실패한 이유)
우리는 먼저 리소스를 자동 태깅 (auto-tag)하고 실행 속도가 느린 쿼리 (queries)를 찾는 프로세스를 자동화하기 위해 머신러닝 (machine learning, ML) 기반 알고리즘을 구현했습니다. 하지만 이 구현 자체가 주요한 병목 현상 (bottleneck)임이 드러났습니다. 알고리즘의 복잡성으로 인해 지연 시간 (latency)이 증가했고 모니터링 도구의 효과가 감소했습니다. 설상가상으로, ML 모델이 "환각 (hallucinate)" 현상을 보이기 시작했습니다. 즉, 기능이 아예 없는 것만큼이나 나쁜 잘못된 결과들을 생성하기 시작한 것입니다. 예를 들어, 실제로는 3ms가 소요된 쿼리에 대해 시스템이 300ms의 지연이 있다고 보고하는 오류가 발생한 적이 있습니다. 이는 단순히 임계값 (threshold)을 조정하는 문제가 아니었습니다. 우리의 ML 모델은 근본적으로 결함이 있는 설계였습니다.

아키텍처 결정
우리는 한 걸음 물러나 우리의 접근 방식을 평가했습니다. 우리의 보물찾기 엔진이 ML 모델에 너무 많은 의존성을 가지고 있으며, 저지연 (low-latency) 쿼리에 최적화되어 있지 않다는 것을 깨달았습니다. 우리는 훨씬 더 단순한 쿼리 메커니즘을 가진 순수 Cassandra 기반 시스템으로 피벗 (pivot)하기로 결정했습니다. 이를 통해 지연 시간을 한 자릿수(an order of magnitude)만큼 줄였으며, 성능 문제를 실제로 정확히 짚어낼 수 있는 능력을 갖추게 되었습니다.

수치가 말해주는 결과
새로운 아키텍처를 배포한 후, 쿼리 지연 시간 (query latency)이 평균 2초에서 30ms 미만으로 크게 감소하는 것을 확인했습니다. 오류율 (error rate) 또한 90% 감소했습니다. 우리는 마침내 성능 문제의 근본 원인 (root cause)을 정확히 찾아낼 수 있었고, 리소스 할당 (resource allocation)에 대해 정보에 기반한 의사결정을 내릴 수 있게 되었습니다.

게다가, 더 단순해진 설계 덕분에 문제를 설명하고 디버깅(debug)하는 것이 훨씬 쉬워졌기에 저희 지원 팀은 안도의 한숨을 내쉴 수 있었습니다.

다르게 했을 점 (What I Would Do Differently)
돌이켜보면, 성능 모니터링 (performance monitoring)과 서버 스케일링 (server scaling) 사이의 관계에 대해 더 미묘한 차이를 이해한 상태로 문제에 접근했을 것입니다. "보물찾기" 엔진을 구축하려고 시도하는 대신, 증가하는 워크로드 (workload)에 적응할 수 있는 견고하고 낮은 지연 시간 (low-latency)을 가진 시스템을 구축하는 데 집중했을 것입니다. 여기에는 Cassandra와 모니터링을 위한 더 단순한 쿼리 기반 메커니즘 (query-based mechanism)을 혼합하여 사용하는 것이 포함될 수 있습니다. 성능 병목 현상 (performance bottlenecks)을 식별하는 데 더 체계적인 접근 방식을 취함으로써, 머신러닝 (machine learning)의 세계로 우회하는 것을 피하고 "환각 (hallucination)" 문제로부터 스스로를 보호할 수 있었을 것입니다.