[Database] Database 프로젝트 성능 개선 트러블슈팅

Beyond SW 과정 중 Database 프로젝트를 진행했었다.

우리 팀은 동영상 스트리밍 프로젝트를 진행하기 때문에 DB 서버의 성능은 조회 성능과 더불어 생성 성능도 많이 요구된 상황이었다.

그렇기에 우리 팀은 하이브리드 DB 아키텍처를 구상하였다.(Cluster + Replication)

Server Architecture

따라서 SQL 성능을 체크함과 동시에 서버 아키텍처가 제대로 작동하는지 확인하기 위해서 Jmeter + Prometheus + Grafana로 성능을 확인했었다.

트러블 발생

아니 근데 Jmeter로 부하를 가한 후 Grafana로 부하 과정을 보는데, 하나의 MariaDB만 부하를 받고, 나머지는 전혀 부하를 안 받는 현상이 발견되었다.

분명히 Clustering을 진행한 후, Haproxy(Round Robin을 적용한)를 적용하여 분산 시스템을 만들었지만 분산이 전혀 안되고 있는 상황이였다.

계속 부하를 다시 줘도 같은 현상이 발생하자, 다시 DB 시스템을 뜯어 보았지만 Clustering에는 전혀 문제가 없었다.

우리 팀의 결론은 부하가 잘 안되고 있다는 것이였다.

DB 시스템도 정상으로 작동하고 있고, Haproxy를 통해 DB Client로 접근해도 분산이 잘 되어 MariaDB Id가 변경되는 것을 눈으로 확인했었다.

부하 시스템의 함정

그렇게 계속 설정들을 찾아가다보니 Jmeter에서 ThreadPool를 설정했던 것이 팀 안에서 이야기가 나왔다.

그 추론은 다음과 같았다.

1. Jmeter에서 DB서버에 Connection을 만들고 유지한다.
2. Connection을 유지하기 때문에 Haproxy를 통과하지 않는다.
3. 따라서 이 경우에는 부하분산이 적용되지 않는다.

그렇기에 우리 팀은 Jmeter 설정에서 Loop Count를 증가시켜 Connection 유지를 피하고, 부하 분산을 시도했었다.

그 결과, 실제로 Grafana에서 CPU 사용율이 3개의 서버에서 다같이 올라오는 그래프가 그려졌고, 우리의 가정이 맞았다는 사실을 알게 되었다.

느낀점 

이렇게 SQL 성능 테스트 및 DB 성능 테스트를 진행하면서 설계대로 진행이 안되는 경우가 꽤 존재하고, 자료를 쉽게 찾을수도 없는 경우도 많이 생긴다는 것을 이번 프로젝트에서 경험했다.

그런 와중에도 개발자로서 우리가 해야하는 일은 이 트러블이 일어날 수 있는 경우의 수를 생각한 후, 테스트를 통해 검증하는 일이라는 것을 알게 되었다.