monolithic : 단단히 짜여 하나로 되어 있는
장점: 하나의 공간에 모든게 들어가있어서 다루기 편함
단점: 쇼핑몰 시스템 만들 때, 다양한 시스템이 들어갈 것. 처음 잘 만들 때는 상관 없다가 특정 시스템 하나를 다룰 때 모든 시스템을 다 다뤄야함. -> 서비스가 커질수록 부담이 커짐
monolithic을 좀 더 쪼개보자 -> SOA
각각의 세부 서비스들과 하나의 큰 '공통'으로 구분해서 개발.
'공통'부분이 잘 되면 이상적이지만, 해당 부분이 이상해지면 다른 서비스들도 영향받음
의존성을 완전 최소화해보자 -> MSA
Isolation 극대화. 각각의 서비스는 독립적.
단, 서비스를 나누는 기준을 나누는 게 어렵고, 분리되어 있어서 어떻게 연결해야되는 지 고민이 필요, monolithic과 SOA보다 개발에 오래 걸림
->많은 기업에서 MSA화 하려고 노력하지만, 그게 힘듬(다 새로 구축해야 하니까)
MSA가 독립성을 유지할 수 있는 이유 -> DB가 분리되어 있기 때문
MSA는 어떻게 구성되나? -> 왠만한 걸 모두 쪼갠다.
기존 monolithic은 모든 서비스가 하나의 db에서 관리, msa는 각 서비스마다 지정된 db에서 관리.
MSA 필요성과 DDD
예) 장바구니 시스템 개발
장바구니 시스템에 필요한 것은? -> Data / UI
모두가 각기 다른 생각을 할 것, 특히 msa에서는 더 심해짐(서로 서비스를 나눠서 하니까)
따라서 DDD(Domain Driven Design)이 필요함.
- DDD의 핵심은 의존성 최소화, 응집성 최소화 -> 하나의 서비스가 다른 서비스에 의존성을 가지지 않도록 함
Domain Model은?
- 역할과 책임이 있는 사건의 주체 영역
- Action 수행할 수 있는 행위, Data 저장 기능, Event 저장된 걸 전파할 수 있음
Domain Model Design Pattern
1. User Story Mapping: 아이디어를 덩어리로 나누어서 토론 및 모델링하는 기법
- 도메인에 대한 이해도가 높은 사람을 중심으로 진행됨
- 토론하는 사람들이 도메인에 대한 이해도가 어느 정도 있어야 함
2. Event Storming: 이벤트를 사용해 시스템을 모델링하기 위한 워크샵(전문가 초빙) 및 브레인스토밍 기법
- 도메인에 대한 이해도를 늘려주는 역할
3. Event Modeling: 시간과 이벤트의 개념 중심으로 마인드맵 모델링 기법
- 사건의 시작과 끝을 알고 있는 사람을 중심으로 진행됨
Domain Event: 도메인이 발생시키는 사건들, 모든 변화
- Create, Update, Delete (조회-Select가 없음, 변화를 일으키지 않기 때문)
Event Sotrming = Domain Event + Brain Storming
원래는 모여서 진행했는데, 코로나 유행으로 'miro'라는 사이트에서 수행하기 시작함
1. (Domain) Event: 해야할 것, 발생된 사건을 P.P 형태의 동사로 작성(~~~됨)
2. Command: 행위를 하기 위한 명령어(현재형으로 작성)
3. Read Model(View / Query): 명령어를 수행하기 위해 참고하는 "데이터"
4. Policy: 검증, 정책
5. Actor(user/role): 수행하는 당사자를 적음
6. Aggregate: 비슷한것들 끼리 하나의 Aggregate로 묶음
7. External System: 이벤트가 호출하는 외부 시스템(내가 하지 않을 모든 것)
예) 광고 담당자. 유저의 나이에 따라서 광고를 달리 해야 할 때. 나이에 따른 광고 설정은 본인 몫이나, 유저 나이를 가져오는 것은 external system
<작성 방법>
- 일단 도메인 이벤트를 다 적어서 붙임
- 도메인 이벤트 정리
- command, external system 이용해서 도메인 이벤트 정리
- 정리 다 되면 aggregate로 묶음
- 이후 계속 다듬음
<정리>
- event storming
- aggregate
- boris diagram(어떻게 통신하는 지 정의)
- snap-e(모든 결과를 보기좋게 하나로 정리)
API GATEWAY PATTERN
이런식으로 되면 endpoint가 너무 많아진다. 이걸 클라우드에서 처리하기 힘듦
공통으로 작업하지만, 각 서비스에서 각각 처리해야 한다.
endpoint 종합, gateway에서 공통처리가 이루어져서 편하다
물론 단점이 없는건 아니다. Gateway가 죽으면 망한다는 문제가 있다.
즉, gateway가 항상 살아있어야 한다.
SERVICE DISCOVERY PATTERN
클라이언트 입장에서, 어느 주소로 갈 지 알아야하는데, 항상 IP 주소를 전해주는 방식으로는 한계가 있다.
서버 단에서 알아서 찾아주는 SERVER SIDE 방식. 클라이언트가 편하기 때문에 이 방식을 가장 많이 사용한다.
문제는 서버쪽 인력이 부족하거나 하면
클라이언트가 주소 정보를 직접 찾아 접근하는 CLIENT SIDE방식을 쓰기도 한다.
이 패턴을 적용할때는, 클라이언트 변화가 적고 서비스 크기가 작을 때 사용한다.
그러니까, 대기업에서는 SERVER SIDE를 쓴다. 클라이언트 변화가 크고(많고) 서비스 크기가 크니까.
SERVICE MESH PATTERN
쉽게 말해 서비스를 한번 가공한 패턴이다.
일반적인 BASIC PATTERN이다. Microservice가 몇개 없으니 보기 편하다. 문제는...
Microservice가 겁나게 많을때는 위의 방식으로 해결할 수 없다.
그래서 Sidecar를 이용한 Service Mesh Pattern 방식으로 구현한다.
사이드카 프록시와 마이크로 서비스를 별도로 두어서 처리한다.
즉, 모든 인프라 통신 연결과 속도 조절을 sidecar가 담당한다.
(사이드카는 뭔가 보조한다는 뜻으로 이해하면 된다.)
Boris Diagram
앞의 v1은 version-ing으로, 프로그램의 버전 변경이 예정되어 있을 때, 기능별 구분을 위해 버전을 명시해준다.
<html 구조> /버전/도메인명/~~~ 으로 표시
/버전/view/~에서 view는 '사용자에게 보여주기 위함'임을 명시한다.
/버전/internal/~에서 internal은 '내부사용자(admin)'만 사용 가능함을 의미한다.
decorator: 꾸며진 화면을 사용자에게 보여주고 싶을 때 사용
MQ(Message Queue): 비동기 방식으로 정보를 전달할 때 사용
Header: API 통신할 때 기본적인 정보들을 담을 수 있는 공간
더 잘 이해하고 싶으면, 아래의 링크에서 예시를 확인해보도록 하자.
https://github.com/drminnaar/ranker
GitHub - drminnaar/ranker: A REST API guide with an example project written in C# using .NET 5
A REST API guide with an example project written in C# using .NET 5 - GitHub - drminnaar/ranker: A REST API guide with an example project written in C# using .NET 5
github.com
Snap-E
Boris-diagram으로 통신을 정리하면, Snap-E는 이를 보기 쉽게 정리하는 역할이다.
각 페이지 별로 API, Data, Stories, UI, Risk에 대해 분할하여 표시하는 형식이다.
- API: 해당 페이지와 연관된 api들을 정리한다.
- Data: API 통신 시 데이터를 교환할 필드를 표시한다. 자신의 데이터를 변경할 때는 본인(필드)를 표시한다.
- Stories: 해당 페이지에서 수행해야 할 일들을 표시한다.
- UI: 어떠한 기능을 누구에게 보여줄지 표시한다.
- Risk: 예외 사항이나 경계해야 할 일들을 표시한다.
이렇게 구상한 Snap-E로 서비스를 구축하게 된다.
Event Storming, Boris Diagram Demo(실습)
도서관 관리 시스템 설계
- 시스템 통한 도서관 접속
- 도서 관리
- 도서관의 도서 대여
- 희망 도서 신청
- 반납 연체 관리
- 고객센터 관리
...를 구현해보았다.
https://miro.com/app/board/uXjVPNE08-s=/
My first board_장건우
miro.com
끝!
'개인 공부용' 카테고리의 다른 글
| Java 자료형과 연산자 (0) | 2023.01.09 |
|---|---|
| Java 기본 및 원리 (0) | 2023.01.09 |
| hadoop 맵리듀스 실습 기록용 (0) | 2022.10.21 |
| hadoop 실습 기록 (0) | 2022.10.20 |
| hadoop 설치(기록용) (0) | 2022.10.20 |