MSA 하는데까지 만들어보기 - (1)

1. MSA 란?

 

MicroService Architecture 로 하나의 거대한 Monolithic 한 앱을 작은 단위의 서비스로 쪼개서 개발하는 것이다.

기존의 서비스들은 대부분 Monolithic하게 개발되어 있고 작은 규모에서는 Monolithic 한 구조가 오히려 더 나을수도 있습니다. (서비스 구성이 간단하기 떄문이죠.) 하지만 서비스가 커지게 되면 Monolithic 한 아키텍처로는 다음과 같은 문제점이 발생합니다.

 

1) 빌드, 배포, 테스트 시간이 기하급수적으로 증가합니다. (당연히 코드가 커질테니)

2) 서비스를 부분적으로 Scale-up 하기 힘듭니다. (예를 들어 내 사이트의 A ,B ,C 기능 중 C를 사용하는 사용자가 많으면 C만 증가하기 싶어도 그렇게 할수 없다. 즉, Mutlimulti hypervisor orchestration 라고 불리는 클라우드 구조에 부적합하죠)

3) 부분의 장애가 전체 장애로 이어집니다.

4) 서비스 간의 의존성이 발생하고, 유연성이 떨어집니다. (기존 서비스에서는 파이썬을 3.1 버전을 사용했는데, 새로운 기능을 개발하기 위해서는 파이썬 3.6 이상의 버전이 필요한 상황이 생긴다 생각해보죠. 기존 서비스의 호환성 문제 때문에 쉽게 파이썬 버전을 올리기는 힘들겁니다.)

 

 그에 반해 MSA는 하나의 거대한 프로그램을 작은 단위의 서비스로 나눕니다. 

 

이로 인해 MSA는 다음과 같은 특징을 가집니다.

 

1) 각각의 서비스는 작지만 하나의 프로세스로 동작하며 그 자체는 Monolithic 한 서비스와 구조적으로 유사합니다.

2) 각각의 서비스는 독립적으로 배포, 빌드가 가능해야합니다.

3) 각각의 서비스는 다른 서비스와의 의존성을 줄여야합니다.( 다른 서비스에 변화가 생겨도 그 서비스에는 영향이 없어야합니다.)

4) 각각의 서비스는 Rest와 같은 가벼운 통신으로 통신합니다.

 

이로 인해 MSA의 장점은 

1) 서비스 별로 배포, 빌드가 가능하다는 점(무중단 배포 + 빈번한 배포 가능)

2) 서비스 별로 개발환경을 유연하게 가져갈수 있습니다.( 서비스에 특화한 개발언어, 프레임워크 사용가능) 또 도커 기반의 컨테이너에 굉장히 적합한 구조입니다.

3) 서비스 장애가 전체 서비스 장애로 이어지지 않습니다.

 

반면 MSA의 단점은

 

1) 서비스 간 Rest API 로 통신하기 떄문에 오버헤드가 존재합니다. 그로 인해 MSA는 성능이 중요한 시스템에 적합하지 않습니다.

2) 하나의 데이터베이스를 사용하는 것이 아니라 여러 개의 서비스에 나눠져있기 떄문에 트랜잭션이 복잡해지고 데이터 동기화 문제가 복잡합니다.

 

2. 나의 MSA 개발 방향

 

내가 전에 Spring Boot를 기반으로 개발한 간단한 웹 사이트가 있다.

이 웹사이트에는 회원, 게시판, 상품 주문 기능을 가지고 있다.

이 프로젝트를 기존 베이스로 두고 웹사이트를 기능 별로 나누고 Spring Cloud와 AWS를 활용하여 MSA로 바꿔 볼 예정이다.

 

다음 포스트에는 MSA를 구성하는 요소들 그리고 도커, 쿠버네티스에 대해서 다뤄보겠다.