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 |