Connection Pool 크기와 타임아웃 설정

기본개념

1. Connection Pool의 역할

• Connection Pool은 애플리케이션이 데이터 베이스와 통신하기 위해 미리 연결을 생성 해 두는 저장소.
• 연결을 매번 생성/해제 하면 성능이 저하되므로 재사용 가능한 연결 풀을 통해 성능을 최적화한다.

2. 주요 파라미터

• Maximum Pool Size: 동시에 사용할 수 있는 최대 연결 수.
• Minium Idle Connections: 사용되지 않을 때 유지할 최소 연결 수.
• Connection Timeout: 연결 요청 시 대기 할 최대 시간.

Connection Pool 크기 설정

왜 중요하가?

• 연결 풀 크기가 너무 작으면 요청이 대기 상태가 되어 처리 속도가 느려짐.
• 연결 풀 크기가 너무 크면 DB서버에 과부하가 발생하여 성능이 저하된다.

단계별 설정

1. 트래픽 분석
   • 애플리케이션의 동시 사용자 수와 요청 패턴을 분석.
   • ex: 애플리케이션 초당 평균 100개의 요청이 발생하고 각 요청이 50ms동안 연결을 유지한다

     = 100 * 0.05
     = 5(최소 연결 필요) 

2. DB서버의 제한 확인
   • DB서버가 지원할 수 있는 최대 연결 수를 확인.
   • ex: MySQL SHOW VARIABLES LIKE 'max_connections' ;
3. 기본 설정
   • 최소 연결 수는 트래픽 분석 결과의 80%로 설정
   • 최대 연결 수는 DB 서버의 최대 연결 수의 80%를 넘지 않도록 설정.
4. 로드 테스트
   • JMeter, Gating 등의 도구로 예상 트래픽을 시뮬레이션 하여 성능 확인.
   • 연결 풀 부족 시 대기시간이 늘어나는지 확인.

Connection Timeout 설정

1. 왜 중요한가?
   • 타임아웃을 짧게 설정하면 불필요한 대기 없이 오류를 빠르게 감지할 수 있다.
   • 너무 길게 설정하면 장애 원인 파악이 어려워진다.
   • 너무 짧게 설정하면
     • 네트워크가 느리거나 서버가 과부하일 경우 요청이 처리되기 전 연결이 끊어질 수 있다.
     • 재시도 과정에서 네트워크 대역폭과 서버리소스가 불필요하게 소비된다.
2. 설정 단계
   1. 요청 응답시간 확인
      • 평균적 DB응답 시간은 수십ms에서 수백ms 수준.
      • ex: 쿼리가 200ms 내외로 완료된다면 타임아웃을 500ms ~ 5000ms 로 설정
   2. Connection Timeout 설정
      • HicariCP의 connection-timeout은 견결을 기다릴 최대 시간이다. (default: 3000ms)
      • 실무에서는 보통 2000~10000ms 사이로 설정한다.
   3. Validation Timeout 추가.
      • 연결 유효성을 검사하는 시간. 일반적으로 1000~5000ms 설정
   4. 실패시 재시도정책
      • 타임아웃 발생 시 재시도를 설정하거나 Circuit Breaker를 사용한다.

성능 최적화

1. 모니터링 도구를 활용한다.
   • Actuator의 /metrics 엔드포인트에서 hicaricp.connections.*지표를 확인.
   • 그라파나, 프로메테우스와 통합하여 커넥션 풀 상태 모니터링
2. 쿼리 효율성 확인.
   • 슬로우쿼리가 풀을 점유하지 않도록 주기적으로 쿼리 성능 분석.
   • mysql의 경우 slow_query_log 활성화
3. 스케일링 전략
   • 트래픽이 지속적으로 증가할 경우 DB와 애플리케이션 인스턴스 수를 증가시킨다.

@Transactional 메소드 내에서 @Transactional(propagation = Propagation.REQUIRED_NEW) 메소드를 실행하게되면 어떤 일이 발생할까

트랜잭셔널 메소드에서 새로운 트랜잭션을 시작하면 어떤일이 발생하는지 알아보자.

1. 애플리케이션 시작 시 작업

1-1. 트랜잭션 관리자 등록

• 애플리케이션 시작 시 트랜잭션 관리자가 등록된다.
• 트랜잭션 전파 정책(Propagation)을 처리할 수 있도록 AOP 프록시가 생성된다.

1-2. AOP 프록시 생성

• @Transactional이 적용된 메소드에 대해 프록시가 생성된다.
• 각각의 메소드가 호출될 때 전파 정책을 해석하도록 설정된다.

2. 부모 매소드 실행(@Transactional, REQUIRED 전파 정책)

2-1. 트랜잭션 시작

• 부모 메소드가 호출되면 프록시가 트랜잭션 관리자를 통해 트랜잭션을 시작
• 트랜잭션 전파 정책 Propagation.REQUEIRED의 기본 동작에 따라 기존 트랜잭션이 없으면 새 트랜잭션을 시작.
• 데이터베이스 연결이 확보되고, auto-commit이 비활성화됨

2-2. 비지니스 로직 실행 중 자식 메소드 호출

• 부모 메소드 내에서 Propagation.REQUIRED_NEW가 적용된 자식 메소드가 호출됨.

3.자식 메소드 실행(@Transactional, Propagation.REQUIRED_NEW)

3-1. 부모 트랜잭션 일시 중단

