프로파일링이 현실 점검으로 바뀔 때

Source: Dev.to

배포와 예상치 못한 지연

어제 마침내 마이크로서비스 스택을 프로덕션에 배포했지만, 사용자들로부터 갑작스러운 지연 스파이크와 429 오류가 폭주한다는 보고를 받았습니다. 문제를 해결한 것은 새로운 라이브러리나 핫‑리로드가 아니라, 앱을 만들면서 무시했던 간단한 “핸드‑오프”였습니다.

개발 환경 vs. 프로덕션 설정

개발 단계에서는 노트북에서 단일 인스턴스만 실행했기 때문에, 데이터베이스 풀 크기, 캐시 제거 정책, HTTP 클라이언트 재시도 횟수를 로컬 성능에 최적화된 값으로 설정했습니다. 하지만 실제로 수평 확장이 가능한 환경에서는 이 하드코딩된 값들이 병목이 되었습니다:

• 연결 풀이 모든 워커를 제한했고,
• 인‑메모리 캐시가 가득 차 가비지 컬렉션에 빠졌으며,
• 재시도 로직이 유휴 네트워크 시간을 연쇄적인 실패로 만들었습니다.

힘든 교훈

힘든 교훈: 노트북이 아니라 클러스터를 목표로 하라. 여러 인스턴스를 띄우거나 부하를 시뮬레이션하는 테스트를 작성하고, 구성 요소가 아닌 전체 시스템을 프로파일링하라. 요청 핸들러 안의 간단한 time.sleep도 공유 캐시에서 숨겨진 레이스 컨디션을 드러낼 수 있고, 무한 루프 하나가 노드‑풀의 이벤트 루프를 고정시킬 수 있다.

계측 및 스테이징

풀 사용량, 캐시 히트 비율, 재시도 횟수를 보고하는 작은 “언더‑더‑후드” 계측기를 추가한 것이, 배포 전에 문제를 가장 빠르게 잡아낼 수 있는 방법이었습니다. 요컨대, 스테이징 환경을 프로덕션의 살아있는 복제본으로 다루고, 메트릭이 실제 제약 조건을 드러내도록 하여 어떤 것을 배포하기 전에 확인하십시오.