작성: 2020-07-21 수정:
2020-07-21
Reactvie Programming(2)
Reactive Programming을 사용하는 이유
해당 포스팅은 한상곤 개발자님의 발표를 정리한 내용입니다.
1. 왜 리액티브인가?
1.1 아래의 문제를 생각해 보자
- 시간당 평균 1,000명의 사용자가 방문한다고 가정
- 톰캣(Tomcat) 웹 서버 + 500개의 스래드 풀로 구성
- 평균 응답 시간은 250 ms
- 초당 몇 명의 사용자 요철을 처리할 수 있는가? 그리고 이 A서버의 문제는 무엇인가? 1) 답: 2,000 2) 답: 확장성 제한, 단일 서버 확장성 제한 예) 로스트 아크
1.2 해결책
- 탄력성(elasticity)을 확보한다.
- 작업 부하에서 응답성을 유지하는 능력
- 시스템 처리량이 자동으로 증가해야 하고 수요가 감소하면 자동으로 감소해야함
- 문제 해결을 위한 가장 흔한 방법
- 수평적/ 수직적 확장
- 암달의 법칙(Amdahl’s Law)/ Gunther의 보편적 확장성 모델(Universal Scalability Model)
- 수평적 확장 시 성능이 비약적으로 늘지 않음 > 수직적 확장(메모리 증설) * 서버를 꺼야함, 서버 세팅을 다시해야 함
2010 AWS 등장 이후-> 수평/ 수직 확장
- 그러나 장애 발생과 무관하게 응답성을 유지하는 능력을 갖추지 않고 확장 가능한 분산 시스템을 구축하는 것은 어려움
- 해결방법
- 시스템의 기능 요소를 격리해 모든 내부 장애를 격리하고 독립성을 확보함으로써 달성할 수 있음
- 탄력성과 복원력이 밀접하게 결합돼 있으며, 이 두 가지를 모두 사용할 때만 시스템의 진정한 응답성을 달성할 수 있다는 것
- 메세지 기반 통신
2. 리액티브 시스템의 기본 원리
- 가치 :
응답성
- 매개체 :
탄력성
(시스템이 얼마 만큰 load에 대해서 응답),복원력
(시스템이 무너졌다가 살아나는 능력) - 표현 방식 :
메시지 기반
(MPI)
메시지 기반을 중심으로 탄력성과 복원력을 높여 응답성을 보장
아파치 카프카(생산자, 소비자) 관련 링크
카프카(메시지 기반), 스프링, 서버(클라우드 > 탄력성과 복원력), 리액트(응답성)
리액티브 시스템 설계에 완벽하게 일치하는 비즈니스 사례
- https://microservices.io/patterns/
- 모던 마이크로서피스 패턴을 예로 든 웹 스토어를 개선
- 위치 투명성을 위해 API 게이트 패턴을 서용
- 위와 비슷한 사례로 ‘애널리틱스’ 분야를 들 수 있음
3. 리액티브 시스템에 좀 더 적합한 프로그래밍 기술
- 복원성 확복
- 배압 지원을 활성화해야함
- 메시지 기반
- 메시지 브로커가 필요함 > 큐 프로그램 ex) 카프카 zeroMQ, rabbitmq
- 실제 환경에서는 데이터 스트림이 일괄 처리로 데이터베이스
4. 스프링 프레임 워크가 리액티브로 전환하는 이유
- JVM 세계에서 리액티브 시스템을 구축하는데 쓰이는 가장 널리 알려진 프레임워크는 Akka 및 Vert.x
- 스프링 클라우드
- 스프링 클라우드 프레임워크는 몇 가지 문제점을 해결하고 분산 시스템 구축을 단순화하는 기반 프로젝트
- 명령 -> 동기 문제(블로킹) -> 콜백 함수로 전달
- 콜백 -> 가장 큰 문제점 -> hell 가독성 저하 시스템 부하
- 쓰레드 -> 시스템 부하/ 관리가 힘듦 -> Future
- Future를 사용해서 결과값 반환을 지연 JDK6 version
- Promise를 CompletionStage와 CompletableFuture 이용해 구현
.then
JDK8 -> 배압 X - RxJava
추천 도서
카프카, 데이터 플랫폼의 최강자
(공용준 저)