여러분의 마음을 사로잡을(?) 썸네일 이미지

소개

안녕하세요, 라포랩스 서버 플랫폼 팀의 지수환입니다. 이번 글에서는 데이터베이스의 CPU 사용률이 간헐적으로 튀는 문제를 해결한 경험에 대해 이야기를 나눠 보려고 합니다.

목차

2022년 여름의 어느 날, 자고 일어났더니 메인 DB의 CPU 사용률이 80%가 넘었다는 알림이 슬랙에 남아 있었습니다. 메트릭을 확인해 보니, 메인 DB 인스턴스 한 대의 CPU 사용률이 약 80% 선에서 12분 정도 유지되다가 다시 정상적인 패턴으로 돌아갔습니다. 퀸잇 서비스에서 DB의 CPU 사용률은 일반적으로 트래픽에 비례하는 패턴을 그리는데, 알람이 울린 시점에는 지표 상 트래픽이 튀지 않았습니다. 따라서 DB의 CPU 사용률이 높아진 현상이 트래픽 증가에 따른 결과라고 보기는 어려웠습니다.

트래픽과는 독립적인 이유로 DB의 CPU 사용률이 높게 유지된 것이라면, 트래픽이 높은 시점에 이 현상이 트리거될 경우 서비스 장애로 이어질 수 있다고 판단했습니다. 따라서 팀 내에서 우선순위를 높여서 이 현상의 원인을 파악하기 시작했습니다.

시스템 메트릭 확인

DB의 CPU 사용률이 비정상적으로 높았다는 것은, 어딘가 DB에 부하를 주는 시스템 요소가 있었다는 의미입니다. 이 시스템 요소를 식별하기 위해 두 가지를 확인해 보았습니다.

첫 번째는 pod의 network I/O rate 메트릭입니다. DB의 부하를 주는 시스템 요소는 DB와의 네트워크 통신량이 많을 가능성이 높고, 이는 pod의 network I/O rate 메트릭을 통해 쉽게 확인할 수 있습니다. 확인 결과, DB의 CPU 사용률이 튄 시점과 정확히 맞물려서 debezium connect pod의 network received bytes가 약 200~400 MiB/s로 매우 높게 유지되었습니다.

사진 1. DB의 CPU 사용률이 튄 당시의 debezium connect pod의 network I/O rate 그래프.

<aside> 💡 debezium은 다양한 데이터베이스에 대해 Change Data Capture(CDC)를 하기 위한 플랫폼으로, 보다 자세한 설명은 debezium 공식 문서에서 찾아보실 수 있습니다.

</aside>