마이크로 서비스 아키텍처 (MSA)

MSA란 소프트웨어 개발 기법 중 하나로, 어플리케이션 단위를 목적으로 나누는 것

 

Monolithic vs MSA

MSA가 도입되기 전, Monolithic 아키텍처 방식으로 개발이 이루어졌다.

한 덩어리에 해당하는 구조로 이루어진 Monolithic은 모든 기능을 하나의 어플리케이션에서 비즈니스 로직을 구성하여 운영한다. 따라서 개발을 하거나 환경설정에 있어서 간단한 장점이 있어 작은 사이즈의 프로젝트에서는 유리하지만 시스템이 점점 확장되거나 큰 프로젝트에서는 단점이 존재한다.

• 빌드/테스트 시간 증가 : 한가지 수정사항이 있어서 시스템 전체를 빌드해야 한다. 즉 유지보수가 힘들다.
• 작은 문제가 시스템 전체에 문제를 일으켜서 만약 하나의 서비스 부분에 트래픽 문제로 서버가 다운되면 모든 서비스 이용이 불가하다.
• 확장성이 불리하여 서비스를 확장하기 위해 전체 프로젝트를 확장해야 한다.

MSA는 좀더 세분화 시킨 아키텍처로 기능별로 컴포넌트를 나누고 조합할 수 있도록 구축한다.

 

 

	마이크로 서비스 아키텍처	Momolithic 아키텍처
단위 설계	애플리케이션은 유연하게 결합된 서비스로 구성 각 서비스는 단일 비즈니스 작업을 지원	전체 애플리케이션은 단일 단위로 설계되고 개발 및 배포된다.
기능 재사용	모든 클라이언트에 해당 기능을 표시하는 API를 정의	애플리케이션 간 기능 재사용 기회가 제한
애플리케이션 내의 통신	서로 통신하기 위해 요청-응답 통신 모델 사용 HTTP 프로토콜을 기반으로한 REST API 호출을 사용	내부 프로시저는 애플리케이션 구성요소 간의 통신을 용이하게 해준다. 내부 프로시저 호출 수를 제한할 필요는 없다.
기술 유연성	각 마이크로 서비스는 마이크로 서비스가 해결하도록 설계된 문제에 가장 잘 맞는 프로그래밍 언어 및 프레임워크를 사용하여 개발	전체 응용 프로그램은 단일 프로그래밍 언어로 작성
데이터 관리	분산화 자체 데이터베이스를 사용	중앙 집중식 전체 응용 프로그램에서는 하나 이상의 데이터베이스를 사용
배치	응용 프로그램의 다른 마이크로 서비스에 영향을 주지 않고 독립적으로 배치	변경하게 되면 전체 애플리케이션을 재배포하고 재시작해야 한다.
유지 관리 기능	단순하고 집중적이며 독립적 쉽게 유지 관리 가능	애플리케이션 범위가 증가하면 코드가 복잡
복원성	애플리케이션 기능이 여러 서비스에 걸쳐 분산된다. 마이크로 서비스가 실패한 경우 다른 마이크로 서비스에서 제공하는 기능을 계속 사용할 수 있음	구성 요소의 오류는 전체 응용 프로그램의 가용성에 영향
확장성	각 마이크로 서비스는 다른 서비스와 독립적으로 확장 가능	비즈니스 요구사항이 애플리케이션의 특정 부분만 스케일링하기 위한 경우에도 전체 애플리케이션의 스케일을 조정해야 함

MSA에서 각 컴포넌트는 API를 통해 다른 서비스와 통신하는데 모든 서비스는 각각 독립된 서버로 운영하고 배포하므로 서로 의존성이 없다. 하나의 서비스에 문제가 생겨도 다른 서비스에는 영향을 끼치지 않으며 서비스 별로 부분적인 확장이 가능

 

---

서비스별로 개발팀이 꾸려지면 다른 팀과 의존 없이 팀 내에서 피드백을 빠르게 할 수 있고 비교적 유연하게 운영이 가능할 것.

다만 MSA는 서비스 별로 호출할 때마다 API로 통신하므로 속도가 느리고 데이터에 맞추는 과정이 필요하기도 하다. 그래서 Monolithic 방식은 하나의 프로세스 내에서 진행되므로 속도면에선 MSA보다 훨씬 빠를 것이다.

 

MSA는 DB또한 개별적으로 운영되기에 트랜잭션으로 묶기 힘든 단점도 존재한다.

 

 

그래서 서비스별로 분리 하면서 얻는 장점도 있지만 체계적으로 준비돼 있지 않으면

MSA로 인해 오히려 프로젝트 성능이 떨어질 수 있다는 점을 명심해야 한다.