[MSA] 마이크로서비스 아키텍처(MSA) 개념에 대해 알아보기

마이크로서비스 아키텍처(MSA) 개념 소개

 

MSA가 도입되기 전의 모습(Monolithic Architecture)

기존에 우리가 사용하던 전통적인 방식의 개발 방법을 모노리틱 아키텍처 스타일이라고 합니다.

사전적 정의대로 한 덩어리의 구조라고 볼 수 있습니다.

 

MSA의 등장배경

MSA와 Monolithic의 비교 출처 - https://kr.tmaxsoft.com/info/storyTView.do?seq=345

< 간단한 온라인 쇼핑몰 monolithic architecture 예시 >

전체 애플리케이션이 하나로 되어있어서 보통 동일한 개발 툴을 사용해 개발되며, 배포 및 테스트도 하나의 애플리케이션만 수행하면 되기 때문에 개발 및 환경설정이 간단합니다. 또한 각 컴포넌트들이 함수로 호출 되기 때문에 성능에 제약이 덜하고, 운영 관리가 용이합니다. 이런 장점 때문에 작은 볼륨의 시스템을 개발할 때는 매우 유용하지만 시스템이 커지기 시작하고 여러 컴포넌트들이 더해지면 문제가 발생하기 시작합니다.

 

< 기능이 추가된 온라인 쇼핑몰의 monolithic architecture 예시 >

위의 예시처럼 이제 온라인 쇼핑몰에 몇몇 기능이 추가되었습니다.

 

👉🏻 Monolithic Architecture는 소프트웨어의 모든 구성요소가 한 프로젝트에 통합되어 있는 형태이다. 웹 개발을 예로 들면 웹 프로그램을 개발하기 위해 모듈별로 개발을 하고, 개발이 완료된 웹 어플리케이션을 하나의 결과물로 패키징하여 배포되는 형태를 말한다. 이런 어플리케이션을 모놀리식 어플리케이션이라 하며, 웹의 경우 WAR파일로 빌드되어 WAS에 배포하는 형태를 말한다. 주로 소규모 프로젝트에서 사용된다.

하지만 일정 규모 이상의 서비스, 혹은 수백명 이상의 개발자가 투입되는 프로젝트에서 Monolithic Architecture는 한계를 보인다. 

• 부분 장애가 전체 서비스의 장애로 확대될 수 있다. 
  
  • 개발자의 잘못된 코드 배포 또는 갑작스런 트래픽 증가로 인해 성능에 문제가 생겼을 때, 서비스 전체의 장애로 확대될 수 있다.
• 부분적인 *Scale-out(여러 server로 나누어 일을 처리하는 방식)이 어렵다.
  • Monolithic Architecture에서는 사용되지 않는 다른 모든 서비스가 Scale-out되어야 하기 때문에 부분 Scale-out이 어렵다.
• 서비스의 변경이 어렵고, 수정 시 장애의 영향도 파악이 힘들다. 
  • 여러 컴포넌트가 하나의 서비스에 강하게 결합되어 있기 때문에 수정에 대한 영향도 파악이 힘들다.
• 배포 시간이 오래 걸린다. 
  • 최근 어플리케이션 개발 방법은 CI/CD를 통한 개발부터 배포까지 빠르게 반영하는 추세이다. 그러나 규모가 커짐에 따라 작은 변경에도 높은 수준의 테스트 비용이 발생하기도 하며, 많은 사람이 하나의 시스템을 개발하여 배포하기 때문에 영향을 줄 수 밖에 없다.
• 한 Framework와 언어에 종속적이다.
  • Spring framework를 사용할 경우, blockchain 연동 모듈을 추가할 때 node.js를 사용하는 것이 일반적이며 강세이다. 그러나 java를 이용하여 해당 모듈을 작성할 수 밖에 없다. 선정했던 framework가 Spring이기 때문이다.

이러한 Monolithic Architecture의 문제점들을 보완하기 위해 MSA가 등장하게 되었다. 기존의 특정한 물리적인 서버에 서비스를 올리던 on-promise 서버 기반의 Monolithic Architecture에서 이제는 클라우드 환경을 이용하여 서버를 구성하는 MicroService Architecture로 많은 서비스들이 전환되고 있다. 

MSA란?

MSA란 마이크로 서비스 아키텍처(Micro Service Architecture)의 약자로 단일 프로그램을 각 컴포넌트 별로 나누어 작은 서비스의 조합으로 구축하는 방법입니다.

 

Microservice는 SOA (Service Oriented Architecture) 의 경량화 버전으로 (Service: 특정 기능의 집합, service의 범위 정의가 중요) 모놀리틱 아키텍처(monolithic architecture)를 쪼개서 독립적으로 구분합니다.

 

