[#9] Scale-Out 테스트 결과 분석하기

개요

Scale-Out에 필요한 사전 준비 사항들은 모두 Infra에 반영하여 구성을 완료했습니다. Pinpoint를 Scale-Out 시킨 Server에 모두 설치하여 Application Server를 모니터링할 수 있도록 구성하였고 Database Server의 경우 이전과 마찬가지로 Prometheus, Grafana를 통하여 테스트 결과를 확인했습니다.

 

TPS 비교

이번 테스트의 목표는 Scale-Out을 도입하였을 때 어느정도의 성능 향상이 이루어지는지와 또 다른 병목지점을 찾기 위한 목적입니다.

Scale-Out TPS

Scale-Out을 위한 사전 작업을 적용하기 전과 Scale-Out 적용된 Infra를 비교했습니다. 그래프를 확인해보면 전반적으로 Scale-Out시 성능이 향상 된 것을 볼 수 있습니다. 비교를 해보니 Scale-Out 시 발생하는 현상들을 찾아낼 수 있었습니다.

 

먼저 Session Management를 도입하므로써 단일 서버의 성능은 이전보다 떨어져 한 개의 Server 성능 * N(Scale-Out Server 개수) 보다 성능이 안 좋게 나오는 것을 확인할 수 있었습니다. 그리고 물품 조회 테스트, 구매 단품목 주문 테스트의 경우 성능이 향상되기는 하지만 목표 기준(1250 TPS)에는 한참 못 미치는 성능을 보이고 특히 구매 단품목 주문 테스트의 경우 8% 정도밖에 향상이 되지 않습니다.

 

이런 결과를 통해 알 수 있는 것은 결국 Database Lock을 통해 병목이 생기는 부분은 Scale-Out을 진행하더라도 향상 폭이 크지 않다는 것입니다. 앞으로 해결할 병목 개선 지점을 하나 더 찾게 되었습니다.

 

Database Lock을 통해 병목이 생기는 부분을 해결해야 된다.

 

Resource 비교

다음으로 Scale-Out시 변화하는 CPU, Memory 사용량 지표에 대해서 비교해보며 어떤 변화가 생겼는지 알아보았습니다. 

CPU 사용량 비교 - Application, Database

먼저 CPU 사용량에 대해 비교해보면 Application Server의 경우 전반적으로 사용량이 감소했습니다. Request를 처리할 수 있는 자원이 늘어났고 Load Balancer를 통해서 부하를 분산했기 때문에 나타날 수 있는 결과라고 판단했습니다. 이와는 반대로 Database CPU 사용량의 경우 사용량이 증가하는 것을 볼 수 있었습니다. Application Server에서 DBCP에서 connection을 갖고 오는 부분이 분산되므로 Database에 더 많은 Request를 보내 처리량이 증가하여 CPU 사용량이 증가하는 것으로 예측할 수 있었습니다.

 

Memory 사용량 비교 - Application, Database

 메모리 사용량은 Application Server의 경우 Heap 메모리를 기준으로 모니터링을 진행했습니다. 하지만 GC 수행 여부에 따라서 메모리 사용량이 달라 의미있는 비교 지표를 나타내지 못한다고 판단했습니다. Database의 경우는 전반적으로 상승은 있었으나 유의미한 차이를 보이지 않아 큰 소득이 없었습니다. 다만 아직 메모리로 인해 문제가 나타나는 영역에는 다다르지 못했다는 확인은 할 수 있었습니다.

 

Conclusion

Scale-Out을 진행한 뒤 테스트를 해보며 얻은 병목 지점의 실마리는 Database에서 병목이 생기는 부분으로 인해 Scale-Out으로 처리할 수 있는 한계가 생긴다는 부분입니다. 물품 조회는 페이징 쿼리, 단일 주문 구매의 경우 Database Lock(UPDATE)으로 인해 대기하는 시간이 존재하므로 기존 Application, Database 구조에서 새로운 해결책의 필요성을 볼 수 있었습니다.

 

고민을 위한 여지

• Database Lock으로 인한 병목은 어떻게 해결할 수 있을까?

해당 프로젝트는 네이버 클라우드를 활용하여 진행했습니다.