왜 리액티브 프로그래밍인가?
1. 왜 리액티브 프로그래밍인가?
왜 리액티브인가?
요청이 집중되는 날에 장애 발생 가능 -> 증가한 부하에 대한 응답 능력을 유지하지 못한 결과
애플리케이션은 변화에 대응해야 함(수요의 변화 및 외부 서비스의 가용성 변화)
즉, 사용자 요청에 대한 응답 능력에 영향을 미칠 수 있는 모든 변화에 대응해야 함
첫 번째 방법은 탄력성(elasticity)
다양한 작업 부하에서 응답성을 유지하는 능력
시스템 처리량이 자동으로 증가하고 감소
탄력성이 없는 시스템에서는 수요가 증가하면 평균 지연시간이 증가하고, 이것이 시스템의 응답성에 직접적인 영향을 미침
수평적 또는 수직적 확장을 통해 탄력성 달성 가능
시스템에 대한 허용 기준은 시스템 실패에도 반응성을 유지할 수 있는 능력, 시스템 복원력을 유지하는 것
시스템의 기능 요소를 격리해 모든 내부 장애를 격리하고 독립성을 확보하여 달성 가능
탄력성과 복원력이 밀접하게 결합돼 있으며, 이 두가지를 모두 사용할 때만 시스템의 진정한 응답성 달성 가능
메시지 기반 통신
동기인 RestTemplate을 사용하면 I/O 중에는 다른 요청을 처리할 수 없음
추가 스레드로 처리할 수 있으나 부하가 많을 경우 비효율적일 수 있다.
자원을 효율적으로 사용하기 위해서는 메시지 기반 통신 원칙을 따라야 함
구성 요소들은 메시지 도착을 기다리고 이에 반응하며, 나머지 시간에는 휴면 상태에 있지만, 동시에 논블로킹 방식으로 메시지를 보낼 수 있어야 함
메시지 기반 통신을 수행하는 방법 중 하나는 메시지 브로커(message broker)를 사용하는 것
메시지 대기열을 모니터링해 시스템이 부하 관리 및 탄력성 제어 가능
분산 시스템으로 구현되는 모든 비즈니스의 핵심 가치는 응답성
시스템이 높은 응답성을 확보한다는 것은 탄력성 및 복원력 같은 기본 기법을 따른다는 의미
응답성,탄력성 및 복원력을 확보하는 기본적인 방법의 하느는 메시지 기반 통신을 사용하는 것
이러한 원칙에 따라 구축된 시스템은 모든 구성 요소가 독립적이고 적절하게 격리돼 있기 때문에 유지 보수 및 확장에 용이
반응성에 대한 유스케이스
생략…..
왜 리액티브 스프링인가?
JVM 세계에서 리액티브 시스템을 구축하는 데 쓰이는 가장 널리 알려지 프레임워크는 Akka 및 Vert.x
서비스 레벨에서의 반응성
리액티브 시스템에 대한 수요 증가로 스프링 클라우드라는 새로운 스프링 프로젝트 시작
스프링 클라우드는 몇 가지 문제점을 해결하고 분산 시스템 구축을 단순화하는 기반 프로젝트
결과적으로, 스프링 프레임워크 생태계는 리액티브 시스템을 구축하는데 적합
구성 요소 수준에서도 리액티브 설계 및 구현을 제공하는 것이 중요
명령형 프로그래밍
로직을 실행하는 동안 스레드가 차단됨 -> 리액티브 시스템의 관점으로 본다면 허용되지 않음
콜백 기법 적용
컴포넌트가 콜백 함수에 의해 분리됨
응답을 기다리지 않고 다른 작업 진행 가능
java.util.concurrent.Future 사용
콜백 지옥을 피할 수 있음
멀티 스레드의 복잡성을 숨길 수 있음
필요한 결과를 얻으려면 현재 스레드를 차단하고 확정성을 현저히 저하시키는 외부 실행과 동기화 필요
CompletionStage 및 CompletionFuture 사용
CompletionStage의 지원으로 함수형 스타일 또는 선언형 스타일로 코드를 작성 가능
코드는 깔끔해지고 결과를 비동기적으로 처리
또한, 결과를 기다리지 않고 결과가 나오면 이를 처리할 함수 제공 가능
하지만, 스프링 4는 호환을 위해 ListenableFuture를 대신 사용
AsyncRestTemplate 과 ListenableFuture
지저분하며 별도의 스레드로 래핑
각각의 요청에 별도의 스레드를 할당하는 서블릿 API 사용
적은 수의 CPU에 동시에 많은 수의 스레드를 활성화시키는 응용 프로그램인 비효율적
참조
- 실전! 스프링5를 활용한 리액티브 프로그래밍
- 리액티브 선언문
- 마이크로 서비스 패턴