최근에는 모놀리식 아키텍처(Monolithic Architecture)가 보유한 단점이나 한계점을 극복하기 위해 많은 서비스 기업들이 마이크로 서비스 아키텍처(Micro Service Architecture) 패턴을 이용해 개발을 진행하고 있습니다. 이번엔 Monolithic Architecture, Micro Service Architecture가 무엇인지 간단히 정리해 보고자 합니다.
1. Monolithic Architecture (모놀리식 아키텍처)
1-1. 모놀리식 아키텍처(Monolithic architecture)
- 소프트웨어의 구성 요소들이 하나의 프로젝트 내부에 모두 통합되어 있는 설계 패턴을 의미합니다.
1-2. 특징
- 모놀리식 아키텍처의 경우 일반적으로 아래와 같은 특징이 존재합니다.
(1) 모놀리식 아키텍처의 경우 모든 프로세스들이 강하게 결합(Tight coupling)되어 있습니다
(2) 단일 서비스로 빌드, 배포, 테스트 등이 가능합니다.
(3) 만약 서비스에 대한 요구 사항 변경, 기능 추가 등이 발생하면 한 프로젝트 내부에서 코드를 수정, 추가해야 합니다.
1-3. 장점
(1) 소규모 프로젝트에서 합리적
- 모놀리식 아키텍처의 경우 모든 기능들을 하나의 프로젝트 안에서 설계하기 때문에 단순한 애플리케이션이나 프로젝트에선 효율적인 설계 방법이 될 수 있습니다.
(2) 개발, 빌드, 배포, 테스트가 용이
- 단순한 설계 패턴으로 로컬 환경에서 개발, 테스트하기 편리해집니다.
- 모든 코드가 하나의 프로젝트에서 관리되기에 배포 시에도 간단하게 진행할 수 있습니다.
1-4. 단점
(1) 애플리케이션 구동 시간 증가, 빌드, 배포 시간이 길어질 수 있습니다.
(2) 작은 수정 사항이 발생하거나, 기능이 추가되면 코드 전체를 수정하고 재빌드, 재배포가 필요합니다.
- 하나의 프로젝트 내에 모든 코드가 몰려있기 때문에 하나를 수정하면 코드 전체를 수정해 줘야 하기 때문에 유지보수성이 떨어지게 됩니다.
(3) 일부분 기능에서 문제가 발생, 이로 인해 오류나 장애가 발생하면 서비스 전체가 다운될 수 있습니다.
(4) 서비스의 복잡도가 증가함에 따라 한계점이 발생
- 소규모 프로젝트에 소수의 개발자들에 한해선 문제가 발생하진 않지만, 서비스 규모가 커지고 비즈니스 로직이 방대해지게 된다면 개발자의 풀이 이전보다 늘어나고, 코드의 양도 기하급수적으로 늘어나기 때문에 작은 수정 사항 발생 시에도 많은 인원이 방대한 코드를 직접 찾아서 수정까지 해야 되는 번거로움이 생기기에 개발의 생산성, 유지보수성 측면에서도 좋지 않습니다.
(5) Scale-out (서버를 추가하여 시스템을 확장하는 것)이 불가능합니다.
2. Micro Service Architecture (MSA, 마이크로 서비스 아키텍처)
2-1. 마이크로 서비스 아키텍처(Micro Service Architecture)
- MSA에 대해서 정확하고 엄밀한 정의는 없지만, 현업에선 다음과 같이 통용되어 불리고 있습니다.
- "하나의 큰 애플리케이션을 나눌 수 있을만큼 작은 단위로 나누고 이들 간에 변경과 조합이 가능하도록 분리가 가능하도록 만든 애플리케이션 아키텍쳐를 의미"합니다.
2-2. 특징
- 마이크로 서비스 아키텍처는 전체 애플리케이션을 기능이나 수행하는 역할 기준으로 여러 개의 작은 서비스 유닛으로 나누어 이들 간의 변경과 조합이 가능하도록 하는 소프트웨어 설계 패턴으로써 각각의 마이크로 서비스들은 서로 상호 통신이 가능하면서 전체 서비스를 구성할 수 있습니다.
- 이러한 서비스들은 경량화된 API를 사용하며 잘 정의된 인터페이스를 통해 통신합니다.
- 각각의 서비스들이 독립적으로 실행되기 때문에 애플리케이션의 각 기능에 맞는 요구 사항을 충족할 수 있도록 각각의 서비스를 따로 업데이트, 배포할 수 있습니다.
2-3. 장점
(1) 각각의 독립적인 서비스를 구성하기 때문에 모놀리식 아키텍처보다 가벼운 편입니다.
(2) 서비스별로 별도의 개발, 배포가 가능하므로 서비스 전체를 중지하지 않고도 개발, 배포가 가능합니다.
- 서버 및 특정 기능에 장애, 오류가 발생해도 각 독립된 서비스로 설계했기 때문에 복구가 빠른 편이고 오류 및 장애가 전체 서비스로 확장될 일이 거의 없습니다.
(3) 각 서비스에 맞게 서버를 나눌 수 있으므로(Scale-out) 서버 자원을 효율적으로 사용할 수 있습니다.
(4) 각 서비스가 모듈화되어 있고 RPC, Message-driven과 같은 통신 방법을 사용해 서비스끼리 상호 작용할 수 있습니다.
(5) 분리된 서비스로 개발할 수 있기에 각 서비스마다 적합한 기술 스택을 적용시킬 수 있습니다.
2-4. 단점
(1) 각자 배포된 서비스에 대해 다른 서비스와 문제없이 연동되는지 확인해 줘야 합니다.
(2) 서비스 간 호출 시, REST API 등을 사용함에 따라 통신 비용, Latency가 증가하게 됩니다.
(3) 서비스가 모두 독립되어 있기에 DB의 트랜잭션 관리, 로그 및 장애 추적, 테스트가 어려운 편입니다.
(4) 서비스 규모가 커질수록 비즈니스 로직의 복잡도가 기하급수적으로 늘어날 수 있습니다.
========================================================================
※ 해당 포스팅에 대해 내용 추가가 필요하다고 생각되면 기존 포스팅 내용에 다른 내용이 추가될 수 있습니다.
개인적으로 공부하며 정리한 내용이기에 오타나 틀린 부분이 있을 수 있으며, 이에 대해 지적해 주시면 감사하겠습니다.
'기술 트렌드, 생각 정리 & 회고 > Engineering trends' 카테고리의 다른 글
| 로드 밸런싱(Load Balancing)의 개념과 특징 (0) | 2023.07.26 |
|---|---|
| 캐싱(Caching) & CORS(교차 출처 리소스 공유, Cross-Origin Resource Sharing) (0) | 2023.07.26 |
| 백엔드 엔지니어링 : Back-end(Server-side) Engineering (0) | 2023.05.01 |
댓글