Monolithic Architecture 란?
사전적 의미
Monolithic : 1. 하나의 암석으로된, 2. 단일체의,한 덩어리로 뭉친
기존에 우리가 사용하던 전통적인 방식의 개발 방법을 모노리틱 아키텍처 스타일이라고 한다. 사전적 의미로 정의한 대로 한 덩어리의 구조라고 볼 수 있다.
전체 애플리케이션이 하나로 되어있어 보통 동일한 개발툴을 사용해 개발되며, 배포 및 테스트도 하나의 애플리케이션만 수행하면 되기 때문에 개발 및 환경설정이 간단하다. 또한 각 컴포넌트들이 함수로 호출되기 때문에 성능에 제약일 덜하고 운영관리가 용이하다. 이런 장점때문에 작은 크기의 시스템을 개발할 때는 매우 유용하지만 시스템이 커지기 시작하고 여러 컴포넌트들이 더해지면 문제가 발생하기 시작한다.
위 그림처럼 몇몇 기능이 추가될 시
문제점 발생
- 빌드/테스트 시간이 길어진다.
작은 수정에도 시스템 전체를 빌드해야 하며, 테스트 시간도 길어집니다. 요즘처럼 CI/CD가 강조되는 시점에서는 큰 문제가 될 수 있다.
- 선택적 확장이 불가능하다.
이벤트로 인해 서비스 접속 량이 폭증할 경우 프로젝트 전체를 확장해야만 한다.
- 하나의 서비스가 모든 서비스에 영향을 준다.
이벤트 서비스에 트래픽이 몰려 해당 서버가 죽게 된다면 다른 모든 서비스 역시 마비 되는 상황이 오게 된다.
MSA(Micro Service Architecture)란?
MSA란 각각을 마이크로하게 나눈 독립적인 서비스를 연결한 구조를 말한다. 이러한 특성 덕분에 시스템 전체의 중단없이 필요한 부분만 업데이터 및 배포가 가능하다. 유연한 대응이 가능해 실시간 요구사항을 반영할 수 있어 급격히 성장한 기업들이 많이 택한 방법이기도 하다.
각 컴포넌트는 서비스 형태로 구현되고 API를 이용하여 타 서비스와 통신하게 된다. 각 서비스는 독립된 서버로 타 컴포넌트와 의존성이 없기 때문에 독립된 배포를 하게 된다. 또한 각 컴포넌트가 독립된 서비스로 개발되어있기 때문에 부분적인 확장이 가능하다. 온라인 쇼핑몰에서 주문 서비스에 트래픽이 증가한다면 해당 서버만 확장을 해주면 된다.
물론 이처럼 장점만 있는 것은 아니다. 모노리틱 아키텍처가 서비스간의 호출이 하나의 프로세스 내에서 이루어지기 때문에 속도가 빠르지만 MSA의 경우 서비스간 호출을 API통신을 이용하기 때문에 속도가 느리고, 통신에 사용하기 위해 값을 데이터 모델로 변환시켜주는 오버헤드가 발생하기도한다.
MSA의 특징
- 데이터 분리
데이터 저장 시 하나의 DB에 중앙 집중화를 하지 않고 서비스 별 별도의 데이터 베이스를 사용한다. DB의 종류를 별도로 가져갈 수도 있고, 같은 DB를 사용하더라도 나누어서 사용하게 된다. 데이터가 분산되어있기 때문에 다른 서비스 컴포넌트에 대한 의존성이 없이 서비스를 독립적으로 개발 및 배포/운영 할 수 있지만, 다른 컴포넌트의 데이터를 API통신을 통해 가져와야 하기 때문에 성능상의 문제가 발생 할 수 있고, 트렌젝션으로 묶을 수 없는 문제가 발생하기도 한다.
- API Gateway
MSA의 문제점 중 하나는 각 서비스가 다른 서버에 분리 배포되어있기 때문에 서버 URL이 각기 다를 수 밖에 없다. 이때 API Gateway는 API 서버 앞 단에서 모든 API 서버들의 End-Point를 단일화하여 묶어주는 역할을 한다. 또한 거미줄처럼 복잡한 서비스간의 API호출 구조도 단순화 시켜준다. 그 외에 라우팅, 로드밸런싱, 인증 역할 등등 여러 역할을 수행합니다.
기존의 팀 모델은 역할별로 나누어진 모델로 팀을 구분했다. 이러한 팀 모델은 인력 관리와 운영에 유연성을 부여하지만 팀간의 커뮤니케이션이 원활하지 않고 협업에 걸리는 시간이 지연되는 경우가 많았다.
MSA에서는 서비스 별로 팀을 나누고 서비스 기획에서부터 설계 개발 운영이 팀 내에서 이루어지기 때문에 다른 팀에 대한 의존성이 사라지게 된다. 역할별 요청과 피드백이 빨라지고, 때문에 유연하고 지속적인 운영과 개발이 함께하게 된다.
물론 장점만이 있는 것은 아니다. 아무래도 인력 리소스 관리에 어려움이 생기게 된다. 각 팀의 역할 담당자들은 기본적인 업무 성숙도를 가지고 있어야 하고, 특히 개발자들은 운영 팀의 고유 영역이었던 인프라 핸들링이 가능해야 한다. 그리고 이러한 일이 가능하게 된 것은 AWS같은 클라우드 서비스 발달이다. 직접적인 인프라 운영 없이 클라우드 서비스를 이용하여 개발자가 운영 환경을 설정할 수 있게 되었다.
정리하자면
MSA는 복잡한 웹 시스템에 맞춰 개발된 API기반의 서비스 지향적 아키텍처 스타일이다. MSA가 유행을 하고 있는 것은 사실이지만, 업무나 비즈니스 특징에 따라 적절한 아키텍처가 선택되야 한다. 최근들어 아키텍처 모델은 시스템에 대한 설계뿐만 아니라 팀의 구조나 프로젝트 관리 방법까지 달라지기 때문에 프로젝트에 미치는 영향이 매우 크며, 때문에 거시적인 관점에서 고려할 필요가 있다.
MSA가 필요하다고 해도 시작을 MSA로 해야 하는 것은 아니다. MSA가 서비스의 재사용성, 유연한 아키텍처구조, 대용량 웹 서비스에 적합한 구조 등 많은 장점을 가지고 있지만 개인의 높은 숙련도가 필요한 편이다. MSA를 구축한 많은 기업들이 시작은 모노리틱 시스템으로 시작하여 팀원들의 숙련도를 높이고 피드백을 통해 시스템을 발전 시키는 과정에서 MSA로 전환한 사례들도 있다. 프로젝트의 목적이나 팀의 상황에 맞는 유연한 선택이 필요하다.
