MSA_기초자료.pdf

MSA 이해
Hong Hyo Sang
2023-01-26

III. ORM-JPA
Contents
1. 기본 용어
2. DAO, DTO, Entity 개념
1. Layer Architecture
2. Domain Driven Design
3. 도메인 주도 설계 기본 요소
I. DDD
IV. MSA
1.
1. MSA ( Microservices Architecture )
2. 구조적 차이점
3. 데이터베이스에 대한 ACID 모델 대 BASE 모델
4. 격리 레벨
5. CQRS & Two Phase Commit
6. SAGA Pattern
1. TDD란
II. TDD

Content
2. Domain Driven Design
3. 도메인 주도 설계 기본 요소
I. DDD의 이해

- User Interface Layer
: 사용자에게 정보를 보여주고 사용자의 명령을 해석 하는 일을 책임 짐.
- Application Layer
: 수행할 작업을 정의하고 표현하는 계층으로 업무 규칙이 포함 되지 않으며 작업을 조정 하고 아래 위치한 도메
인 객체의 협력자에게 작업을 위임 함.
- Domain Layer
: 업무 개념과 업무 상황에 관한 정보, 업무 규칙을 표현 하는 일을 책임짐. 상태 저장과 관련된 기술은
Infrastructure 위임
- Infrastructure Layer
: 일반화된 기술 기능 제공, 메시지 전송, 도메인 영속화, UI에 위젯 등.
1. DDD 이해
1-1. Layer Architecture
- 시스템을 유사한 책임을 지닌 레이어로 분해한 후 각각의 레이어가 하위의 레이어만 의존 하도록 하는 시스템을 구성 하는 것
- 목적
: 관심사의 분리를 통한 결합도는 낮추고 재사용성을 높이고 유지 보수성 향상
- 적용 방식
: 완화된 레이어 시스템 ( relaxed layered system ) - 하위 레이어만 의존해야만 하는 제약을 완화
: 상속을 통한 레이어 구성 ( layering through in inheritance ) - 인터페이스나 클래스 상속을 받아 구현
- 적용
: Model-View-Controller

