2024-04-08) 모니터링&테스트와 관련된 의사결정 여러가지

저번 4월 6일에 멘토님께 피드백을 받으면서 내용을 정리하고, 다음 주제에 대해 의사결정을 내리게 되었다.

테스트 스크립트 작성

통합 테스트 하나만 있어도 괜찮을 것 같다는 결론에 도달했다. 통합 테스트는 시스템 전체의 동작을 확인하는 데 유용하기 때문에, 개별 단위 테스트만으로는 확인할 수 없는 문제들을 발견할 수 있다. 예를 들어, 로그인 후 쿠키 인증, 예약 후 예약을 기반으로 한 결제, 대기열 통과 후 통과 인증 토큰 등이 있다. 우리가 확인해야 하는 것은 결국 수많은 사용자가 동시에 한 작업들을 수행하는 것을 목표로 둬야 하기 때문에 단일 테스트보다는 통합 테스트 기준으로 테스트 스크립트를 작성해야 한다.

테스트 코드 작성 시 유의사항(멘토님 피드백 내용)

• 단위 테스트가 안 되는 코드는 잘못 작성한 코드라는 것을 명심해야 한다.
• 단위 테스트는 여러 로직을 엮어서 하는 것이 아님을 이해해야 한다.
• 단위 테스트는 개별 모듈이나 함수가 올바르게 동작하는지를 확인하는 것이므로, 다른 로직에서 필요한 것들은 Mock을 사용하는 것이 바람직하다.

서버 관리

보통은 가상 서버를 나눠서 띄우는 것이 맞지만, 예산 문제로 일단 같이 띄우는 것도 방법일 수 있다고 피드백 해주셨다. 이를 기반으로, Docker Compose로 서버 레벨을 나눠놓고, 실제 프로젝트 발표 때 서버를 분리할 계획이다. 이렇게 하면 초기 비용을 절감하면서도 나중에 확장성을 고려한 준비를 할 수 있다.

서버 레벨을 분리함으로써 각 서버가 담당하는 역할에 따라 최적화할 수 있기 때문에 성능과 안정성을 높일 수 있다. 예를 들어, 애플리케이션 서버와 데이터베이스 서버를 분리하면 각각의 자원을 독립적으로 관리할 수 있어 자원의 충돌을 줄이고 성능을 향상시킬 수 있다. 또한, 문제가 발생했을 때 원인을 쉽게 파악하고 해결할 수 있다.

모니터링 툴 선택

모니터링, 실제, 부하 테스트 서버로 나누기로 했다. 그 이유는 좀 더 공정한 측정 결과를 얻기 위해서였다. (각각에 가해지는 부하가 온전히 가해질 수 있도록)

모니터링 툴의 선택은 프로젝트의 안정성과 성능을 보장하는 데 중요한 역할을 한다. 여기서 놓친 부분이 바로 모니터링할 지표와 범위를 명확히 설정하는 것이었다. 서버 성능, 네트워크 트래픽, 응답 시간, 오류 발생률 등을 모니터링할 수 있었지만, 실제로 활용했던 것은 응답시간 정도였던 것 같다.

모니터링 툴로는 엘라스틱과 핀포인트 중에서 지원하는 기능이나 UI 부분이 편리한 엘라스틱 APM을 선택할 것 같다. 당시의 러닝 커브에서는 최선이었다. 프로젝트의 기간이 길지 않았었고, 핀포인트를 더 붙잡고 있었다면 프로젝트가 지체되었을 것이다.

API별 부하 테스트와 Use Case 기반 통합 테스트

현업에서는 실제로 Use Case를 다 묶어서 해보는 경우가 흔치 않기 때문에, 이 부분은 면접장에서 어필할 수 있는 포인트가 될 것이다. 이를 기반으로 테스트 스크립트를 로그인 -> 검색 -> 항공기 선택 -> 좌석 예약 -> 결제 이 순으로 작성하기로 결정했다.

API별로 부하 테스트를 할 때는 성공뿐만 아니라 실패하는 것도 테스트해야 하고, 어느 부분에서 병목이 발생하는지 확인해서 테스트하는 것이 중요하다. 예를 들면 예약 실패와 같은 경우는 경쟁 상황에서 자주 발생하는 에러이기 때문에, 이를 테스트하여 어느 부분에서 병목이 발생하는지 확인하고 이를 해결하는 것이 중요하다. 추후에 이 부분에서 병목현상이 발생하였고, 비관적 락 때문이라는 것을 알 수 있었다.