MSA(Micro Service Architecture)를 공부하기전에 MSA가 나오게 된 배경을 알아보자
과거에는 Onpremise 환경이 일반적이였기에 모놀리스 방식만을 사용했다.
모놀리스 Monolithic란?
하나의 주요 프로세스로 구성이 되어있다.
개발->컴파일->빌드한 class묶은 war파일을 바로 실행시키면 됨. 매우 간단.
하나의 프로세스가 그 서버의 자원을 모두 사용한다.
거의 대부분 DB도 하나만 사용한다. (endpoint하나기에 DB에 문제가 생기면 관련된 다른 서비스도 죽는다?)
단 한줄의 코드만 수정이 되더라도, 모든 App.의 재배포가 필요하다.
배포의 의미는 프로세스를 다시 띄우는 작업.
싱글/멀티 모듈로 구성은 가능하나 CI단위만 다르고, 배포(CD)의 범위는 여전히 전체가 대상이다.
모놀리스 아키텍쳐의 싱글모듈? 멀티모듈?
모듈: 독립적으로 빌드되고 배포될 수 있는 단위. 멀티모듈 프로젝트는 여러 모듈로 구성된다.
(1) 싱글모듈
모든 소스가 단일 모듈내에 존재
응집성과 결합도가 매우 높다.
* 응집도: 하나의 목적을 수행하는 요소들간의 연관성 척도, 높을수록 연관성있는 기능이 한 모듈내에 있다는 의미
* 결합도: 모듈이 다른 모듈에 의존하는 정도의 척도, 모듈간의 상호결합정도, 높을수록 수정시에 다른 모듈에 대한 영향도가 크다.
설계/구현이 간단하고 단순하다, 최상위 싱글 패키지
다만 유연성/확장성이 제한적이다.
하나의 jar/war를 기준으로 서비스를 띄운다.
project/
├── src/
│ ├── main/
│ │ ├── java/
│ │ │ └── com/
│ │ │ └── example/
│ │ │ ├── Application.java
│ │ │ ├── Controller.java
│ │ │ ├── Service.java
│ │ │ └── Repository.java
│ └── resources/
│ └── application.properties
└── build.gradle
(2)멀티모듈
서비스별로 모듈화 되어있다.
최상위 패키지에 대해서 여러개의 패키지가 존재
응집성과 결합도가 낮다.
모듈 간 I/F정의 필요
모듈별로 별도 빌드(pom.xml, build.gradle 존재)되어 jar파일이 여러개가 나오게 되며, 동시에 배포를 진행한다.
배포서버에서는 jar여러개를 같이 올림
project/
├── core/
│ ├── src/
│ │ ├── main/
│ │ │ ├── java/
│ │ │ │ └── com/
│ │ │ │ └── example/
│ │ │ │ ├── CoreApplication.java
│ │ │ │ ├── CoreService.java
│ │ │ │ └── CoreRepository.java
│ │ └── resources/
│ │ └── core.properties
│ └── build.gradle
├── web/
│ ├── src/
│ │ ├── main/
│ │ │ ├── java/
│ │ │ │ └── com/
│ │ │ │ └── example/
│ │ │ │ ├── WebApplication.java
│ │ │ │ ├── WebController.java
│ │ │ │ └── WebService.java
│ │ └── resources/
│ │ └── web.properties
│ └── build.gradle
└── build.gradle
각각의 properties를 가지고 있다.
모듈과 패키지의 차이
모듈과 패키지는 서로 다른 개념이다.
모듈은 독립적인 단위로 빌드되고 배포될 수 있는 코드의 단위를 의미하며,
패키지는 코드의 논리적 그룹화를 의미한다.
- 모듈: 빌드 도구에서 독립적으로 관리되는 코드의 단위. 각 모듈은 독립적으로 빌드되고, 테스트되고, 배포될 수 있습니다. 모듈 간의 종속성을 정의할 수 있습니다.
- 패키지: 클래스 파일을 그룹화하기 위한 논리적인 네임스페이스입니다. Java에서 패키지는 디렉토리 구조로 표현되며, 클래스 파일의 논리적 구조를 나타냅니다.
모놀리식 아키텍쳐의 장점?
개발도 단순, 배포도 단순
배포할 때 하나의 파일이나 패키지를 배포하면 되므로 운영 관리가 단순
모든 로그와 모니터링 데이터가 한 곳에 모이므로, 이를 관리하기가 쉬움
모든 코드가 한 곳에 있으므로, 디버깅 과정이 단순,전체 애플리케이션을 로컬에서 쉽게 실행하고 테스트할 수 있다.
좋은 서버 하나의 리소스를 최적화해서 사용 가능하다.
모놀리식 아키텍쳐의 단점?
Scale Out이 어렵다. (서버 여러개 추가하여 요청 분산) Scale Up은 하나의 서버의 자원을 업그레이드 한다.
개별 구성 요소가 아닌 전체 시스템을 확장해야 하므로, 비효율적일 수 있습니다. 단순 수정이여도 특정 기능만 확장하기 어려워집니다.
한 부분의 실패가 전체 애플리케이션의 가용성에 영향을 줄 수 있다. 장애나면 그냥 끝!?
보안을 중시하거나 빠르게 개발해야하는 경우 MSA보다 모놀리식 아키텍쳐가 장점!!
Cloud환경이 아니고 Cloud지식이 부족한 인력이 있는 상황인 Onpremise에서도 모놀리식이 좋다.
Scale Up/ Out 차이;
- Scale Up: 웹 서버의 메모리를 16GB에서 32GB로 업그레이드하거나, 더 빠른 CPU로 교체하여 처리 성능을 향상시킵니다.
- Scale Out: 동일한 웹 애플리케이션을 실행하는 서버를 한 대 더 추가하고, 로드 밸런서를 통해 두 서버로 트래픽을 분산시킵니다.
'프로그래밍 > MSA' 카테고리의 다른 글
[MSA] MSA의 여러 패턴들 (1) | 2024.07.24 |
---|---|
[MSA] 분해, 통신, 트랜잭션 패턴이란? (3) | 2024.07.23 |
[MSA] MSA의 단점과 진입장벽이 높은 이유 (3) | 2024.07.22 |
[MSA] MSA의 핵심 원칙 (0) | 2024.07.09 |
[MSA] 아키텍처의 발전 과정 (모놀리식, SOA, MSA) (0) | 2024.07.03 |