기존 : 모노리스(monolith) 아키텍처
쉽게 말하면 기존에는 하나의 코드 베이스에 모두가 달라붙어 기능을 모두 구현하는(...) 구조가 주로 사용되었다.
이러한 아키텍처의 문제는, 점점 커질수록 뭐 하나 마음대로 수정하기가 조심스럽다. (merge하다 conflict도... 문제..)
코드 몇줄 변경에도 전체 서비스를 다시 빌드하고 다시 배포해야 하므로 위험성이 너무 커지는 방법이다.
그러다 보니 어느 곳에서는 새로운 기능의 release가 아예 느려진다고 한다.
그래서 등장한게 마이크로 서비스!
기존 서비스 → 마이크로 서비스
하지만 기존에 이미 있는 서비스를 통째로 마이크로 서비스로 바꾸는 것은 참 난감하다. 특히 인증 절차의 구성이 쉽지 않은데, 이러다보니 결국 1개의 모노리스가 n개의 모노리스로 흩어져버리는 상황이 올 수 있음에도 주의해야한다.
이미 존재하는 큰 서비스에 대해서는 top-down 방식으로 분해해 나가며 마이크로 서비스로 만들거나, 작은 서비스부터 마이크로 서비스로 만들기 시작하는 bottom-up 방식으로 구성할 수는 있겠다.
마이크로 서비스 아키텍처의 특징
- 중앙화된 DB가 없고, 각자의 모듈이 각자의 DB를 갖게 된다.
- 기능별로 나누고, 기능들 사이에 의존성이 없어야 한다.
- RESTful 하게 구성해야 적합하다.
마이크로 서비스 아키텍처의 장점
- 각 모듈은 독립적이므로, 해당 모듈에 가장 잘 맞는 프로그래밍 언어를 자유롭게 선택할 수 있다.
- 각 모듈마다 자신의 DB를 갖고 있기 때문에, 마찬가지로 NoSQL을 선택하든 관계형데이터베이스를 선택하든 그것마저도 자유롭다.
- 따라서, 애플리케이션도 전적으로 폴리글랏하다.
- 개발자는 마이크로서비스의 개발, 관리를 통해 여러 모듈에 대한 방대한 지식을 갖출 수 있다.
- 다기능 멤버들이 서비스를 위해 함께 일할 수 있음
- 개발자들도 폴리글랏해질 수 있다.
*폴리글랏 polyglot : 여러 언어를 사용하여 개발하는 행위 혹은 그 결과물. 특성에 맞추어 적절한 언어를 사용하는 경우.
마이크로 서비스 아키텍처의 단점
- 서비스가 다른 서비스를 호출하는 구조가 될 수 밖에 없는데, 대규모의 프로젝트에서는 서비스 호출을 추적하거나 모니터링 하기가 어렵다.
- 하나의 서비스가 다른 서비스와 REST API를 통해 소통하게 되기 때문에, 단일 프로세스보다 느려질 수 밖에 없다.
- 디버깅이 어렵다.
- 특히 서비스 호출이 다른 서비스를 연속적으로 호출하는 경우.
References
'CS > Software Engineering' 카테고리의 다른 글
| 함수형 프로그래밍의 컨셉과 순수 함수 예시 (0) | 2019.11.09 |
|---|
