기존에 1대였던 replica를 1대 추가하여 2대로 구성한다.
사용한 쿼리는 제품을 키워드를 포함하여 페이지네이션으로 조회하는 요청이다.
개선 전(Replica 1대)
개선 후(Replica 2대)
Pinpoint 그래프 비교(y축은 응답 속도, x축은 시간)
결론
DB Replication의 replica 개수를 1대에서 2대로 scale out으로 성능이 좋아짐
약 15~20% 향상
왜 2배가 아니라 15~20% 만 향상되었는가?
실제 쿼리를 수행하는 excuteQuery는 시간이 줄어들지 않았지만, Connection을 점유할 때 사용할 수 있는 커넥션이 없어서 기다리는 getConnection의 시간이 절반으로 줄어들었다.
getConnection의 시간만 줄어든 것이기 때문에 이 비율에 따라서 성능이 향상된 것으로 보임
최악의 경우에서는 replica 2대인 경우가 더 느린 응답속도를 보여줬다.
그 이유는 성능이 향상되면서 더 많은 요청을 처리하기 때문에 excuteQuery 하는 과정이 시간이 더 늘어났다
이유는 Context Switching 이라고 생각함
또한 슬로우 쿼리 요청이 1대의 replica에 몰릴 수 있는 가능성이 있기 때문에 최악의 결과에서는 더 느린 응답 속도를 나타낸 것이라 보임
이를 개선하기 위해서는 roundRobin 방식이 아니라, 응답 시간을 기준으로 트래픽을 로드 밸런싱 방법을 이용하면 될 것 같다.
주의사항
일반적으로 Connetor/J 를 사용해서 로드밸런싱을 구현할 수 있었지만, 기존에 있는 spirng boot 코드와 AtomicInteger를 사용해서 구현했다. 이유는 Connetor/J 의 장점이라고 할 수 있었던 failover에 대한 것이 실제로 상황을 구현했을 때 제대로 작동하지 않았다. (MariaDB Connector/J 를 활용해야만 가능하다고 하는 글이 있다. 그리고 mysql을 사용한다면, AWS aurora를 사용해야하는 것 같다.)
또한 Connector/J에서도 replicationProxy를 사용해서 로드밸런싱을 사용하는 것을 확인할 수 있었으나, 실제 내부적인 구현에 대한 파악이 어려웠으므로 직접 구현하는 방식을 선택했습니다.
직접 구현했을 때 단점은, 헬스 체크를 통한 failover 기능을 구현하기 어렵다는 것입니다.
issue: #882
작업 내용
기존에 1대였던 replica를 1대 추가하여 2대로 구성한다. 사용한 쿼리는 제품을 키워드를 포함하여 페이지네이션으로 조회하는 요청이다.
개선 전(Replica 1대)
개선 후(Replica 2대)
Pinpoint 그래프 비교(y축은 응답 속도, x축은 시간)
결론
DB Replication의 replica 개수를 1대에서 2대로 scale out으로 성능이 좋아짐
주의사항
일반적으로 Connetor/J 를 사용해서 로드밸런싱을 구현할 수 있었지만, 기존에 있는 spirng boot 코드와 AtomicInteger를 사용해서 구현했다. 이유는 Connetor/J 의 장점이라고 할 수 있었던 failover에 대한 것이 실제로 상황을 구현했을 때 제대로 작동하지 않았다. (MariaDB Connector/J 를 활용해야만 가능하다고 하는 글이 있다. 그리고 mysql을 사용한다면, AWS aurora를 사용해야하는 것 같다.) 또한 Connector/J에서도 replicationProxy를 사용해서 로드밸런싱을 사용하는 것을 확인할 수 있었으나, 실제 내부적인 구현에 대한 파악이 어려웠으므로 직접 구현하는 방식을 선택했습니다. 직접 구현했을 때 단점은, 헬스 체크를 통한 failover 기능을 구현하기 어렵다는 것입니다.