이슈 생성 시 커넥션 풀 트러블 슈팅 해결 및 성능 개선

[minsang-alt]

## 코드 리뷰할 때 안봐도 되는 클래스

1. 성능테스트를 용이하게 하기 위해 JwtAuthFilter와 Spring Security 관련 인증 필터는 다 비활성화 시켰습니다.
2. Retry 어노테이션과 RetryAspect는 낙관적락으로 테스트해볼때 써보고 사용되지 않은 클래스이므로 제거하겠습니다.
3. cd, Dockerfile, docker-compose 다 넘기셔도 됩니다
4. DummyDataLoader도 마찬가지
5. ...~~

중점적으로 봐야할 클래스들

• EpicFactory
• IssueNumberGenerator
• application.yml
• application-redis.yml
• SchedulingConfig
• RedisConfig

해결한 부분

요약

20명의 동시 이슈 생성 요청 시 발생한 커넥션 풀 부족 문제로 발생한 데드락을 해결하고, 100명 규모의 동시 사용자 처리를 위한 성능 개선을 수행

상황

• HikariCP 기본 설정(10개)으로 인한 데드락과 커넥션 타임아웃 발생
• 로그 분석 결과, 이슈 생성 요청당 2개 이상의 트랜잭션(커넥션) 필요 (이슈 생성 + 이슈번호 발급)

• 1000명 규모 조직 대상, 동시 사용자 100명, 30-40 TPS, 응답시간 2초 이내, 에러율 0.1% 목표

해결방안

• Ngrinder 부하테스트로 HikariCP Pool Size와 톰캣 스레드 최적 값 (Hikari Pool size 8개, tomcat max thread 10개) 도출

• 데드락 위험이 있는 REQUIRES_NEW 트랜잭션 제거로 요청 당 필요 커넥션 수를 2개에서 1개로 감소시켜 Pool Size 관리 부담을 해소
• 해당 요청에 대한 SELECT 쿼리 EXPLAIN 확인했지만, 성능 저하 부분이 없었음
• 이슈 생성 요청 중, 이슈 번호 생성 시 비관적 락을 사용하여, 이슈 생성 전체 트랜잭션이 끝날 때까지 해당 시퀀스 테이블에 락을 걸어서 성능저하가 일어나고 있었음

커넥션 제거 전 다이어그램

• synchronized와 ReentrantLock은 다중 서버환경에서 동시성 제어가 불가능하여 부적절

• 낙관적락으로 Retry 3번 시도하는 것은 충돌 발생이 오히려 증가되어 비관적락보다 성능저하가 일어남

• 이슈 번호 생성 로직을 따로 트랜잭션을 분리했지만(REQUIRED_NEW) 히카리 풀 적정 개수를 찾는 게 매우 어려움

• Redis의 atomic INCR 연산을 활용한 동시성 제어 방식 도입

  • 이슈번호를 생성한 뒤, 가공하여 이슈테이블에 저장하기 때문에, 이슈시퀀스 테이블은 일관성이 떨어져도 됨
  • Redis와 MySQL의 동기화를 위해 Write-Back 전략을 적용해, 배치프로세스로 비동기 동기화
  • 레디스 가용성 문제를 해결하기 위해 Replication 이나 클러스터중 스케일아웃은 필요없어서, Replication으로 해결 예정

결과

• TPS 33 → 68 (106% 증가)
• 평균 응답시간 2,944ms → 1,429ms (51% 감소)
• 에러율 0% 달성
• 100 VUser 동시 요청 처리 가능

---

[github-actions]

Unit Test Results

46 tests   46 ✔️  2s ⏱️
24 suites    0 💤
24 files      0 ❌

Results for commit 2ff31d0.

♻️ This comment has been updated with latest results.