2014년 마틴파울러는 마이크로서비스에 대한 정의를 자신의 블로그(바로가기)에 올렸다. 이를 바탕으로 나의 생각과 함께 정리해보았다.
개요
"마이크로 서비스 (Microservices)"- 소프트웨어 아키텍처에 대한 또 다른 새로운 용어다. 지난 몇 년 동안 많은 프로젝트에서이 스타일을 사용 해왔고 지금까지의 결과는 긍정적이었다. 많은 동료가 엔터프라이즈 application 구축의 기본 스타일이되었지만 슬프게도 마이크로 서비스 스타일이 무엇이며 어떻게 수행하는지 설명하는 정보는 많지 않다. 이를 설명하고자 한다.
마이크로서비스(Microservices)
간단히 말해 Micro service Archiectrure(이하 MSA)는 작은 단위의 경량 application의 모음 군으로 개발하는 접근 방식이다. 이런 서비스는 비즈니스 function 중심(ex. 결재, 배송 등)으로 구축되며 각각의 application은 독립적으로 구축된다. MSA를 설명하기 위해서는 Monolithic application과 비교하는것이 좋다. Monolithic application은 하나의 단일 단위로 개발된 applicaiton을 뜻한다. 이 application을 개발하기 위해 개발자는 각각의 기능을 class, namespace, package 등으로 분할하여 개발한다. 하지만 이 application은 기능이 늘어날때 마다 각 기능별 모듈을 유지보수하기 쉬운 방향으로 구성하기 어렵게 된다.
이러한 불만으로 서비스제품 group으로 application을 구축하는 MSA가 생겨났다. 서비스가 독립적으로 배치가능하고 확장가능할 뿐만아니라, 각 서비스의 견고한 모듈 경계를 제공하여 서로 다른 프로그래밍 언어로 작성할 수도 있다. 또한 여러팀에서 관리가 가능하다.
Monolithic application
Monolithic application은 서비스가 한개의 application에 여러 기능이 들어가 있는 것을 뜻한다.
Monolitic application은 단일 application에 여러기능이 포함되어 있는 모습이다. 예를 들어 로그인을 하면 선물을 주는 event를 한다고 가정을 하자. 유입이 폭발적으로 증가하여 로그인기능에 대한 resource(cpu, ram 등)의 증가가 필요하다면 monolitic application은 전체 application을 확장해야한다.
MSA
MSA는 Monolitic application과는 다른 양상이다. 로그인 이벤트로 인해 로그인 기능의 resource가 필요할 경우 로그인 기능에 대한 resource만 scale out하면 된다. 이를 통해 각 기능은 독립적으로 배치가 가능하고 확장가능할 뿐만아니라, 각 서비스별로 서로 다른 프로그래밍 언어로 작성할 수도 있다. 또한 여러 팀에서 관리 할 수 있다.(서로 다른 언어로 작성되어 있더라도 protocol만 맞으면 문제 없음)
MSA의 여러 특징들
MSA가 모두 이렇다고는 할수 없지만 대부분의 MSA구조는 아래와 같은 특징을 따라간다고 말할 수 있다.
1) 서비스를 통한 구성요소화 : 각 기능을 라이브러리가 아닌 서비스로 만듦으로서 독립적으로 개발
2) 비즈니스기능을 중심으로한 조직화 : 비즈니스 기능(배송, 로그인 등)을 기준으로 팀을 구성
3) 프로젝트가 아닌 제품 : waterfall방식의 개발, 운영이 아닌 지속적인 개발과 운영
4) 스마트 앤드포인트 및 단순한 파이프라인 : 각 서비스별 rest api 호출을 하거나 혹은 kafka, MQ 등 pipeline을 이용한 메시지 전달
5) 분산통치 : 각 서비스 별 적합한 code 혹은 framework선택
6) 분산데이터 관리 : 각 서비스별 자체 데이터베이스 관리, 허용
7) 인프라 자동화 : Continous Integration/Continous Deploy 를 통한 자동화
8) 고장을 위한 설계 : 각 서비스는 장애가 날 수 있음을 가정하고 식속감지, 복원토록 하는것이 중요
9) 진화 디자인 : Monolithic to MSA
MSA가 정답일까?
MSA가 미래의 아키텍쳐의 궁극적인 방향이라고 생각하지 않다고 한다. 기능별 모듈화에 대한 강한 욕심을 가진 팀이 여러가지 아키텍쳐를 제안했지만 수없는 아키텍쳐가 생겨나고 사라졌다. 아직 MSA가 성숙되지 않는 이상(시간이 충분히 지나고 예제 사례가 많지 않은 이상) 진정으로 평가할 순 없다. 또한 프로세스간 통신하는 인터페이스는 좋은 서비스 인터페이스가 아니기 때문에 초기에는 Monolitic application으로 진행하다가 추후에 문제가 되었을때 그것을 MSA구조로 가져가는것이 옳은 방향이라고 생각한다.
'DevOps > 소프트웨어공학' 카테고리의 다른 글
| You aren't going to Need it(YAGNI). 그 기능이 필요할 때 만들어라! (0) | 2024.01.04 |
|---|---|
| [번역]마틴파울러의 테스트 피라미드 (0) | 2021.08.06 |
| 예제로 풀어보는 구독형 아키텍쳐(Subscribe architecture) for Micoro Service Architecture(MSA) (952) | 2018.05.27 |
| 개발자에게 은총알(silver bullet)은 없다. (942) | 2018.05.22 |
