시작
개발 프로젝트를 진행하면 기능을 개발하는 것이 전부가 아니라는 것을 아실 겁니다. 성능, 신뢰성, 보안 등 다양한 비기능 요구사항 역시 충족시켜야 하죠. 저 역시 프로젝트에서 만든 기능에 대한 성능을 점검하고, 개선할 수 있는 부분은 능력이 닿는 한 향상하려고 노력합니다. 저는 가장 먼저 하는 작업으로는 조회 API에 대해서 성능 테스트를 진행하고, 캐싱이 가능한 부분은 캐싱을 도입해서 성능 개선을 하려고 하는 편입니다.
이 글은 제가 성능 테스트와 캐싱을 적용하는 과정에서 겪었던 시행착오에 대해서 다룹니다. 이미 내용을 아는 분들은 웃으면서 읽어주시고, 알지 못했던 분들은 저와 같은 실수를 하지 않으시길 바랍니다.
발단
블로그 소재가 없나.. 하면서 `velog`를 구경하는 와중에 이런 글을 읽었습니다.
localhost 의 동작 원리
거의 매일 사용하시지만, 동작되는 이유를 모른채 사용하는 IP주소가 있습니다.127.0.0.1 즉, localhost 말 입니다.내 PC에서 다른 서버가 아닌, 바로 나 자신을 가리키는 주소 입니다.엄밀하게는 localho
velog.io
아니 세상에.. localhost끼리 통신하면 handshake와 같은 과정이 없단 말이야?
생각해 보니 네트워크를 배울 때 `wire shark`로 통신 과정을 보여주는 걸 보면서 봤던 거 같기도 합니다..
그런데 여기서 문제가 생깁니다. 저는 지금까지 성능 테스트를 할 때엔 항상 로컬에서 로컬로만 돌리고 있었거든요.. (서버에다가 쏘지 않았으니 당연히 잘못된 방법입니다.)
그러니까 위처럼 테스트를 하고 있던 거죠.
저 상황으로 성능 테스트를 한 결과는 아래와 같았습니다.
와! 무려 1000% 상승!
자랑스럽게 저런 내용을 가지고 자소서를 쓰고, 포폴을 작성했던 과거가 부끄러워 지는 순간이었습니다.
전개
그래도 실수를 알았으니 다시 잡아 봅시다.
마침 집에 굴러다니는 노트북이 하나 더 있어서, 그 노트북에 서버를 띄우고 테스트를 진행해 봤습니다.
이전에 `127.0.0.1`로 셀프 테스트를 하던 시절에 비해서 확실히 성능이 떨어지는 것이 보여서 다행입니다.
이젠... 행복해질 수 있는 거죠??
위기
그런데... 어라?
캐싱을 적용했는데 성능이 똑같습니다.
왜 그럴까요? 이때가 인생의 최대 위기였습니다.
이젠 제 상식이 의심이 되기 시작하는 순간입니다.
'캐싱을 써도 더 느릴 수가 있나? ㅎㅎ' 하고 이곳저곳 검색을 하고 있었는데...
이런 글을 읽고 정말 절망에 빠지게 되었습니다. (물론 저 글은 저 내용이 전부는 아니니 읽어보시는 것도 추천합니다.)
캐싱을 써서 성능을 개선했다고 말한 지금까지의 말이 다 거짓말이었고, 캐싱을 쓴다고 성능이 좋아지지도 않는다니... 이젠 어쩜 좋을까요?
절정
프로젝트 개선의 의지가 꺾여버려 매일을 술로 허망함을 달래면서 살아가다가 갑자기 이런 생각이 들었습니다.
디비를 `h2`로 켜놔서 그런가?
아무래도 `h2`는 인메모리 db니까 속도가 너무 빨라서 같이 메모리에 떠있는 캐싱이랑 비슷하게 빨랐던 거 아니야?
얼른 후다닥 `h2`를 `mariadb`로 바꾸고 다시 테스트를 진행했습니다.
그 결과는!!
네 아니었습니다.
하지만 갑자기 보이지 않던 큰 그림이 보이게 되었습니다.
처음으로 돌아와서 `Spring`과 `MariaDB`도 같은 PC에 떠있었기 때문에 이미 충분히 빨랐던 것입니다.
그렇다면 DB를 `Spring`과 따로 분리시켜 준다면 제가 원하는 대로 될까요?
위에 처럼 만들어주고 성능 테스트를 돌려봤는데!!!
드디어 원하는 결과를 얻을 수 있었습니다.
다시 보니 1000%라는 결과가 정말 터무니없이 느껴지네요.
결론
지금까지 성능 테스트를 하고 캐싱을 통해 개선을 하면서 만났던 좌절스러운 경험을 소개했습니다. 글로 표현하니 그 당시에 슬픔이 별로 드러나지 않아서 조금 아쉽네요. 이 경험을 통해서 분산 환경에 대해서 맛본 것 같아서 좋았습니다. 저 같은 취준생은 돌릴 수 있는 서버가 별로 없다 보니 하나의 서버에서 WAS, DB를 같이 돌리는 경우가 많은데 실제론 이렇지 않을 것 같으니 돈을 조금 더 쓰더라도 이런 상황을 만들어 보는 게 어떨까 생각이 들었습니다.
문득 네트워크와 관련된 내용을 공부하면서 봤던 블로그의 글이 생각났습니다. 현재는 완전 맞는 말은 아니라고 하지만, Network IO의 영향력을 느낄 수 있었던 경험이었네요.
서버가 HTTP 트랜잭션을 처리하는데 걸리는 시간은 TCP 커넥션을 설정하고, 요청을 전송하고, 응답 메세지를 보내는 것에 비하면 상당히 짧다. 대부분 HTTP 지연의 원인은 서버의 처리 지연보다는 이러한 TCP 네트워크 지연에 있다.
- HTTP 완벽 가이드
Broccolism - HTTP 커넥션 관리 (라고 쓰고 TCP 커넥션 살펴보기) - HTTP 완벽 가이드 4장
한 줄 요약을 하자면... 서버랑 DB, Test 도구를 다른 환경에서 굴리시오. 가 되겠습니다.
참고자료
스토리지 성능 이야기 - 캐싱 (Caching)은 무조건 성능이 좋다?
김형섭 (Matthew) - localhost 의 동작 원리
Broccolism - HTTP 커넥션 관리 (라고 쓰고 TCP 커넥션 살펴보기) - HTTP 완벽 가이드 4장