Microservice는 독립적으로 디플로이 / 확장 될 수 있는 서비스들을 조합하여 large 어플리케이션을 구성하는 아키텍처 패턴입니다.

 

일반적으로 Service Discovery, API Gateway, Orchestration, Choreography, Context Boundary등의 서비스들의 조합으로 이루어져있습니다.

 

Netflix, Twitter, Amazon, Nike 등의 회사에서 채택한 아키텍처로 소개되면서 '14년 초반부터 현재까지 주목 받고 있습니다. 아키텍처 관련 기술 표준은 없으며 SW벤더들이 기존 제품군(SOA, PaaS, ...)을 Microservices를 지원하기 위한 플랫폼으로서 rebrand하는 추세로 전환되고 있습니다.

 

 

< 온라인 쇼핑몰에 MSA적용 예시 >

각 컴포넌트는 서비스 형태로 구현되고 API를 이용하여 타 서비스와 통신하게 됩니다.

각 서비스는 독립된 서버로 타 컴포넌트와 의존성이 없기 때문에 독립된 배포를 하게 됩니다.

또한 각 컴포넌트가 독립된 서비스로 개발되어있기 때문에 부분적인 확장이 가능합니다.

온라인 쇼핑몰에서 주문 서비스에 트래픽이 증가한다면 해당 서버만 확장을 해주면 됩니다.

 

물론 이처럼 장점만 있는 것은 아닙니다. 모노리틱 아키텍처가 서비스간의 호출이 하나의 프로세스 내에서 이루어지기 때문에 속도가 빠르지만 MSA의 경우 서비스간 호출을 API통신을 이용하기 때문에 속도가 느리고, 통신에 사용하기 위해 값을 데이터 모델로 변환시켜주는 오버헤드가 발생하기도합니다. MSA는 다음과 같은 특징들을 가지고 있습니다.

 

데이터 분리

데이터 저장 시 하나의 DB에 중앙 집중화를 하지 않고 서비스 별 별도의 데이터 베이스를 사용합니다.

DB의 종류를 별도로 가져갈 수도 있고, 같은 DB를 사용하더라도 나누어서 사용하게 됩니다.

데이터가 분산되어있기 때문에 다른 서비스 컴포넌트에 대한 의존성이 없이 서비스를 독립적으로 개발 및 배포/운영 할 수 있지만, 다른 컴포넌트의 데이터를 API통신을 통해 가져와야 하기 때문에 성능상의 문제가 발생 할 수 있고, 트렌젝션으로 묶을 수 없는 문제가 발생하기도 합니다.

 

API Gateway

MSA의 문제점 중 하나는 각 서비스가 다른 서버에 분리 배포되어있기 때문에 서버 URL이 각기 다를 수 밖에 없습니다. 이때 API Gateway는 API 서버 앞 단에서 모든 API 서버들의 End-Point를 단일화하여 묶어주는 역할을 합니다. 또한 거미줄처럼 복잡한 서비스간의 API호출 구조도 단순화 시켜줍니다. 그 외에 라우팅, 로드밸런싱, 인증 역할 등등 여러 역할을 수행합니다.

 

팀의 변화

< 모노리틱 아키텍처에서의 팀 모델 >

기존의 팀 모델은 역할별로 나누어진 모델로 팀을 구분했습니다. 이러한 팀 모델은 인력 관리와 운영에 유연성을 부여하지만 팀간의 커뮤니케이션이 원활하지 않고 협업에 걸리는 시간이 지연되는 경우가 많았습니다.

 

< MSA에서의 팀 모델 >

MSA에서는 서비스 별로 팀을 나누고 서비스 기획에서부터 설계 개발 운영이 팀 내에서 이루어지기 때문에 다른 팀에 대한 의존성이 사라지게 됩니다. 역할별 요청과 피드백이 빨라지고, 때문에 유연하고 지속적인 운영과 개발이 함께하게 됩니다.

 

물론 장점만이 있는 것은 아닙니다. 아무래도 인력 리소스 관리에 어려움이 생기게 됩니다. 각 팀의 역할 담당자들은 기본적인 업무 성숙도를 가지고 있어야 하고, 특히 개발자들은 운영 팀의 고유 영역이었던 인프라 핸들링이 가능해야 합니다. 그리고 이러한 일이 가능하게 된 것은 AWS같은 클라우드 서비스 발달입니다. 직접적인 인프라 운영 없이 클라우드 서비스를 이용하여 개발자가 운영 환경을 설정할 수 있게 되었습니다.

 

요약 및 정리

