MSA

Dal.001·2022년 11월 30일

Services architecture data msa

서버

목록 보기

5/5

오늘은 MSA 패턴에서 대해서 알아보고자 한다

MSA란?

MSA는 Micro Service Architecture의 줄인 말로, 하나의 서비스를 여러가지 작은 서비스의 조합으로 만드는 것을 말한다.

보통 작은 프로젝트에서는 Monolotical한 아키텍쳐를 많이 사용한다.
모놀리틱하다는 것은, 모든 기능이 하나 구조에 들어있는 것을 말한다.

이런 모놀릭한 환경에서는 작은 변경 사항들이 있을 때마다 전체 서버를 다시 배포해야한다.
그리고 이 말은 다르게 말하면, 한 부분의 장애가 생기면 서버 전체에 영향이 생긴다는 의미다.

이런 모놀리틱한 아키텍쳐의 단점을 보안하기 위해 MSA 아키텍쳐가 등장했다.
MSA 아키텍쳐는 작은 서비스 단위로 쪼개진, 여러개의 서비스가 모여 하나의 단일 어플리케이션을 이루는 방식을 말한다.

MSA도 겉에서 보기에는 동일하게 작동한다.
모놀리틱한 어플리케이션 처럼, 단일 진입 지점을 가지고 클라이언트나 다른 서비스와 소통 할 수 있어야 한다.

일종의 블랙박스 모델처럼 동작한다는 말이다.
아키텍쳐와는 무관하게 클라이언트는 서버와 API를 주고 받을 수 있어야 한다.

그렇기 위해서 서버는 서비스 간에 통신 및 연결을 만들고 이들을 엮어서 연결 지점을 형성한다.

MSA 장점

1. 배포 구조 개선
앞서 말했듯이, 모놀리틱한 구조에서는 모든 변경사항이 생길 때마다 전체 서버를 다시 배포해야만 하는 문제가 있었다.

하지만 MSA 형식에서는 각 서비스 별로 별도로 배포 할 수 있기 때문에, 전체 서버가 매번 전부 배포되야하는 상황을 피할 수 있다.

또한 개별 배포되기 때문에 배포 시간도 크게 절약할 수 있다.

2. 장애의 확산 방지
모노리틱한 서버에서 장애의 발생은, 서비스 전체의 장애로 이어진다.

하지만, MSA 형식에서는 장애가 이러나도 다른 서비스로 장애가 번지지 않을 수 있는 장점이 있다.
물론 연관된 서비스에 영향이 있을 수 있지만, 모놀리틱한 환경보다는 미치는 영향이 덜하다.

3. Scale Up/Out
서비스 도중에 트랙픽이나 리소스 증가로 Scale Up/Out 시켜야하는 경우가 있다.
이때 모놀리틱한 아키텍쳐에서는 서버 전체를 Scale Up/Out 시켜야 한다.

하지만 MSA를 사용하면, 서비스 별로 나눠서 Scale Up/Out 할 수 있다.

예를 들어, 당근마켓 서비스 중에 갑자기 채팅 관련 부분만 이용량이 크게 증가했다고 하자.
이런 상황에서 상품 등록 등의 서비스는 그대로 유지하고, 채팅 관련 서비스만 Scale Up/Out 시켜서 효율적으로 서비스를 운용할 수 있다.

4. 다양한 환경 사용가능
MSA에서 각 서비스는 다른 서비스의 환경에 종속적이지 않기 때문에, 서로 다른 framework나 언어를 사용할 수 있다.

예를 들어, 특정기능은 Spring framework를 사용해서 쉽게 구현할 수 있지만, 다른 부분은 Node.js를 사용했을 때 오는 이점이 크다면, 서비스를 분리해서 운영 할 수 있는 것이다.

MSA 단점

1. 배포 어려움
위에서는 배포의 장점에 대해 서술했지만, MSA는 배포 과정에 장점만 있는 것은 아니다.
오히려 MSA를 사용함으로 배포가 더 어려워지는 경우도 있다.

MSA 내부의 서비스는 독립적으로 존재한다고 하지만, 논리적으로 완전히 독립된다는 것은 말이 안된다.
각 서비스들은 모여서 하나의 어플리케이션을 이뤄야하기 때문에, 서로 논리적을 연결되어 있을 수 밖에 없다.
어떤 서비스는 다른 서비스에 종속성을 가지고 있을 수도 있고, 특정 배포가 다른 부분에 영향을 미칠 수도 있다.

이렇기 때문에 한 서비스의 배포가 오히려 더 복잡하고 고려할 사항이 많아질 수 있다.
서로 서비스 간의 배포 순서나 버전이 맞지 않아 분기 처리를 해야 될 수도 있다.

2. 테스팅 복잠함
MSA에서의 테스팅은 양날의 검과 같은 면을 가진다.

각 서비스가 구분되어 있기 때문에, 유닛 테스트나 기능별 테스트가 더 효율적으로 진행 될 수 있다.

하지만, 통합 테스트는 반대다.
서로 구분되어 있는 탓에, 전체 서비스의 통합 테스트는 모놀리틱한 구조보다 더 어려워진다.
한 서비스에서의 변경사항이 다른 서비스에 미치는 영향까지 완벽하게 테스팅 하지 못하고 배포해야 할 수도 있다.

3. 개발 난이도
MSA 형태는 모놀리틱할 때보다 개발 난이도가 더 높다.

각각의 서비스의 연결 관계 및 데이터 관리가 필요하다. 또한 서비스를 연결하고 배포하는 인프라도 더 복잡해질 수 밖에 없다.

쿠버네티스를 활용한 도커 컨테이너들의 오케스트레이션이 필요하기도 하고, 상호 통신을 위한 메세지 큐의 관리도 필요하다.
또한 API 게이트 웨이등 인프라 아키텍쳐 설계가 중요하기 때문에, 관리 및 개발 난이도가 모놀리틱한 아키텍쳐보다 어렵다.