목차
- 사전 이해를 위한 구조 설명
- 문제 상황
- 1차 개선: 캐시 도입
- 2차 개선: mesh 방식으로의 전환
- 추가 개선 포인트: ForkJoinPool을 이용한 병렬 처리, ConnectionPool 조정
- 최종 테스트
- 도대체 왜?! - 답은 늘 쉬운 곳에
- 결론
- 번외편 - 데드락 만들기
본 글에 대해서
주차 도메인 업무를 하면서 정기권 서비스를 개발했습니다. 해당 서비스의 성능을 개선하면서 시도한 방법과 시행착오들을 다룹니다. 실제 코드는 컨셉 코드로 대체하였고 일부 로직은 간소화하거나 대체하였음을 밝힙니다.
사전 이해를 위한 구조 설명
- 스프링 MSA 환경에서 API 오케스트레이션과 사가(도메인)를 구분하는 패턴을 사용한다.
- 엔드포인트는 오케스트레이션에서 받고, 오케스트레이션에서 도메인 서비스를 호출하여 필요한 정보를 조합하여 클라이언트에게 최종 응답한다.
- 엔티티 참조는 직접 참조 방식이 아닌 간접 참조 방식을 사용한다.
- 대상 엔티티의 더미 데이터는 약 5천 건이다. 대용량 데이터셋을 다루는 테스트는 아니므로 데이터 개수는 크게 늘리지 않았다.
- APM은 스카우터, 성능 테스터 도구는 Gatling을 이용했다.