MSA 란? (등장 배경과 Micro 의 기준, SOA)

들어가며

지난번에 API Gateway 를 찾아보며 참으로 많이 접한 MSA 에 대해 알아보았습니다. 들어보기만 많이 들어봤지 잘 모르고 있었습니다.

질문

알아보기 전에 먼저 MSA 를 떠올리면 제일 궁금한 것들에 대해 정리해보았습니다. 내용이 끝나면 이 질문에 다시 대답해보겠습니다!

MSA 란 무엇이지?
몇년 전 부터 많이 들어봤다, 언제부터 나온거지?
왜 나오게 된거지? 어디서 제안했지? 기존의 아키텍처와는 어떤 차이가 있는거지?
Monorepo 가 최근에 등장했는데, 이와 대비되는 듯한 개념인 MSA 도 최근에 등장했다. 어떻게 다른거지?
어디까지가 Micro 인걸까?

MSA 란?

MSA 란 microservice architecture 로, micro + service + architecture 입니다.

즉 아키텍처인데 아주 작은 서비스들로 이루어진 아키텍처 를 말합니다.

마이크로서비스(microservice)는 애플리케이션을 느슨하게 결합된 서비스의 모임으로 구조화하는 서비스 지향 아키텍처(SOA) 스타일의 일종인 소프트웨어 개발 기법이다. - wikipedia-microservice

SOA 란?

앗 모르는 개념이 나왔습니다! 처음 들어보는 용어입니다.

SOA 는 Service-oriented architecture 의 약자로, MSA 와 유사한 부분이 많습니다. 물론 MSA 는 SOA 의 일종이므로, 비슷한점이 많을 수 밖에 없을 것 같습니다.

SOA 는 (하나의 서비스에서 모든 것을 개발하는) Monolithic design 과 달리, 각 서비스에 초점을 맞춘 아키텍처 스타일 입니다.

출처 :  https://medium.com/@magenta2127/monorepo-vs-multi-repo-vs-monolith-7c4a5f476009

여기서 말하는 서비스는 개별적인 기능의 단위입니다. 예를 들어 위의 예시에서 shopping-cart, payment, inventory 등이 service 라고 볼 수 있습니다. 서비스는 개별적으로 개발되고 배포되므로, 네트워크를 통해 사용할 수 있습니다.

SOA 는 공급업체, 제품, 기술로부터 독립적이도록 고안되었고, 2004년부터 주목을 받기 시작했습니다.

MSA 의 등장 배경

MSA 의 등장

2011년 5월에 베니스에서 소프트웨어 아키텍처 워크숍이 개최되었습니다. 이곳에서 당시 참가자들이 탐구하고 있던 common architecture style (공통 아키텍쳐 스타일) 을 두고 "마이크로서비스"(microservice) 라는 용어를 사용하였습니다.

그리고 2012년 5월, 이 그룹은 common architecture style 의 이름을 "마이크로서비스" 로 결정하였습니다.

무엇을 개선하고자했는지

기존의 monolithic architecture 의 문제를 해결하기 위해 등장하였습니다. (아래쪽에 monolithic architecture 의 자세한 설명이 있습니다, 우선은 단점먼저...)

monolithic architecture 는 하나의 프로젝트 내에 모든 서비스가 있는 구조입니다. 따라서 초기 개발상태일때는 개발, 리소스 공유, 배포, 테스트 등 다양한 면에서 용이하지만, 하나의 하나의 프로젝트 내에 모든 서비스가 있기에 프로젝트가 커질수록 부담이 생길 수 밖에 없습니다.