2. Layer 분리 원칙
1. DDD 이해
1-1. Layer Architecture
- Model-View Separation(Fowler POEAA, Larman AUP)
: 모델(도메인 로직과 관련된 관심사)과 뷰(사용자 인터페이스와 관련된 관심사)는 별도의 레이어로 분리
- Clean and Thin View(Johnson J2EED)
: 모델-뷰 분리원칙에 따라 모델과 뷰를 분리했다면 뷰는 오직 링크업과 화면 출력 로직을 포함해야 하며(Clean View), 시스템의 상태를 변경시킬 수 있
는 비즈니스 로직을 포함해서는 안 된다(Thin View
- PI, Persistence Ignorance(Nilsson, ADDD)
: 도메인 로직과 영속성 로직은 서로 다른 레이어로 분리, 도메인 객체를 데이터베이스 관련 인프라스트럭처에 독립적인 POJO(Plain Old Java Object)로
개발하고 DAO(Data Access Object) 패턴[Alur CORE]을 이용해서 인터페이스 하부로 영속성 메커니즘을 캡슐화하는 것
- Domain Layer Isolation(Evans, DDD)
: 도메인 레이어는 비즈니스를 구성하는 핵심 개념과 중요한 정보, 준수해야 하는 비즈니스 규칙을 표현하는 곳이다. 시스템을 단순하고 유연한 상태로
유지하기 위해서는 도메인 레이어를 기술적인 이슈로부터 고립시켜야 한다

1. 도메인 이란
도메인 주도 개발은 Eric Evans가 2003년 출간한 Domain-Driven Design책으로 처음 소개한 방법론
으로 “유용한 소프트웨어를 개발하고 싶다면 도메인 귀를 기울여라“ 라는 슬로건으로 시작됨
1. DDD 이해
1-2. Domain Driven Design
- 일반적인 요구사항, 전문 용어, 그리고 컴퓨터 프로그래밍 분
야에서 문제를 풀기 위해 설계된 어떤 소프트웨어 프로그램에
대한 기능성을 정의하는 연구의 한 영역
- 소프트웨어로 해결하고자 하는 문제 영역
- 회사의 전체 비즈니스 영역을 정의
- 특정 도메인을 개념적으로 표현한 것
- 도메인 모델을 사용하면 여러 관계자들(개발자, 기획자, 사용자 등)이 동일한 모습으로 도메인을 이
해하고 도메인 지식을 공유하는 데 도움이 된다
- 모델의 각 구성 요소는 특정 도메인을 한정할 때 비로소 의미가 완전해지기 때문에, 각 하위 도메인
마다 별도로 모델을 만들어야 한다.
- 애자일 개발 방식으로 반복 수행 하여 완성도를 높임
- 예 : 호텔, 통신, 은행….
- 도메인 아래 여러 하위 도메인에서 작업을 해야 하는데 하위
도메인으로 충분하지 않기 때문에 서브 도메인이라 함.
-하위 도메인을 분류하는 이 방법은 비즈니스 논리의 복잡성
수준
- Generic, Core 및 Supporting의 세 가지 유형으로 분류

2. 하위 도메인 유형
회사는 도메인 아래 여러 하위 도메인에서 작업을 해야 하는데 하위 도메인으로 충분하지 않기 때문에 서브 도메
인이라 함. Generic, Core 및 Supporting의 세 가지 유형으로 분류
Generic Subdomains
1. DDD 이해
- 도메인은 서브도메인으로 구성되며, 서브 도메인은 또 다른 서브도메인을 포함 할 수 있다.
- 모든 회사가 동일한 방식으로 수행 하는 작업으로 외부 솔루션을 채택 할 수 있다.
Core Domains
- 우리의 소프트웨어를 차별화하고 구축할 가치가 있게끔 만들어주는 도메인
- 규모가 큰 시스템은 복잡하고 여러 도메인으로 구성되는데 핵심 가치가 있는 도메인
- 설계 측면에서 우선 순위가 높음
- 가장 가치 있는 전문화된 개념을 부각 시키고 작게 유지
- 재능 있는 인력으로 구성
- 지속적으로 발전 시켜야 함
Supporting Subdomain
- 경쟁 우위를 제공하지 않지만 Core 하위 도메인을 구현하는 데 필요한 도메인
- 경쟁 우위를 제공하지 않으므로 복잡하지 말아야 함 즉 단순화 해야 함

2. 도메인 주도 개발
1. DDD 이해
- 도메인 전문가와 개발자 사이의 의사소통의 어려움은 해소 하기 위해 보편언어(Ubiquitous Languages)를 사용하여 도메인과 구현을 충
분히 만족 하는 모델을 만드는 것
- 설계와 구현은 계속된 수정 과정을 거친다.
- 도메인에 대한 역할과 책임을 부여 하기 위해서 경계를 설정 한다. ( Bounded Context )
- 독립적으로 서비스 될 때 문제없는 업무 범위
- 역할과 책임 명확
- 도메인 : Bounded Context는 1:1이 이상적임
- 다른 Context 연결은 API통신으로만 한다.
- Bounded Context 마다 한 팀이 존재
- 코드 Repository 가 Bound Context마다 존재
- Domain Model + DB Schema + UI + Web Service(API)로 구성
- 주의할 점
: 하위 도메인 모델이 뒤섞이지 않도록 한다.
: 도메인이 섞이면 기능 확장이 어렵게 되고 서비스 경쟁력이 떨어짐
: 개별 Bounded Context Package로 구성
- Bounded Context는 Ubiquitous Language와 domain model을
캡슐화하나 도메인 모델과 상호작용하는 것, 도메인 모델을 서포트 하
는 기능을 포함.
- Bounded Context안에 Aggregates Entity(유니크한 트랜잭션),
Value Object(불변의 객체)가 존재
domain model
Ubiquitous Language
Bounded Context

1. Entity, Value
1. DDD 이해
1-3. 설계 기본 요소
가입 Root <<entity >>
Attributes
ID
ENTR_NO
고객
가입상태변경
Method
가입 생성자()
고객변경(고객)
가입상태변경(가입상태변경)
고객 << VO >>
Attributes
명의자 고객번호
실사용자 고객반호
가입 상태 변경 VO
Attributes
최초가입일자
상태변경일자
가입상태
Entity’s
Data
Entity’s
Behavior
and
Logic
-Entity
: 속성이 아닌 식별성을 기준으로 정의되는 도메인 객체
: 식별자는 Entity 객체마다 고유해서 각 Entity는 서로 다른 식별자를 갖는다.
: 생성 시점에 필요한 것을 전달 한다.
: setXXX Method는 완전한 상태가 아닐 수 있으므로 사용 자제
- Value
: 식별상이 아닌 속성을 이용해 정의 되는 불변 객체
: 의미를 명확하게 표현 하거나 두 개 이상의 데이터가 개념적으로 하나인 경
우 사용
; 값의 변경은 새로운 Value 객체를 할당
: 주민번호는 String로만 표현 되지 않음 -> 자료형 + 검증 로직

2. Aggregate
1. DDD 이해
가입 Root
<<entity >>
Attributes
ID
ENTR_NO
[고객[
[가입상태변경[
[가입별상품id[
Operations
가입 생성자()
고객 << VO >>
Attributes
명의자 고객번호
실사용자 고객번호
가입 상태 변경 VO
Operation
최초가입일자
상태변경일자
가입상태
가입 Aggregate
가입별상품 Root
<<entity >>
Attributes
ID
ENTR_NO
서비스코드
상품코드
[가입별상품목록]
Operations
가입별상품등록()
가입별상품수정()
가입별상품조회()
상품 Aggregate
1. 관련 객체를 하나로 묶음으로 데이터를 변경 하는 단위
2. 루트 엔티티를 갖는다.
: 애그리커트가 제공해야 할 도메인 기능 구현
: 내부 구현을 숨겨서 애그리거트 단위로 캡슐화
: 애그리커트에 속해 있는 Entity와 Value를 이용하여 기능 구현
: 애그리커트의 참조는 id를 이용한 참조 방식 사용
: 직접 참조 시 편리하지만 성능 및 확장 어려움 발생
: 외부에서 객체 참조 시 루트 애그리커트를 통해서 참조 (내부 개체를 보호)
- 외부개체는 루트 Aggregates를 통해 접근 가능하며 Aggregates의 상태
는 변경 불가능하다.
3. 애그리거트에 속해 객체는 유사 하거나 동일한 라이프 사이클을 갖
는다.
4. 한 애그리거트에 속한 객체는 다른 애그리거트에 속하지 않는다.
5. 자기자신을 관리 할 뿐 다른 애그리거트를 관리 하지 않음 즉 (경계
가 명확하다.(외부 개체는 신경쓰지 않음)
6. 외부개체는 루트 Aggregates를 통해 접근 가능하며 Aggregates의
상태는 변경 불가능하다.

3. Service
가입
<<entity >>
Attributes
ID
ENTR_NO
[고객[
[가입상태변경[
[가입별상품id[
Operation
가입 생성자()
가입처리()
가입 Aggregate
가입별상품
<<entity >>
Attributes
ID
ENTR_NO
서비스코드
상품코드
[가입별상품목록]
Operations
가입별상품수정()
가입별상품조회()
상품 Aggregate
가입처리()
가입 Service
- 업무의 흐름
: Use Case를 생각 해라
- 도메인 로직을 담당
- 상태 없이 로직만 구현
: 연산에 영향을 주는 상태를 잦기 않는다.
- Transaction의 주체
- Domain Object애 위치 시키기 어려운 Operation으로 Domain 객체
호출
: 가입 상태를 변경 하고 상품을 등록 한다면 가입상태변경 애그리거트와 상품 등록
애그리거트로 분리 하고 서비스에서 로직 구현
-Module(Package)
: 인지 과부하 방지와 낮은 결합도와 높은 응집도를 가진다
1. DDD 이해

4. Respository
-구현을 위한 모델
-애그리커드 단위로 도메인 객체를 저장하고 조회 하는 기능
: 애그리커드에 대한 영속성 관리를 통한 일관성 유지
-도메인 영역과 데이터 인프라스럭쳐 계층 분리하여 데이터 계층에 대한 결합도 낮추기 위한 방안
-어떤 객체나 전체 AGGREATE를 생성하는 일이 복잡하다면 팩토리를 이용해 이것을 캡슐화 할 수 있다
1. DDD 이해

1. 고객 관심사
1. DDD 이해
1-4. 통신 서비스 도메인 설계
-고객이 모바일 서비스를 사용 하기 위해서 통신사를 선택 하여 가입을 하고 서비스를 이용 하다가 해지를 통해서 서비스를 종료 한다.
#. 고객 괌심사
통화료 문자 사용료 단말기
고객
통신사 선택
• 무료 통화
• 초/분당 통화료
• 무료 건수
• 건당 사용료
DATA 속도
• 무료 데이터 량
• M/G 바이트당 사용 금액
• 단말기 금액
• 공시 지원금
할인
• 요금 할인 ( 약정 기간 )
• 복지 할인
• 결합 할인 등…
인터넷 대리점
#. 통신사
예약
• 고객정보
- 전자문서
• 상품정보
• 단말정보
• 약정정보
상담원 주문
• 고객정보
• 가입계약정보
전자문서
청구정보
납부정보
• 상품정보
• 단말정보
• 약정정보
• 유치대리점
계약
• 고객정보
• 가입계약정보
전자문서
청구정보
납부정보
• 상품정보
• 단말정보
• 약정정보
• 유치대리점
전자문서
/ 검수
• 전자문서
• 검수
맴버쉽
프로비저닝 • Network
• 제휴서비스
통신사는 요금/부가 서비스로 제공
대리점
고객
통신사는 단말판매 통신사는 할인 제공

2. 통신사 관심사
1. DDD 이해
-통신사는 고객 편의 서비스를 만들어서 제공 하고 제공한 서비스의 사용료를 고객에게 청구 하여 수납을 받고, 각종 판매에 대한 수수료를
대리점에게 지급한다.
• 계약상태
일시정지/해제
가입중/해지
#. 통신사 관심사
Data 사용
고객
• 무료 음성/문자/DATA 통화
• 음성 통화량
• 문자 건수
• 데이터 사용량
수수료
• 판매 수수료
계약
• 전화번호
• 명의자
주문영역
청구/납부
• 청구 방법
• 납부계좌/카드
요금제 단말기 할인
부가상품 • 요금 할인 ( 약정 기간 )
• 복지 할인
• 결합 할인 등…
• 사용기기
• 장비판매
- 약정 기간
- 현금/카드/할부
청구/수납
• 청구 정보
• 수납 처리
과금영역 청수미 영역 수수료
주문
고객
수수
료
과금
청수
미
계약
예약
대리점
상담원
프로
비저
닝 Network
제휴서비스
맴버
쉽
전자
문서
검수
외부영역

3. 하위 도메인
1. DDD 이해
-도메인은 다수의 하위 도메인으로 구성 되지만 다른 영역에 따라서 다르기 때문에 같은 용어라도 의미가 틀리다.
예약
고객
예약
상품
정보
주문
주문
할인
정보
예약
장비
정보
예약
고객
정보
예약
스캔
정보
주문
고객
정보
주문
장비
정보
주문
상품
정보
전자
문서
검수 계약
프로
비저
닝
맴버
쉽
계약
할인
정보
계약
정보
계약
장비
정보
계약
상품
정보
번호
자원

3. 주문 엔티티 설계
1. DDD 이해
주문신청 : TB_SB_ENTR_RQST
<< Entity >
가입신청번호 : ENTR_RQST_NO : Number (PK)
주문번호 : ORDER_NO : Number ( PK, FK )
서비스코드 : PROD_CD : String
서비스군코드 : SVCGRP_CD : String
전화번호 : PROD_NO : String
가입번호 : ENTR_NO : String
가입계약번호 : ACENO : String
VPN대표여부 : VPN_REP_NO_YN : String
가입유형코드 : ENTR_KD_CD : String
주문 : TB_SB_ORDER
<< Entity >
주문번호 : ORDER_NO : Number ( PK )
전화번호 : TB_SB_ENTR_RQST
<< Value >>
전화번호 : PROD_NO : String
가상번호 : VT_NO : String
IMSI번호 : IMSI_NO : String
MIN번호 : MIN_NO : String
MIC번호 : MIC_NO : String
변경전상품번호 : CHNG_BFR_PROD_NO : String
변경후상품번호 : CHNG_AFT_PROD_NO : String
고객번호 : TB_SB_ENTR_RQST
<< Value >>
명의자고객번호 : HLDR_CUST_NO : Number
실사용자고객번호 : RLUSER_CUST_NO : Number
변경전고객번호 : CHNG_BFR_NAME_CUST_NO: Number
변경후고객번호 : CHNG_AFT_NAME_CUST_NO: Number
주문상품신청정보: TB_SB_SVC_BY_ENTR_RQST
<< Entity >
가입상품신텅누적번호 : ENTR_SVC_RQST_SEQNO : Numer (PK)
가입신청번호 : ENTR_RQST_NO : Number ( FK, ID )
가입번호 : ENTR_NO : String
주문장비신청정보: TB_SB_ENTR_RQST
<< Entity >
가입단말신텅누적번호 : ENTR_SVC_RQST_SEQNO : Numer (PK)
가입신청번호 : ENTR_RQST_NO : Number
서비스 : TB_SB_SVC_BY_ENTR_RQST
<< Value >>
서비스코드 : PROD_CD : String
상품코드 : SVC_CD : String
가입상품누적번호 : ENTR_SVC_SEQNO : Number
상위상품코드 : HPOS_SVC_CD : String
상위가입상품누적번호 : HPOS_ENTR_SVC_SEQNO : String
상품유형코드 : SVC_KD_CD : String
상품명세코드 : SVC_DTL_CD : String
적용레벨코드 : APLY_LVL_CD : String
상품상태 : TB_SB_SVC_BY_ENTR_RQST
<< Value >>
상품상태코드 : SVC_STTS_CD : String
상품신청일시 : SVC_RQST_DTTM : Date
상품상태변경일시 : SVC_STTS_CHNG_DTTM : Date
진행상태코드 : RQST_PRGRS_STTS_CD : String
진행상태변경일자 : RQST_PRGRS_STTS_CHNG_DTTM : Date

1. DDD 이해
주문신청 : TB_SB_ENTR_RQST
<< Entity >
가입신청번호 : ENTR_RQST_NO : Number (PK)
가입신청상태 : TB_SB_ENTR_RQST
<< Value >>
진행상태코드 : PRGRS_STTS_CD : String
진행상태변경일자 : PRGRS_STTS_CHNG_APLY_DT : String
신청일자 : RQST_DT : String
가입신청개통일자 : ENTR_RQST_SBG_DT
가입상태변경사유코드 : ENTR_STTS_CHNG_RSN_CD : String
가입상태변경사유내역코드 : ENTR_STTS_CHNG_RSN_DTL_CD : String
소유자 : TB_SB_ENTR_RQST
<< Value >>
마켓코드 : MRKT_CD: String
가입대리점 : ENTR_DLR_CD : String
솔류션코드 : SLTN : String
최초신청자 : FRST_APCNT_ID : String
가입영업정책 : TB_SB_ENTR_RQST
<< Value >>
가입영업정책코드 : ENTR_BIZ_PLCY_CD : String
대리점메모 : TB_SB_ENTR_RQST
<< Value >>
대리점메모1 : DLR_EXCLV_INF01: String
번호이동 : TB_SB_ENTR_RQST
<< Value >>
이전사업자코드 : MNP_BFR_ENPR_CD : String
이후사업자코드 : MNP_AFT_ENPR_CD : String
번호이동유형코드 : MNP_KD_CD : String
번호이동상태코드 : MNP_STTS_CD : String
재가입 : TB_SB_ENTR_RQST
<< Value >>
재가입일자 : RJN_DTTM : Date
재가입여부 : RJN_YN : String
청구계정 : TB_SB_ENTR_RQST
<< Value >>
청구계정번호 : BILL_ACNT_NO : Number
변경전 청구계정번호 : CHNG_BFR_ BILL_ACNT_NO : Number
변경후 청구계정번호 : CHNG_AFT_ BILL_ACNT_NO : Number

1. DDD 이해

Content
1. TDD 란
I. TDD의 이해

1. TDD란
TDD ?
- 보다 튼튼한 객체 지향적인 코드 생산
- 재설계 시간의 단축
- 디버깅 시간의 단축
- 추가 구현의 용이함
- Test Driven Development의 약자로 ‘테스트 주도 개발’
- 생산성의 저하 : 테스트 코드도 작성을 해야 함
-> 클린 코드를 작성 한다면 ???

Content
1. 기본 용어
II. JPA

1. 기본 용어
-데이터를 생성한 프로그램이 종료되더라도 사라지지 않는 데이터의 특성
-메모리 상의 데이터를 파일시스템, 관계형 데이터 베이스 혹은 객체 데이터베이스 등을 활용 하여 영구적으로 저장 하여 영속성을 부
여함
-데이터를 데이터베이스에 저장 하는 방법 :: JDBC, Spring JDBC Persistence Framework ( Hibernate, Mybatis … )
-객체는 객체대로 설계 하고, 관계형 데이터 베이스는 관계형 데이터베이스로 설계로 ORM 프레임워크가 중간에 매핑
-데이터 베이스 객체를 자바 객체로 매핑함으로써 객체 간의 관계를 바탕으로 SQL을 자동 생성 해서 자동으로 매핑(연결) 해 주는 것
-객체는 Class를 사용 하고 관계형 데이터베이스는 테이블 사용 :: 데이터 베이스 데이터 <- 매핑 -> Object 필드
-SQL Query가 아닌 직관적인 코드(메서드)로 데이터 조작 :: Persistence API ( JPA, Hibernate .. )
자바 ORM기술에 대한 표준 명세로 자바 에서 제공하는 API
-Persistence Layer : 데이터에 영속성을 부여해 주는 계층
-Persistence Framework : JDBC프로그램의 복잡함이나 번거로움 없이 간단한 작업만으로 데이터 베이스와 연동 하여 안정정성을 보장
( JPA, Hibernate, Mybatis ..)
- SQL Mapper
- ORM

-실제로 DB에 접근하는 객체
-Service와 DB를 연결하는 고리 역할
-Object – SQL CRUD – DB Record Service
Object
DAO DB
Business
Logic
Persistence
Layer
Provides
an object-oriented API
(CRUD)
“Objects” “Record”
miss match 발생
-계층간 데이터 교환을 위한 객체(Java Beans)
-로직을 가지고 있지 않는 순수한 데이터 객체, getter/setter 메소드로 구성
-DB에서 꺼낸 값을 임으로 변경할 필요가 없기 때문에 DTO Class에는 setter 없음 (대신 생성자에서 값을 할당 )
-VO(Value Object)는 DTO와 동일한 개념 이지만 read only 속성을 갖음
: VO는 특정한 비즈니스 값을 담는 객체, DTO는 Layer간의 통신 용도 객체
Presentation Layer ( UI )
Business Layer ( Domain )
Persistence Layer ( DAO )
DB
Application Layer ( Service )
DTO
Entity
Controller
Service
Repository
DTO
DTO
DB
Entity
Client
DTO
– Domain Model
-실제 DB의 테이블과 매칭될 Class, 즉 테이블과 링크될 Class
-최대한 외부에서 Entity Class의 getter method를 사용 하지
않도록 해당 Class안에서 필요한 로직 Method 구현으로
Service Layer에서 사용
# DTO 와 Entity 분리 이유
- View Layer와 DB Layer분리
- Entity Class의 변경은 여러 Class에 영향을 주는 반면에 View와 통신 하는 DTO
는 요청과 응답에 따라서 변경이 되므로
- Domain Model에 Presentation을 위한 필드 추가 시 모델링의 순수성이 깨짐
- Presentation 요구사항들을 수용하기 위해서 여러 Domain Model 사용

Content
4. 격리 레벨
6. SAGA Pattern
III. MSA

비즈니스 로직을 몇몇의 작은 단위로 나눈 어플리케이션으로 API(HTTP, AMQP… )를 통해서 연결하여 하나의 서
비스가 정지 될 경우 다른 것에 영향을 미치지 않는 구조를 가진다.
- 각각의 컴포넌트는 독립적으로 빌드되고 배포된다.
- vertical 하며 layered하다. 또한 Process driven 형태이다.
- Microservice Architecture는 SOA와 유사하다.
-
- Application/Logic : 단일 비즈니스 기능 구현 ()
- Data Store : 자신만의 데이터 베이스를 가진다. ()
각각의 레퍼지토리를 갖는다
- Public API(POST, GET ) : 잘 정의된 API ( HTTP, AMQP
… )로 연결 되어 있다.

Monolithic Architecture vs Microservice Architecture Microservices vs SOA
Monolithic Architecture : 모든 기능이 단일 코드베이스에 위치하
고 하나의 DB를 사용한다. 또한 한 기능이 마비되면 전체가 마비되
며 크고 복잡한 어플리케이션 형태
SOA는 집중화 되어 있다
Monolithic Architecture vs SOA vs Microservices

- ACID 모델은 일관된 시스템을 제공. ( MySQL , PostgreSQL , Oracle, SQLite 및 Microsoft SQL Server와 같은 관계형 데이터베이스 )
- 강한 일관성, commit에 초점, 보수적
- BASE 모델은 고가용성을 제공. ( MongoDB, Cassandra 및 Redis )
- 약한 일관성, 가용성 우선, 간단하고 빠르다
- 원자성 ( Atomicity ) : 모든 작업이 실행되거나 전혀 실행되지 않으며 트랜잭션이 부분적으로 완료된 데이터베이스에 상태가 없어야 하며 상태도 정의 한다.
- 일관성 ( Consistency ) : 트랜잭션 후에도 일관된 상태를 유지해야 하며 어떤 트랜잭션도 데이터베이스에 상주하는 데이터에 부정적인 영향을 미치지 않아
야 한다.
- 격리 ( Isolation ) : 둘 이상의 트랜잭션이 동시에 병렬로 실행되는 데이터베이스 시스템에서 격리 속성은 각 트랜잭션이 시스템의 유일한 트랜잭션이기 때문에
관리되고 실행될 것임을 의미합니다. 다른 트랜잭션의 존재에 영향을 미친다.
- 내구성 ( Durability ) : 데이터베이스는 시스템이 실패하거나 다시 시작되는 경우에도 모든 최신 업데이트를 유지할 수 있을 만큼 충분히 내구성이 있어야 한다.
- 기본적으로 사용 가능 ( Basically Available ) : 즉각적인 일관성을 위해 필수로 만드는 대신 BASE 모델 NoSQL 데이터베이스는 데이터를 데이터베이스 클
러스터의 노드 전체에 분산 및 복제하여 데이터 가용성을 보장
- 소프트 상태 ( Soft-state ) : 즉각적인 일관성이 없기 때문에 데이터 값이 시간이 지남에 따라 변경될 수 있습니다. BASE 모델은 자체 일관성을 의무화하고 해
당 책임을 개발자에게 위임하는 데이터베이스 개념과 구분됩니다
- 결국 일관성 ( Eventual consistency ) : BASE가 즉각적인 일관성을 의무화하지는 않지만 결코 달성하지 못한다는 의미는 아님. 그러나 그렇게 될 때까지 데
이터 읽기는 여전히 가능하다(현실을 반영하지 않을 수도 있음).

4. 격리 레벨
@Transactional(isolation = Isolation.READ_COMMITTED, propagation = Propagation.REQUIRED, rollbackFor = Exception.class)
- READ_UNCOMMITTED (level 0) : 트랜잭션 처리중 or 아직 commit되지 않은 데이터를 다른 트랜잭션이 읽는 것을 허용 (Dirty read 발생)
- READ_COMMITTED (level 1) : dirty read 방지 : 트랜잭션이 commit 되어 확정된 데이터만을 읽도록 허용
- REPEATABLE_READ (level 2) : 트랜잭션이 완료될 때까지 SELECT 문장이 사용하는 모든 데이터에 shared lock이 걸린다. 따라서, 다른 사용자는
해당 영역에 대한 데이터 수정이 불가능
- SERIALIZABLE (level 3) : 완벽한 읽기 일관성 모드 제공(가장 엄격함), 트랜잭션이 완료될 때까지 SELECT 문장이 사용하는 모든 데이터에 shared
lock이 걸리므로 다른 사용자는 그 영역에 해당하는 데이터에 대한 수정 및 입력이 불가능하다. 거의 사용하지 않음
- REQUIRED : 부모 트랜잭션 내에서 실행하며 부모 트랜잭션이 없을 경우 새로운 트랜잭션을 생성
- REQUIRES_NEW : 부모 트랜잭션을 무시하고 무조건 새로운 트랜잭션이 생성
- SUPPORT : 부모 트랜잭션 내에서 실행하며 부모 트랜잭션이 없을 경우 nontransactionally로 실행
- MANDATORY : 부모 트랜잭션 내에서 실행되며 부모 트랜잭션이 없을 경우 예외가 발생
- NOT_SUPPORT : nontransactionally로 실행하며 부모 트랜잭션 내에서 실행될 경우 일시 정지
- NEVER : nontransactionally로 실행되며 부모 트랜잭션이 존재한다면 예외가 발생
- NESTED : 해당 메서드가 부모 트랜잭션에서 진행될 경우 별개로 커밋되거나 롤백될 수 있음. 둘러싼 트랜잭션이 없을 경우 REQUIRED와 동일하게
작동
** no-rollback-for - 예외처리 (기본값 : 없음) : 특정 예외가 발생하더라도 롤백되지 않도록 설정

CQRS ( Command Query Responsibility Segregation )
- 명령과 조회의 책임 분리
TWO-PHASE Commit
- 여러 노드에 거쳐서 원자성 트랜잭션 커밋을 달성하기 위한
알고리즘이다.
- 트랜잭션 매니저이며, 각 데이터베이스 노드들 관리
- 글로벌 트랜잭션은 여러 리소스 사이에서 처리하는 작업이기 때문에 '
분산' 트랜잭션(Distributed Transaction)이라고도 하며 이를 줄여
서 XA 라고 함.
- Java(자바)에서는 XA를 기초로 하여 자바 환경에서의 트랜잭션에 대해
정의하였다. 이를 JTS 라고 한다. 그리고 이에 대한 Java API를 JTA 라
고 한다. JTS와 JTA 얘기를 꺼낸 이유는 WAS 가 자바를 기반으로 되어
있고, WAS의 기본 구성 요소 중 하나가 JTS와 JTA에 기반한 트랜잭션
매니저(Transaction Manager)이기 때문이다.

6. SAGA Pattern
- 분산 트랜잭션의 잘 알려진 패턴
SAGA는 일련의 local 트랙잭션들을 의미하며 각 트랜잭션은 하나의 서비스안에서 데이터를 업데이트 한다. 첫 번째 트랜잭션은 시스템 작업에
해당하는 외부 요청에 의해 시작되고 이후엔 이전단계 완료가 될 때마다 트리거링되어 작동한다
- 각 서비스는 다른 서비스의 event, decides를 보고 action을 할
지 말지 결정하며 non centralize 한 것.
- 분산 트랜잭션의 경우 롤백에 대한 로직은 직접 만들어야 한다
- coordinator 서비스가 의사결정 및 sequncing 비즈니스 로직에
대한 책임이 있는 것. 즉 centralize 한 것.
- Orchestration은 트랜잭션을 실행하는데 필요한 흐름을 알고있으며 롤
백 명령을 보낸다.

www.iabacus.co.kr
Tel. 82-2-2109-5400
Fax. 82-2-6442-5409
THANKS

MSA_기초자료.pdf

Recomendados

Recomendados

Mais conteúdo relacionado

Semelhante a MSA_기초자료.pdf

Semelhante a MSA_기초자료.pdf (20)

Mais de Hyosang Hong

Mais de Hyosang Hong (20)

MSA_기초자료.pdf