MSA

가언·2024년 8월 6일

msa

모놀리식

MSA

MSA의 장점: Scale-out

Scale-out: 서버를 추가하여 시스템을 확장
- 서비스가 다 나뉘어져 있기 때문에 추가 삭제 수정이 용이하기 때문(서비스가 죽지 않아야 한다!)
- 만약, 각 서버들이 수정될 때마다 주소값을 수동으로 바꿔야 한다면?
- Scale-out장점이 되려 단점이 되버림ㅠㅠ 관리 포인트가 늘어나기 때문!
- 따라서, "서비스 레지스트리": 서비스 주소를 관리해주는 친구(User, Room...)
Scalue-up: 기존 서버 사양 업그레이드

Service Registry

서비스의 위치 저장/관리 전담

내부 서비스 간 통신(다른 서비스 주소 필요할 때)
게이트웨이가 Request에 따른 서비스 주소가 필요할 때
사실 서비스 B, C, D가 아니라, 서비스 A 부하 분산용 인스턴스를 여러개 둘때 많이 씀
(로드밸런스도 여기서 함께 사용됨 부하를 막기 위해!)

cf. 레지스트리
윈도우 레지스트리: OS설정값, 정보를 담고 있는 저장소)
=> 소프트웨어들에 대한 각종 설정값, 정보를 담고있는 저장소

게이트 웨이

네트워크 상에서 서로 다른
- 통신망
- 프로토콜
끼리 통신이 가능하게 하는 컴퓨터/소프트웨어
"(종류가) 다른 하드웨어/소프트웨어 간 통로의 역할"

ex) ESL, 여러개의 게이트 웨이를 통해 매장 내 가격 태그를 커버한다.

registry

1️⃣그림

2️⃣그림
1️⃣과2️⃣의 그림과 다른 점은 서비스가 직접 regitry에 주소를 저장하고, 레지스터를 참고하는 것은 api gateway단에서 진행되며 api gateway에서 뿌려준다는 것

고민한 점

로드 밸런스를 여러 개 두면,
룸과 유저에서 소통할때 부하가 너무 심해지지않을까?

주문 내역을 가져오기 위해 회원 ID가 필요한 경우
미리 인증 인가를 판단하고 들어오도록 해서 부하를 줄이자!

DB를 다 따로 사용하면, DB를 동기화하는데 어렵지 않을까?

RDS를 사용하자!! DB서버 따로, 웹서버 따로 사용해서 하나의 DB만 사용할 수 있도록
그럼 위 그림에서는 RDS를 4개 사용하게 되는 거겠쪼?!

정리
MSA는 연관관계를 다 끊는 것!
: user에게 요청을 하면 안된다. order객체 안에 파라미터 안에 직접 유저 아이디를 집어 넣어야하고, 객체간의 연관관계를 끊어야 하기 때문

그럼 어떻게 연관관계를 끊어야 할까?

foriegn key를 사용하지 않고 순수한 컬럼을 사용하고,
메시지 큐를 사용해서 탈퇴했다는 이벤트가 발생하면 각각의 테이블을 업데이트 하는 방법

Client Side Discovery

서비스 레지스트리(구현체)를 직접 사용
대표적인 라이브러리: Spring Cloud Netflix Eureka

서비스 A와 서비스 B가 소통하고 싶을때 서비스 A는 주소를 registy에 등록하고, 서비스 B가 A의 주소를 받아와 소통함
장점: 구현 간단, 레퍼런스가 많음
단점: 각 서비스임에도 불구하고, 서비스 레지스트리에 모두 완전 의존
=> 폴리그랏의 경우, 환경에 따라 여러번 구현해야 한다!
cf. 폴리그랏(polyglot) 각 서비스가 다른 언어/프레임워크 환경

Server Side Discovery

로드 밸런스가 있는 것: 인스턴스가 여러개
4번까지 로드밸런스가 해줌

<그림에는 없지만, A외에도 B, C서비스가 존재한다>
서비스가 registy에 주소를 등록하고, 서비스 A가 직접 동사무소에 가지않고, 로드밸런스에게 대신 물어보고, B가 하려는 일도 대신 해줌
질의(주소 알아와주고) + 통신(다른 서비스와 통신)