시스템 아키텍처란?
- 시스템의 구조나 설계 방식
- 확장성, 유지보수성, 서능 등 큰 영향
대표적인 아키텍처
- Monolithic Architecture
- Micorservice Architecture
Monolithic Architecture
Monolithic: 단일의, 일체형의, 하나의 큰 덩어리로 된
Monolithic Architecture:애플리케이션의 모든 기능이 하나로 통합된 아키텍처
위 애플리케이션은 게시판 서비스의 모든 기능을 포함하고 있다. 간단한 구조를 가지기 때문에 초기에 쉽고 빠르게 개발할 수 있다.
이러한 애플리케이션을 1대의 서버에 배포하여 서비스하는 상황을 가정
Monolithic Architecture 로 구성된 애플리케이션 서버 한 대에 배포했을 때 단일 코드베이스로 관리하기 때문에, 각 애플리케이션에는 모든 기능이 포함되어 있다.
서비스가 활성화되면, 게시글 조회 수와 작성 트래픽이 급등했다고 가정했을 때,
게시글 기능만 트래픽이 많아 진 것이다.
부하를 감당하기 위해 Scale-Up하여 단일 서버의 성능을 향상시키는 것이다.
그렇다면 트래픽이 서버에서 감당할 수 없을 정도로 많아질 때 마다 Scale-Up을 하면 되는 것일까? 하지만 서버를 무한정 Scale-Up하는 것은 한계가 있고 가격도 점점 비싸진다.
수직으로 확장하는 것은 한계가 있으므로, 수평으로 확장하는 방법을 고려해 볼 수 있다. 서버를 여러대의 부하를 분산하여 성능을 높이는 Scale-Out
서버가 1대에서 3대로 확장되었고, 3개의 서버에서 게시글 트래픽을 처리하므로, 1대에서 처리되는 부하가 3대로 분산되는 것이다.이제 게시글 기능은 문제 없이 처리될 수 있다.
하지만, 위 구성은 리소스 낭비되는 지점이 있다. 분명 게시글 기능에 대한 부담만 대응하면 충분했다. Monolithic Architecture에서 모든 기능이 단일 애플리케이션에서 함께 배보되므로, 게시글과 관련 없는 기능들도 같이 배푀되어서 리소스를 점유하고 있는 것이다.
직접 코드를 개발하는 상황에서의 문제점도 있다.
흔히 개발 편의와 생산성을 위해 중복을 제거하고, 공통 코드를 관리한다. 위 그림에서 인기글 기능에서 공통 코드를 사용한다.
서비스의 활성화를 위해 인기글 선정 정책에 변화가 필요해졌을 때 인기글의 코드 변경이 필요한상황이라고 가정한다.
인기글 코드와 인기글 개발 편의를 위해 사용하던 공통 코드에 변경이 생겼다.
코드에서 인기글과 공통 코드만 변경이 있었고, 인기글 기능에 문제가 없음을 확인했다. 그리고 개발자는 변경 사항을 반영하기 위해 재배포를 진행한다.
그런데 문제가 발생한다. 건드린적 없던 게시글과 댓글 기능이 동작하지 않는 것이다.
공통 코드의 사용처를 살펴보니, 게시글과 댓글 기능에서도 함께 사용되고 있었다.
인기글을 위한 변경 사항이 게시글과 댓글 기능에선 호환되지 않던 것이다.
단일 코드베이스에서 통합 관리하다보면, 공통 코드 관리 등으로 변경 사항이 타 기능에 예기치 않게 전파될 수 있다. 전파되는 범위는 시스템이 커질수록 넓어지고 복잡해진다.
공통 코드가 아니더라도, 연관된 기능에 대해 서로의 코드를 침범하며, 코드 간 결합도가 높아지고, 각 기능의 응딥도가 낮아질 수 있다. 이는 유지보수를 점점 어렵게 만든다.
또한, 인기글 기능만 변경하려고 했음에도 모든 기능이 다시 배포되어야 했다. 모든 기능이 단일 애플리케이션에 함계 관리되기 때문이다. 애플리케이션이 무거워질수록, 빌드 및 배포 시간은 늘어난다.
만약 인기글 기능 변경 사항에 오류가 남아있어서 장애가 발생했다면? 인기글 기능만 사용할 수 없다면 다행이다.
또는, 변경이 전파된 게시글, 댓글까지만 사용할 수 없어도 다행일 것이다.
최악의 경우 모든 기능이 단일 애플리케이션에서 함께 배포 및 관리되므로, 시스템의 모든 기능으로 장애가 전파될 수 있다.
정리
- 모든 기능이 단일 코드베이스로 결합된 아키텍처
- 소규모 시스템에서 개발 및 배포가 간단하기 때문에 많이 선택
- 빠르고 효율적으로 개발할 수 있음
하지만
- 특정 부분만 확장하기 어려움
- 변경 사항이 시스템 전체에 영향을 미침
- 대규모 시스템에서 복잡도가 커지고 개발의 어려움
Micorservice Architecture
Micorservice Architecture에서는 시스템이 작고 독립적인 서비스(Microservice)로 구성된다.
단일 애플리케이션에 모두 포함 됐던 기능이 각각의 마이크로서비스로 분리되고, 하나의 애플리케이션에 만들어진 기능이 6개의 애플리케이션으로 분리된 것이다.
각각의 마이크로 서비스는 독립적으로 배포될 수 있다. 6개의 마이크로 서비스가 배포되는 상황을 가정
각 서비스가 독립적인 애플리케이션으로 배포되었고, 배포되는 서버도 독립적으로 구성될 수 있다. 각 서비스는 유기적으로 연결되어 통신하며 하나의 시스템을 이룬다.
각 서비스의 코드는 독립적으로 관리 및 배포되므로, 개별 서비스 내에서는 복잡도가 낮고, 빠르게 빌드 및 배포할 수 있다.
게시글에 대한 트래픽에 대응해야 한다면??
모든 기능이 함께 배포되어야 했던 Monolithic Architecture와 달리 Microservice Archtecture에서는 게시글 서비스의 서버만 증설해볼 수 있다. 다른 서비스들과 독립적으로 배포되기 때문에, 게시글에 대한 리소스만 추가로 점유하게 된다.
인기글에 대한 코드 변경 또는 장애가 발행하더라도 다른 서비스의 코드는 물리적으로 분리되어 있기 때문에 전파 범위가 줄어든다.
얼핏 보면 Monolithic의 문제를 모두 해결하는 만능 아키텍처인 것 같지만, 서비스 간 통신 비용, 트랜잭션 관리, 서비스 분리 기준, 모니터링, 개발 비용, 테스트, 설계 등 고려해야할 부분이 엄청 많다.
정리
- 시스템이 작도 독립전이 서비스(Microservice)로 구성
- 각 서비스는 단일 기능을 담당하며, 독립적 배포가능
- 서비스 단위로 유연한 확장 가능
하지만
- 서비스 간 복잡한 통신 및 모니터링 필요
- 데이터 일관성 및 트랜잭션 관리의 어려움
- 여러운 개발 난이도
| 구분 | Monolithic Architecture | Microservice Architecture |
|---|---|---|
| 구조 | 통합 | 분산 |
| 결합도 | 높음 | 낮음 |
| 확장성 | 개별 확장 어려움 | 개별 확장 쉬움 |
| 배포 | 통합 배포 | 독립 배포 |
| 기술 스택 | 단일 기술 스택 | 여러 기술 스택 가능 |
| 변경 전파 범위 | 시스템 전체 | 서비스 또는 전파 범위 이내 |
| 통신 비용 | 낮음 | 높음 |
| 개발 난이도 | 쉬움(소규모 일수록) | 어려움 |
