마이크로서비스 아키텍처(MSA) - #1 모놀리식 아키텍처와 마이크로서비스 아키텍처

모놀리식 아키텍처

기존의 애플리케이션들은 논리적으로 모듈화된 아키텍처라도, 애플리케이션 자체가 WAR 파일 하나로 패키징 된다든지, 시스템을 하나의 실행/ 배포 가능한 컴포넌트로 구성한 모놀리식 아키텍처를 따르는 경우가 많았다.

 

비교적 규모가 작은 애플리케이션일 때는 모놀리식 아키텍쳐는 다음과 같은 장점을 가질 수 있다.

 

- 개발이 간단.

- 통합 테스트가 용이.

- 배포가 쉬움.

- 애플리케이션을 쉽게 변경 가능.

 

그러나 애플리케이션 규모가 커지고, 요즘과 같이 비즈니스 요구사항이 빠르게 변하는 상황에서 모놀리식 아키텍처는 한계점을 가진다.

 

1.  코드베이스가 복잡해짐 : 시간이 지날 수록, 애플리케이션 규모가 커지면 특정 개발자가 모든 코드를 다 이해하기가 힘들어지고, 대규모 개발 조직이 단일 코드베이스를 관리하기 때문에 소통/ 조정 오버헤드가 많이 발생한다는 문제가 존재한다. 

2. 개발 속도의 지연 : 개발자 IDE에서의 실행속도도 느려지고 빌드 시간이 오래걸림. 

3. 커밋부터 테스트, 배포까지 오래걸림 : 한 코드베이스에서 여러 개발자가 작업하기 때문에 머지과정에서 시간이 오래걸리고, 코드베이스가 복잡해지기 때문에 변경 영향도가 제대로 파악이 안되어 CI의 시간이 너무 오래걸린다.

4. 기술 스택의 업그레이드가 어려움 : 애플리케이션 규모가 커지면 새로운 프레임워크, 프로그래밍 언어를 도입하기가 힘들며 초창기 시스템 설계 시 결정했던 것들을 계속 따라야 함. (뒤쳐질 수 밖에 없다)

 

 

마이크로 서비스 아키텍처??

마이크로 서비스 아키텍처는 기존 애플리케이션을 핵심 기능을 기준으로 독립된 서비스로 세분화하여 전체 애플리케이션을 제공하는 아키텍쳐라고 할 수 있다. 각 서비스는 독립적으로 구축할 수 있고 배포할 수 있으며, 독립된 DB를 가진다.

 

The Art of Scalability 라는 책에서는 확장 큐브라는 3차원 확장 모델이 나오는데, 마이크로 서비스를 설명하는 데 도움이 되는 모델이다.

 

- X축 확장(수평 분해 - 다중 인스턴스에 요청을 분산)

• 일반적인 모놀리식 애플리케이션에서의 확장 수단인데, 로드 밸런서 뒷면에 애플리케이션 인스턴스를 N개를 띄워 놓고, 로드 밸런서는 들어온 요청을 여러 방식에 따라서 분배한다. 각 인스턴스들의 상황을 체크하고, 부하에 따라서 로드 밸런서가 요청을 분배시키기 때문에, 애플리케이션의 가용성을 개선할 수 있다는 장점을 가진다. 

 

- Y축 확장(기능 분해 - 기능에 따라 애플리케이션을 여러 서비스로 분해)

• 애플리케이션을 여러 서비스로 분해시키는 것 - 예를 들어, 쇼핑몰 애플리케이션을 주문, 고객, 리뷰 서비스 등으로 분해. 중요한 것은 각 서비스는 cohesive한 책임을 맡아야함.

 

- Z축 확장(데이터 분할 - 요청 속성별 라우팅)

• 인스턴스 별로 분리된 데이터 집합을 처리하도록 설정하는 방법. 각 요청 속성에 맞는 인스턴스로 라우팅한다.

 

마이크로 서비스의 특징 

 

• 각 서비스는 모듈성을 가지고 있음.
• 서비스 마다 DB가 따로 있음 (SOA와 구분되는 특징이라고 생각.) : 서로 느슨하게 결합되어 있으며 오로지 API를 통해서만 통신한다.

 

마이크로 서비스의 장단점.

 

장점

- 지속적인 배포가 가능.

- 서비스 규모가 작기 때문에 관리하기 쉽고, 각 서비스를 독립적으로 배포/ 확장할 수 있음.

- 각 서비스에 특화된 언어 및 프레임워크, DB등을 사용할 수 있음. (새로운 기술을 실험하고 도입하기가 용이)

 

단점

- 시스템 전체를 테스트하거나 배포하기가 어려움.

- 여러 서비스에 걸친 기능을 배포할 때 주의가 필요함.

- 마이크로 서비스 아키텍쳐 도입 시점을 결정하기 어려움.

- 분산 트랜잭션 관리가 까다로움. (모놀리식 아키텍처에서는 DBMS가 제공하는 트랜잭션을 이용할 수 있지만, 마이크로서비스 아키텍처에서는 DB가 나뉘어져 있기 때문에 별도 처리가 필요)