백오피스 튜닝기 1
개발일기
백오피스가 너무 느렸다.
리팩토링은 꾸준히 진행하고 있지만, 보통 레거시가 아닌지라 해야 할게 너무 많다.
뭐 하나 클릭하기만 하면 돌아가는 프로그레스바와 함께 내 속도 같이 타들어갔다.
이 느림은 내게 이대로는 도저히 안되겠다는 생각을 갖게 만들었다.
이 느림을 어떻게든 개선 해 보고야 말겠다는 다짐을 하게만들고, 이를 행동에 옮기게 만들었다.
튜닝에 앞서 내 경험상 스프링으로 돌아가는 자바 애플리케이션은 항상 리소스가 여유롭게 남아도는 자원이었기 때문에 애플리케이션 속도에 결정적인 영향을 미치는 부분은 두 가지라고 생각했다.
DB 처리속도
화면 렌더링
우선 APM에서 슬로우 쿼리를 집중적으로 살펴보는데, 백오피스에서 가장 많이 호출되는 쿼리중 하나가 유별나게 느린 걸 발견했다.
처리속도는 매 쿼리당 4초 내외였다.
바로 두 눈에 쌍심지를 켜고 이 쿼리를 찾아 들어가 보니 inner, cross, outer join만 10번 가까이 붙어있었다.
심지어 단순히 where절 한 번만 쓰면 될 것을 자기 자신을 다시 inner join 하는 대참사가 벌어지고 있었다.
이 프로젝트가 완성된 게 5년 전이었고, 당시에는 테이블에 데이터가 많지 않았으니 괜찮았겠다 싶으면서도, 왜 하필 내가 담당할 때 이런 문제가 발생하는지… 😭
아무튼 우선 실행계획을 돌려봤는데
당최 뭔 소린지 아예 모르겠는 것이다.
Full Index Scan, Index Scan, Index Seek 등등
뭔가 많이 쓰여있는데 이것들이 뭔지 아예 몰랐다.
그래서 이것이 SQL 서버다 라는 책을 휴일 하루(석가탄신일) 동안 읽었다.
다음날 다시 보니 이제 대충 이해가 가기 시작했다.
위 쿼리에서 가장 문제가 되는 부분은 11,490,000건의 데이터를 Full Index Scan 하며 처리하는 부분이었다.
이 부분의 쿼리를 수정하고 실행계획을 다시 돌려보니,
11,490,000건을 Full Index Scan 하며 처리하던 쿼리는 이렇게 바뀌었다.
시간복잡도로 치면 O(1)이 된건가?
아무튼 증가한 쿼리의 효율성은 약 125배 정도였다. (4,271ms -> 약 30~40ms)
로컬, 개발서버에서 적절한 테스트를 마친 후
운영서버에 배포를 해 보니 정말 만족스러운 체감속도의 차이가 느껴졌다.
이에 탄력을 받아 이것저것 수정하기 시작했다.
테이블에 인덱스를 새로 생성하여 처리속도가 약 10배가량 증가한다거나, 처리하는 데이터는 40KB인데 웹 폰트를 4MB 정도 다운로드하여 렌더링이 오래 걸린다거나 등등의 잡다한 문제들이 있었고, 이를 하루 내내 처리하고 보니 괄목할만한 속도의 변화가 느껴졌다.
내가 맡은 백오피스와 내 실력은 아직도 갈길이 멀고 내가 이 회사에 언제까지 있을지도 잘 모르겠지만, 추후에 내가 퇴직하더라도 백오피스가 좋은 프로젝트로 남았으면 하는 바람이 크다.
개발자 커리어에 처음으로 담당하게 된 녀석이라 유독 더 그런지도 모르겠다.
