[성능 개선 이야기] 조용한 날이 더 무서웠습니다 — Zabbix 알림 운영에서 배운 것

안녕하세요, 가야태자 @talkit 입니다.

앞선 글들에서 APM이 무엇인지, 시스템 모니터링 도구에는 어떤 것들이 있는지 정리해 드렸는데요.

오늘은 그중 Zabbix를 실제로 쓰면서 겪은 이야기를 해보려고 합니다.

결론부터 말씀드리면, 이 글은 제가 잘한 이야기가 아닙니다. 매일 울리는 알림을 그냥 두고 지냈던 이야기고, 나중에야 그게 무슨 뜻이었는지 알게 된 이야기입니다.

Zabbix는 두 번 만났는데, 입장이 달랐습니다

첫 번째는 금융권 성능 테스트를 할 때였습니다.

이때는 설치를 TA 분이 같이 해주셨고, 저는 그 자료를 가지고 분석하는 역할이었습니다.

대신 제가 한 일은 무엇을 볼지 정하는 일이었습니다. 성능 테스트를 하려면 이런 게 필요하다고 요청드렸죠.

• CPU
• 메모리
• 디스크 IO
• 네트워크

부하를 걸었을 때 어디가 먼저 한계에 닿는지 보려면 이 넷은 있어야 합니다. TA 분이 그 요구에 맞춰 대시보드를 만들어 주셨고, 저는 그걸 보면서 분석했습니다.

두 번째는 지방의 한 공공기관이었습니다. 여기서는 설치부터 전부 직접 했습니다.

구성

서버는 다섯 대였습니다.

• 웹 서버 1대
• WAS 1대
• DB 서버 1대
• 처리 서버 1대
• AI 서버 1대

OS는 CentOS 7과 8이 섞여 있었습니다.

웹 서버에 Zabbix 서버 UI와 호스트 에이전트를 설치하고, 나머지 서버들에는 수집 에이전트만 올려서 웹 서버 쪽으로 데이터를 보내게 했습니다.

대시보드는 금융권 때와 비슷하게 만들되 두 가지를 더 넣었습니다.

• 디스크 용량 체크 — IO만 보는 게 아니라 얼마나 찼는지도
• 서버 포트 감시 — 떠 있어야 할 포트가 살아 있는지

그리고 텔레그램 알림을 붙였습니다. 임계값을 넘으면 메신저로 바로 오도록요.

그런데 매일 울렸습니다

CPU 사용량이 과도하거나 메모리 사용량이 과도하면 텔레그램이 왔습니다.

그리고 이게 매일 계속됐습니다 ^^;;

이유가 있었습니다. 이 기관은 주기적으로 대용량 데이터 후처리를 하는 곳이었습니다. 후처리가 돌 때마다 처리 서버가 CPU를 잔뜩 먹었다가, 작업이 끝나면 다시 안정화되는 패턴이었죠.

즉 정상 업무가 임계값을 넘는 구조였습니다.

보통 이런 상황을 알림 피로(Alert Fatigue)라고 부릅니다. 매일 울리는 알림은 결국 안 보게 되고, 그러다 진짜 장애를 놓치게 되니까요.

저도 임계값을 조정할까 생각했습니다. 그런데 그러지 않았습니다.

조용한 날이 더 무서웠거든요

시간이 지나면서 알게 된 게 있습니다.

알림이 안 오는 날이 있었습니다. 그런데 그런 날은 대체로 후처리 데이터가 꼬였거나 뭔가 이상이 생긴 날이었습니다.

생각해 보면 당연합니다.

• 후처리가 정상적으로 돌고 있다 → 처리 서버가 CPU를 먹는다 → 알림이 온다
• 후처리가 안 돌았거나 중간에 죽었다 → CPU를 안 먹는다 → 알림이 안 온다

알림이 오는 게 정상이고, 안 오는 게 비정상이었던 겁니다. ^^;;

그래서 저는 임계값을 조정하는 대신, 매일 오는 알림을 그냥 두기로 했습니다. 그게 그날 작업이 잘 돌았다는 신호였으니까요.

지금 돌아보면

당시엔 "매일 오지만 그러려니" 하고 넘겼는데, 정리하면서 보니 저는 알림을 잘못된 이름으로 쓰고 있었습니다.

제가 걸어둔 건 "CPU가 높다"는 경고였습니다. 그런데 실제로 그 알림이 알려주고 있던 건 "후처리 작업이 돌고 있다"는 사실이었습니다.

이름과 내용이 달랐던 거죠.

제대로 설계했다면 이렇게 했어야 합니다.

• CPU 임계값 알림은 끄거나 훨씬 높게 잡고
• 대신 "후처리 작업이 예정된 시간에 시작했는가, 정상적으로 끝났는가"를 감시하고
• 그게 안 일어났을 때 알림이 오게

그러면 매일 울리지도 않고, 진짜 문제가 생겼을 때만 울립니다. 지금 제가 겪은 상황을 뒤집어 놓은 형태죠.

자원을 보는 것과 작업을 보는 것은 다릅니다. CPU 사용률은 서버의 상태이고, 후처리가 돌았는지는 업무의 상태입니다. 제가 알고 싶었던 건 후자인데, 감시하고 있던 건 전자였습니다.

앞선 APM 글에서 "인프라가 아니라 트랜잭션을 봐야 한다"고 썼는데, 같은 이야기가 여기서도 반복됩니다. 층만 다를 뿐입니다.

디스크는 이야기가 조금 달랐습니다

처리 서버와 각 서버에 NAS와 SAN 디스크를 연결해 두었는데, 이게 차면 역시 텔레그램이 왔습니다.

그러면 쌓인 처리 자료들을 NAS의 빈 곳으로 옮겨 주는 작업을 했습니다.

그런데 솔직히 말씀드리면, 알림이 오든 안 오든 한 달에 한 번씩 정기적으로 이관 작업을 했습니다 ^^

처음엔 이게 알림을 제대로 활용 못 한 것 같아서 좀 그랬는데, 지금 보면 오히려 그게 맞았습니다.

디스크는 예측 가능하게 찹니다. 매일 일정한 양의 산출물이 쌓이니까요. 언제쯤 찰지 대충 알 수 있습니다.

그리고 예측 가능한 일은 알림이 아니라 일정으로 관리하는 게 맞습니다. 알림을 기다렸다가 처리하면 이미 급한 상황이고, 정기적으로 비워두면 급할 일이 없습니다.

알림은 예측할 수 없는 일에 쓰는 겁니다.

정리하면

Zabbix를 붙이고 텔레그램까지 연결했을 때는 뭔가 다 갖춘 것 같았는데, 실제로 운영해 보니 배운 게 세 가지였습니다.

① 정상 업무가 임계값을 넘는다면, 임계값이 잘못된 겁니다
알림이 매일 온다면 그건 알림이 아니라 배경 소음입니다.

② 자원이 아니라 작업을 감시했어야 합니다
CPU가 높은 게 문제가 아니라, 돌아야 할 작업이 안 도는 게 문제였습니다.

③ 예측 가능한 일은 알림이 아니라 일정으로
디스크 이관은 알림을 기다릴 일이 아니라 달력에 넣을 일이었습니다.

그래도 하나는 다행이었습니다. 매일 오는 알림을 끄지 않은 것이요. 껐다면 조용한 날이 이상하다는 걸 영영 몰랐을 테니까요 ^^;;

즐거운 하루 되십시오.