MSA [Micro Service Architecture]
간단하게 이야기하면
- Monolithic 은 통짜이고
- MSA는 독립적인 응용 프로그램 서비스
이다.
더 쉬운 예시를 보자면 하단의 그림같이 각각의 로직별로 마이크로 서비스라는 단위로 독립적인 실행을 하는 것이다.
Monolithic Architecture
애플리케이션 안에 모든 비지니스 로직이 들어가 있는 구조 .
Micro Service Architecture
조금더 자세히 마이크로 서비스를 들여보자면
서비스를 비지니스 경계에 맞게 세분화 하고, 서비스 간 통신은 네트워크 호출을 통해 진행하여
확장 가능하고 유지보수가 용이한 유연한 어플리케이션을 구성하는 것이다.
서비스를 노출시키지 않고 **API Gateway 를 통해 인증 절차를 가지며
DB 또한 각각의 서비스에 맞게 따로 가지고 있다는 특징을 가지고 있다.
**API GateWay에 대한 설명>>
외부 게이트웨이는 전체 서비스를 외부로부터 들어오는 접근을, 내부 구조를 드려내지 않고 처리하기 위한 요소이다. 사용자 인증과 권한 정책 관리 등을 수행하며, API 게이트웨이가 가장 핵심적인 역할을한다.
API게이트웨이는 서버 최앞단에 위치하며 모든 API 호출을 받는다. 받은 API호출을 인증한 후, 적절한 서비스에 전달한다.
Micro Service Architecture 는 왜 유명한가?
Monolithic의 단점과 그에 대응한 MSA의 장점
결국 MSA 도 Monolithic 방법의 문제점들에서 시작 되었다.
바로, 여러 기능들이 뭉쳐 강하게 결합되어있다 라는 것이다. Monolithic 에는 어떤 단점들이 생겨날까?
- 어플리케이션의 구동시간이 늘어나고 빌드, 배포의 시간이 늘어난다.
- 작은 수정사항이 있어도 전체를 빌드 및 배포 해야한다.
- 소규모가 아닐경우 많은 코드가 있어 유지보수에 어려움을 겪는다.
- 기능별로 알맞는 기술, 언어, 프레임워크를 선택하는데 한계가 있다.
- 높은 결합도로 인한 오류의 발생
- *scale out 이 불가능하다. (*장비를 추가해서 확장하는 방식을 말한다.)
**Scale up : 기존의 서버를 보다 높은 사양으로 업그레이드 하는것.
" Monolithic " vs " MSA "
1. [Monolithic]기존의 Monolithic 방법은 모든 구성요소가 한 프로젝트에 합쳐져 있어,
새로운 기능 추가 및 업데이트에 대한 어려움이 있었습니다. 높은 결합도로 인한 오류의 발생이 가장 큰원인이다.
[MSA]그에 비해 MSA는 서로 낮은 결합도로 인해서 예상하지 못한 오류에 대한 걱정이 적고 빌드 및 배포에 대한 부담이 적어진다.
2. [Monolithic]여러 역할을 하는 시스템이 하나의 소프트웨어로 집합되어 있어, 특정 한 부분에 문제가 발생할 시에
큰 문제로 돌아올 수 있다.
[MSA] MSA는 각각의 서비스가 분리 되어있기에 각각의 문제가 있는 서비스만 수정하여 배포가 가능하다.
3. [Monolithic] 여러 역할을 하는 시스템이 하나의 소프트웨어로 집합되어 있어, Scale-Out시 필요없는 자원이 함께 증가됩니다.
이해가 어려워 부연 설명을 하자면 [ 서비스1, 서비스2, 서비스3 ] 이 있을때 서비스3에 대한 확장이 필요할 경우
하나의 소프트웨어인 특징 때문에 서비스1, 서비스2 에 대한 확장도 하게된다. (묶여 있으니까)
[MSA] MSA는 따로 분리되어 있기때문에 확장이 필요한 서비스에서만 확장이 가능하여 유연한 대처(Scale-out)가 가능하다.
4. [Monolithic] Monolithic 방법은 신규 기능이 추가된 코드의 바이너리파일을 만들어 배포하게되며, 문제가 발생하여 재배포를 할시에
잘못된 부분을 수정하여 다시 바이너리 파일을 만들어 재배포 하게된다. 여기서 소탐대실이 일어날 가능성이 크다.
[MSA] 그에 반해 MSA는 **Blue-Green 배포 방식을 사용하여 점직적으로 배포가 가능하다. Green 으로 트래픽이 다 넘어가더라도, Blue를 남겨두어 롤백이 바로 가능하다.
**blue green 배포방식에 대한 정보 >>
Blue : 구버전, Green : 신버전을 의미 운영중인 구버전과 동일하게 신버전의 인스턴스를 구성한 후
로드밸러서를 통해 모든 트래픽을 한번에 신버전 쪽으로 전환하는 방식
장점
- 구버전의 인스턴스가 그대로 남아 있어서 롤백이 가능하다.
- 구버전의 환경을 다음 배포에 재사용할 수 있다.
- 운영 환경에 영향을 주지 않고 새 버전 테스트가 가능하다.
단점
- 시스템 자원이 두배로 필요하다.
- 새로운 환경에 대한 테스트가 전제되어야한다.
이외의 무중단 배포 방식
- Rolling 배포
- 카나리 배포
문제가 발생하여 재배포를 할시에 특정 부분만 수정하여 컨테이너화 하여 해당 부분만 재배포한다.
여기 까지 기본적인 MSA의 개념에 대해 알아 보았다 .
다음 포스팅에서는 MSA의 고려 할 부분과 함께 Spring Cloud 를 알아보려한다.