인프런 커뮤니티 질문&답변
작성한 질문수
네임드 락 사용 시 커넥션 풀을 분리하는 방법에 대한 질문
작성
·
60
·
수정됨
0
1. 현재 학습 진도
몇 챕터/몇 강을 수강 중이신가요? 4-10
2. 어려움을 겪는 부분
강의 끝 부분에서 네임드 락을 위한 커넥션과 일반 트랜잭션을 처리하는 커넥션을 분리시켜서 중요한 트랜잭션 처리에 영향을 주지 않는 방법을 말씀해주셨습니다.
제가 기술면접을 보면서 서킷 브레이커라는 내용을 접하게 되었는데, 이 부분이 해당 내용과 연관이 있는건지 궁금합니다.
정확히는 외부 API의 호출 지연으로 인해 스레드 풀이 고갈되는 상황에서 어떻게 설계할 것인지에 대한 질문이었고, 이 과정에서 예시 키워드로 서킷 브레이커 Bulk Head가 있었습니다.
또한, 실제 실무 환경에서는 커넥션 풀을 분리하기 위해 어떤 방법들을 사용하는지 궁금합니다! Q&A로 설명이 어렵다면, 키워드라도 알고 싶습니다.
답변 2
0
cho766님 좋은 질문 해주셔서 감사합니다!!
면접에서 나온 키워드까지 연결지어서 질문해주신 부분이 정말 좋은 사고 흐름인 것 같습니다!!
서킷 브레이커 / Bulkhead와 커넥션 풀 분리의 관계
결론부터 말씀드리면, 서킷 브레이커와 Bulkhead는 커넥션 풀 분리와 직접적으로 같은 기술은 아니지만, 해결하려는 문제의 본질이 같습니다. "하나의 장애가 전체 시스템으로 전파되는 것을 막자"라는 격리(Isolation) 원칙입니다
강의에서 다룬 네임드 락 커넥션 풀 분리는 이렇게 생각하시면 됩니다. Named Lock용 커넥션이 일반 비즈니스 트랜잭션 커넥션을 잡아먹지 않도록 풀 자체를 나눠서, Named Lock 쪽에서 지연이 생기더라도 일반 트랜잭션은 정상 동작하게 만드는 거죠. 이게 사실 Bulkhead 패턴의 핵심 아이디어와 동일합니다!
Bulkhead는 선박의 격벽에서 유래한 개념인데, 배의 한 구획에 물이 들어와도 다른 구획은 안전하도록 벽으로 나누는 겁니다. (격벽 패턴, 격벽이라고도 불러용)면접에서 나온 "외부 API 호출 지연으로 스레드 풀이 고갈되는 상황"도 똑같은 맥락이에요. 외부 API 호출용 스레드 풀과 내부 처리용 스레드 풀을 분리해서, 외부 API가 느려져도 내부 서비스는 영향받지 않게 하는 겁니다.
서킷 브레이커는 조금 다른 각도에서 접근합니다. 외부 시스템이 일정 횟수 이상 실패하면 아예 호출 자체를 차단(Open)해버리고, 일정 시간 후에 다시 시도(Half-Open)하는 방식이에요. 풀을 분리하는 게 아니라 "더 이상 요청을 보내지 않는다"는 전략입니다.
커넥션 풀 분리 / Bulkhead 패턴은 리소스를 격리해서 장애 전파를 차단하는 방식이고, 서킷 브레이커는 실패가 반복되면 요청 자체를 끊어서 시스템을 보호하는 방식입니다. 실무에서는 이 두 가지를 함께 사용하는 경우가 많아요. Resilience4j 라이브러리가 서킷 브레이커와 Bulkhead를 모두 지원하니 참고하시면 좋겠습니다. (https://resilience4j.readme.io/docs/getting-started)
실무에서 커넥션 풀을 분리하는 방법
실무에서 가장 많이 쓰이는 방법들을 키워드와 함께 알려드리겠습니다.
첫 번째는 Spring Boot에서 DataSource를 여러 개 등록하는 방법입니다. HikariCP 기반으로 Named Lock 전용 DataSource와 비즈니스 로직 전용 DataSource를 각각 Bean으로 등록하고, @Qualifier를 통해 구분해서 주입하는 방식이에요. 강의에서 언급한 "Named Lock 전용 HikariCP 풀"이 바로 이 방법입니다. Spring Boot의 Multi DataSource 설정으로 검색하시면 구현 가이드를 찾으실 수 있습니다. (https://docs.spring.io/spring-boot/reference/data/sql.html)
두 번째는 AbstractRoutingDataSource를 활용하는 방법입니다. 요청의 컨텍스트에 따라 동적으로 DataSource를 선택하는 방식인데, 읽기/쓰기를 분리하는 용도로도 많이 사용됩니다. 예를 들어 @Transactional(readOnly = true)일 때는 읽기 전용 DB로, 아닐 때는 쓰기 DB로 라우팅하는 식이죠. (요건 대부분의 서비스에서 적용하곤 합니다)
세 번째는 JDBC를 직접 사용하는 방법입니다. Named Lock의 GET_LOCK/RELEASE_LOCK은 JPA의 트랜잭션 관리와 별개로 동작하는 게 오히려 자연스러운 경우가 있어서, Named Lock 전용으로는 별도의 DataSource에서 직접 JDBC Connection을 가져와서 사용하는 방식도 실무에서 쓰입니다. 이러면 JPA의 트랜잭션 관리와 완전히 분리되니까 커넥션 충돌 가능성이 사라집니다.
면접에서 이 내용을 연결하는 방법
면접에서 "외부 API 호출 지연으로 스레드 풀 고갈 시 어떻게 설계할 것인가"라는 질문을 받으셨다면, 이렇게 연결해서 대답할 수 있습니다.
"리소스 격리 차원에서 Bulkhead 패턴으로 스레드 풀이나 커넥션 풀을 분리하고, 실패 임계치를 넘기면 서킷 브레이커로 요청 자체를 차단합니다. 실제로 프로젝트에서 Named Lock과 비즈니스 트랜잭션의 커넥션 풀을 분리하면서 이 격리 원칙을 적용해본 경험이 있습니다." 이런 식으로 프로젝트 경험과 면접 질문을 자연스럽게 연결시킬 수 있으면 상당히 인상적인 답변이 됩니다.
이런 격리 패턴에 대한 고민을 프로젝트에 직접 적용해보시고, 커넥션 풀 분리 전후의 성능 차이를 수치로 만들어서 이력서에 녹여보시면 좋겠습니다. 파이팅입ㄴ다!!!
0
안녕하세요, 인프런 AI 인턴입니다. cho766님.
네임드 락 사용 시 커넥션 풀을 분리하는 방법에 대한 질문을 하셨군요. 네임드 락은 분산 환경에서 여러 트랜잭션 간의 자원 접근을 조율하기 위한 방법으로, 커넥션 풀을 분리하는 전략은 성능을 최적화하고 한 트랜잭션이 다른 트랜잭션에 영향을 미치지 않도록 하기 위해 사용됩니다.
커넥션 풀 분리의 이유
- 성능 최적화: 네임드 락과 일반 트랜잭션을 다른 풀에서 처리함으로써 락이 걸린 트랜잭션이 다른 트랜잭션의 성능에 미치는 영향을 줄입니다.
- 리소스 격리: 각 트랜잭션 유형이 독립적으로 자원을 사용할 수 있도록 하여, 자원 고갈 등의 문제를 방지합니다.
커넥션 풀 분리를 위한 방법
- Spring Boot 사용 시: 여러 DataSource를 설정하여 네임드 락과 일반 트랜잭션을 분리된 동작 환경으로 실행할 수 있습니다. 두 개의 DataSource를 정의하고, 각기 다른 Hibernate EntityManager를 통해 접근하면 됩니다.
- HikariCP 사용: HikariCP의 설정을 통해 각 커넥션 풀의 최대 크기 또는 최소 유휴 시간을 맞춤 설정할 수 있습니다.
- 구성: 환경 변수나 Configuration 파일을 통해 필요에 따라 설정을 동적으로 분리할 수 있습니다.
서킷 브레이커와의 관계
서킷 브레이커는 실패한 호출을 잠시 중단하여 시스템의 안정성을 높이는 패턴입니다. 커넥션 풀 분리와 서킷 브레이커는 직접적으로 연관되기보다는, 시스템 리소스의 안정적인 사용과 보호라는 측면에서 동일한 목표를 가집니다.
다음의 링크에서 관련 내용을 확인하시면 도움이 될 것입니다:
- Spring Boot에서 여러 DataSource 설정
저는 질문자님의 이해를 돕고자 지식공유자님의 기존 답변을 참고하여 유사한 답변 링크를 추천해드립니다. 현재 베타 기능으로 답변이 만족스럽지 않을 수 있는 점 양해 부탁드립니다. 🙏 추가적으로 궁금한 점이 있으시면, 이어서 질문해 주세요. 곧 지식공유자께서 답변해 주실 것입니다.
딩코딩코님! 항상 양질의 답변 감사드립니다. 질문을 드리고 나서 개인적으로 강의의 형식과 비슷하게 테스트 코드를 기반으로 환경을 구성하여 커넥션 풀을 분리(DataSource를 분리시키고, JdbcTemplate을 사용)하는 실습을 진행했습니다.
추후, 면접에서 답변을 할 때 이 경험을 함께 언급해도 괜찮을까요? 실제 프로젝트에서 진행한 것은 아니어서 면접관 입장에서 임팩트가 적을지 궁금합니다 ㅎㅎ;