1. Micro Services Architecture 란

Monolithic Architecture와 Micro Services Architecture

과거에는 소프트웨어의 모든 구성요소들이 하나의 Application에 통합 개발되어 빌드되고 배포하는 설계가 많았습니다. 이러한 방식을 모놀리식(Monolithic) 아키텍처라고 부릅니다.

 

 

MSA 쇼핑몰이라는 가상의 프로젝트를 예로 들겠습니다.

위의 그림에서 쇼핑몰의 서비스 기능으로 "상품", "배송", "회원관리", "주문" 등이 있으며 각각의 서비스들은 하나의 어플리케이션 안에 기능들이 강하게 결합되어 있습니다.

또한, 하나의 DB에 관련 서비스의 모든 테이블이 포함되어 있습니다.

 

하여, 모든 기능 및 DB가 통합되어 있다보니 다음과 같은 여러가지 한계점이 드러나게 되었습니다.

 

1. 부분 장애가 전체 시스템의 장애로 이어 질수 있다.

만약 주문 서비스의 갑작스러운 트래픽 등의 증가로 모든 자원이 고갈되어 버린다면 전체 시스템의 장애로 이어질 수도 있습니다.

또한 통합 DB에 문제점이 발생한다면 모든 서비스의 문제로 확대되어 질것입니다.

 

2. 결합도가 강하다.

모노로식 아키텍처는 결합도가 높아 특정 부분의 수정이 다른 부분에 영향을 미칠 수가 있습니다.

특히 오랜 기간 프로젝트가 운영되다 보면 공통 기능이 거대해 질수 있는데 이를 수정하면 연계된 부분도 함께 확인하고 테스트 해야 합니다.

이러한 요소는 프로젝트의 개발함에 있어 불필요한 노력이 필요해 집니다.

 

3. 클라우드 환경에 적합하지 못하다.

서비스가 잘되어 인스턴스를 늘려야 할 경우 많이 사용되지 않는 기능까지 불필요하게 확장되어야 합니다.

또한 인스턴스 자동 확장(Auto-Scale Out) 등이 제한적입니다.

• Auto-Scale Out : 트래픽의 부하에 따라 자동으로 서비스 인스턴스의 수를 유연성하게 조절하는 클라우드 기술입니다. 부하가 많을 때는 인스턴스를 자동으로 늘이며, 부하가 작을때는 인스턴스를 줄여 불필요한 자원 낭비를 방지합니다.

 

4. 배포가 용이하지 않다.

전체 프로젝트를 배포해야하기에 항상 부담이 따릅니다. 작은 단위 기능만 독립적인 배포가 어려우며 이에 따라 데브옵스 환경 혹은 지속적인 배포에 어려움이 따릅니다.

 

 

Micro Services Architecture 도입

이러한 단점을 극복하고자 기업들 간에 Micro Services Architecture (MSA) 도입이 활발하게 이루어 지고 있습니다.

(물론 과거에도 SOA와 같은 비슷한 개념이 존재하긴 했지만, 다양한 이슈로 활성화되지 못하였습니다.)

 

 

위의 그림은 조금 전의 모놀리식 MSA 쇼핑몰을 Micro Services Architecture로 구성한 예 입니다.

통합되어 있던 Application과 Database를 "상품", "배송", "회원관리", "주문"의 각각의 서비스별로 작은 단위로 분산하여 구성하며 상호간에 약속된 규격으로 통신합니다. 이로서 만약 하나의 서비스 혹은 DB에서 장애가 발생하더라도 다른 서비스로의 영향은 아주 제한적이게 됩니다.

 

• 대표적인 통신 방식으로는 REST기반의 API 통신이 있으며, 그외에도 Message Queue 등 다양한 통신 프로토콜을  이용 합니다.   
• API Gateway는 외부에의 유일한 진입로 입니다. 자세한 사항은 다음장에서 다룰 예정입니다.

 

또한 개발과 운영 관점에서도 다양한 장점이 존재 합니다.

각 서비스들은 Rest API 등으로 상호간에 규칙만 정의하면 서로의 서비스에 영향을 끼치지 않습니다.

 

하여, 개인 혹은 팀 단위의 서비스들은 오로지 자신의 서비스 개발&운영에 집중할 수 있습니다.

