Today I Learned
오늘은 평소에 알고는 있었지만 자세히는 몰랐던 MSA에 대해 정리해보고자 한다.
모놀리틱 아키텍처
MSA와는 반대로 전체 애플리케이션을 하나의 단일 단위로 개발, 배포하는 방식. 모듈 별로 개발을 하더라도 하나의 결과물로 패키징하여 애플리케이션의 모든 구성요소가 하나의 코드베이스 내에 통합된다.
-
모놀리틱 방식은 로컬 환경에서 개발하기도 편리하고 통합 테스트를 수행하기도 쉬우며 배포도 간단하다.
-
하지만, 서비스가 성장함에 따라 규모가 커지면서 서비스의 복잡도가 커지면 문제가 발생한다. 간단한 기능을 추가하고싶어도 많은 코드를 수정해야할 수도 있고, 코드의 변화가 영향을 끼치는 범위가 증가된다.
-
이 외에도 배포시간의 증가, 부분적 Scale-Out의 어려움, 유지보수의 어려움, 기술 스택의 다양성 부재 등의 단점이 따라온다.
MSA (Microservices Architecture)
전체 소프트웨어 시스템을 특정 목적을 가진 작은 독립적인 서비스들로 나누는 아키텍처 패턴
-
각 마이크로 서비스는 특정한 업무 기능을 수행하고 해당 도메인에 대한 책임만 가진다.
-
각 마이크로 서비스는 크기만 작을 뿐 각각이 하나의 모놀리틱 아키텍처와 유사하다.
-
서로 다른 마이크로 서비스 간에는 독립적으로 개발, 배포, 운영된다.
개발 언어 또한 달라도 상관이 없다.
각 서비스 마다 독립적인 DB, 런타임환경, 개발 팀을 가질 수 있다.
모놀리틱 vs MSA
- 확장성
- 모놀리틱은 애플리케이션의 전체 스케일을 확장해야 하므로, 부분 확장이 어려울 수 있다.
- MSA는 각 마이크로 서비스 단위로 확장이 가능하므로 특정 부분만 확장해 자원을 효율적으로 사용할 수 있다.
- 유지보수
- 모놀리틱은 모든 코드가 단일 코드베이스에 있기 때문에 변경 및 유지보수가 어려울 수 있다.
- MSA는 독립적으로 관리되므로 유지보수 및 변경이 용이하다.
- 배포
- 모놀리틱은 한 번에 배포할 수 있는 장점이 있지만, 반대로 작은 수정사항에도 전체 애플리케이션을 다시 배포하거나 중단해야하는 단점이 있다.
- MSA는 독립된 마이크로 서비스만 배포할 수 있어 수정된 부분만 업데이트가 가능하다.
- 기술 다양성
- 모놀리틱은 모든 구성요소가 동일한 기술 스택을 공유해야한다.
- MSA는 독립적으로 기술 스택을 사용해 더 다양하고 필요한 기술만 사용이 가능하다.
- 상호 통신
- 모놀리틱은 내부 프로시저(함수 호출)로 구성요소간 통신이 가능하다.
- MSA는 일반적으로 HTTP프로토콜 기반 REST API 호출이나, kafka를 이용한 message stream을 이용한다.
- 데이터 관리
- 모놀리틱은 하나의 DB로 관리한다.
- MSA는 서비스마다 자체 DB를 사용할 수 있다.
MSA의 주요 과제
-
복잡성 관리
MSA가 전체적인 시스템 상 오히려 더 큰 복잡성을 불러올 수 있다. 서비스 간의 통신, 데이터 일관성, 버전 관리 등 다양한 복잡성을 효과적으로 관리해야한다. -
테스트와 디버깅
모놀리틱에 비해 통합 테스트가 어렵다. 각 서비스 간의 상호작용 및 문제 해결이 복잡해진다. 디버깅 및 테스트 전략을 정의하고 구현해야 한다. -
모니터링과 로깅
다수의 마이크로서비스를 모니터링하고 로깅해야 한다. 이로인해 데이터 양이 폭증할 수 있으니, 효과적인 로깅과 모니터링이 필요하다. -
비용
독립적인 개발팀, 서버 및 인프라 관리에 따른 비용이 증가할 수 있다. 비용 효율적인 전략을 고려해야 한다. -
배포
실제 운영환경에 대해 마이크로서비스 한 개만 재배포할 경우 다른 서비스들과의 연계가 정상적으로 잘 이루어지는지 확인해야한다. -
장애 발생
통신이나 서버의 장애가 발생할 경우 내부 시스템의 통신에 어떻게 트랜잭션을 유지할 지 결정하고 구현해야 한다. 실패 발생시 오류를 핸들링 하는 범위도 고려해야 한다. -
데이터 관리
서비스 별로 DB를 독립적으로 운영하되, 공통의 데이터에 있어 데이터 무결성을 유지해야 한다.
