핀포인트

개요 Index를 적용하여 쿼리 최적화를 진행한 뒤에 N + 1 문제도 해결했습니다. 하지만 N + 1 문제를 개선한 뒤에 분리하여 테스트를 기록하지는 않았습니다. 왜냐하면 가장 오래 걸렸던 테스트 TOP 3안에 뽑히는 Database Connection PoolSize를 조정해보며 실험을 하게 되면 자연스럽게 기본 Pool 사이즈에서 N + 1 문제의 개선 결과도 볼 수 있을 것이기 때문입니다. 이 부분에서 가장 고생했던 부분은 Pool Size를 최적화 실험에서 더 효율적으로 테스트 하는 방법이었습니다. 예를 들면 '어느 정도의 테스트 시간을 설정하면 Connection Pool Size에 대한 변화를 잘 볼 수 있을까?', 'Connection Pool Size의 간격을 어느 정도로 진행해야 최적의..

개요 [#1](인프라 개선하기 작업)을 통해 이제 정상적으로 테스트는 가능했지만 전반적으로 개선의 필요성이 있다는 것을 절실히 느꼈습니다. 'Postman으로 응답 오면 잘 만들어졌군!' 하던 스스로가 너무 부끄러웠지만 이제 시작이니 차근차근 해결해 나가 보자는 생각을 갖고 가장 쉽게 고칠 수 있는 부분부터 접근해 나가려는 계획을 세우고 시작했습니다. 가장 먼저 눈에 띄는 것은 바로 '쿼리의 수행 시간'이었습니다. Database라는 것을 학습하면서 인덱스를 통해 빠른 속도를 통해 데이터를 갖고 올 수 있고 왜 빠른지에 대해서 알고 있었지만 '정말 빨라?'라는 의문과 '나는 실행 계획(EXPLAIN)을 통해 쿼리를 개선할 수 있을까?'라는 의구심으로써 Primary Key와 Foreign Key를 제외하..

개요 E-Commerce의 핵심이라고 할 수 있는 구매 주문 API 테스트 결과입니다. 인프라 개선 전에는 구매 주문 테스트를 시작하는 순간 서버가 다운돼서 테스트 결과를 얻지 못해 어느 정도로 개선되었는지 비교할 수는 없지만 로그인 API와 물품 목록 조회 API를 보았을 때 개선점이 많을 것이라 예상했습니다. 초기 테스트 계획은 랜덤한 물품 옵션을 랜덤한 수량으로 구매하는 시나리오만 테스트하려고 했으나 고민해보니 진정한 문제는 하나의 물품을 많은 유저가 구매하는 경우라고 생각이 스쳐 지나갔습니다. 랜덤한 상품을 구매하는 것을 다품목 구매 주문 테스트, 하나의 상품만 구매하는 것을 단품목 구매 주문 테스트라고 명명하고 테스트를 진행했습니다. 다품목 구매 주문 테스트 기대도 없어서 일까요 아니면 물품 조..

개요 하나의 개선점과 여러 테스트들을 모두 하나의 포스트에 담고 싶었지만 가독성이 떨어질 것이라 예상해서 분리하려고 합니다. 이번에는 물품 목록을 조회하는 API에 대해 테스트를 진행했습니다. 이해를 돕기 위해 ERD도 첨부했습니다. 물품 목록 조회 API는 Product의 Category를 쿼리 파라미터로 받아 Product Option과 함께 반환해주는 기능입니다. Spring Rest Doc을 통해 생성된 문서를 보면 다음과 같이 요청을 보냅니다. 이렇게 요청을 보내면 다음과 같이 응답이 반환됩니다. 상품과 함께 사이즈에 따른 수량도 함께 나오는 것이 기획이었기 때문에 Index, N + 1 문제 등 테스트 하기도 전에 걱정되는 API 입니다. 그럼 테스트 결과를 한번 보겠습니다! 물품 조회 API..

개요 기획한 기능들을 모두 완성하고 nGrinder를 통해 처음 Load Test를 진행했습니다. 위의 그림과 같이 nGrinder의 Controller와 Agent는 다른 서버로 분리했지만 CI/CD 툴로 Jenkins, Application Server, MySQL까지 하나의 인스턴스 안에 들어있는 구조입니다. Docker Out Of Docker라는 방식을 사용해서 빌드와 배포까지 진행하는 구조입니다. 정말 간단하게 테스트를 진행해서 병목을 찾을 수 있다고 생각했기 때문에 가장 저렴한 방식으로 구성했습니다. Docker Out Of Docker란 Docker Host와의 통신하여 Jenkins Docker 외부에 Docker를 실행시키는 방법입니다. 이런 구조가 문제가 될 것이라는 것은 테스트 이전..