CS 강의를 듣던 중 MSA가 무엇인지 자세히 알아보고 싶어서 이번 포스팅을 작성하게 되었다.
MSA에 대해 정리하기에 앞서, MSA가 등장하기 이전의 MA라는 아키텍쳐에 대해 살펴보고 넘어가면 이해하는 과정이 훨씬 수월할 것이다.
MA(Momolithic Architecture)란?
애플리케이션의 모든 구성 요소(프론트엔드, 백엔드, 데이터베이스, 비즈니스 로직 등)가 하나의 코드베이스에 통합되어 있는 소프트웨어 아키텍처
모든 기능이 하나의 단일 애플리케이션으로 구현되고, 단일 프로세스에서 실행된다.
하나의 배포 파일(ex. .jar, .war)로 배포되며, 애플리케이션 전체가 하나의 단위로 동작한다.
MA의 장점
- 간단한 개발 및 배포 : 모든 코드가 단일 코드 베이스에 있어 시작하기 쉽고, 초기에 개발 및 배포 속도가 빠르다.
- 쉬운 테스트 및 디버깅 : 모든 기능이 하나의 애플리케이션에서 동작하므로 테스트 및 디버깅이 간편하다.
- 보편성 : 대부분의 개발자가 모놀리식 아키텍처에서 작업한 경험이 있어, 프로젝트를 쉽게 시작할 수 있다.
MA의 단점
- 규모가 커지면 유지보수하기 어려움 : 기능이 많아질수록 의존성이 복잡해지고, 코드 충돌이나 의도치 않은 버그가 발생할 가능성이 높아진다.
- 유연하지 않은 확장성 : 애플리케이션이 커지면 빌드 및 배포 시간이 길어지고, 특정 부분만 확장할 수는 없고 전체 애플리케이션을 확장해야 한다.
- 대규모 팀 작업이 어려움 : 모든 팀이 동일한 코드, 동일한 프로젝트에서 작업하기 때문에 코드 병합에 대한 충돌 가능성이 높고, 기능 변경 시 다른 팀이 작업에 영향을 줄 수 있다.
모놀리식 아키텍쳐의 장점과 단점을 살펴보면, 모놀리식 아키텍쳐는 소규모 프로젝트에 적합하다는 것을 알 수 있다. 소규모 프로젝트에서 부각되는 장점들이 대규모 프로젝트에 적용되면 단점으로 적용된다.
MA의 사용 예시
- 규모가 작은 애플리케이션
- 현 비즈니스를 통해 성장할 계획이 없거나, 복잡한 시스템 설계 및 관리가 필요하지 않은 경우
- 블로그나 작은 e커머스 사이트처럼 초기 개발 및 배포가 간단한 프로젝트
MSA(MicroService Architecture)
하나의 큰 어플리케이션(Monolithic)을 여러 개의 작은 서비스(Micro-Service)로 나누어 구성하는 소프트웨어 아키텍쳐
- 각 서비스가 서로 독립적(느슨하게 결합)이라 기술에 구애받지 않는다.
- 각 서비스는 별도의 데이터베이스를 가질 수 있고, 필요한 경우 공통 데이터베이스를 공유할 수 있다.
- MSA는 API를 통해서만 상호작용할 수 있다. 즉, 마이크로 서비스는 서비스의 end-point(접근점)을 API 형태로 외부에 노출하고, 실질적인 세부 사항은 모두 추상화한다. 내부의 구현 로직, 아키텍처와 프로그래밍 언어, 데이터베이스, 품질 유지 체계와 같은 기술적인 사항들은 서비스 API에 의해 철저하게 가려진다.
MSA의 장점
- 독립적 배포 : 특정 기능만 업데이트 하거나 배포할 수 있어 개발 속도가 빨라진다.
- 유연한 확장 : 각 서비스를 독립적으로 확장할 수 있어 자원 활용이 효율적이다.
- 기술 다양성 : 각 서비스에 적합한 기술 스택을 자유롭게 선택할 수 있다.
- 개발팀의 독립성 : 팀 단위로 특정 서비스만 담당할 수 있어 개발 및 유지보수 효율성이 높아진다.
MSA의 단점
- 복잡한 관리 : 서비스 간 통신, 데이터 동기화 등 아키텍쳐 설계가 복잡해진다.
- 오버헤드 증가 : 네트워크 통신, 데이터베이스 분할 등으로 인한 추가 비용과 성능 저하가 있을 수 있다.
- 어려운 배포 및 테스트 : 각 서비스가 독립적이므로 종합적인 테스트와 통합 배포가 까다롭다.
- 초기 도입 비용 : 기술 스택의 다양성과 CI/CD(지속적인 통합 및 배포) 구축 비용으로 인해 초기 투자 비용이 증가한다.
MA의 사용 예시
- 대규모 및 복잡한 시스템인 경우
- 유연한 확장이 요구될 경우
- 서비스를 만드는 독립적인 팀이 존재하는 경우
요약 비교
어제보다 더 나은