MSA(Micro Service Architecture) 마이크로 서비스 아키텍처 개념

마이크로 서비스 아키텍처는 소프트웨어 개발 기법 중 하나로, 

많은 클라우드 시스템 회사들이 출시하는 어플리케이션과 업데이트는 거의 MSA를 위해 맞춰가고 있다고 한다. 

실제 클라우드 시스템에서 제공하는 어플리케이션 또한 Microservices이다. 

Monolithic vs MSA

MSA가 도입되기 전에 Monolithic Architecture가 전통적인 방식의 개발 방법이었다. 

'한 덩어리'라는 뜻의 Monolithic처럼 Monolithic Architecture는 한 덩어리 형태의 구조를 가지고 있다. 

모든 기능을 하나의 어플리케이션에서 비즈니스 로직을 구성해 운영한다.

따라서 개발을 하거나 환경설정에 있어서 간단한 장점이 있어 작은 사이즈의 프로젝트에서는 유리하지만, 시스템이 점점 확장되거나 큰 프로젝트에서는 단점들이 존재한다.

 

단점

빌드/테스트 시간의 증가

• 하나를 수정하기 위해선 시스템 전체를 빌드해야 한다. 
• 이러한 문제로 유지보수가 힘들다

작은 문제가 시스템 전체에 문제를 일으킴

• 하나의 서비스 부분에 트래픽 문제로 서버가 다운되면 모든 서비스 이용이 불가능하다.

확장성에 불리

• 하나의 서비스 부분에 트래픽 문제로 서버가 다운되면, 모든 서비스 이용이 불가능하다.

 

MSA는 이를 보완하여 좀 더 세분화된 아키텍처이다. 

한꺼번에 로직을 구성하던 이전 방법과는 다르게 기능/목적별로 컴포넌트를 나누고 조합할 수 있도록 구축한다. 

 

컴포넌트란?
▶️ 재사용이 가능한 각각의 독립된 모듈

 

MSA

MSA에서 각 컴포넌트는 API를 통해 다른 서비스와 통신을 하는데, 모든 서비스는 각각 독립된 서버로 운영하고 배포하기 때문에 서로 의존성이 없다.

하나의 서비스에 문제가 생겨도 다른 서비스에는 영향을 끼치지 않으며, 서비스 별로 부분적인 확장이 가능한 장점이 있다.

 

하지만, 모노리틱 아키텍처가 하나의 프로세스 내에서 서비스간의 호출이 이루어지므로 속도가 빠르지만

MSA는 서비스간 호출을 API통신을 이용하기 때문에 속도가 느리고, 통신에 사용하기 위해 값을 데이터 모델로 변환시켜주는 오버헤드가 발생할 수 있다. 

 

특징

데이터 분리

• 서비스 별 별도의 데이터 베이스를 사용
  • 의존성이 없이 서비스를 독립적으로 개발 및 배포/운영 가능
  • 다른 컴포넌트의 데이터를 API통신을 통해 가져와야 하기 때문에 성능상의 문제가 발생 할 수 있고, 트렌젝션으로 묶을 수 없는 문제가 발생
  • 한 트랜젝션의 처리 및 각각의 어플리케이션 에러에 대한 처리가 필요
  • 어플리케이션의 숫자가 많아질수록, 복잡해질수록 테스트가 어려워짐
  • 각각 어플리케이션의 데이터의 무결성이 발생할 수 있음

API Gateway

각 서비스가 다른 서버에 분리 배포되어있기 때문에 서버 URL이 각기 다르다.

API Gateway는 API 서버 앞 단에서 모든 API 서버들의 End-Point를 단일화하여 묶어주는 역할을 한다.

이러한 역할로 인해 서비스간의 API호출 구조도 단순화 시켜준다.

그 외에 라우팅, 로드밸런싱, 인증 역할 등등 여러 역할을 수행한다. 

 

Endpoint란?
API가 서버에서 리소스에 접근할 수 있도록 가능하게 하는 URL이다.
서비스를 이용할 때 사용하는 커뮤니케이션 채널의 한쪽 끝에 해당하는 URL.

 

서비스별로 분리를 하면서 얻을 수 있는 장점도 있지만,

그만큼 체계적으로 준비돼 있지 않으면 MSA로 인해 오히려 프로젝트 성능이 떨어질 수도 있다.