서론
일반적으로 프로젝트를 개발하면 한 프로젝트 파일을 만들어서 관리한다. 이러한 일반적인 구조를 모놀리식 구조라고 하는데, 이와 다르게 서비스별로 프로젝트를 생성해서 이를 관리하는 MSA (Microservice Archtiecture) 구조도 존재한다. 대표적으로 아마존과 넷플릭스가 MSA를 사용한다고 알려져있다.
이전에 진행한 프로젝트를 MSA구조로 개발했는데 복습겸 정리해볼려한다.
모놀리식(Monolithic) vs 마이크로서비스(Microservice)
Monolithic Architecture
모놀리식 구조는 한 프로젝트 파일에 모든 구성요소를 넣어 개발하는 구조를 의미한다. 전통적인 방법이다.
- 장점
- 상대적으로 운영하기 용이하다. => 프로젝트 파일이 하나이므로, 관찰 대상이 하나이다.
- 내부 메소드 호출로 성능 문제 없다, MSA는 서비스간에 메소드는 API를 통하여 호출한다.
- 주로 단일 DB를 사용하며, 트랜잭션 관리가 용이하다.
- 단점
- 빌드 및 배포를 하는데도 굉장히 사이즈가 크다보니 엄청 오래 걸릴 수 있다. 이는 작은 수정 사항에도 배포가 부담스러울 수 있다.
- 코드 수정시 변경 영향이 어디까지 미치는지 파악하기가 너무 어렵다. => 에러 하나가 났는데, 전체 서비스가 다운될수도 있다.
정리해보자면, 모놀리식 구조는 모든 요소가 응집되어있기에 관리가 편할 수 있으나, 무겁다는 단점이 있으며 그 규모가 커지면 에러대응에도 힘들다는 것을 알 수 있다.
Mircoservice Archtiecture
마이크로서비스 구조는 모놀리식 구조의 단점을 보완하기 위해 등장한 구조이다. 모놀리식과 다르게 서비스에 따라 프로젝트를 여러개를 나누어 개발한다.
- 장점
- 빠른 배포가 가능하다. (서비스 단위로 자율적, 독립적 배포 가능)
- 서비스는 작기 때문에 코드 수정에 대한 영향범위가 상대적으로 적다.
- 탄력적이고 선택적인 확장 (작은 서비스 단위로 확장이 가능하다.)
- 일부의 장애가 시스템 전체 장애로 이어지지 않는다.
- 결과적으로 빠르게 변화하는 비즈니스 환경에 민청하게 대응 가능
- 서비스에 맞춰 고유한 언어 및 프레임워크 선택이 가능하다.
- 단점
- 서비스와 그에 따른 언어나 프레임워크의 종류가 많아져서 모니터링 할 대상이 많아진다. (자바/스프링만 사용했다가, 자바/스프링/노드/익스프레스 ... 등 다양하게 사용할수록 부하가 커진다.)
- MSA는 각 서비스에서 각각의 DB를 사용한다. 따라서 이러한 분산환경에서는 DB트랜잭션 처리가 어렵다.
요약해보면, MSA는 모놀리식의 집중구조에서 벗어나 역할에 맞게 프로젝트를 나누어서 그를 하나의 서비스로 운영하는 구조이다. 우리가 클래스나 함수를 나누듯이 말이다. 나눔으로써 배포나 확장성면으로는 이점을 얻으나, 나눔으로써 얻는 부하도 필히 존재한다.
MSA 의 핵심 및 특징
서비스간의 낮은 결합도
MSA 구조를 이루는 핵심은 "서비스간 매우 낮은 결합도" 이다. 만약 서비스간에 결합도가 높으면 어떻게 될까? A서비스에 기능을 추가하고, 재배포를 할려고 했는데 A서비스와 B서비스간에 연결된 로직이 존재해서, B서비스도 다시 빌드를 해야하는 상황이 발생할 수 있다. MSA는 서비스간에 영향을 끼치지 않음으로써 독자적으로 행동할 수 있기에 등장한 구조이기에 이 부분을 간과하면 안된다. 자칫하면 분산된 모놀리식 구조가 될수도 있다.
분산된 관리체제
MSA는 서비스마다 다른 언어나 프레임워크를 사용할 수 있다. 따라서 중앙에 강력한 표준이나 절차를 강요하기 보다는, 팀이나 서비스에 따라 알맞은 언어나 프레임워크를 사용하며 유연하게 대처하는것이 좋다.
데이터관리
서비스는 서비스별로 각각의 DB를 지니며, 각 서비스들은 다른 서비스의 데이터에 접근하기 위해서 API를 활용하는 것이 좋다. 만약 다이렉트로 다른 서비스의 DB에 접근한다면 서비스간 (DB간) 의 결합도가 높아질 위험성이 있다.
클라우드 환경
MSA는 확장성에 초점이 맞춰져 있는 구조인 만큼, 서버의 증설또한 클라우드로 관리되어 실시간으로 확장할 수 있어야 한다. 그리고 이에 따른 실시간 모니터링 기술도 필히 뒤따라야 할 것이다.
API Gateway Pattern
API Gateway는 여러 서비스들의 엔드 포인트를 단일화 해주고, 공통로직을 처리하는 등 MSA에서 사용하는 패턴이다. 아래 사진을 한 번 보자.
MSA 구조에 맞게 서비스가 많아지고, 각 서비스에 유저가 다이렉트로 접근한다고하면 고려해야할 문제점들이 많아진다.
각 서비스에 맞춰 인증/인가 처리를 해줘야하며(코드의 중복이 무수히 발생할 것이다.), 수많은 API를 다뤄야하는 복잡함도 생긴다. 이러한 문제점을 해소하기 위해서 중간에 API Gateway 라는 서버를 하나 둔다.
서비스로 바로 직행하지 않고, 유저의 요청을 Gateway에서 확인하고, 마이크로서비스로 라우팅을 진행해줌으로 그 구조를 간략화 시켜준다.
- 장점
- 인증/인가 등 공통 로직을 처리할 수 있다.
- 요청이 단순화 된다. 클라이언트는 API Gateway로만 요청하면 된다. 이로써 클라이언트와 백엔드의간의 API 통신을 최소화 할 수 있다.
- 각 서비스들로 라우팅 및 로드밸런싱을 처리해준다.
- 단점
- 결국 중간에 서버를 하나 더 두는 시스템이므로 네트워크 지연이 일어날 수 있다.
- 들어오는 요청에 비하여 게이트웨이의 scale out이 적절히 이루어지지 않는다면, 게이트웨이에서 병목 현상이 일어날 수 있다.
개발 레퍼런스
'🔬아키텍처/- Microservice Architecture' 카테고리의 글 목록
백엔드 개발자 장원익의 기술 블로그
wonit.tistory.com
MSA 제대로 이해하기 -(3)API Gateway
지난 포스팅에서 MSA를 구성하는 아키텍처 요소에 대해 살펴보았습니다. Inner Architecture와 Outer Architecture로 나누어 설명을 드렸었죠. MSA 제대로 이해하기 - (2)아키텍처 개요 오늘은 그 중 Outer Archit
velog.io
'개발' 카테고리의 다른 글
| Nest JS 프로젝트 배포 자동화 하기 (2) - docker 설치 (0) | 2023.10.30 |
|---|---|
| Nest JS 프로젝트 배포 자동화 하기 (1) - jenkins, webhook (0) | 2023.10.29 |
| 쿠키 / 세션 / 토큰(JWT) 의 차이는? (0) | 2023.09.27 |
| [Typescript] Path alias (import 경로 단축) (0) | 2023.09.19 |
| TypeScript는 왜 사용하는 걸까? (0) | 2023.09.11 |