✅ 모노리스
- 애플리케이션이 한 덩어리로 구성
- 단일 프로세스 실행
- 한꺼번에 수정, 배포되어야 함
- 하나가 실패하면 모두 실패됨을 의미
- 모노리스를 클라우드 인프라에서 활용 시에 스케일 아웃의 대상은 모노리스 전체가 된다.
- 그것만으로 충분히 확장성, 탄력성이 보장이 가능하나 비용 효율적이지 않는다.
- 예를 들어 온라인 쇼핑몰 같은 경우는 많은 트래픽이 상품을 전체 조회하고, 상세 조회할 때 많은 리소스를 소요하게 된다.
- 해당 기능에 대해서만 서버 스케일 아웃을 할 수가 없는 구조이다.
- 사용량이 많지 않는 부분에 대해서도 서버 확대를 한다고 하면, 비용적인 측면에서 효율적이지 않다.
✅ 마이크로 서비스
- 모노리스에 비해 마이크로 서비스는 애플리케이션이 여러 개의 서비스 조각을 구성 됨
- 서비스는 각기 독립적인 기능을 제공
- 주문, 상품 조회, 배송들이 별도의 서비스로 제공
- 서비스가 사용하는 저장소는 다른 서비스와 완벽히 격리 됨
- 독립적으로 저장소를 수정하고 배포할 수 있다.
- 따라서 독립적으로 수정 가능하며 별도 배포, 확장 가능
- 하나의 서비스 실패는 전체 실패가 아닌 부분적인 실패를 의미
- Public Interface, 데이터 캡슐화
- Martin Fowler
✅ SOA
특징
- SOA는 서비스는 분리하더라도, 저장소는 같이 가져간다.
- SOA는 서비스의 재사용성을 강조 했기에 DataBase 격리는 그렇게 강조하지 않았다.
- Table 끼리의 Join을 허용한다. 그렇게 했을 때 변경에 의한 파급 효과가 각각의 서비스에 전이가 된다.
- 공통 모듈이 있으면, 공통 서비스를 식별한 다음에 공통 서비스를 다른 서비스들이 사용하게 함으로써 생산성을 높이겠다.
단점
- 공통 서비스 모듈을 Call 하면서 어떻게 보면 의존 관계가 많이 발생한다.
- 의존 관계가 많이 생긴다는 것은 MSA 환경에서 변경점에 의한 독립적인 배포가 불가능 하다.
✅ MSA
특징
- SOA 범주 안에 MSA가 있다.
- MSA는 작은 여러 조각의 시스템의 데이터 베이스는 다 격리되어 있다.
- 격리한다는 측면에서 SOA하고는 많이 다르다.
- MSA의 장점은 변경 사항에 의한 파급효과가 제한된다.
- SOA 처럼 하게 되면 Table 변경 사항에 의한 파급효과가 호출하는 서비스에게 전이가 된다.
- MSA는 이런 SOA의 문제점을 해결하기 위해, 저장소를 격리함으로써 극복을 했다.
- MSA는 공통 모듈의 재사용성 보다는 각가의 서비스에 조금씩 공통 모듈이 속해 있는 것이 독립적인 배포 환경에서 바람직하다.
- 공통적인 측면들을 Common 이라는 서비스로 만들지 않고
- 중복을 허용하더라도, 서비스들 간의 독립성을 보장하는 방식으로 구성하는 것을 추구하고 있다.
✅ 마이크로 서비스 개발을 위한 공정
✅ 아키텍쳐 정의
-
Outer Architecture 정의
- Cloud Infra 정의
- IaaS, PaaS ,CaaS
- Platform 구성요소 , MSA 패턴
- 라우팅, 로드 밸런싱, 인증/인가, 로깅, 트레이싱 , 모니터링
- DevOps Infra 정의
- 형상관리,빌드,배포(CI/CD)
- Cloud Infra 정의
-
Inner Architecture 정의
- Front End
- 기술 stack 정의
- 내부 구조 정의
- Back End
- 기술 stack, 프레임웍
- 내부 구조 정의
- 통신
- 서비스 간
- 레거시 연계
- Front End
✅ 설계 / 구현
-
마이크로서비스 식별
- 조직구성 ,구성원 역량, 비지니스 서비스 성격, 변경/배포 빈도, 사용량, 운영 조직
- 다양한 마이크로서비스 도출 기법
-
백엔드 설계
- 도메인 모델 설계
- API 설계
- 데이터 모델 설계
-
테스트
- 단위
- API
- EtoE
-
배포
- CI/CD
✅ 시스템 복잡성
- 로컬 복잡성
- 각각의 개별 마이크로 서비스의 복잡성
- 글로벌 복잡성
- 전체 시스템의 복잡성, 서비스 간의 상호적용과 의존성
다른 모듈과의 호출성 관계에서도 복잡성이 적당히 작아야 한다.
적당히 모듈을 쪼개는 것의 판단점이 중요하다.
✅ 서브 시스템 / 업무 영역
- 기능 분해를 통해 도출
- What 관점 : 업무를 제공하는 서비스, 비지니스 능력 (조직이 하는 일)
✅ 도메인 주도 설계
- How 관점
- 업무 경계 (바운디드 컨텍스트, 어그리거트)
참고
Go For It