일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | |||||
3 | 4 | 5 | 6 | 7 | 8 | 9 |
10 | 11 | 12 | 13 | 14 | 15 | 16 |
17 | 18 | 19 | 20 | 21 | 22 | 23 |
24 | 25 | 26 | 27 | 28 | 29 | 30 |
- Gateway
- JWT
- HikariCP
- 커넥션 풀
- Spring Batch
- Elk
- tomcat
- 최종 합격
- 살아남았다.
- Transactio
- 트랜잭션
- Spring cloud gateway
- 우테코 5기
- Kotlin
- DispatcherServlet
- 오어스
- circuitbreaker
- MDC
- 테스트코드
- 톰캣
- resilience4j
- 우아한테크코스
- redis
- 우아한 테크 코스
- Thread
- 우테코
- AOP
- spirng
- 동시성문제
- oauth
- Today
- Total
코딩은 내일부터
파사드 패턴으로 외부 API와 DB 트랜잭션 범위 분리하기 본문
DB 커넥션은 개수가 제한적이므로 단위 프로그램이 커넥션을 소유하는 시간이 길어질수록 사용 가능한 커넥션의 개수는 줄어든다.
따라서 하나의 작업이(트랜잭션이 필요 없는 로직이 붙어있는) 아무리 빨리 처리한다 해도 DBMS 트랜잭션에 포함될 필요 없다.
그리고 어느 순간 각 단위 프로그램에서 커넥션을 가지기 위해 대기해야 하는 상황에 안 좋을 수,,,,,,
위에 내용은 Real MySQL을 읽으면 나오는 내용으로
DB의 커넥션을 오래 가지고 있으면 웹 서버뿐 아니라 DB서버의 장애로 이어지는데
특히 지금 개발하고 있는 동글 서비스는 외부 API와 통신하는 로직이 많다.
만에 하나 외부 API를 요청할 때 서버와의 송수신의 문제가 생긴다면 현재 API요청 로직과 DB로 쿼리를 요청하는 로직이 섞여있어
DB서버의 장애로 까지 이어진다.
그래서 이번 글에서는 파사드 패턴을 활 요하여 트랜잭션의 범위를 최소화해 볼 예정이다.
문제의 코드
먼저 login 메서드 안에 oauthClients.finduserInfo()메소드는
외부 API통신으로 회원의 정보를 가져오는 로직과, 가져온 회원의 정보를 저장하는 로직으로 크게 나눌 수 있는데
이 메소드 finduserInfo부분에서는 트랜잭션을 사용할 필요가 없는 부분이지만 DB와의 커넥션을 잡아먹고 있는 것이다.
이러한 이유로 파사드 패턴을 이용해서 트랜잭션의 범위를 최소화해 보겠다!(위와 같은 구조가 파사드패턴이다.)
위에 사진은 원래 트랜잭션의 범위를 최소화하기 전이다.
AuthService는 login메서드가 시작할 때 DB커넥션 풀을 이용하여 커낵션을 맺은 상태에서 API를 요청하고 있는 모습이다.
(LoginClients클래스는 인터페이스로 추상화를 해서 Map형태로 LoginClient들을 모아 놓은 형태이다.)
변경 전의 구조에서 변경 후의 구조를 보면 최상위 service에 Transactional어노테이션이 붙어있지 않고,
MemberService에 붙어있는 걸 볼 수 있다.
이렇게 되면 MemberService내에 있는 메서드를 실행할 때만 DB와의 커넥션이 이루어질 테니
한정적인 자원에서 최적화된 포퍼먼스를 보여줄 수 있을 것이다!
적용 코드
로그인 관련 클래스뿐만 아니라 외부 API를 많이 다루는 프로젝트다 보니 트랜잭션의 범위를 분리하는 거는 필수적인 거 같다!!
https://github.com/woowacourse-teams/2023-dong-gle/pull/403
'우아한 테크 코스(우테코) > 우테코 공부' 카테고리의 다른 글
동글 프로젝트 쿼리 개선기 (0) | 2023.09.24 |
---|---|
LinkedList로 글과 카테고리의 순서 구현했을 때 동시성 제어 (2) | 2023.09.16 |
동시성 문제 해결을 위한 회원가입 기능 개선 (5) | 2023.09.11 |
전략패턴을 이용한 외부API 추상화하기 (0) | 2023.09.10 |
Thread 와 톰캣 튜닝하기 (2) | 2023.09.09 |