유연성과 확장성 부족: monolithic architecture 는 규모가 커질수록 복잡해지며, 특정 부분만을 확장하기 어렵습니다. 반면, MSA 는 각 서비스를 독립적으로 확장하고 관리할 수 있어, 시스템의 유연성과 확장성을 크게 향상시킵니다.
개발 속도 저하: monolithic architecture 에서는 애플리케이션의 모든 부분이 서로 밀접하게 연결되어 있어, 작은 변경사항 하나에도 전체 시스템을 다시 테스트하고 배포해야 할 수 있습니다. MSA 는 독립적으로 배포 가능하므로, 더 빠른 개발과 반복이 가능합니다.
기술 스택의 유연성 부족: monolithic architecture 는 일반적으로 단일 기술 스택에 종속됩니다. MSA 는 각 서비스가 서로 다른 기술 스택을 사용할 수 있어, 새로운 기술을 채택하거나 최적의 기술을 선택하는 데 더 유연합니다.
복잡한 확장 문제: monolithic architecture 에서는 전체 애플리케이션을 확장해야 하며, 이는 비용과 리소스 측면에서 비효율적일 수 있습니다. MSA 는 필요한 서비스만을 타겟으로 확장할 수 있어 효율성이 높습니다.
장애의 영향 최소화: monolithic architecture 에서 한 부분의 실패는 전체 시스템에 영향을 줄 수 있습니다. MSA 는 서비스간의 격리를 통해 장애가 전체 시스템에 미치는 영향을 최소화합니다.
팀의 독립성: monolithic architecture 은 팀 간의 의존성을 증가시킵니다. MSA 는 각 팀이 자신의 서비스에 집중할 수 있게 하여, 더 빠르고 효율적인 개발을 가능하게 합니다.

Monorepo 와 MSA

Monorepo 는 리소스, 의존성 관리 등 코드의 관리에 대한 방법론입니다. MSA 는 이와 달리 아키텍처에 대한 방법론으로, 소프트웨어를 작고, 독립적으로 배포 가능한 서비스로 분할하는 것을 말합니다.

Micro 의 기준은? (분리는 언제 해야할까?)

주변의 백엔드 개발자분들께 여쭤봤습니다. (무려 5시간 전에!)

Q. 마이크로의 기준은 무엇인가요? 저희도 OO 관련 서버는 따로 분리되어 있기는 한데요, 작다고 보기에는 조금.. 애매합니다. 그런데 분리가 되어있긴 한데요, 그렇다면 이 경우도 MSA 라고 볼 수 있는걸까요?

A. 네 맞습니다

DB 를 기준으로 분리한다
처음부터 고려하기보다는 우선은 monolithic 으로 개발하다가 점진적으로 분리한다. 단 적당히 클 때가 아닌, 아주 클 때. 오히려 애매하게 분리하면 보다 복잡해진다.

딱 정해진 기준이 없어, 백엔드 개발자들도 기준이 애매하다고 합니다. 해당 프로젝트에 개발 인원이 10명보다 많아지면 그때 쯤이 나눌 때가 아닐까라는 재미있는 기준도 들었습니다.

참고로 하나의 프로젝트 내에서 이루어지는 것이 아니라 여러 서비스들과 주고받기 때문에, 트랜젝션 문제가 발생할 수 있는 경우가 있다고 합니다.

서비스를 분리할 때에는, DB 도 같이 분리가 됩니다. 예를들어 A 서비스의 a-1 을 rollback 하려는데, 이는 B 서비스의 b-1 을 사용하고 있다고 합니다. 그러면 이 때 a-1 도 rollback 하고, b-1 도 rollback 을 해야 합니다. 즉 각 서비스의 rollback 에 대한 API 가 구현이 되어있어야 한다고 합니다. 실제 production 에서는 사용하는 서비스들도 많고 상황도 복잡하기 때문에 고민이 많은 상황이라고 합니다.

돌아보기

