마지막 테스트를 조금 더 분석해 봤다.
어느 부분이 병목이 되었는지, 어떻게 개선할 수 있을지에 대한 고민을 정리해 봤다.
마지막 테스트
검색 성능의 마지막 테스트 결과는 이렇다.
사용자가 늘어날수록 RPS는 80에서 더이상 늘어나지 않고 응답 시간만 길어지는 상태다.
왜 이런 결과가 나왔는지 그동안 설정했던 모니터링툴을 통해 확인해 봤다.
이 그래프는 테스트 기간동안 docker service(swarm) 들의 CPU 사용량을 측정한 결과다.
보면 MySQL이 눈에 띄게 CPU 사용량이 높은것을 확인해볼 수 있다.
아무래도 MySQL이 성능 병목으로 의심이 되는 상황이다.
(100%가 넘어가는건 VM 하나당 CPU가 2개이기 때문에 최대 CPU 바운드일때 200%가 최대치다)
sum(irate(container_cpu_usage_seconds_total[1m]))JVM
우선 JVM의 상세한 상태를 확인해 봤다.
테스트 기간동안의 힙 상태를 체크해 봤는데, 여유공간도 충분하고 자잘한 GC들이 수행되고 있었지만 GC 시간도 전혀 성능에 영향을 줄정도는 아니였다.
또한 CPU나, Memory를 봐도 전혀 무리가 가는 상황은 아니였다.
역시 JVM은 성능 병목의 원인이 아니라고 판단하고 다음으로 넘어갔다.
MySQL
다음은 MySQL의 상태를 체크해 봤다.
아래 그래프는 써있긴 하지만 왼쪽 상단부터 CPU, Memory, I/O, Network 사용량 그래프다.
이번 테스트에선 CPU가 100%를 찍으면서 터질라고 하는동안 디스크 I/O 는 발생하지 않았다.
그럼 그 많은 데이터들은 어디서 왔을까?
테스트에 사용된 데이터들이 버퍼풀에 저장되어서 디스크 I/O 없이 버퍼풀 메모리에만 접근한것을 확인할 수 있었다.
즉 지금 MySQL의 성능 병목은 I/O가 아닌 CPU 의 성능 병목이란것을 알 수 있다.
그리고 만약 CPU병목이 아닌 I/O 병목이라면 다음과 같은 그래프가 그려진다.
즉 이번 테스트에서 병목은 MySQL 노드의 CPU였다.
Redis
다음은 Redis의 상태를 체크해 봤다.
그리고 현재 MySQL과 Redis가 같은 노드에서 동작하고 있어 혹시나 Redis의 CPU 사용량 때문에 병목이 생겼나 해서 이것도 알아봤다.
아래는 docker container 기준 CPU, Memory 사용량이다.
확인해 봐도 MySQL 컨테이너의 사용량이 압도적인것을 알 수 있다.
결론
내가 예상한 이번 테스트의 병목은 MySQL의 디스크 I/O 였다.
하지만 예상 외로 MySQL의 CPU가 병목이 되었다.
다음 테스트 때에는 MySQL을 수평확장해 master-slave 로 만들어 읽기 능력을 키워볼 계획이다.