만약 프로젝트에 신규 인력이 투입된다면 모놀리식 프로젝트에서는 해당 신규 인력의 당담업무를 분석하는데 있어 다른 업무와의 연관관계가 높아 를 파악이 어렵지만, MSA 프로젝트에서는 외부와의 Interface만 알면 자신의 업무 파악에

집중할 수 있기에 효율성이 증가됩니다.

 

또한 운영중에도 신규 기능 등의 개발 요구사항이 계속 반영되어야 하기 때문에 작은 서비스 단위의 개발, 테스트, 운영 배포가 용이해집니다.

 

또 다른 장점으로는 모놀리식 아키텍처와 달리 MSA 기반에서는 새로운 언어나 기술의 도입이 쉽습니다.

기존의 운영 서비스들과 Interface만 약속하면 새로 만들어질 서비스에서 원하는 언어와 기술로 개발하면 되니까요.

 

 

Micro Services Architecture 이 만능일까?

물론 이러한 MSA가 완벽한 것만은 아니며, 다양한 단점이 존재합니다.

 

일단 아키텍처 적인 측면에서 단조로운 모놀로식보다 복잡합니다.

다양하게 분산된 서비스들을 관리하고 통신하여 하하며, 장애가 발생하였을 경우 대처하는 방법도 까다롭다 보니 모놀리식 아키텍처에서 신경 쓰지 않아도 될 다양한 이슈들이 발생합니다

 

Dababase의 트랜잭션을 유지하기 어렵다는 것이 큰 이슈 중 하나 입니다.

각 서비스 별로 Database가 분리되어 있다는 것이 단점이 될 수 있습니다.

예를 들어 모놀리식 아키텍처에서는 단 한번의 서비스 요청이 하나의 트랜젝션으로 묶일수가 있어(DB가 하나이기에)

행여 처리중에 오류가 발생하더라도 전체 Rollback이 쉽습니다.

 

하지만, MSA에서는 각 서비스마다 DB가 분리되어 있기 때문에 여러 서비스를 거치다 특정 서비스에서

오류가 발생했을 경우 이미 완료처리된 서비스를 Rollback 하는 것이 쉽지 않습니다.

 

(하지만 Neflix OSS 및 Spring Cloud 프레임워크가 있기에 그나마 MSA를 편리하게 구성할 수 있어 정말 다행이지 않을 수 없습니다. 우리는 이러한 프레임워크를 앞으로 배워나가볼 예정입니다.)

 

다른 이슈로는 최초 프로젝트 시작할 경우 많은 시간과 비용이 발생합니다.

일반적으로MSA로 프로젝트를 진행할 경우 설계 부터 시작하여 다양한 기술들의 결정, 구현, 테스트 등 전반의 과정에서 모놀리식과 비교하여 더 많은 시간과 비용이 발생합니다.

하여 스타트업과 같은 제한된 비용으로 빠르게 출시하는 것이 중요한 프로젝트에서는 처음부터 MSA를 시작하는 것보다 모놀로식으로 빠르게 오픈하고 이후 프로젝트가 더욱 활성화 되는 시점에 MSA를 도입하는 것도 좋은 방안이 될 수 있습니다.

 

또한 모놀리식에서 MSA로 전환시에는 한번에 모든것을 바꿀 필요가 없습니다.

새로운 기능 혹은 기존의 작은 기능부터 하나씩 분리하여 차근차근 전환할 수 있는 것이 MSA의 장점이며 운영중인 프로젝트에 안정한 방법이 될 수 있습니다.

 

 

지금까지 모놀리식 아키텍처와 마이크로서비스 아키텍처를 비교하면서 MSA의 특징을 알아보았습니다.

다음장에서는 이러한 MSA를 구축하기 위해 가장 많이 쓰이는 Spring Cloud(Neflix OSS 포함) 프레임워크의 필수 요소들의 개념을 다루어 보겠습니다.

그 이후 이러한 프레임워크를 활용하여 초간단한 프로젝트를 함께 만들어 봄으로써 MSA의 기초를 탄탄하게 잡도록 하겠습니다.

 

 

참고문헌

 - sabarada.tistory.com/50

 - www.slideshare.net/balladofgale/spring-camp-2018-11-spring-cloud-msa-1

 - www.slideshare.net/balladofgale/spring-cloud-workshop