반응형
What is Reactive Programming? 글 요약 (원문은 여기 참고)
원문 제목은 리액티브 프로그래밍이나 실제 내용은 리액티브 시스템에 대한 내용을 담고 있음.
개발자가 직면한 것
- 1) H/W 발전, 2) 인터넷(엄청난 트래픽!)
- SW의 중요성, 기대 수준, 규모
문제 상황(grey sky)을 대비하지 않으면, 매우 높은 대가를 치를 수 있다.
리액티브 시스템으로 이런 문제를 해결
리액티브 시스템 4가지 원칙
[출처: https://www.reactivemanifesto.org/]
- 응답성(Responsive) : 사용자에게 일관된 긍정적인 경험을 제공하기 위해 상황에 상관없이 모든 사용자에게 빠르게 응답
- 유연성(Elastic) : 다양한 부하 상황에서 응답
- 탄력성(Resilient) : 실패 상황에서 응답
- 메시지 구동(Message Driven) : 시간, 공간에 대한 커플링 제거(비동기 경계)
탄력성
- 오늘날 어플리케이션은 다양한 상황에서 응답성을 유지하기 위해 회복 탄력성을 가져야 한다.
- 성능, 내구성, 보안 등 모든 측면이 탄력성 필요
메시지 구동에 기반한 탄력성
메시지 구동 아키텍처로 얻을 수 있는 것: 견고한 에러 처리와 내고장성
- 격리 : 시스템이 자가 회복하기 위해 필요. 격리된 컴포넌트의 실패는 전체 시스템의 응답성에 영향을 주지 않음. 실패한 컴포넌트 또한 회복할 기회를 가짐
- 위치 투명성 : 같은 VM의 프로세스처럼 다른 노드의 다른 프로세스와 상호작용할 수 있다.
- 전용 에러 채널 : 호출한 곳에 에러를 던지는 것 외에 다른 어딘가로 에러 신호를 리다이렉트하는 것을 허용
유연성 또는 확장성
- 다양항 부하 상황에서 응답할 수 있도록 시스템을 쉽게 확대/축소할 수 있어야 함
- 패러다임 먼저
- 병행 처리에서 쓰레드 기반은 한계를 가짐
- 공유 가변 상태, 요청 당 쓰레드, 변이 상태 동시 접근 : 성능, 확장 임계점에 빠르게 도달
- 쓰레드 안정성을 위한 복잡함,어려움 증가
메시지 구동 2가지 : 이벤트 방식과 액터 기반
이벤트 방식
- 0개 이상 옵저버가 모니터링하는 이벤트에 기반
- 호출자가 옵저버 응답을 기다리지 않음
- 이벤트는 특정 수신자(줏소)를 직접 지정하지 않음
액터 기반
- 메시지 전달 아키텍처 확장
- 메시지를 전달할 수취인 지정
- 메시지를 쓰레드 경계 간에 또는 다른 서버 액터에 전달 가능
액터 장점
- 네트워크 경계를 넘어 연산 확장 쉬움
- 액터에 메시지를 직접 보내서 콜백지옥 없어짐(액터 간 메시지 흐름만 생각하면 됨)
- 컴포넌트 간 결합도 낮춤