#모놀리식 #Monolithic #MSA #아키텍처 #탄생배경

기존 모놀리식(Monolithic) 아키텍처형식의 단일 애플리케이션으로 모든 기능을 구현하는 방식이다. 

이 방식의 장점은 초기 개발이 빠르고, 하나만 배포를 하니 배포, 테스트가 간단하고, 함수 호출로 기능이 연결되어 성능이 좋은 부분이다. 하지만 서비스가 커지면서 MSA라는 개념을 염두해야한다. 

 

MSA란? 

Micro Service Architecture로 작은 아키텍처 서비스? 라고 볼수 있다.

MSA가 등장한 이유는 모놀리식이 커지면서 발생하는 이슈때문이라고 볼수 있다. 

1. 작은 수정에도 전체를 다시 배포해야한다. 
	-> 알람 문구 한줄만 바뀌어도 애플리케이션을 다시 빌드 및 배포를 해야한다.

2. 하나가 죽으면 전체가 죽는다. 
	-> 결제 모듈의 메모리 누수 발생시 회원, 주문, 회원가입 등 서비스가 마비 된다. ( 즉 장애 경리가 안된다. ) 

3. 부분만 확장할 수 없다. 
	-> 트래픽이 몰리는 주문 기능에 대한 확장이 비효율적이다. (전체를 복사해야하기 때문에 자원 낭비 발생 ) 

4. 기술 스택이 묵여버린다. 
	-> 전체 프레임 워크가 하나라서 모듈별 다른 언어로의 개발 시도가 불가하다. 

5. 코드가 커질수록 팀이 서로를 막는다. 
	-> 여러 개발자가 코드 베이스를 건드리니 충돌, 의존성이 폭발하고, 빌드 시간도 길어짐

 

이러한 모놀로식 이슈들로 인해 MSA아키텍처를 통한 구현이 많아진다. MSA란 

애플리케이션을 독립적으로 배포 가능한 작은 서비스들의 집합으로 나누는 방식으로 각 서비스는 자기만의 코드, 자기만의 DB를 가지는 것이 보편적이다. 

구분	모놀리식	MSA
배포단위	전체를 한 번에	서비스별 독립 배포
확장(스케일)	앱 전체 복제	필요한 서비스만 확장
장애 영향	전체로 전파	해당 서비스로 격리
기술 스택	통일(묶임)	서비스별 자유
DB	보통 단위 DB공유	서비스별 분리
개발 초기 속도	빠름	느림(설계 비용 큼)
운영 복잡도	낮음	높음(모니터링, 통신, 분산)
적합한 시점	초기/소규모	대규모, 다팀 조직

 

이렇게 모놀로식과 MSA간의 장단점이 있는건 분명한 사실이다. 각 요구 사항과 상황에 맞게 구성을 해야할 필요할것 같다. 

MSA라고 해서 서비스간 네트워크 통신 지연, 실패처리, 분산 트랜젝션, 데이터 정합성, 모니터링, 로깅, 추적이 복잡하기도하고 

인프라 운영이 부담되기도 하다.

 

그래서 시작에서는 모놀로식으로 가되 부하가 발생하는 서비스는 MSA로 구현하여 트래픽대응과 상황 대응을 하는 전략을 세워볼 필요가 있을것이다.