1. Microservice (마이크로서비스)
개념
- 어플리케이션을 독립적으로 배포 가능한 작은 서비스들로 구성.
- 각 서비스는 특정 비즈니스 기능에 집중하며 독립적으로 배포 및 확장 가능.
- 서비스 간 통신은 일반적으로 REST API, 메시지 큐, gRPC 등을 사용.
장점
- 확장성: 각 서비스는 독립적으로 확장 가능하여 특정 기능에 필요한 리소스를 유동적으로 관리할 수 있음.
- 유연성: 각 서비스가 독립적으로 배포 가능하여 빠른 개발 및 배포 가능.
- 장애 격리: 한 서비스의 문제가 전체 시스템에 영향을 미치지 않음.
- 다양한 기술 스택 사용 가능: 서비스별로 최적의 기술 스택을 선택할 수 있음.
단점
- 복잡성 증가: 서비스가 많아질수록 관리가 어려움.
- 통신 비용: 네트워크를 통한 서비스 간 통신으로 인해 성능이 저하될 수 있음.
- 분산 트랜잭션 처리의 어려움: 데이터 일관성을 유지하는 데 추가적인 노력이 필요.
- 배포 복잡성: 서비스 간 의존성을 조율하며 배포해야 함.
2. Monolithic Service (모놀리식 서비스)
개념
- 모든 기능이 단일 코드베이스와 단일 배포 단위로 구성된 구조.
- 어플리케이션의 모든 구성 요소가 하나의 프로세스에서 실행됨.
장점
- 간단한 개발 및 배포: 코드베이스가 단일 구조로 유지되어 관리가 용이.
- 성능 최적화 용이: 서비스 간 통신이 프로세스 내부에서 이루어지므로 성능이 우수.
- 테스트 편리: 통합된 환경에서 테스트가 용이.
단점
- 확장성 제한: 전체 어플리케이션을 확장해야 하므로 리소스 낭비.
- 유연성 부족: 특정 기능의 변경이 전체 어플리케이션에 영향을 줄 수 있음.
- 장애 전파: 하나의 문제로 전체 시스템이 중단될 위험.
3. Mini Service (미니서비스)
개념
- Microservice와 Monolithic의 중간 형태로, 관련 기능을 묶어 비교적 큰 서비스 단위로 구성.
- 각 미니서비스는 독립적으로 배포 및 확장 가능하며, 서비스 간 통신은 주로 REST API를 사용.
장점
- 균형 잡힌 구조: Microservice와 Monolithic의 장점을 적절히 활용.
- 관리 용이성: Microservice보다 서비스의 수가 적어 관리가 쉬움.
- 유연한 확장성: 관련 기능 단위로 확장 가능.
- 적응 기간 짧음: Monolithic에서 단계적으로 전환하기에 적합.
단점
- 서비스 경계 설정 어려움: 적절한 서비스 크기를 정의하는 데 어려움이 있을 수 있음.
- 제한된 확장성: Microservice만큼의 세분화된 확장은 어려움.
- 통신 비용 증가: 서비스 간 통신으로 인해 성능 저하 가능.
4. 세 가지 아키텍처 비교
| 구조 |
작고 독립적인 서비스들의 집합 |
단일 코드베이스로 구성 |
관련 기능을 묶은 서비스들의 집합 |
| 확장성 |
서비스 단위로 독립적 확장 가능 |
전체 시스템 단위로 확장 |
기능 단위로 제한적 확장 가능 |
| 관리 복잡성 |
높음 |
낮음 |
중간 |
| 배포 유연성 |
개별 서비스 배포 가능 |
전체 시스템을 배포해야 함 |
기능 단위로 배포 가능 |
| 기술 스택 선택 |
자유 |
제한적 |
제한적 |
| 성능 |
통신 오버헤드 있음 |
최적화 쉬움 |
중간 |
| 장애 전파 |
장애 격리 가능 |
장애 전파 위험 높음 |
제한적 격리 가능 |
| 전환 용이성 |
기존 Monolithic에서 전환 어려움 |
기존 형태 |
단계적 전환 가능 |
결론
- Microservice는 대규모 시스템에서 확장성과 유연성을 극대화하는 데 적합하지만, 복잡성이 크므로 철저한 계획이 필요합니다.
- Monolithic Service는 단순한 구조와 개발 속도를 필요로 하는 소규모 프로젝트에 적합합니다.
- Mini Service는 Monolithic에서 Microservice로 전환하는 과도기적 단계에서 활용하기 좋으며, 두 구조의 장점을 적절히 융합할 수 있는 선택지입니다.
프로젝트 규모에 따라서 적절한 아키텍처를 사용하는게 제일 베스트 입니다. 😊