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