1. 내가 구현한 흐름은 어떻게 구성되었고, 어떤 기준으로 구조를 나눴나요?
Controller -> Facade -> Service -> Repository <- RepositoryImpl
Layered Architecture + Clean Architecture 관점에서 접근하여 단방향 의존성을 지키며 구현했다.
2. 통합 테스트를 어떤 방식으로 구성했나요? 테스트를 통해 확인하고 싶었던 건 무엇이었나요?
Controller, Facade, Service에 대해서 통합 테스트를 진행하였다.
이전 주차에 작성해둔 단위 테스트를 바탕으로 비즈니스 흐름 상 각 단위가 잘 조립되어 작동하는지에 대해 집중하며 통합테스트를 구현하였다.
시간 부족 이슈로 성공하는 케이스에 대해서만 작성한 것이 아쉬움이 남는다.
5주차를 진행하면서 예외 케이스에 대해서 추가로 작성해보는 것도 좋을 것 같다.
3. DB 성능이나 동시성 문제를 어떻게 분석했고, 어떤 해결 방안을 고민했나요?
예상했던 느린 조회 기능
- 인기 상품 조회
- 상품 목록 조회
- 사용자 보유 쿠폰 조회 -> user_id 인덱스 처리
- 주문 시 재고 조회 -> PK로 조회(이미 인덱스)
- 결제 시 잔액 조회 -> user_id 인덱스 처리
- 결제 시 주문 정보 조회 -> PK로 조회(이미 인덱스)
인기 상품 조회의 경우 인덱스를 걸기 전에 full scan을 하고 있었다.
(product_id, created_at, sales)로 복합 인덱스를 걸고 성능을 측정한 결과 성능 개선 가능성은 확보되었으나, 실행시간이 줄어들지는 않았다.
조회된 결과를 캐시 테이블에 저장하는 방법을 통해 추가로 성능 최적화를 진행할 수 있을 것이다.
상품 목록 조회의 경우 full scan을 하며 인덱스를 걸 수 없기 때문에
추후 검색 조건을 추가하거나 페이징을 추가해 성능을 향상시킬 수 있을 것이다.
사유에 대해 좀 더 디깅을 해서 보고서를 작성했으면 좋았을 것 같다는 아쉬움이 있다.
4. 이번 과정을 통해 느낀 점은 무엇인가요?
DB 성능을 고민하면서 DB에 대한 개념과 경험이 부족하다고 느꼈다.
DB 성능 최적화 과정을 경험한 적이 전무하다보니 시작을 어떻게 해야할지부터 어려웠다.
성능에 대한 고민을 하면서 최적화할 수 있는 방법을 디깅해봐야겠다.
이번주차는 3주차 피드백을 바탕으로 리팩토링 하는데 시간을 많이 쓰면서 4주차 과제에 힘을 좀 덜 들였는데,
5주차부터는 시간 분배를 잘해서 해당 주차 과제에 힘을 써야겠다.
