스케일링 악몽: Service Mesh에서 병목 디버깅

Source: Dev.to

Problem Overview

마이크로서비스 아키텍처를 10배 트래픽에 맞추어 확장했을 때, 처음 나타난 문제는 부하가 걸릴 때만 간헐적으로 발생하고 개발 환경에서는 전혀 나타나지 않던 502 오류였습니다. 로그를 파헤쳐 보니 각 요청마다 새로운 데이터베이스 연결을 생성하고 이를 해제하지 않아 로드 밸런서 풀(pool)이 포화 상태에 이른 것을 발견했습니다.

Fixing the Database Connection Leak

해결책은 단순히 DB 인스턴스를 더 늘리는 것이 아니라, 적절한 커넥션 풀을 도입하고 모든 워커(worker)에서 최대 크기를 강제 적용하는 것이었습니다.

Caching Issues and Resolution

두 번째 고통스러운 깨달음은 요청 지연 시간 급증이 과도한 캐싱 전략에서 비롯된다는 것이었습니다. 우리는 쿼리 결과를 10분 동안 캐시했지만, 캐시 키에 버전 메타데이터를 포함하지 않아 오래된 데이터가 하위 서비스에 제공되었습니다. 이로 인해 오래된 쓰기가 유출되는 문제가 발생했습니다. 캐시 무효화 훅을 추가하고 키 스키마를 강화한 뒤, 지연 시간을 절반으로 줄였을 뿐만 아니라, 사용자 데이터를 은밀히 손상시켜 온 일련의 레이스 컨디션을 완전히 제거했습니다.

Cultural Lessons and Ongoing Practices

마지막으로 가장 큰 문화적 교훈은 확장성은 일회성 최적화가 아니라 지속적인 디버깅 마인드셋이라는 점이었습니다. 우리는 배포 시 엔지니어들을 페어링하고, 모든 서비스에 요청당 트레이싱을 도입했으며, 성능 퇴보를 포스트모템이 필요한 버그로 취급하기 시작했습니다. 이러한 변화는 배포 파이프라인을 안전망으로 바꾸어, 병목 현상이 프로덕션에 도달하기 전에 잡아내고, 이전에 두려워하던 “스케일‑아웃” 사고를 일상적이고 예측 가능한 조정으로 전환시켰습니다.