MSA 란 무엇이지?
- Microservice architecture 의 약자
- 하나의 프로젝트에 모든 서비스가 있는 것이 아닌 (Monolithic architecture), 각 서비스는 분리되어 관리되는 것
몇년 전 부터 많이 들어봤다, 언제부터 나온거지?
- 2010년도 초반에 software architect workshop 에서 등장한 것으로, common architecture style 에 microservice 라는 이름을 붙였다.
왜 나오게 된거지? 어디서 제안했지? 기존의 아키텍처와는 어떤 차이가 있는거지?
- 어플리케이션이 커질수록 무거워지는 monolithic architecture 를 개선하기 위해 등장한 것
- 하나의 프로젝트안에 모든 서비스가 있는 monolithic architecture 와 달리, 각 서비스들은 각기 다른 프로젝트로 관리된다.
Monorepo 가 최근에 등장했는데, 이와 대비되는 듯한 개념인 MSA 도 최근에 등장했다. 어떻게 다른거지?
- Monorepo 는 코드쪽, MSA 는 아키텍쳐 쪽.
어디까지가 Micro 인걸까?
- 백엔드 개발자들도 기준이 애매하다고 함, 경험적으로 한다고 함
- 우선은 monolithic 으로 하다가, 많이 커지면 그때부터 점진적으로 분리
- 해당 프로젝트의 개발 인원이 10명이 넘어간다면...
- DB 를 기준으로

Appendix

https://medium.com/@magenta2127/monorepo-vs-multi-repo-vs-monolith-7c4a5f476009 이곳에서 Monolithic architecture 과 monorepo 에 대한 내용만 가져왔습니다.

Monorepo vs Multi-repo vs Monolith

This blog compares advantages and disadvantages of mono repo, multi repo and monolith architecture, and discuss which architecture to…

medium.com

Monolithic architecture

주로 프로젝트의 초기 상태의 구조입니다. 두 가지 특징이 있습니다.

One code base : 하나의 git repo 에 의해 관리
Coupled : 모든 기능, util 과 서비스가 결합되어있음

프로젝트의 모든 코드가 하나의 repo 에서 관리되기 때문에, 모든 기능과 util, 서비스도 하나의 레포 안에서 같이 관리됩니다.

장점
- 하나의 레포 (프로젝트) 에서 관리하므로 개발도 쉽고, 배포, 테스트, 디버깅도 간결함
단점
- 어플리케이션이 커질수록 안좋아집니다.
1. 배포의 속도 느려짐, 작은 변화가 있어도 모든 것을 배포하고 테스트해야되서 불편함
2. 작은 에러가 애플리케이션 전체를 안되게 할 수 있음
3. 모든 컴포넌트, 함수, 서비스로직, 유틸 등 모두가 하나로 결합되어있으므로 개별로 확장이 어려움

디렉토리 구조 예시

├── assets
├── components
│   ├── Button.js
│   ├── Modal.js
│   └── ...
├── node_modules
├── pages
│   ├── Payment
│   │   └── ...
│   │   └── ...
│   ├── Shoping Cart
│   │   └── ...
│   │   └── ...
│   ├── Inventory
│   │   └── ...
├── utils
├── package.json
├── webpack.config.js
├── yarn.lock
└── README.md

Monorepo

여러 프로젝트를 하나의 코드 베이스에서 관리합니다. 즉 레포는 하나지만 각 서비스는 (= 패키지) 분리가 되어있습니다.

장점
- resoure, dependecy 공유가 쉽습니다.
- 공통 의존성은 root 에 설치하면, 다른 프로젝트에서 추가로 다운로드 할 필요가 없습니다.
- 공통으로 의존성을 사용하기때문에, 각 프로젝트는 자신의 것만 가지고 있으면 됩니다. 따라서 보다 가벼워집니다.
단점
- 의존성 관리가 생각보다 잘 안됩니다. 결국 각 프로젝트에서 다른 버전을 다운받는 경우도 자주 생깁니다.
- 레포가 커질수록 pull 이 느려집니다.
- 하나의 프로젝트만 변경된 경우에도 전체 배포를 해야합니다. (단 Lerna 를 통해 변한 것들만 배포할 수도 있음)
- 하나의 레포 안에 모두 존재하기 때문에, 권한을 다르게 주기가 어렵습니다.