데이터베이스 성능 최적화 기록

서비스 DB CPU 사용률 확인

현재 외주로 일하고 있는 서비스의 DB를 모니터링하던 중, CPU 사용률이 굉장히 높다는 사실을 확인하게 되었다. CPU 사용량이 높아질 경우에는 성능이 저하되거나, 타임 아웃 및 연결 실패, 리소스 병목등 다양한 문제를 발생하며 결국 서비스 장애로까지 이어질 수 있다.

이를 해결하기 위해 스케일 업/아웃, 인덱스 최적화, 캐싱 도입, 쿼리 최적화 등 여러 방법을 고려할 수 있으나, 이번 경우에는 데이터베이스의 사양이 서비스 규모에 비해 충분히 높다고 판단되어, 우선 쿼리 최적화와 인덱스 최적화를 통해 문제를 해결해 보기로 했다.

문제 분석 및 개선 과정

인덱싱

DB에 부하가 집중되는 시간대에 서버 로그를 확인해 보니, 해당 시간에 자주 호출되는 로직이 있었음을 확인할 수 있었다. 해당 로직에서 사용하고 있는 쿼리의 실행 계획을 살펴보며 문제점을 찾아보았다.

1. 서브쿼리 부분에서 전체 테이블 스캔을 발생해, 실행 속도가 매우 느려지고 인덱스를 제대로 활용하지 못하고 있었다.
2. 서브쿼리 부분에서 Max(created_at)연산을 수행하며 테이블 전체 스캔이 유발되었다.
3. 특정 조건을 만족하는 값을 찾기 위해 반복 조회를 발생시키고 있었다.

위의 문제점을 찾은 후, 먼저 인덱스를 효율적으로 활용할 수 있도록 복합 인덱스를 추가하였다.

그리고 2번에서 사용하던 created_at조건이 실제로는 불필요한 범위를 포함하고 있어, 해당 조건을 제거했다. 그 결과 약 3만 건 이상의 불필요한 데이터를 조회 대상이 줄어들었다.

DB CPU 사용률이 기존 100%에서 최대 60%까지 낮아지는 효과를 확인했다.

조건 필터링

CPU의 사용율은 이전보다 안정화되었지만, 여전히 특정 API호출할 때 응답 속도가 굉장히 느리다는 제보를 받게 되었다. 운영서버에서 측정한 네트워크 응답시간은 약 6초 정도 소요되고 있었다. 한국에서 미국 서버에 올라가 있는 데이터베이스에 접근하다 보니, 어느 정도 지연을 감안하였음에도 6초는 너무 긴 시간이었다.

해당 API에서 사용되는 쿼리를 다시 분석해 보니, 조회되는 데이터가 천만 건을 넘어가고 있었고, OR 조건으로 인해 인덱스를 전혀 타지 못하는 상태였다.

OR 조건은 로직상 반드시 필요했기에 서브쿼리나 Union을 시도하여 해결하려 했으나 효과가 없었다.

천만 건이 발생하는 쿼리의 범위를 줄이는 것이 먼저라고 생각하여, 해당 비즈니스에서만 사용되는 추가 조건을 발견해 냈다.

해당 조건을 발견해 쿼리에 반영함으로써 조회 범위를 크게 줄일 수 있었다. 약 1,200만 건에 달하던 조회 건수가 883건으로 축소되었고, 배포 후 테스트 결과 6초가 걸리던 응답이 1초 이내로 단축되었다.

더불어 이 조치로 인하여 DB CPU 사용률 또한 최대 40% 수준을 넘지 않게 되었음을 확인하였다.

결론

이번 작업을 통해 DB CPU 사용률을 100%에서 60%, 나아가 40% 수준까지 안정화시킬 수 있었고, 6초 이상 소요되던 API 응답 시간을 1초 이하로 개선할 수 있었다. 인덱스 최적화, 불필요한 조건 제거, 그리고 비즈니스 로직에 맞는 조건 필터링을 통해 근본적인 문제를 해결하여 DB 부하와 API 지연 문제를 개선할 수 있었다.

 

"내가 만들지 않은 기능이니까, 기존에 만들어져 있던 기능들이 원래 느렸으니까, 다른 리전에 올라가 있는 서비스니까 느릴 수 밖에 없지"라는 안일한 생각을 가졌던 것 같다. 그러나 이번 작업을 통해, 서비스 성능 저하의 원인을 단순히 외부 요인으로 탓할 수 없으며, 내가 직접 관리하는 서비스의 성능에 대해 책임을 져야 한다는 점을 깨닫게 되었다.

 

비록 이번에는 우연히 해당 이슈를 확인하게 되었지만, 해당 서비스에는 여전히 복잡하고 성능적 이슈를 야기할 수 있는 쿼리들이 많다는 것을 인지하고 있다. 앞으로도 부하가 걸리고 있는 서비스들을 꾸준히 파악하고, 개선할 수 있는 쿼리를 지속적으로 찾아내면서, DB 사양을 최적화하고 비용을 절감하는 도전을 이어가야겠다.