[3차 과제] 톰캣, 스프링 설정 값 고민해보기

[dltnals317]

✅ TPS 1000 대응을 위한 성능 최적화 방안

---

▶️ 병목지점 예상 및 분석

💡 읽기 요청이 많은 경우

• DB 조회 속도가 병목이 될 가능성이 높음
• 자주 조회되는 데이터를 캐싱하여 DB 부하를 줄일 필요 있음
• 느린 쿼리, 인덱스 부족, 지나치게 많은 DB 연결 요청으로 인한 병목

💡 쓰기 요청이 많은 경우

• DB 쓰기 작업의 트랜잭션 처리 시간이 병목이 될 가능성이 있음
• 동시성 문제, 트랜잭션 충돌, 디스크 I/O 한계로 인한 병목

💡 외부 API 호출 포함

• 네이버 Open API를 사용하는 경우, 호출 응답 시간이 전체 처리 속도를 늦출 가능성이 있음
• 병목 원인:
  • 네이버 API의 대기 시간(latency) 또는 호출 횟수 제한(rate limit)
  • 외부 API 응답 실패 시의 처리 시간
• 해결 방안:
  • 외부 API 호출 결과를 일부 캐싱 (or 인기 검색어를 캐싱)
  • 호출 실패 시 재시도 로직 및 백오프 전략 적용

---

▶️ 톰캣 및 스프링 설정

💡톰캣 워커 스레드 설정:

• server.tomcat.max-threads=300 (요청량에 따라 200~500 사이로 조정).
• TPS 1000 요청을 처리하려면 동시에 처리 가능한 스레드 수 확보

💡스프링 비동기 처리:

• API 요청 중 DB 쓰기/읽기 시간이 길다면, 부분적으로 비동기 처리 진행
• Spring MVC를 사용하되, 부분적으로 이벤트 큐 방식으로 요청을 처리하는 로직 추가

💡스프링 캐시:

• 자주 호출되는 데이터를 Redis 같은 캐시에 저장:

  spring.cache.type=redis
  spring.redis.host=localhost
  spring.redis.port=6379
  

2.4 DB 커넥션 풀 설정

• spring.datasource.hikari.maximum-pool-size=300 (TPS 및 쿼리 성능에 따라 조정).
• 느린 쿼리(EXPLAIN PLAN) 분석 및 인덱스 추가.

---

▶️ 스케일링 방안

💡스케일 아웃

• 여러 서버로 API 트래픽 분산:
  • 로드밸런서를 통해 요청 분배(AWS ALB, Nginx 등).
  • 서버 1대당 TPS 500~700을 처리할 수 있도록 구성.

💡스케일 업

• 서버 사양을 늘려 더 많은 트래픽 처리:

  • 예: CPU 코어 수 8개, RAM 32GB.

• 현실적으로, AWS 프리 티어 계정을 쓰고 있기 때문에 스케일 업 방식은 어려운 부분이 있습니다.

• 프리 티어 계정을 여러 개 사용하여, 스케일 아웃을 통한 트래픽 분산을 시도하는 것이 현재 상황에 더 맞다고 생각하고 있습니다.

---

▶️ 성능 테스트

• JMeter로 API 요청 시뮬레이션(TPS 1000 테스트):

  • 주요 테스트 지표:
    • 평균 응답 시간
    • 에러율
    • TPS 유지 여부

• 테스트 결과에 따른 병목지점 개선:

  1. 느린 API 응답 분석 및 최적화.
  2. DB 커넥션 부족 문제 발견 시 커넥션 풀 크기 조정.
  3. 톰캣 스레드 증가 여부 결정.

---

▶️ 성능 개선 주요 과제

💡JPA N+1 문제 해결

• 현재 코드에서는 추가 데이터 JOIN 문제를 고려하고 있지 않은데, 일괄적으로 리팩터링 진행 예정 (Fetch Join 설정)

💡페이징 처리 적용

• 대량의 데이터를 한 번에 가져오지 않고, 필요한 범위만 가져와 메모리 및 응답 시간을 최적화
• 직후 스프린트에서, 피드 조회 API에 적용될 예정!

💡캐싱

• 자주 사용되는 데이터, 특히 네이버 장소 검색 API로 인해 반환되는 데이터 중 자주 사용되는 데이터들을 서버 또는 클라이언트 측에 캐싱하여 응답 시간을 줄임

💡커넥션 풀 관리

• 커넥션 풀 값을 조정하며 최적의 설정 찾기

💡쓰레드 풀 크기 조정

• 쓰레드 풀 크기를 조정하며 최적의 설정을 찾되, 커넥션 풀을 동시에 고려

💡로드 밸런싱

• 스케일 아웃 방식을 적용하는 경우, Nginx를 사용하여 로드 밸런싱 진행
• 부하가 큰 API(피드 조회 API 등)를 별도의 독립적인 서버로 분리하여, 장애가 전파되지 않도록 설계

[daehwan2da]

👍🏻