[운영] 모니터링을 붙였더니 결함이 나왔다, 그런데 바로 안 고쳤다

부제: 측정이 드러낸 숫자를 곧바로 결함으로 단정하지 않은 이야기

모니터링을 붙이는 작업을 했다.
목적은 단순했다. 안 보이던 걸 보이게 하는 것.

그런데 실측을 시작하자, 모니터링과 무관한 원래부터 있던 것들이 드러났다.

• PostgreSQL 트랜잭션 롤백율 18.4%
• 정렬·해시가 메모리가 모자라 디스크로 새면서 6일간 임시 파일 19GB, 1,439개
• 로그용 Redis가 메모리 무제한 + 축출 안 함 → 호스트 램이 유일한 한계, 즉 OOM 위험. 게다가 append 로그가 원본 대비 47배로 부풀어 있음

숫자만 보면 다 나쁘다.
그런데 바로 안 고쳤다.

18%는 나쁜 숫자인가

롤백율 18%는 언뜻 앱이 에러투성이로 보인다.

그런데 롤백은 에러일 때만 생기는 게 아니다.
커넥션 풀은 연결을 반납할 때 상태를 리셋하며 롤백한다.
읽기 전용 트랜잭션도 롤백으로 끝난다.
헬스체크도 롤백을 만든다.

이런 "양성 롤백"이 대부분이면 18%는 정상이다.
즉 비율 하나만으로는 이상인지 아닌지 단정할 수 없었다.

그래서 목표를 바꿨다.
"롤백율을 낮춘다"가 아니라 "이 18%가 양성인지 진짜 앱 에러인지 판별한다" 로.

판별하려면 어떤 트랜잭션이 롤백되는지 봐야 하는데, 느린 쿼리 로깅이 꺼져 있어 안 보였다.
그걸 임시로 켜서 출처를 가려내는 게 조치가 됐다. 원인을 안 다음에 고칠 일이다.

원인을 모르면 알림을 걸지 않는다

여기서 판단 하나를 더 했다.
롤백율에 호출 알림을 걸지 않기로 했다.

원인을 모르는 지표에 알림을 걸면, 울려도 할 수 있는 게 없다.
행동할 수 없는 알림은 소음이고, 소음은 진짜 알림을 무디게 만든다.

그래서 원인과 정상 범위가 확정될 때까지는 대시보드에만 띄우고 알림은 보류했다.
알림은 "고칠 수 있게 된 다음"에 붙인다.

고치는 것도 조심스럽다

나머지 둘도 단순히 값만 올리면 되는 게 아니었다.

정렬용 메모리는 올리면 디스크로 새는 게 줄어든다.
그런데 이 값은 연결마다, 정렬마다 잡힌다. 과하게 올리면 동시 연결 수만큼 곱해져 메모리가 터진다.
최대 연결 수와 실제 동시성을 보고 신중히 올리거나, 큰 쿼리만 세션 단위로 올리는 게 안전하다.

Redis도 그렇다. 무제한은 위험하지만, 축출 안 함은 의도한 설정이다.
큐로 쓰는 데이터라 메모리가 찼다고 지워버리면 데이터가 사라진다.
그러니 "축출하게 바꾸기"가 아니라 "상한을 두고 알림을 건다" 가 답이었다.

발견과 관측을 섞지 않는다

마지막으로 하나.
이 결함들은 모니터링 작업이 발견했지만, 모니터링 작업이 아니다.

그래서 모니터링 PR에 섞지 않고 독립 작업으로 분리했다.
섞으면 리뷰 범위가 커지고, 나중에 모니터링을 되돌릴 때 관계없는 수정까지 딸려 나온다.
모니터링은 이것들을 관측만 한다. 고치는 건 별개의 일이다.

정리

• 모니터링을 붙이자 원래 있던 것들이 드러남 — 롤백율 18.4%, 임시파일 19GB spill, Redis 무제한+OOM 위험
• 나쁜 숫자 ≠ 결함 — 롤백 18%는 커넥션 풀 리셋·읽기전용·헬스체크가 만든 양성일 수 있음 → 목표를 "판별"로 잡음
• 원인을 모르면 알림을 걸지 않는다 — 행동 불가한 알림은 소음, 소음은 진짜 알림을 무디게 함 → 대시보드만
• 고치는 것도 신중 — 정렬 메모리는 연결 단위라 과상향 시 폭발, Redis 축출 금지는 의도된 것 → 상한+알림
• 발견한 결함은 관측 작업과 분리해 독립 작업으로

측정은 답을 주지 않는다.
판별할 거리를 줄 뿐이다.
숫자가 나왔다고 바로 고치러 달려가면, 정상인 걸 고치거나 울리기만 하는 알림을 남기게 된다.