Monolithic Architecture(모놀리식 아키텍처)
모놀리식 아키텍처는 마이크로서비스(MSA) 아키텍처에 반대되는 개념으로, 애플리케이션의 모든 구성 요소가 한 프로젝트에 통합되어 있는 형태
장점 | 단점 |
개발 초기에 단순한 아키텍처 구조로 인해 개발에 용이 | 프로젝트의 구조가 커짐에 따라 애플리케이션 구동 시간이 늘어나고 빌드 및 배포 시간이 길어짐 |
어떤 서비스든지 개발되어 있는 환경이 같아서 복잡하지 않음 | 조그마한 수정 사항이 있어도 전체를 다시 빌드하고 배포해야 함 |
배포 간단, 확장성이 쉬움(로드밸런스를 이용해 로드 부하를 나눠 가지는 방식으로 진행) | 많은 양의 코드가 몰려 있어 개발자가 모든 코드를 이해하기 힘들고 유지보수가 어려움 |
쉽게 고가용성 서버 환경을 만들 수 있음 | 일부분의 오류가 전체에 영향을 미침(장애 전파) |
End-to-End 테스트 용이 | 기술 스택이 한 번 정해지면 바꾸기 어려움 |
MSA(MicroService Architecture)
small services, each running in its own process + independently deployable
마이크로서비스란 작고, 독립적으로 배포 가능한 각각의 기능을 수행하는 서비스로 구성된 프레임워크
마이크로서비스는 완전히 독립적으로 배포가 가능하고, 다른 기술 스택(개발 언어, 데이터베이스 등)이 사용 가능한 단일 사업 영역에 초점을 둔다.
- 작은 서비스가 여러 개 모여서 하나의 시스템을 제공하는 아키텍처
- 복잡한 웹 시스템에 맞춰 개발된 API 기반의 서비스 지향적 아키텍처 스타일
- 각 서비스는 작고 독립적이고 느슨하게 결합되어 있다.
- 서비스들 독립적으로 배포 가능
- 전체 프로그램을 빌드한 뒤에 재배치하지 않고도 기존 서비스들을 업데이트 가능
- 클라우드와 컨테이너와 잘 어울리는 아키텍처이기도 하다.
MSA의 장단점
장점
1. 배포
- 서비스 별 개별 배포 가능(배포 시 전체 서비스의 중단이 없다.)
- 요구사항을 반영해 빠르게 배포 가능
2. 확장
- 특정 서비스에 대한 확장성이 유리함(scale-out)
- 클라우드 사용 시 적합
3. 장애 해결(Error Handling)
- 일부 장애가 전체 서비스로 확장될 가능성이 적음
- 부분적으로 발생하는 장애에 대해 격리가 수월함
4. 그 외
- 새로운 기술을 적용하기 유연함
- 서비스를 여러 언어를 사용해 개발 및 운영할 수 있음
단점
1. 성능 이슈
- 서비스 간 호출 시 API를 사용하므로, 통신 비용이나 latency(지연 시간)에 대해 이슈가존재함
2. 테스트 / 트랜잭션
- 서비스가 분리되어 있어 테스트와 트랜잭션의 복잡도 증가한다.
- 많은 자원이 필요하다.
- 단위 테스트는 쉽지만, 통합 테스트, End-to-End 테스트 단위로 들어가면 여러 서비스의 API를 검증해야 하므로 시간 비용 많이 듦
3. 데이터 관리
- 데이터가 여러서비스에 분산되어 조회하기 어려움
- 데이터를 관리하기 어려움
장점 | 단점 |
전체 프로그램을 다시 배포하지 않고도 업데이트 가능 | 서비스 간 통신방법이 필요하고 복잡함 |
독립적으로 개발가능 | 서비스끼리의 테스트가 어려움: 단위 테스트는 쉽지만, 통합 테스트, End-to-End 테스트 단위로 들어가면 여러 서비스의 API를 검증해야 하므로 시간 비용 많이 듦 |
서비스 하나가 다운되도 전체 서비스에 영향을 끼치지 않음 | 각 서비스 별로 데이터베이스가 있기 때문에 트랜잭션을 구현하기 까다롭다. |
서비스를 독립적으로 확장 가능, 리소스의 유연한 운용 가능 | 데이터가 여러 서비스에 걸쳐서 분산되기 때문에 한 번에 조회하기 어렵고, 데이터의 정합성 또한 관리하기 어렵다. |
"서비스의 재사용성, 클라우드환경에 친화적"이라는 장점 때문에 현재 가장 핫한 아키텍처가 되었다!
언제 모놀리식 아키텍처를 사용하고, 언제 MSA 아키텍처를 사용하는 가
초기 시작은 프로젝트의 규모가 작은 경우가 많으므로 모놀리식 아키텍처로 사용하다가 다음 관점들을 비교하여 이득이 된다면 MSA 아키텍처로 전환하는 것이 좋다.
- 비용: MSA 아키텍처를 도입할 경우, 모놀리식 아키텍처에 비해 비용을 얼마나 절감할 수 있는가?
- 개발 생산성: 마이크로 서비스를 요구할 만큼 시스템 복잡도가 높은가? 또는 복잡도를 지나치게 높인 마이크로 서비스가 생산성을 저해하고 있진 않은가?
- 운영: 개발 팀에게 개발과 운영을 동시에 할 만큼 인프라가 준비되어 있는가? 또는 개발 인력이 마이크로 서비스를 관리할 역량이 있는가?
- 배포: 배포를 충분히 자주 하고 있는가? MSA는 빠른 변화에 대응하기 위해 도입하는 것인데, 회사마다 배포 일이 정해져 있고, 배포가 가끔 일어난다면 효율이 떨어진다.
MSA 아키텍처
- 남색 부분: 내부 아키텍처
- 회색 부분 : 외부 아키텍처
- Extrernal Gateway, Service Mesh, Container Management, Backing Services, Telemetry, CI/CD Automation
내부 아키텍처
내부 서비스와 관련된 아키텍처로, 내부의 서비스를 어떻게 잘 쪼개는 지에 대한 설계
- 마이크로 서비스를 어떻게 정의할 것인가?
- DB 접근 구조를 어떻게 설계할 것인가?
- 일부의 비즈니스 트랜잭션은 여러 마이크로 서비스에 걸쳐 있기 때문에, 각 서비스에 연결된 데이터베이스의 정합성을 보장해야 함
- 마이크로 서비스 내 API를 어떻게 설계할 것인가?
- 내부 아키텍처는 각 비즈니스, 서비스, 시스템마다 각각의 특성이 있기 때문에 정해진 것은 없다. 각자 알아서 팀 사정에 맞게 구현하면 된다. 표준이 없기 때문에 MSA를 설계하는 데 가장 어려운 부분이다.
외부 아키텍처
1. External Gateway
- 전체 서비스 외부로부터 들어오는 접근을, 내부 구조를 드러내지 않고 처리하기 위한 요소
- 사용자 인증과 권한 정책 관리 등을 수행하고, API 게이트웨이가 가장 핵심적인 역할
- API 게이트웨이는 서버 최앞단에 위치해 모든 API 호출을 받는다. 받은 API 호출을 인증한 후, 적절한 서비스에 메시지를 전달한다.
2. Service Mesh
- 마이크로 서비스 구성 요소 간의 네트워크를 제어하는 역할
- 서비스 간에 통신을 하기 위해서는 service discovery, service routing, 트래픽 관리 및 보안 등을 담당하는 요소가 있어야 하는데 이를 Service Mesh가 모두 수행
3. Container Management
- 컨테이너 기반 애플리케이션 운영은 유연성과 자율성을 가지며, 개발자가 손쉽게 접근 및 운영할 수 있는 인프라 관리 기술이므로 MSA 아키텍처가 이에 적합하다고 평가 받는다.
4. Backing Service
- 애플리케이션이 실행되는 가운데, 네트워크를 통해서 사용할 수 있는 모든 서비스
- MySQL과 같은 데이터베이스, 캐시 시스템, SMTP 서비스 등 애플리케이션과 통신하는 Attached 자원을 지칭하는 포괄적인 개념
- 대표적인 Backing 서비스의 예시로는 메시지 큐가 있다.
- MSA에서는 메시지의 송신자와 수신자가 직접 통신하지 않고, 메시지 큐를 활용하여 비동기적으로 통신한다.
- 만약 메시지 큐를 사용하지 않는 강한 결합 구조의 경우, 여러 서비스를 걸치는 실시간 트랜잭션을 처리할 때, 하나의 서비스가 죽어버린다면 트랜잭션이 끊어지기 때문에 해당 서비스 요청을 보존할 수 없고 큰 에러가 발생하게 된다.
- 또한 REST 통신으로 트랜잭션 실패에 대한 처리를 구현하는 방법은 굉장히 복잡하다.
5. Telemetry
- 서비스들을 모니터링하고 서비스 별로 발생하는 이슈에 대응할 수 있도록 환경을 구성하는 역할을 한다.
- MSA에서는 상당수의 마이크로 서비스가 분산 환경에서 운영되기 때문에 서비스의 상태를 일일이 모니터링하고 이슈에 대응하는 것이 어렵다.
6. CI/CD Automation
- 지속적인 통합과 지속적인 배포를 자동화하는 것은 배포가 잦은 MSA 시스템에서 반드시 필요한 요소 중에 하나이다.
'cs' 카테고리의 다른 글
[혼공운영체제] 2. CPU의 작동원리(ALU와 제어장치, 레지스터) (0) | 2023.04.13 |
---|---|
방화벽(Firewall)의 동작 원리 (0) | 2023.04.10 |
CORS (0) | 2023.04.08 |
[혼공운영체제] 1. 데이터와 명령어 (0) | 2023.04.06 |
[혼공운영체제] 0.컴퓨터 구조의 큰 그림(컴퓨터 핵심 부품) (0) | 2023.04.05 |