상황
백엔드 개발자로서 1 + N 문제, 쿼리 튜닝, 인덱스, 캐싱 등등 서비스의 품질을 개선하기 위해 노력할 수 있는 고려할 수 있는 상황들이 있습니다. 조금은 무모했던, 더 나은 방법들을 고민할 수 있었던 저의 개발 경험을 소개할까 합니다.
nGrinder 소개에 의하면 Groovy로 작성된 Script를 활용하여 stress를 줄 수 있다고 설명되어 있습니다.
필자는 Docker를 활용하여 nGrinder Agent와 Controller를 운영해서 부하 테스트를 진행했습니다.
문제
낮은 TPS
/todos/feed/following
유저가 팔로잉 하고 있는 피드를 조회할때, 피드가 가지고 있는 Nag 즉 NagLike 유무와 해당 Nag에 대한 초성 해제(NagUnlock) 유무에 대한 테이블까지 함께 조회하는 쿼리가 발생하면서 낮은 TPS를 확인할 수 있었습니다.
개선의 노력
테이블 역정규화
개선 내용 (NagLike와 NagUnlock에 대한 역정규화 진행 → NagInteraction
테이블 역정규화 작업으로도 높은 성능 개선을 느낄 수 있었습니다.
복합 INDEX
사실 데이터 크기가 크지 않아서 복합 INDEX가 크게 효과적일까 라는 생각을 했었으나 역시 개선할 수 있었습니다.
개선해야 할 상황
올바른 성능 테스트와 개선 방향
필자는 부하 테스트를 해보고 싶었던 마음도 있었고 눈에 보이는 수치들을 보면서 개발을 하고 싶었던 마음이 컸습니다. 하지만 프로젝트 기간동안 순차적인 단계를 밟지 않고 무리하게 진행했다는 생각이 들었습니다.
오만한 판단
Redis를 활용한 Caching, 역정규화 등등
이런 부분들을 바로 적용하면 좋은 서비스를 만들 수 있겠지! 라는 생각을 했습니다.
- 서버에는 문제가 없는지? CPU 사용률 등등...
- 쿼리는 쿼리 실행계획대로 잘 발생하고 있는지?
- 병목 현상은 없는지?
- 이중화는 고려해봤는지?
이런 기초적인 고민들도 하지 않고 개발했다는 점입니다.
앞으로는 테이블 풀 스캔 여부, 페이징에서 발생할 수 있는 쿼리 개선 등등
기초적인 부분들을 놓치지 않고 개발해야겠다고 생각했습니다.
더하여, 실무에서는 이런 부분들을 전문적으로 모니터링하고 개선하기 위한 팀들이 있겠다는 것을 느꼈습니다
(취업해서 이런 일들을 느껴보고 싶다..)
참고 자료
