테스트 전략

애플리케이션이 완성되었으니 본격적으로 실험을 진행하고자 한다.

부하 테스트 클라이언트와 애플리케이션 서버를 클라우드 컴퓨팅 서비스에서 실행한다.

• 네트워크 환경이나 다른 프로세스 등 로컬 환경에는 변수가 너무 많아 실험 결과에 영향을 줄 수 있다.
• 테스트에 필요한 하드웨어 성능을 손쉽게 확장할 수 있다.

애플리케이션 서버와 데이터베이스는 동일한 인스턴스에서 실행한다.

• 환경을 격리하면 좋겠지만, 현실적으로 인스턴스를 두 개로 쪼개면 예산이 더 들고 자원을 효율적으로 사용하지 못 한다.
• 실험 중 구분해야 할 이유가 생기면 그때 고려해보자.

부하 테스트 클라이언트는 gatling을 활용한다.

• 오픈소스(무료)다.
• 시나리오 기반 테스트가 필요한데, Scala를 통해 유연하게 작성할 수 있다.
• 다른 솔루션에 비해 쉽고 간단한 편이다. 공식 문서도 잘 되어 있어서 조금만 읽으면 바로 사용할 수 있을 것 같다.
• Scala를 배워야하긴 하지만, 어차피 다른 솔루션도 시나리오 작성을 위해서는 언어 하나는 배워야하는 것 같다.
  • 이미 비슷한 JVM 언어인 Kotlin을 배웠기 때문에 큰 어려움 없이 배울 수 있을 것 같다.

테스트에 필요한 서버 데이터 삽입은 python을 통해 자동화한다.

• python의 requests 모듈은 HTTP 요청 스크립트를 빠르게 작성할 수 있도록 돕는다.
• 언어 자체가 간결해서 필요할 때 빠르게 수정할 수도 있다.
• csv 모듈로 클라이언트 데이터를 생성하고 gatling에서 읽도록 할 수 있다.

모니터링과 디버깅 전략

원하는 성능이 나오지 않거나 버그가 발견되면 그에 대한 정보를 수집하여 문제를 해결해야 한다.
따라서 서버 모니터링과 디버깅 전략이 필요하다.

애플리케이션 서버 모니터링은 Spring Boot Actuator의 Metrics를 수집하여 구현한다.

• 프레임워크에서 지원하고 있는 기능이므로 비교적 손쉽게 도입할 수 있을 것 같다.
• 일반적으로 매트릭은 성능 추이 확인, 이벤트 로그는 사용자 통계와 문제 해결을 목적으로 사용된다고 한다. 이벤트 로그도 수집하면 좋겠지만 시스템 구현이 복잡하고, 지금은 매트릭만 수집하고 로그는 직접 뜯어서 봐도 무방할 것 같다.

Metrics Registry는 Prometheus를 활용한다.

• 공식 문서가 잘 되어있는 기술 중 하나이다.
• Metrics 수집에 대표적으로 활용된다고 한다. 반면 InfluxDB는 이벤트 로그 수집에 활용된다.
• 기본적으로 pull-based지만, pushgateway로 push 방식도 지원한다.
  • 애플리케이션과 DB 모두 수집해야하는 상황인데, DB는 무조건 pull 방식으로 가져와야 한다.
  • 애플리케이션을 pull 방식으로 가져오면 Tomcat 스레드가 부족할 때 응답을 주지 못 한다. 따라서 이때에는 이벤트 로깅이나 push 방식을 활용해야만 한다.
  • 결국 pull 방식과 push 방식 모두 사용해야 한다. Prometheus가 기본적으로 pull 방식인 점은 깊게 고려할 사항이 아니다. (어차피 둘 다 지원되고, 큰 차이가 없다)
• 초기 설정이 간단하다. Docker로 컨테이너를 띄워서 바로 실행할 수 있다.
• PromQL이라는 간결한 표현식으로 쿼리한다.
  • 공식 문서에도 잘 나와있고 양이 많지않아 큰 시간을 들이지 않고 학습할 수 있다.
  • 반면 InfluxDB는 InfluxQL이라는 SQL 비스무리한 방식을 사용했고, 최근에는 아예 새로운 Flux라는 표현을 사용하고 있다. 이전 방식은 비교적 사용하기 어렵고, 최근 방식은 연계할 다른 기술에서 제대로 지원하지 않는다.

Metrics 시각화에는 Grafana를 활용한다.

• 오픈소스이다.
• 초기 설정이 간단하다. Docker로 컨테이너를 띄워서 바로 실행할 수 있다.
• 다양한 기술과 연계할 수 있다.

애플리케이션 서버 디버깅에는 로그를 활용한다.

• 여러 요청이 동시에 처리되므로 로그 분석이 어렵긴 하지만, 같은 종류의 요청이므로 조금만 노력을 기울이면 충분히 해석할 수 있는 규모이다.
• 다른 솔루션을 도입하기에는 시간적 비용이 크다.

데이터베이스 모니터링은 MySQL의 Metrics 테이블을 활용한다.

• mysqld_exporter로 MySQL의 Metrics를 Prometheus가 수집하도록 한다. (pull-based)
• 무료이며, 다른 솔루션을 도입할 필요가 없고, 공식 문서에도 어느 정도 설명되어 있다.

데이터베이스 디버깅은 SHOW ENGINE 표현을 활용한다.

• 이것만으로도 대부분의 데드락 문제를 진단할 수 있다.
• 다른 수단이 추가로 필요하면 그때 더 찾아보자.