모놀리식 아키텍처

소개

크게 보면 마이크로서비스 아키텍처는 마이크로서비스라는 작은 단위의 컴포넌트로 구성되어 있다.

서비스 전체 기능을 독립된 작은 단위로 나누어 분리하고, 각각의 컴포넌트는 독립된 시스템 형태로 개발하고 운영한다.

독립된 마이크로서비들은 전체 서비스와 분리해서 개발할 수 있으므로 서비스 변화에 비교적 자유롭다. 그러므로 민첩한 대응이 가능하다. 또한 독립성과 민첩성을 확보한 마이크로서비스 아키텍처는 대규모 서비스에서 여러 장점이 발현된다.

보통 마이크로서비스 아키텍처와 비교해서 설명하는 것으로 모놀리식 아키텍처가 있다.

 

모놀리식 아키텍처란?

위의 사진처럼 하나의 시스템이 서비스 전체 기능을 처리하도록 설계한 것으로, 과거부터 현재까지 흔히 볼 수 있는 아키텍처다.

모놀리식 아키텍처는 전통적인 개발 방식으로 하나의 프로젝트에 모든 기능을 함께 포함한다.

이렇게 하면 코드의 양이 커질수록 개발 및 복잡성이 증가하게 된다.

마이크로서비스처럼 모듈 단위로 쪼개는 것이 아닌 하나의 프로젝트로 전체 애플리케이션을 묶어서 개발하기 때문에 점점 데이터베이스가 커지는 구조이다. 

 

모놀리식 아키텍처의 장점

보통 모놀리식 아키텍처로 애플리케이션을 설계할 때는 하나의 WAS에서 모든 기능을 처리하도록 구성한다.

그리고 데이터를 저장하기 위해 하나의 데이터 저장소를 사용한다.

일반적으로 RDB 같은 데이터 저장소를 사용하므로 전반적으로 구조가 매우 간단하다.

이러한 간단한 구조 덕분에 시스템 운영과 개발이 편리한 장점이 있다.

예를 들어 WAS와 RDB가 각각 하나일 경우 개발자는 하나의 데이터 저장소에 하나의 애플리케이션을 개발하면 되므로 데이터를 처리하는 일에만 집중하면 된다. 애플리케이션도 하나이므로 코드베이스도 하나면 충분하다. 

개발자는 클래스 단위로 기능을 개발하면 되고, 데이터는 객체들 사이에서만 전달된다. 결국 서비스의 기능들은 클래스들의 유기적인 조합으로 이루어진다. 반면에 MSA는 마이크로서비스 단위로 기능을 개발해야 하므로 데이터는 마이크로서비스 사이에 전송된다.

정리하자면 MSA는 마이크로서비스에서 데이터는 네트워크를 통해 전송된다. 반면에 모놀리식 아키텍처는 네트워크로 인한 지연이나 데이터 유실은 걱정할 필요가 없다. 

또한 데이터 저장소가 하나이므로 RDB의 트랜잭션 기능을 쉽게 사용할 수 있다.

이러한 트랜잭션 기능을 통해 데이터를 여러 테이블에 영속할 때 일관성을 유지할 수 있다.

장점에 대해서 정리를 해보자면 다음과 같다.

1. 전반적으로 구조가 매우 간단하다.
2. 초기 개발에 유리하고 빠르게 프로토타입을 개발할 수 있다.
3. 필요한 모든 기능을 한 곳에서 처리할 수 있기 때문에 복잡한 통신 없이 직접 사용이 가능하다.
4. 시스템 장애나 기능에 버그가 있다면 하나의 애플리케이션에서 쉽게 원인 파악을 할 수 있다.
5. 데이터의 일관성을 유지할 수 있다.

 

모놀리식 아키텍처의 단점

하나의 데이터 저장소를 사용하고 하나의 애플리케이션에서 모든 작업에서 처리한다는 장점이 단점으로 다가오게 된다.

하나의 서버에서 여러 기능들을 수행하므로 서비스나 부가적인 기능들이 많아지면 더욱 복잡해질 수 있다.

시스템의 오류가 기능을 업데이트할 경우 서버를 재시작해야 한다.

정리를 해보자면

1. 데이터베이스가 커질수록 더 복잡해지고 유지관리 및 확장이 어려워진다.
2. 일부 기능을 수정하거나 업데이트를 하려면 전체 애플리케이션을 재배포해야 한다.
3. 대규모 모놀리식 애플리케이션에서는 개발이 더욱 복잡해지고 속도가 느려진다.

모놀리틱 아키텍처에서 클라이언트로부터 들어온 요청을 유연하게 처리하기 위해 로드 밸런서를 사용하여 트래픽을 분산시키고,

WAS가 동일한 인스턴스를 여러 개 생성하여 전체 처리량을 늘리는 방법을 스케일 아웃이라고 한다.

이때 로드 밸런서는 클라이언트로부터 들어오는 요청을 여러 서버(WAS, TomCat 등등) 인스턴스로 분산시켜 주는 역할을 한다.

→ 어떠한 아키텍처를 사용하든 클라이언트의 요청 처리 과정은 동일하다.

1. 클라이언트가 애플리케이션에 요청
2. 로드 밸런서에게 요청 전달
3. 로드 밸런서가 존재하는 서버 인스턴스에게 적절하게 트래픽을 분배
4. 이때 관리자나 서버 측에서 설정한 조건이 충족되면 Kubernetes, Docker Swarm 같은 오케스트레이션 도구를 사용하여 스케일 아웃을 통해 서버 인스턴스를 늘린다.
5. 로드 밸런서가 새로 생성된 서버 인스턴스(WAS, TomCat 등등..)에게도 트래픽을 분배한다.                                                              - 그렇게 유연하고 효율적인 트래픽 처리가 가능해진다.
6. 각 서버 인스턴스는 DB를 통해 로직을 처리한다.

 

모놀리식 아키텍처 사용 상황

모놀리식 아키텍처는 이러한 장단점이 확실히 존재한다.

내가 느끼기엔 클라이언트의 요청이 점점 많아지거나, 기능을 주기적으로 수정하여 업데이트하는 일이 많을 경우에는

해당 아키텍처보다는 MSA를 사용하는 것이 훨씬 좋다고 느꼈다. 물론 구조가 더욱 복잡하고 공부할 것이 더 많겠지만 사용자가 모놀리식으로 구성된 서비스를 이용할 때 주기적으로 서버가 재실행되거나, 오류 발생 시 개발자 측에 유지보수나 오류 대응이 힘들기 때문에

모놀리식은 간단한 구조와 빠르게 개발을 진행해야 하는 소규모 프로젝트나 프로토타입을 제작할 때 적합하다고 느꼈다.

 

 

 

 

해당 경로의 모놀리식 아키텍처 이미지를 참고하였습니다.

https://www.atlassian.com/ko/microservices/microservices-architecture/microservices-vs-monolith