MSA?

MSA를 알기전에 기존의 체계에 대해 먼저 알아 보자.

 

Monolithic Architecture?

• 소프트웨어의 모든 구성요소가 한 프로젝트에 통합되어 있는 형태이다.
• 웹 개발을 예로 들면 웹 프로그램을 개발하기 위해 모듈별로 개발을 하고, 개발이 완료된 웹 어플리케이션을 하나의 결과물로 패키징하여 배포되는 형태를 말한다.(SSAFY에서 진행한 프로젝트 들?) 
• 이런 어플리케이션을 모놀리식 어플리케이션이라 하며, 웹의 경우 WAR파일로 빌드되어 WAS에 배포하는 형태를 말한다.
• 주로 소규모 프로젝트에서 사용된다.
• 하지만 일정 규모 이상의 서비스, 혹은 수백명 이상의 개발자가 투입되는 프로젝트에서 Monolithic Architecture는 한계를 보인다. 

 

Monolithic vs Micro-Service

MSA ?

• Micro Service Arcitecture의 약자이다.
• 현재 마이크로서비스 아키텍처에 대한 정확한 정의는 없다고 한다. 하지만 마이크로 서비스란 작고, 독립적으로 배포 가능한 각각의 기능을 수행하는 서비스로 구성된 프레임워크라고 볼 수 있을 것같다..
• MSA는 API를 통해서만 상호작용할 수 있다. 즉, 마이크로 서비스는 서비스의 end-point(접근점)을 API 형태로 외부에 노출하고, 실질적인 세부 사항은 모두 추상화한다. 내부의 구현 로직, 아키텍처와 프로그래밍 언어, 데이터베이스, 품질 유지 체계와 같은 기술적인 사항들은 서비스 API에 의해 철저하게 가려진다. 

 

MSA의 특징

• 전체 Application을 특정 목적을 가진 Application 단위로 나누어 서비스 구조를 갖추는 것이다. 
• MSA의 슬로건은 '한가지 일을 잘하자!'로, MSA의 목적은 단일 비즈니스단위 처리를 잘하는 것이다.
• 전체를 각 목적마다 나누기 때문에 Application의 결합도는 약해지고 응집도는 강해져 보다 나은 프로그램으로 개선할 수 있다.
• 잘 정의된 API를 통해 통신하고 결과물을 신뢰할 수 있어야 한다.
• 다른 기술 스택(개발 언어, 데이터베이스 등)이 사용 가능한 단일 사업 영역에 초점을 둔다.
• Application 단위로 독립 배포가 가능하다.
• 어플리케이션 출시처럼 하나의 목표를 향해 일하지만 자기가 개발하는 서비스만 책임진다. (단일 책임 원칙)
• 여러 어플리케이션에서 재사용할 수 있어야 한다.
• 마이크로서비스는 각각 서비스의 부하에 따라 개별적으로 scale-out이 가능하다. 메모리, CPU적으로 상당부분 이득이 된다.

MSA의 단점

• 한 트랜잭션당 처리, 각 Application의 처리가 가능해야 한다.
• 구조가 복잡해질 수록 테스트 코드 작성이 어려워진다.
• 구조가 많아질 수록 Network의 레이턴시와 트래픽이 증가한다.
• 배포자동화가 필수적이다.
• 데이터의 무결성을 책임지지 못한다.

 

 

 

 

 

 

 

 

 

 

 

출처: https://wooaoe.tistory.com/57 [개발개발 울었다]