팀 차원에서 체계적인 성능 측정 방법에 대한 고민

나는 왜 이런 고민을 하는가

백엔드 CRUD 작업도 거의 끝났고 프론트의 기본적인 틀도 갖춰지고 있다. MVP가 완성되어가는 시점이 되자 슬슬 퍼포먼스에 대한 질문이 팀원들 사이에서 자주 언급되었다. 게시글 모듈의 fineOne은 쿼리문 2개로 되어있는데, 쿼리문 1개로 합치면 속도가 더 빨라질까? DB에 10,000개가 넘어가면 findAll이 안되는 상황이 생기는데 왜 이런걸까 등등.
사실 백엔드 엔지니어로서 이런 부분에 대한 인사이트를 얻는 것은 매력적인 기회이다. 하지만 나를 포함하여 3명 뿐인 프로젝트에서는 조심스러운 기회다. 왜냐하면 팀원 중 누군가는 프론트를 해야하고 누군가는 인프라를 건드려야 한다. 어떤 상황에서나 팀원이 나만 왜 이런걸 해야하지 라는 의문을 갖는 것은 당연하고 이는 곧바로 팀의 분열로 이어질 수도 있다. 따라서 이런 기회는 최대한 균등하게 정밀하게 쪼개서 분배해야 한다.
그렇다고 해서 이러한 접근 방식은 단순히 공정의 문제만이 아니다. 어떤 것을 잘 측정하려면 기준을 잘 세워야할 뿐만 아니라 어떤 방식으로 접근할 것인지 등 체계적으로 접근하지 않으면 안된다. 따라서 측정하기 전에 미리 어떻게 측정할 것인지에 대해 생각을 정리하고자 한다.

무엇을 측정할 것인가

우리 래플 서비스 시스템의 아키텍처다. 리액트로 구축된 프론트엔드의 API 요청을 백엔드에서 데이터로 응답해주고 있다. 클라이언트 사이드 랜더링 방식이다. API 요청이 크게 몰릴 것으로 예상되는 경로는 래플(경매)의 전체 조회(findAll)과 상세 페이지(findOne) 그리고 bid의 post 요청이다. bid는 입찰 요청인데 사실 이 부분이 가장 스트레스가 많은 구간일 것이다. 이 모듈은 websocket으로 실시간 처리하는데, 튜터 님의 조언에 따르면 bid 데이터를 DB로 처리하기엔 힘들 것이고 차라리 log로 추출하여 따로 캐싱하는 것이 좋다는 이야기를 들었다. 아직 캐싱 관련 기술을 접해본 적이 없어서 구체적으로 어떻게 접근해야할 지 잘 모르겠다.

우선 현재 우리의 관심사를 기반으로 측정 대상이 무엇이고 어떤 요소를 측정할 것인지 큰 틀에서 나눠보았다.

대용량 데이터를 다루는 프로젝트에서 측정 대상의 큰 축은 조회와 등록이라고 생각한다. 조회외 등록은 엄연히 성질이 다르기 때문에 별개의 실험으로 나누는 것이 좋겠다.

조회는 전체 조회인 findAll과 상세 조회인 fineOne으로 구분했다. 이 두개도 실제 서비스에선 다른 페이지이지만 조회 기능이라는 관점에서 비슷하기 때문에 서로 측정하는 요소를 공유해도 좋을 것 같다. 예를 들어, 데이터베이스 내 적재한 데이터의 개수, 컬럼 수, DB 유형, DB 성능 등을 측정하면 되겠다. 특히 현재 우리 findOne 코드는 쿼리를 2번 쏜 결과를 하나의 객체에 담아 리턴하는 상황인데, 쿼리를 1개로 줄인 것과 어떤 차이가 있는지도 그리고 쿼리 빌더의 유무에 따른 성능 차이도 궁금하다. 데이터 1,000개 기준으로는 체감상 약 10ms 정도 쿼리빌더가 빨랐던 것 같은데, 네트워크 문제는 전혀 고려하지 않았기에 신뢰할 수는 없다. 아마도 데이터의 크기가 커지면 그 차이가 뚜렷하게 나타날 것으로 기대된다.

등록은 어떻게 접근해야 할지 지금은 잘 모르겠다. 아직 공부해보지 못한 websocket으로 구현할 예정이이기도 하고 데이터를 생성하는 것을 측정해봐 하면 바로 떠오르는 생각은 서버가 터졌냐 안터졌냐 정도다. 아마도 이 부분에서는 세부적으로 node.js의 배경 기술의 관점에서 현상을 해석하면 좋을 것 같다는 생각이 든다. 시간이 된다면 꼭 해보고 싶은 부분이다. 브라우저의 작동 원리를 설명하는데 V8 엔진의 구체적인 코드를 예시로 들면서 설명하는 블로그를 보면 멋지다는 생각이 들었는데, 이참에 node.js에 대해 깊이있게 공부할 수 있는 기회가 될 것 같다.

참고자료

정보시스템 운영 성과측정 매뉴얼(행정자치부)
file:///Users/thursdaycurry/Downloads/170411%2017%20(%20).pdf