인프런 커뮤니티 질문&답변

영빈님 안녕하세요. 지식 공유자 조세영입니다.

제 강의가 도움이 되어서 정말 기쁘네요! 좋은 말씀 남겨주셔서 감사하고, 강의도 열심히 들어주셔서 감사합니다.

질문에 답변을 드리면

1. 사내에서 사용하는 기술스택이 spring web mvc + JPA + feignClient인데 혹시 이와 유사한 환경에서 코루틴을 적용해보신 경험이 있으실까요?
   
   특히 제가 기대했던 부분은 IO작업에 관해 요청을 보내고 스레드를 점유하지 않음으로써 리소스를 효율적으로 사용하는 것(즉 처리량을 증가시키는 것)을 기대했었는데 아무래도 JPA나 feignClient나 응답이 올때까지 대기하는 구조로 되어 있더라구요ㅠㅠ.. 드라마틱한 성과를 기대하기는 조금 힘들어보이긴하네요 혹시 관련해서 유사한 경험이 있으신지 싶어서 의견을 묻고자 여쭤봅니다.

답변
Spring MVC를 사용하시면, 요청 당 스레드가 한 개가 생성되고, JPA를 사용하면 요청이 동기적으로 처리되는 것으로 알고 있는데요. 이런 경우는 코루틴을 사용하실 경우, 큰 이점을 기대하기는 힘들 것 같습니다. 만약 이점이 있다면, 요청을 받아서 처리할 때 내부에서 여러 서버에 요청을 하고 응답을 받을 때 등 요청 처리를 위해 여러 비동기 작업을 병렬로 실행해야 하는 경우 정도에서 이점이 있지 않을까 합니다.

제가 생각하기에는 WebFlux + Spring Data 모듈에서 코루틴 지원 두 개를 함께 사용 했을 때 rps가 급증할 경우 성능적으로 유의미한 이점이 생기지 않을까 싶습니다.

2. 코루틴을 사용중인 환경에서 rps가 급증하면 어떤식으로 흘러갈지 궁금합니다. 스레드가 고갈될 것 같은데, 자연스럽게 dispatcherIO등의 스레드가 새로 생성되나요?
   - 그렇다고 하면 메모리가 고갈될 것 같은데, 코루틴을 사용할때는 결과적으로 메모리 기준으로 스케일아웃을 걸어야할지? 등이 궁금하네요.

답변
Dispatchers.IO는 최대 생성할 수 있는 스레드의 개수가 특정 개수로 제한되어 있습니다. rps가 급증하고 요청을 처리할 때 Dispatchers.IO가 사용될 경우 최대 스레드 개수(일반적으로 64개) 만큼 생성되고 이 내부에서 코루틴이 서로 스레드 사용 권한을 양보하면서 동작할 것 같습니다.
즉, 코루틴을 사용해도 스레드가 무한정 생성되는게 아니고 64개의 스레드면 메모리도 상대적으로 많이 차지하지 않을 것으로 보입니다.

제가 안드로이드 실무 경력만 있고, Spring은 실무 경험이 없고 개인적으로 공부를 계속 하고 있다 보니 답변이 부족할 수 있는 점 참고 부탁드립니다. 좋은 질문 남겨주셔서 감사합니다. 좋은 하루 되세요!

안녕하세요, 인프런 AI 인턴입니다. 김영빈님.

여러 부분에 걸쳐 좋은 질문 주셔서 감사합니다. 특히 Spring Web MVC 환경에서의 코루틴 활용에 대한 관심과 고민이 느껴집니다. 아래 질문에 대해 차례로 답변 드리겠습니다.

1. Spring Web MVC + JPA + FeignClient 환경에서의 코루틴 적용

Spring Web MVC 환경에서 코루틴을 적용하는 것은 현재 전통적인 블록킹 방식의 스프링 프레임워크와는 자연스럽지 않을 수 있습니다. Spring WebFlux와 같은 리액티브 프로그래밍을 지향하는 프레임워크에서는 코루틴 사용이 보다 일반적입니다. JPA나 FeignClient는 기본적으로 블록킹 방식으로 설계되어 있어, 코루틴의 비동기 작업의 이점을 끌어내기가 어렵습니다.

• JPA 문제: JPA는 기본적으로 블록킹 IO 성격을 가지고 있습니다. Hibernate Reactive나 Spring Data R2DBC 같은 리액티브 데이터 애플리케이션을 사용하는 것이 코루틴 사용에 더 어울립니다.
  
• Feign Client 문제: FeignClient 또한 API 호출이 응답을 대기하는 블록킹 방식이라, 이를 비동기로 사용하기 위해서는 리액티브 확장을 사용하거나 CompletableFuture와 같은 비동기 콜을 사용할 수 있습니다.
  

저는 이와 같은 이유로 유사한 기술 스택에서는 특정 구성 요소를 리액티브 방식으로 교체하거나 적절한 라이브러리를 사용해야 코루틴의 이점을 살릴 수 있다고 생각합니다.

2. RPS 급증 시의 코루틴 동작

코루틴은 비동기 작업을 효율적으로 처리하지만, RPS가 급증하면 결국 스레드에 부담이 가며 자원이 고갈될 수 있습니다. 특히 Dispatcher.IO와 같은 스레드는 자동으로 더 많은 스레드를 사용할 수 있게 확장될 수 있지만, 이것이 무작정 좋지는 않습니다.

• 메모리 관리: 동시에 많은 작업이 발생하면 메모리가 고갈될 수 있습니다. 이러한 문제를 방지하기 위해 서비스는 코루틴과 같은 비동기 처리뿐만 아니라, 적절한 수준의 throttling, circuit breaker, rate limiting 등을 설정하여 자원 소모를 제어하는 것이 중요합니다.
  
• 스케일링 전략: 비동기 연산이 많아질 때 메모리 기반의 스케일 아웃을 고려할 수 있지만, 결국 중요한 건 전체적인 아키텍처의 효율성입니다. 따라서 JVM 튜닝, 적절한 인스턴스 증가 등 다각도로 접근해야 합니다.
  

더 자세한 정보가 필요하시다면 아래 링크들도 참고해 보시길 바랍니다:

• Coroutine과 RPS 관리에 관한 질문 - 이 게시물에서는 코루틴 사용 시 RPS 급증에 대한 질문이 다루어집니다.
  
• 스프링에서의 코루틴 적용 경험 질문 - 스프링 환경에서의 코루틴 적용에 대한 경험 질문이 다루어집니다.
  

저는 질문자님의 이해를 돕고자 지식공유자님의 기존 답변을 참고하여 유사한 답변 링크를 추천해드리고 있습니다.
현재 베타 기능으로 답변이 만족스럽지 않을 수 있는 점 양해 부탁드립니다. 🙏 추가적으로 궁금한 점이 있으시면, 이어서 질문해 주세요. 곧 지식공유자께서 답변해 주실 것입니다.