• 자식 메소드가 호출되면 부모 트랜잭션이 일시중단 상태로 변경됨.
• 일시 중단된 트랜잭션은 컨텍스트에 보관되며, 자식 메소드가 끝날때까지 대기.

3-2. 새로운 트랜잭션 시작

• 자식 메소드는 항상 별도의 트랜잭션에서 실행
  • 트랜잭션 관리자가 새로운 데이터베이스 연결을 확보하거나 기존 연결을 재사용 하여 별도 트랜잭션을 시작.
  • 새로운 트랜잭션은 부모 트랜잭션과 독립적으로 커밋 또는 롤백될 수 있다.

3-3. 비지니스 로직 실행

• 자식 메소드의 비지니스 로직이 새로운 트랜잭션 내에서 실행됨.
• 데이터베이스 작업은 자식 트랜잭션의 컨텍스트에서만 적용됨.

3-4. 자식메소드 종료

• 자식 메소드 실행이 끝나면 아래와 같은 동작 발생
  • 정상종료시, 커밋
  • 예외 발생시 자식 트랜잭션롤백

4. 부모 메소드 재개

4-1. 부모 트랜잭션 복구

• 자식 메소드 실행이 끝난 후, 무보 트랜잭션이 일시중단 상태에서 복구됨.
• 부모 트랜잭션은 자식 트랜잭션과는 독립적으로 계속 진행됨.

4-2. 부모 메소드 비지니스 로직 실행(남은 작업)

• 부모 메소드의 나머지 비지니스 로직 실행.
• 데이터베이스 작업은 부모 트랜잭션 컨텍스트에 반영.

4-3 부모 메소드 종료

• 부모 메소드 종료되면 아래와 같은 동작 발생
  • 정상 종료시 커밋
  • 예외 발생시 부모 트랜잭션 롤백

5. 특이 케이스

5-1. 자식 트랜잭션 커밋 후 부모 트랜잭션 롤백

• 부모 트랜잭션이 나중에 롤백 되더라도 자신 트랜잭션은 독립적으로 커밋 되었기 때문에 영향을 받지 않는다.

5-2. 자식 트랜잭션 롤백 후 부모 트랜잭션 정상 종료

• 자식 트랜잭션이 실패하면 부모 트랜잭션은 이를 감지할 수 없다.
  • 단, 예외를 명시적으로 처리한다면 감지시킬 수 있다.
  • 부모 트랜잭션은 독립적으로 커밋 또는 롤백된다.

정리:

1. 부모 메소드(@Transactional, Propagation.REQUIRED)가 호출되며 트랜잭션이 시작됨.
2. 자식 메소드(@Transactional, Propagation.REQUIRED_NEW)가 호출되면 부모 트랜잭션 일시중단.
3. 자식 메소드는 새로운 트랜잭션에서 실행되며 독립적으로 커밋 또는 롤백됨
4. 자식 메소드 실행 후, 부모 트랜잭션이 북구되어 남은 로직 실행
5. 자식과 부모 트랜잭션은 서로 독립정이며, 서로의 성공 여부에 영향을 주지 않음.

이런 구조로 트랜잭션간의 독립성이 보장되며, 필요 시점에 새로운 트랜잭션을 생성해 데이터 무결성을 관리하는데 도움이 된다.

MSA란 무엇인가?

• MSA

  • 하나의 서비스를 만들때 도메인별로 서비스를 쪼개어 독립적으로 서비스하고, 디플로이할 수 있도록 구성하는 아키텍쳐
  • 모놀리식(monolithic) 아키텍처와 대비되는 성격의 아키텍처이다.
  • 애플리케이션 로직을 각자 책임이 명확한 도메인별로 분리하여 이를 조합해 솔루션을 제공한다.
  • 각 컴포넌트(도메인)는 작은 책임 영역을 담당하고 완전히 상호 독립적으로 배포된다. 마이크로 서비스는 비지니스 영역의 한 부분에서의 책임만을 담당하고, 여러 어플리케이션에서 재사용할 수 있어야한다.
  • 어플리케이션은 항상 기술 중립적 프로토콜을 사용해 통신하기때문에 서비스 구현기술과 무관하다. 이는 한 서비스를 구축하할때 개발언어 및 기술에 종속되지 않고 다양한 언어와 기술을 사용할 수 있다는 장점이있다.

• Monolithic

  • 모듈이 서비스 내부의 Product 현태로 종속되어있으며, 서비스에만 집중할 수 있는 구조
  • 장점
    • 개발 초기에는 단순한 아키텍처 구조와 개발의 용이함이 큰 잠점.
  • 단점
    • 규모가 커짐에따라 복잡도의 증가가 심해진다.

• MSA의 장점

  • 각 도메인별로 서비스를 배포하고 운용하기때문에 결합도(coupling)이 낮아지는 장점이있다.
  • 배포가 유연하다.
  • 재사용성 및 확장성이 크다.
  • 서비스별 기술의 도입 및 확장이 자유롭다.
  • 하나의 서비스에 문제가생겨도 연관되지 않은 다른 도메인은 지속적으로 서비스가 가능하다.

• MSA의 단점

  • 장애추적, 모니터링, 매시징이 어렵다(?? 이게 어렵나?)
  • 어려 도메인에 걸친 기능의 경우 트랙잭션을 다루기 어렵다.
  • 도매인간 의존성이 있는경우 릴리즈가 어렵다. <=> 도매인간 roll-out계획 마련 및 명확한 의존성 관리

** 참고 자료 https://waspro.tistory.com/429