매일 매일, 차곡 차곡 쌓기



완벽하지 않은 것을 두려워 말며,
완성도를 높히는데 집중하자.

Spring/Webflux

Reactive Programming

blockbuddy93 2024. 3. 1. 15:28

1. 프로그래밍의 진화

  • 오늘날 우리가 구축하는 애플리케이션은 마이크로 애플리케이션으로 분할되어 실시간으로 상호 작용하며 비즈니스를 제공합니다.
  • 10 ~ 15 년 전과 비교하여 비즈니스가 확장됨에 따라 우리가 구축하는 앱에 대한 기대치도 변경되었습니다.
시간 과거(10 - 15 년 전) 현재
실행 환경 Monolith Applications Run it in cloud
분산 시스템 여부 Dose not embrace Distributed System Embraces Distributed Systems

 

2. 앱에 대한 기대

  • Scale based on the load : 애플리케이션은 부하에 따라 확장되어야 합니다.
  • Use resources efficiently : 과거에는 일부 데이터를 얻기 위해 데이터베이스나 외부 서버를 통해 데이터를 얻을때 응답된 데이터가 반환되기 까지 리소스 활용을 못했기에 비효율적인 부분이 있었습니다. 이를 효율적으로 사용하고자 합니다.
  • Latency or Response Time should be faster : 지연시간과 응답시간은 되도록 빨라야 합니다.

3. Spring MVC/Spring Boot를 이용한 전통적인 Rest API Request/Response 

  • 전통적인 어플리케이션은 동시에 여러 요청을 처리하기 위해서, Servlet Container가 Thread Pool 에서 Thread를 가지고와서 1개의 Thread가 1개의 Request를 담당하여 처리하는 "Thread Per Request Model" 형태입니다. 
  • server.tomcat.max-threads 에 의해 스레드 수가 제어 될 수 있으며 기본적으로 200 개 연결을 처리할 수 있습니다. 많은 수의 스레드를 할당하면 좋을것 처럼 보이나, 많은 수의 스레드를 할당한 만큼 메모리 사용 공간이 줄어 결론적으로 애플리케이션 성능이 저하됩니다.

 

 

  • 따라서 오늘날 가낭 널리 사용되는 확장 방식은 수평 확장이며, 더 많은 로드를 기반으론 더 많은 애플리케이션 인스턴스를 가동한다는 의미입니다.
  • 이러한 확장 방식은 안정적으로 서비스를 할 수 있으나, 서버 증설에 따른 추가 비용이 발생됩니다.

 

 

4. 왜 리액티브 프로그래밍을 해야하나?

  • Spring MVC/Spring Boot 기반 어플맄테이션은 동시에 여러개의 Request를 처리하는데 한계를 가지고 있습니다.
  • 리액트 프로그래밍의 목적은 "Thread Per Request Model" 에서 벗어나 더 적은 수의 스레드로 더 많은 로드를 처리하는 것입니다.

'Spring > Webflux' 카테고리의 다른 글

R2DBC  (0) 2024.03.02
Reactive Programming 2  (0) 2024.03.01
Context  (0) 2024.03.01
Scheduler의 종류  (0) 2024.02.29
Scheduler  (0) 2024.02.29