💬 목표
한 두달 전부터 아른 거리던 프로젝트의 겉면을 좀 세분화 해봤다. 손이 심심할 때마다 빌드업하기에 좋을 것 같았다. 혼자 진행하게 될테지만, 그만큼 유연할 설계/구현/테스팅/배포 등의 과정 안에서 지난 흩어진 경험들을 모아보련다. 명확한 결과물을 보고 싶다.
순전한 개발사항들 보다도 병행하는 개발관련 공부내용도 함께 같은 카테고리에 집어넣을 것이다. 그래야 더 기억날 것 같으니까.
💬 리액티브 프로그래밍와 데이터 액세스
블로킹과 리액티브
- 웹 컨트롤러, 서비스 계층을 리액티브 방식으로 만들었으나 블로킹 방식의 데이터베이스 호출 시 리액티브는 무너진다
- 블로킹 방식의 데이터베이스 호출을 하는 스레드는 응답을 받을 때까지 다른직업을 못하고 있기때문이다
- 리액터 기반 Application은 스레드를 많이 갖지 않아, 블로킹된 스레드가 많아질 수록 아무런 일도 할 수 없게 되어 망가진다
리액티브 프로그래밍의 모순 발생
- 리액티브가 태생적으로 빠르다는 선입견이 존재한다
- 작업을 수행하는 단일 스레드의 처리 속도 기준으로는, 리액티브는 오버헤드의 가능성으로 인한 성능 저하가 발생한다
대형트럭과 소형차를 통한 비교
- 대형트럭: 소형차보다 훨씬 많은 화물을 실어 나를 수 있다, 주행속도는 느리다
- 대형트럭을 물건 하나만 나르는데에 사용한다면 엄청난 낭비이며 이것이 리액티브에서도 동일한 논리이다
- 사용자 수가 적도 데이터도 많지 않다면 리액티브 사용은 낭비다
리액티브가 효율적인 경우
- 대규모의 트래픽 발생
- 대용량의 데이터 처리 환경
- 따라서, 데이터베이스의 리액티브한 동작을 요구함
💬 리액티브 데이터 스토어
최신형 리액티브 패러다임을 지원하는 데이터페이스
- MongoDB
- Radis (마크 팔루크의 Lettuce 드라이버 사용시)
- 아파치 카산드라
- 엘라스틱서치
- 네오포제이
- 카우치베이스
Java의 JPA, JDBC와 리액티브 패러다임의 충돌
사전적인 배경
- 실제 현업에서 쓰이는 데이터베이스의 대부분은 관계형 데이터베이스
- 자바는 관계형 데이터베이스를 다루기 위해 JDBC, JPA, JDBI, jQQQ 기술이 존재
JDBC와 JPA는 블로킹 API다
- 트랜잭션 시작 메시지 전송, 쿼리 포함 메시지 전송 후 결과가 나올 때까지 Client에게 스트리밍하는 개념은 존재하지 않는다
- 모든 데이터베이스 호출이 응답 때까지 블로킹 되어 있다
- JDBC, JPA를 감싸 리액티브 스트림 계층에서 쓰는 솔루션은 불완전하며 오히려 처리량의 문제와 함께 제대로 동작하지 않는다
리액티브 애플리케이션을 만들기 위한 데이터베이스 드라이브 사용하기
- 리액티브를 만들고 싶다면, 리액티브 지원 데이터베이스 중 하나인 MongoDB 등을 사용해보자.
참고서적: 스프링부트 실전활용 마스터(2021)