DB 성능 측정 실험에 대한 논의

대용량 데이터를 잘 제어하기 위해선 어떻게 제어할 지 잘 알아야 한다. 어떻게 제어할지 잘 알려면 어떤 방법이 더 나은 것인지 비교할 수 있어야 한다. 비교하기 위해선 수치를 기반으로 측정해야 한다. 우리가 개발 과정에서 성능을 측정하고자 하는 이유가 바로 이 이유다.

어제 내가 정리한 내용을 바탕으로 팀원들에게 '우리는 이런 방향으로 측정하는 것이 좋겠습니다'라고 어필을 했고, 팀원분들의 반응이 좋았다.

하지만 중요한 피드백 하나를 받았는데, 바로 인프라 관련 측정 요소가 없다는 점이였다. 한 튜터분께서는 쿼리 성능을 튜닝하는 것보다 인프라의 구조를 바꾸는 것이 더 드라마틱한 변화가 생길 수도 있다는 의견을 주셨다고 한다. 현업에서 데브옵스 관련 있는 포지션에 있지 않는 이상 인프라를 다룰 경우가 과연 많을까라는 생각이 들었지만, 다양한 관점에서 성능을 분석하고 개선해나가는 것이 더 흥미로울 것 같아서 이 부분도 함께 고민해보기로 했다.

실험의 시작

어떤 실험을 해볼까 준비하려다가 문제 하나를 발견했다 🤗. 현재 나의 DB(raffle 테이블)에는 10,500개의 경매 데이터가 저장되어있는데, POSTMAN에서 GET 요청을 해도 응답을 받지 못한다는 점이 문제였다. POSTMAN의 limit과 관련된 이슈일 것이라 추측하고 있지만, 이 이슈보다는 데이터 크기로 인해 조회에 실패했다는 경험을 처음하게 된 것이 나에겐 더 흥미롭게 다가왔다.
데이터 500개를 지우고 10,000개의 데이터로 GET 요청을 시도해보니 정상적으로 응답이 반환되었는데, 그 응답속도가 수십 초 이상 소요되었다.
우리는 이 지점이 실험의 시작점이 될 가능성이 있다고 직감했다. 그리고 1,000개부터 10,000개 사이 데이터를 조회하여 어떤 방식으로 측정할지 논의하기 시작했다.

실험 계획

현재 경매 시스템의 가장 기본 CRUD 기능인 findAll을 테스트해보기로 했다.

1000부터 10000개 사이 1,000개 단위로 latency를 측정해보았다. 네트워크 편차를 고려하여 동일한 조건의 실험을 5회 반복 실험했다.

측정 요소

팀원들과 함께 어떤 요소를 측정하면 좋을지 머리를 맞대었는데, 결국 일단 측정할 수 있는건 다 해보자는 쪽으로 기울어졌다. 현업 cfo를 맡고 계신 튜터님은 고르기만 하세요, 일단 우리가 다 준비는 해드릴게요라는 마음으로.

측정 요소는 아래와 같다

• 응답
  • latency
  • 응답 데이터 용량
  • DB 내 데이터 개수(참조)
• 환경
  • 로컬환경 유무
• 하드웨어
  • 메모리
  • 운영체제
  • 칩
• 네트워크
  • upload capa
  • download capa
• DB
  • 인프라
  • 인스턴스
  • 엔진 버전
  • DB 소프트웨어
  • 인스턴스 성능
  • CPU
  • RAM
  • storage type
  • storage 용량
  • Max storage threshold

등이다.

실험 결과 깨달은 점

실험 결과는 예상한대로 데이터의 양이 많아질 수록 latency가 높아진다는 누구도 예상 가능한 결과다. 우리도 이 실험 결과로부터 특별한 인사이트를 얻을 것이라는 기대를 하지 않았다. 하지만 그 외 우리가 팀 차원에서 새롭게 발견한 사실(문제)들이 몇 가지 있었다.

뜻밖에 알게된 것들

각자 다른 DB를 쓰고 있다

• 우리는 각자 다른 DB엔진 버전과 성능을 사용하고 있었다는 점. 두명은 t3micro를 한명은 t4migro버전을 쓰고 있다. -> DB까지 모두 통일할 것

네트워크 속도에 따라 latency가 천차만별

• 놀라운 점은 이 상식적인 이야기를 내 홀로 실험을 할 때는 전혀 인지하지 못하고 있었다는 사실이다. 데이터 10,000개를 조회하니 latency가 엄청 길게 나오네?라는 것이 쿼리나 DB의 문제라고 생각했지 네트워크의 문제라고 생각하지 못했다. -> 공공장소 wifi 환경에서의 응답 속도는 놀랄만큼 느리다

팀원들의 사기가 올라간다

• 사실 이 실험을 기획할 때 팀원들의 R&R을 명확하게 나눠서 일을 배분하기 위함이 컸다. 그렇게 R&R을 나눠서 각자 실험한 것을 함께 수집하여 분석하는 시간을 가지면서 느낀 점은 팀원들이 이 과정을 정말 즐거워한다는 점이다. 가시적인 결과가 나오니 나 또한 만족도가 높았다.

앞으로

예상했듯이 이 실험에서 기술적 인사이트를 얻은 것은 없다. 우선 데이터의 양을 더 늘리는 방법으로 접근할 수도 있고 Artillery와 같은 부하 테스트 도구를 사용하여 접근할 수도 있을 것 같다. 팀원께서 Artillery로 자동화하자는 의견을 내주셨는데, 충분히 동의한다. nGrinder 이야기도 나왔는데, 우선 가볍게 Artillery로 접근한 뒤 니즈가 생기면 넘어가는 것도 생각하고 있다.