[MSA] MSA란 무엇일까?

목차

1. 모놀리식(Monolithic) 방식(AS-IS)

2. MSA 방식(TO-BE)

3. Monolithic? MSA?

4. MSA방식 성공의 핵심 요소

 

 

 

 

 

1. 모놀리식(Monolithic) 방식(AS-IS)

:하나의 애플리케이션이 하나의 거대한 아키텍처를 가지는 방식

 

장점

단순성

모든 코드가 모여있어서 변경 사항이 발생할 경우 필요한 모든 코드가 한 곳에 존재한다. 그래서 테스트와 디버깅이 간단하다.

 

간편한 배포

단일 프로젝트로 배포하면 되기 때문이 간단하다. 새로운 기능이 추가되거나 버그가 수정될때마다 애플리케이션을 배포하면 된다.

 

보편성

대부분의 개발자가 모놀리식 방식으로 개발하기 때문에 익숙함이 높아 프로젝트를 쉽게 시작할 수 있다.

 

쉬운 모니터링

오류 발생시 문제가 발생한 위치를 식별하기 쉽다

 

단점

효율성

- 수정사항이 생기면 전체를 재빌드하고 재배포해야 함(규모가 커지면 구동시간 증가)

특정 오류가 서버 전체에 영향을 줌

부분적인 서버의 장애가 전체 장애로 번질확률이 높다.

 

 

 

2. MSA 방식(TO-BE)

: 하나의 큰 애플리케이션을 여러개의 작은 애플리케이션으로 쪼개어 변경과 조합이 가능하도록 만든 아키텍처. 각 서비스가 서로 독립적으로 작용하며 기술과 언어에 구애받지 않고 각각 고유한 DB를 사용할 수 있다.

 

장점

유연한 확장

각 서비스를 독립적으로 확장할 수 있다.

 

독립적인 배포

하나의 서비스만 배포할 수 있다. 한 서비스를 업데이트할 때 전체 서비스를 멈출 필요가 없다.

 

전체 서비스 중단 위험 감소

특정 서비스가 중단되더라도 전체 애플리케이션에 영향을 미치지 않고, 해당 서비스에만 영향을 받는다.

 

다른 DB를 소유 가능

서비스별로 다른 DB를 사용할 수 있다. 각 서비스에 맞는 DB를 사용해 개발이 가능하다.

 

민첩성

새로운 것을 추가할 때 전체 어플리케이션에 큰 영향을 주지 않기 때문에 새 버전을 배포하는 것에 대한 부담이 적다.

 

단점

난이도

여러 서비스 중 하나의 서비스에게 새로운 기능을 구현해야 할 때, 다른 서비스에서 접근할 수 있도록 환경을 갖춰줘야 한다.

 

디버깅

디버깅이나 테스트를 위해서는 둘 이상의 서비스를 실행해야 해서 디버깅이 어려울 수 있음.

 

표준화 부족

공통 플랫폼이 없다. 서비스에서 발생하는 오류나 문제를 모니터링 할 수 있는 모니터링 체계를 갖추는 게 필요할 수 있다.

 

 

 

3. Monolithic? MSA?

모놀리식이 추천되는 경우

규모가 작은 애플리케이션일 때

복잡한 시스템 설계 및 관리가 필요하지 않을 때

 

MSA가 추천되는 경우

계속 성장중인 애플리케이션일 때

도메인에 대해 잘 알고 있거나, 요구 사항이 명확한 경우

복잡한 애플리케이션이 될 수 있고 서비스 간 영향을 최소화하고 싶을 때

 

 

 

 

4. MSA방식 성공의 핵심 요소

서비스 분리

목표설정 -> 서비스 분리 -> 평가 검증 -> 서비스 설계

 

서비스 아키텍처 설계

서비스가 독립성을 가질 수 있도록 아키텍쳐를 설계하고 구상 (API 우선설계)