거짓 경보만 계속 울리던 슬롯 발행 타임아웃

슬롯 확인 배경 작업에서 계속 울리던 타임아웃 경보를 결국 때려잡기로 했다. 발행 프로세스의 타임아웃 한계를 15분에서 45분으로 늘렸다.

배경: 모니터링 신뢰성이 무너지다

처음부터 이상했다. 슬롯 발행 체크업이 정상적으로 돌고 있는데 정기적으로 PUBLISH_TIMEOUT 경보가 나온다. 팀 슬랙에 경보가 떨어질 때마다 확인해보면 실제로는 프로세스가 무사히 완료되어 있다. 거짓 양성이 계속되니 누구도 경보를 진지하게 받아들이지 않기 시작했다.

모니터링 시스템은 신뢰가 생명인데, false positive가 반복되면 팀이 알람을 무시하기 시작한다. 진짜 문제가 터져도 "또 거짓 경보겠지" 하고 넘어가는 상황이 생긴다. 이건 장기적으로 매우 위험하다. 그래서 문제의 근원을 파고들기로 했다.

실제 실행 시간 vs 설정된 제한

데이터를 들여다보니 원인이 명확했다. 슬롯 발행 작업이 실제로는 꽤 오래 걸린다. 여러 개의 슬롯을 동시에 처리하고, 외부 인터페이스와 통신하고, 데이터 일관성 체크를 거쳐야 한다. 피크 타임에는 더 오래 걸린다. 900초(15분)라는 제한은 평상시 조건에서 설정된 것 같았는데, 실제 운영 환경에서는 부족했다.

여기서 중요한 판단이 필요했다. 타임아웃을 무한정 늘릴 수는 없다. 그건 정말 뭔가 막히는 상황을 감지하지 못하는 것과 같다. 대신 실제 SLA(서비스 수준 협약)를 충족하면서도 operational reality를 반영하는 값을 찾아야 했다. 로그를 분석해서 p99 실행 시간을 구했고, 거기에 여유분을 더했다.

타임아웃 설정의 트레이드오프

타임아웃 같은 설정은 언뜻 단순해 보이지만, 실제로는 여러 제약이 얽혀 있다:

• 너무 짧으면: false positive가 늘어난다 (지금 상황)
• 너무 길면: 실제 장애가 터졌을 때 감지가 늦어진다
• 점진적 증가: 한 번에 크게 늘리는 것도 위험하다 (원인을 제대로 파악하지 못했을 수 있음)

이번에는 데이터 분석을 바탕으로 근거 있는 값을 선택했다. 로그상 최대 실행 시간이 약 2500초 정도였고, 예외 상황을 고려해 2700초로 설정했다. 동시에 슬롯 발행 프로세스 자체의 성능 개선도 백로그에 올렸다. 타임아웃을 늘리는 것은 근본 해결이 아니니까.

회고: 모니터링 문화와 책임

이 fix가 코드 관점으로는 한 줄 변경이지만, 조직 관점으로는 중요한 신호다.

경보가 울리지 않는 상태에 안주하기 쉽다. "어차피 false positive니까" 하면서. 하지만 온콜 엔지니어 입장에서는 매번 대응해야 하고, 경보의 신뢰성이 떨어지면 정말 위험한 상황도 놓친다. 따라서 false positive를 줄이는 것도 엔지니어링 작업이다.

같은 이유로, 다른 체크업이나 배경 작업들도 주기적으로 타임아웃 설정을 리뷰할 가치가 있다. 시스템이 성장하고 트래픽이 변하면 예전 설정이 맞지 않을 수 있으니까. 이번 작업을 계기로 팀과 함께 모니터링 규칙을 정기적으로 점검하는 프로세스를 만들기로 했다.

코드 리뷰할 때도 이런 타입의 설정값 변경에 주목할 필요가 있다. "왜 이 값으로 변경했는가?"를 물어보는 것만으로도 부실 설정을 많이 잡을 수 있다.

🛒 이 글과 어울리는 추천 상품

• 모니터 쿠팡에서 보기 →
• 커피머신 쿠팡에서 보기 →
• 노이즈캔슬링헤드폰 쿠팡에서 보기 →

*위 링크는 쿠팡파트너스 활동의 일환이며, 일정액의 수수료를 제공받을 수 있습니다.