MSA는 복잡한 웹 시스템에 맞춰 개발된 API기반의 서비스 지향적 아키텍처 스타일입니다. MSA가 유행을 하고 있지만 꼭 정답은 아니고, 업무나 비즈니스 특징에 따라 적절한 아키텍처가 선택됩니다. 근래의 아키텍처 모델은 시스템에 대한 설계뿐만 아니라 팀의 구조나 프로젝트 관리 방법까지 달라지기 때문에 프로젝트에 미치는 영향이 매우 크며, 때문에 거시적인 관점에서 고려할 필요가 있습니다.

 

MSA가 필요하다고 해도 꼭 시작을 MSA로 해야 하는 것은 아닙니다.

MSA가 서비스의 재사용 성, 유연한 아키텍처구조, 대용량 웹 서비스에 적합한 구조 등 많은 장점을 가지고 있지만 개개인의 높은 숙련도가 필요한 편입니다. MSA를 구축한 많은 기업들이 시작은 모노리틱 시스템으로 시작하여 팀원들의 숙련도를 높이고 피드백을 통해 시스템을 발전 시키는 과정에서 MSA로 전환한 사례들도 있습니다. 프로젝트의 목적이나 팀의 상황에 맞는 유연한 선택이 필요합니다. 

MSA의 장단점

MSA의 장점

우선 MSA의 장점에 대해 알아보도록 하겠습니다. MSA는 서비스가 커지면서 생겼던 Monolithic Architecture의 문제점들을 어느정도 보완해 줄 수 있습니다.

• 배포(deployment) 관점
  * 서비스 별 개별 배포 가능 (배포 시 전체 서비스의 중단이 없음)
  • 요구사항을 신속하게 반영하여 빠르게 배포할 수 있음.
• 확장(scaling) 관점
  * 특정 서비스에 대한 확장성이 용이함.
  • 클라우드 사용에 적합한 아키텍쳐.
• 장애(failure) 관점
  * 장애가 전체 서비스로 확장될 가능성이 적음
  • 부분적 장애에 대한 격리가 수월함

이외에도, 신기술의 적용이 유연하고, 서비스를 polyglot하게 개발/운영 할 수 있다는 장점이 있습니다.

MSA의 단점

Monolithic Architecture은 단순한 아키텍쳐인데 비해 MSA는 보다 복잡한 아키텍쳐로, 전체 서비스가 커짐에 따라 그 복잡도가 기하급수적으로 늘어날 수 있습니다.

• 성능 - 서비스 간 호출 시 API를 사용하기 때문에, 통신 비용이나, Latency가 그만큼 늘어나게 됩니다.

• 테스트 / 트랜잭션 - 서비스가 분리되어 있기 때문에 테스트와 트랜잭션의 복잡도가 증가하고, 많은 자원을 필요로 합니다.

• 데이터 관리 - 데이터가 여러 서비스에 걸쳐 분산되기 때문에 한번에 조회하기 어렵고, 데이터의 정합성 또한 관리하기 어렵습니다.

단점	보완방법
장애추적, 모니터링, 매지징이 어렵다.	Sleuth등과 ELK, EFK등의 서비스를 연동하여 사용하는 방안 고려
여러 서비스에 걸쳐져 있는 feature의 경우, 트랜잭션을 다루기 어렵다.	보상 트랜잭션 또는 부분적으로 composite 서비스로의 병합 고려
여러 서비스에 걸쳐져 있는 feature의 경우, 테스팅이 복잡하다.	테스팅 계획 및 방법에 노력 투자
서비스 간 dependency가 있는 경우 릴리즈가 까다롭다.	관련 개발조직 간 roll-out 계획 마련 및 dependency의 명백한 관리
서비스 개수가 많고 유동적이기때문에 Continuous Integration/Delivery 및 서비스 관리 상의 문제가 발생할 수 있다.	서비스 레지스트리, 모니터링, 개발~디플로이 자동화 기술 고려 (PaaS 고려)
monolith로 시작한 시스템을 Microservices로 전환할 때 큰 고통이 수반될 수 있다.	B2C웹 또는 SaaS 어플리케이션은 처음부터 Microservices 및 서비스별 조직 구성 고려

 

 

참조 사이트 : http://clipsoft.co.kr/wp/blog/%EB%A7%88%EC%9D%B4%ED%81%AC%EB%A1%9C%EC%84%9C%EB%B9%84%EC%8A%A4-%EC%95%84%ED%82%A4%ED%85%8D%EC%B2%98msa-%EA%B0%9C%EB%85%90/

 

https://waspro.tistory.com/429

 

https://wooaoe.tistory.com/57