knockknock 서비스를 제작하면서, 댓글 기능을 구현할 때 고민 했던 부분들을 정리해 보고자 한다. knockknock 서비스가 궁금하다면 아래 회고록에서 확인해 볼 수 있다.
프로젝트 회고록 : "KnockKnock"
⭐️ 서비스 소개 주제 선정 및 동기 : 이번 프로젝트에서는 실제로 서비스를 론칭했을 때 많은 사람들이 관심을 가지고 서비스의 사용까지 이어질 수 있는 프로젝트를 기획하고 싶었다. 이러한
dev2-jay.tistory.com
프로젝트 단계에서는 실제로 엄청나게 방대한 데이터를 다루는 상황이 발생하지 않기 때문에, 고민하지 않고 넘어가면 실제 서비스 상황에서 나타날 수 있는 문제점이 많을 수 있다고 생각했다. 따라서 작은 단계에서의 의사결정에서도, 확장성을 고려한 서비스 기술 채택이 중요하다고 생각한다. 댓글 서비스를 구현할 때 생각을 해보았다.
이러한 생각의 흐름을 따라, 오프셋 기반과 커서 기반으로 동작하는 두 가지 페이지네이션을 모두 적용해 보고 더미데이터를 넣어보고 동작하는 시간을 확인하기로 결정하였다.
오프셋의 장단점 커서의 장단점을 설명하는 글들은 워낙 좋은 정보들이 많아 생략하고 내가 어떤 식으로 테스트하였는지 적어봐야겠다.ㅎㅎ
먼저 오프셋과 커서기반의 코드를 작성해 주었다.
그 후, DB에 더미데이터를 넣어줬는데, 성능 테스트를 위해서는 몇만 개로는 의미가 없고 1억 정도의 데이터가 필요하다는 정보를 보고, "오? 1억...? 뭐... 잘은 모르겠는데 많은 거 같긴 한데 일단 넣어 볼까? 아니 반만 줄여서 5천만 개부터 해보자...!"라고 생각하고, SQL문으로 5천만 개의 데이터를 생성하기로 결정하였다.
그런데... 계속 쿼리가 30초만 지나면 연결이 끊어지면서 ERROR 가 발생했다. 뭔가 이상하다 생각하고 검색해 보니 workbench 설정에서 쿼리가 일정시 간이상 초과하면 자동으로 끊어지는 설정이 되어있어서 그렇다는 것을 발견했다. 화끈하게 10시간 이상으로 설정 변경 후 다시 시도했다. (실제로 운영되는 서비스에서는 슬로우쿼리때문에 발생하는 서비스 오류를 방지하기위해 의도적으로 짧게 설정하는 것 같다.)
"음~ 잘 되겠지? 좀 걸릴 것 같은데 밥 먹고 와야지~~~" 라면서, 밥을 먹고 오고 40분이 지났다.
"음.... 좀 많이 걸리네?... RDS 괜찮나?" 걱정이 들기 시작했다. RDS에 들어가 확인을 해보니, 잘못 계산했을 수도 있으나 당시 시점에서 시간과 데이터의 양을 비교해 계산해 보니 "이거 이거,,, 매우 큰일 나겠어.. 나 돈 없어..."라는 생각이 먼저 들었고 허겁지겁 쿼리를 중지시켰다.
그 후, 최종적으로 확인해 보니 2,682,541 개의 댓글이 생성되었다.
이제 대망의 성능 테스트 시간이다. 첫 페이지를 불러왔을 때다.
댓글 아이디 1882552를 기준으로 불러왔을 때이다.
그렇다. 결론은 페이지가 뒤로 가면 갈수록 커서와 오프셋의 확연한 성능차이가 발생하는 것을 눈으로 확인할 수 있었다. 내가 확인한 지점에서는 커서가 0.46초 오프셋이 10초가 넘어가면서 약 20배 이상의 속도차이가 있었다. 이렇듯 이론으로만 알고 지나가는 것이 아니라 데이터로 확인하고 나니, 커서기반의 페이지네이션으로 구현해야겠다고 결정할 수 있었다. 나중에 서비스가 번창하여 많은 유저가 댓글을 달아도 금방금방 랜딩 되는 페이지를 보는 날이 왔으면 좋겠다는 조그마한 소망과 함께 미흡한 성능 테스트 경험담을 마치겠다.
