모놀리식 아키텍처와 마이크로 서비스 아키텍처 비교
모놀리식 아키텍처 (Monolithic Architecture)
모놀리식 아키텍처는 전통적인 개발 방식으로 하나의 프로젝트에 모든 기능을 함께 포함한다.
이렇게 하면 코드 베이스가 커질수록 개발 및 배포에 복잡성이 증가한다.
아래는 모놀리식 아키텍처의 예시이다.
모놀리식 아키텍처의 경우 위의 그림과 같이 모듈단위로 쪼개는 것이 아닌 하나의 프로젝트로 전체 애플리케이션을 묶어서 개발하는 방식이다. 이의 경우 회원, 상품, 주문뿐만 아니라 여러 개의 비즈니스 로직이 추가된다면 코드베이스가 커지게 되는 구조이다.
모놀리식 아키텍처의 장단점
1. 장점
- 초기 개발에 유리하며 빠르게 프로토타입을 개발할 수 있다.
- 즉, 개발 초기에 단순한 아키텍처 구조로 인해 개발에 용이하다.
- 필요한 모든 기능을 한 번만 호출하기 때문에 복잡한 통신 없이 직접 사용할 수 있다.
- 어떤 서비스든지 개발되어 있는 환경이 같아서 복잡하지 않다.
- 배포가 간단하다.
- 확장성이 쉽다.
- 로드밸런스를 이용하여 로드 부하를 나눠 가지는 방식으로 진행한다.
- 쉽게 고가용성 서버 환경을 만들 수 있다.
- End-to-End 테스트가 용이하다.
- 손쉬운 모니터링, 디버깅이 가능하다.
2. 단점
- 코드 베이스가 커질수록 복잡해지고 유지관리 및 확장이 어려워진다.
- 즉, 많은 양의 코드가 몰려 있어서 개발자가 모든 코드를 이해하기 힘들며, 유지 보수가 어렵다.
- 일부 기능을 수정하거나 업데이트를 하려면 전체 애플리케이션을 재배포해야한다.
- 프로젝트의 규모가 커짐에 따라 애플리케이션 구동 시간이 늘어나고 빌드 및 배포 시간이 길어진다.
- 일부분의 오류가 전체에 영향을 미친다. (장애가 전파된다.)
- 기술 스택이 한 번 정해지면 바꾸기 어렵다.
- 전체 애플리케이션 확장은 쉽지만, 부하 분산을 위해 각 컴포넌트를 독립적으로 확장하기 어렵다.
모놀리식 아키텍처를 사용하기 적합한 경우
- 기술적 복잡도가 낮은 소규모 프로젝트
- MVP 수준의 단일 비즈니스 또는 신설 도메인 등
- 시장 진입을 위해 빠르고 간편하게 기능 개발 및 배포를 수행해야 할 때
마이크로서비스 아키텍처 (Microservice Architecture)
마이크로서비스 아키텍처(MSA)는 작고 독립적인 서비스들의 집합으로 구성된 애플리케이션 구조이다.
즉, 여러 개의 작은 서비스로 구성되어 각 서비스가 독립적으로 개발되고 배포되는 구조이다.
MSA로 구성되어 있는 애플리케이션의 경우 전체 시트템이 분산되어 있어 개발, 배포가 독립적으로 가능하며 확장성과 유지관리가 용이해진다.
아래는 MSA에 대한 예시이다.
MSA의 경우 위의 그림과 같이 애플리케이션을 작은 독립적인 서비스로 분리하고, 각 서비스는 모듈 또는 프로젝트로 나눠서 개발 및 관리를 진행한다. 이렇게 개발을 진행할 경우 독립적으로 개발 및 배포가 가능하여 개별적인 배포 주기를 가질 수 있다.
마이크로서비스 아키텍처(MSA)의 특징
- 각각의 서비스는 그 크기가 작을 뿐, 서비스 자체는 하나의 모놀리식 아키텍처와 유사한 구조를 갖는다.
- 각각의 서비스는 독립적으로 배포가 가능해야 한다.
- 각각의 서비스는 다른 서비스에 대한 의존성이 작아야 한다.
- 각 서비스는 개별 프로세스로 구동되며, REST API와 같은 가벼운 방식으로 통신되어야 함.
마이크로서비스 아키텍처(MSA)의 장단점
1. 장점
서비스 간 독립성으로 인해 확장성과 유연성이 높아진다.
기능 고립성이라는 특징 때문에 일부 서비스가 실패하더라도 전체 시스템에 큰 영향을 미치지 않는다.
기술 유연성 높아 서비스별 독립적인 스택 선정이 가능하다.
- 배포 관점
- 서비스 별 개별 배포가 가능하다. (배포 시 전체 서비스의 중단이 없음.)
- 독립 배포가 가능하므로 개발자의 자율성이 증가한다. (내가 A 기능 다 만들었고, 다른 사람이 B 기능 못 만들었으면, 나는 그냥 놀아도 됨.)
- 요구 사항을 신속하게 반영하여 빠르게 배포할 수 있다.
- 확장 관점
- 특정 서비스에 대한 확장성이 용이하다.
- 클라우드 사용에 적합하다.
- 장애 관점
- 장애가 전체 서비스로 확장될 가능성이 적다.
- 부분적 장애에 대한 격리가 수월하다.
- 코드 / 유지 보수 관점
- 팀 별로 프로젝트가 분리되어 있으므로 코드의 이해도가 증가하고, 그에 따라 유지 보수하기 쉽다.
- 신기술의 적용이 유연하고, 서비스를 polyglot하게 개발 및 운영할 수 있다.
- polyglot 개발: 여러 프로그래밍 언어, 패러다임 등을 사용
2. 단점
서비스 간 통신이 필요하며, 서로 간 연결 구축 및 관리의 복잡성이 증가한다.
초기 개발 및 통신 등에 시간이 소요된다.
- 성능 관점
- 서비스 간 호출 시 API를 사용하기 때문에 통신 비용 및 지연 시간이 증가한다.
- 데이터 관리 관점
- 데이터가 여러 서비스에 걸쳐서 분산되므로 한 번에 조회하기 어렵고, 데이터의 정합성 또한 관리하기 어렵다.
- 테스트 / 트랜잭션 관점
- 단위 테스트는 쉽지만, 통합 테스트 및 End-to-End 테스트 단위로 들어가면 여러 서비스의 API를 검증해야 하므로 시간과 비용이 많이 든다.
- 각 서비스 별로 데이터베이스가 있으므로 트랜잭션을 구현하기 까다롭다.
- 아키텍처가 다소 복잡하므로 개발 및 관리가 어렵고, 비용이 많이 든다.
- 모니터링, 디버깅, 통합 테스트가 어렵다.
마이크로서비스 아키텍처(MSA)를 사용하기 적합한 경우
- 기술적 복잡도가 높은 대규모 프로젝트
- 다양한 기술 스택을 사용하고, 여러 비즈니스별 요구사항이 명확한 경우
- 장애를 줄이고 시스템 전체의 가용성과 탄력성을 높여야 할 때
참고 자료
https://daaa0555.tistory.com/457
https://dodo-devops.tistory.com/19
https://steady-coding.tistory.com/595