운영 시스템에서 저지연 (Low Latency) 이벤트 처리라는 찾기 힘든 보물

우리가 실제로 해결하고 있었던 문제

언뜻 보기에 이것은 증가하는 수요를 충족하기 위해 인프라를 확장하는 전형적인 문제처럼 보였습니다. 하지만 더 깊이 파고들면서, 우리는 진짜 도전 과제가 이벤트 처리 (Event Handling)와 지연 시간 (Latency)에 있다는 것을 깨달았습니다. 우리의 보물 찾기 엔진은 실시간으로 개인화된 추천을 계산하기 위해 복잡한 그래프 데이터베이스 (Graph Database)를 사용했습니다. 이 그래프 데이터베이스는 사용자의 클릭, 구매, 브라우징 동작과 같은 일련의 이벤트에 의해 트리거되었습니다. 그러나 사용자 기반이 커짐에 따라 이벤트의 수가 급증했고, 이로 인해 시스템은 점점 더 지연에 취약해지고 신뢰할 수 없게 되었습니다.

우리가 처음 시도했던 것 (그리고 실패한 이유)

우리는 처음에 더 많은 리소스가 문제를 해결해 줄 것이라는 희망을 품고, 단순히 그래프 데이터베이스 클러스터에 더 많은 머신을 추가함으로써 문제를 해결하려고 시도했습니다. 또한 이벤트 처리 작업의 일부를 오프로드 (Offload)하기 위해 RabbitMQ 및 Apache Kafka와 같은 다양한 큐잉 시스템 (Queuing Systems)을 실험했습니다. 그러나 시스템이 성장함에 따라 높은 지연 시간 (High Latency), 패킷 손실 (Packet Loss), 그리고 일관되지 않은 성능을 포함한 다양한 문제에 직면했습니다. 시스템은 종종 응답하지 않는 상태가 되어 오류와 타임아웃 (Timeout)을 발생시켰고, 이는 결과적으로 전반적인 사용자 경험에 영향을 미쳤습니다.

아키텍처 결정

몇 주간의 실험과 시행착오 끝에, 우리는 마침내 다른 접근 방식을 결정했습니다. 우리는 이벤트를 처리하는 더 견고하고 확장 가능한 방법을 제공하는 Amazon SQS라고 불리는 메시지 큐잉 시스템 (Message Queueing System)을 선택했습니다. 또한 데이터베이스 쿼리 수를 줄이고 읽기 성능을 향상시키기 위해 Redis를 사용하여 구현된 캐싱 레이어 (Caching Layer)를 도입했습니다. 추가적으로, 이벤트 처리 파이프라인 (Event Handling Pipeline)에서 연쇄적인 장애 (Cascading Failures)를 감지하고 방지하기 위해 서킷 브레이커 패턴 (Circuit Breaker Pattern)을 구현했습니다. 이 접근 방식을 통해 우리는 낮은 지연 시간 (Low Latency)과 높은 처리량 (High Throughput)을 유지하면서 훨씬 더 많은 양의 이벤트를 처리할 수 있게 되었습니다.

수치가 말해주는 것

결과는 인상적이었습니다. 새로운 아키텍처를 구현한 후, 지연 시간이 평균 500ms에서 단 50ms로 크게 감소하는 것을 확인했습니다.

또한 오류율(error rates)이 5%에서 1% 미만으로 대폭 감소하는 것을 경험했습니다. 시스템은 훨씬 더 신뢰할 수 있고 확장 가능해졌으며, 성능 저하 없이 가장 격렬한 사용자 활동까지 처리할 수 있게 되었습니다.

다르게 했을 점
돌이켜보면, 단순히 인프라를 확장하는 것에 집중하기보다 이벤트 처리(event handling)와 지연 시간(latency)이라는 구체적인 문제에 초점을 맞추어 처음부터 더 구조적인 접근 방식을 취했을 것입니다. 또한 다양한 부하(load) 상황에서 시스템 동작에 대한 우리의 가설을 테스트하고 검증하는 데 더 많은 시간을 할애했을 것입니다. 나아가, Grafana 및 Prometheus와 같은 도구를 사용하여 시스템 메트릭(metrics)과 오류율을 면밀히 모니터링함으로써 시스템 성능에 대한 더 깊은 이해를 얻고 잠재적인 문제를 조기에 발견했을 것입니다. 더 정보에 기반하고 데이터 중심적인(data-driven) 접근 방식을 취함으로써, 진행 과정에서 저질렀던 몇 가지 값비싼 실수들을 피하고 훨씬 더 빨리 더 나은 결과를 얻을 수 있었을 것입니다.