0. 들어가며...
프론트는 React로 구성을 마쳤다. (GPT 없었으면 불가능)
유튜브로 공개된 강의듣고, 코드를 읽고 원하는 대로 바꿀 수 있을 정도로만 익혔다.
React의 특징으로 서버에서 렌더링을 하는 것이 아닌 클라이언트단에서 렌더링이 진행이되면서 이걸로 얻을 수 있는 장점들이 여럿 있는 것 같은데, 페이지 넘어갈 때 깜빡이지 않는다 정도로만 이해하고 넘어갔다. 가상돔, 컴포넌트 뭐 이래저래 많은데, 프로젝트 완성하고 깊게 다뤄보는 방향으로 가자.
여기서부터 파보면 한도 끝도 없다...
1. Websocket 구상
단순한 생각
먼저, 프론트에 웹소켓을 구현해서 실시간 시세를 받아오는 경우를 생각해보았다.
사용자가 늘어날 때마다 실시간 시세를 받아오는 Websocket 연결이 늘어날텐데
- 시세제공 서버로부터 API key 밴부터 먹고 시작하지않을까?
- 그리고 외부 웹소켓 구독에 필요한 API key가 다 노출될텐데?
그럼 백엔드 서버 1대에서 실시간 시세 Websocket 연결을 관리하고,
클라이언트와 연결하는 Websocket를 각각 생성해서 실시간 시세를 뿌려주자
조금 깊은 생각
그래서 그냥 스프링으로 외부 Websocket 구독하고 스프링에서 웹소켓 열어서 클라이언트에 뿌려주면 되겠다.
라고 쉽게 생각했다. 여기서 이유는 모르겠는데 이질감이 들었다.
- 클라이언트가 많아지면 서버 한대가 그 많은 웹소켓 연결을 관리할 수 있을까?
-> Scale-out으로 백엔드 서버 갯수를 늘리면 감당이 된다.- 그러면 시세제공 서버와 Websocket 연결도 늘어나겠네?
- 그런데 각 서버가 받는 데이터가 모두 일치할까?
- 비즈니스로직을 처리하는 백엔드서버에서 실시간 시세도 받는다?
이제서야 이렇게 4가지로 고민의 흔적을 정리하는데, 이질감이 들었을땐 그냥 막막해서 바로 구현에 들어가기보다 웹소켓을 활용해 실시간 서비스를 구현한 자료를 많이 찾아보았다.
많은 블로그 자료를 통해 메시지 브로커라는 존재를 알았다. 근데 왜 쓰는 거냐에 대해 확실하게 와닿는 글들은 없었다. 공식문서가 아니니깐...
[ 토스ㅣSLASH 23 - 실시간 시세 데이터 안전하고 빠르게 처리하기 ]
https://www.youtube.com/watch?v=SF7eqlL0mjw
토스증권에서 실시간 시세 데이터를 다룬 방법에 대해 고민한 영상이 가장 도움되었다.
메시지 브로커를 도입하는 이유에 대해 Scale-out, MSA 구조들을 예시로 들어가며 설명해주는데, 메시지 브로커를 사용하는 이유에 대한 고민이 해결되었다.
도움이 된 부분
수신부가 늘어난 처리부에 일일 모두 데이터를 보내주어야하는데 이 때 수신부의 성능이 떨어진다.
해결: 메시지 브로커 도입을 통해 수신부와 처리부의 결합도를 낮추고, 수신부는 데이터를 한번만 보내면된다.
결론
메시지 브로커 도입으로 해결
1. 외부 시세 수신 로직과 비즈니스 로직의 결합도를 낮춘다.
2. Scale-out으로 늘어나는 백엔드 서버로 넘어가는 데이터 일관성도 확보할 수 있다.
3. 그리고 외부 시세제공 서버와 WebSocket 연결을 1개만 유지할 수 있다.
4. 시세를 수신하는 서버에서 데이터를 메시지 브로커에 한번만 보낼 수 있다.
2. 잡담
꿀벌집인줄 알고 건들였더니 말벌집이다.
"실시간 정보를 처리할 때는 웹소켓이란 기술을 활용한다."만 알고 덤볐는데 존재만 알고 있던 Redis Pub/Sub, Kafka와 같은 메시지 브로커 역할을 하는 기술들에 대해 접할 수 있는 기회였다.
구현 언제함.
