[MSA] MSA의 개념과 특징

이 포스트는 K-MOOC의 'Microservice 설계 및 구현' 강의를 개인 학습을 위해 정리한 내용입니다.

---

 

기업의 비지니스 민첩성이 증가하고 있다. Amazon의 어플리케이션 배포 주기는 11.6초

 

Devops 개발 문화

 

기존에는 개발조직과 운영조직이 분리된 문화였지만 최근 변화의 흐름은 개발을 하고 또 운영을 직접 하는 문화로 변화하고있다.

 

어플리케이션 개발을 위해서 인프라 구축에 많은 시간이 소요된다.

서버 구입과 네트워크 연결, 운영체제 설치 및 필요한 소프트웨어 설치에 소요되는 시간이 상당함

그러나 클라우드 기술의 도입과 발전으로 인해 필요에 따라 원하는 만큼(on-demand) 쉽고 편하게 이용할 수 있도록 서비스 형태로 인프라 및 개발환경을 제공한다.

 

이런 클라우드 환경을 조금 더 효과적으로 이용할 수 있도록 어플리케이션 아키텍처도 변화하고 있다. 과거 모노리스 방식의 모든 모듈이 하나의 시스템 안에 패키징되어 배포되는 방식으로 개발이 되었다면 수평확장을 위해 각 모듈을 독립적인 시스템으로 설계하고 이를 연계하여 서비스 하는 'MSA(Micro Service Architecture)' 방식으로 변화되었다.

 

SOA와 MSA

 

MSA는 기존에 없던 패러다임은 아니다. 기존의 SOA라는 아키텍쳐 방식도 하나의 어플리케이션을 여러 개의 서비스 집합으로 구성하려는 노력이 있었으나 이를 더 완성도 있게 제공하는 것이 MSA이다.

 

일체식(monolithic) 어플리케이션 설계

 

사용자 인터페이스와 데이터베이스, 그리고 서버 쪽 어플리케이션으로 구성된다.

서버 쪽 어플리케이션이 일체(monolithic), 즉 논리적인 단일 실행체이다. 아무리 작은 변화에도 새로운 버전을 전체 빌드 해야 하고 단일 프로세스에서 실행된다.

필요한 기능만 확장(scale-out)할 수 없고, 전체 어플리케이션을 동시에 확장해야 한다.

 

마이크로서비스 설계

 

마이크로서비스는 확고한 모듈 경계를 가지며 특정 기능별로 독립적으로 배포, 확장(scale-out)할 수 있다.

서로 다른 언어로 개발되는 것도 허용되며 각 서비스를 서로 다른 팀이 관리할 수 있다.

 

마이크로서비스의 정의

 

여러 개의 작은 서비스 집합으로 개발하는 접근방법

각 서비스는 개별 프로세스에서 실행

HTTP자원 API와 같은 가벼운 수단을 사용하여 통신

서비스는 Biz 기능 단위로 구성

자동화된 배포 방식을 이용/독립 배포

서비스들에 대한 중앙 집중적인 관리는 최소화

각 서비스의 서로 다른 언어와 데이터 저장기술을 사용할 수 있음.

 

콘웨이의 법칙

 

팀의 구조가 시스템에 반영된다. 기존에 대규모 어플리케이션을 나눌 때 UI, 서버 로직, DB와 같이 기술 기준으로 나누었으나 이런 방식의 팀 구조에서는 작은 변화라도 여러 팀의 협업이 필요하며, 시간과 예산이 많이 들어간다.

 

MSA 개발을 위한 조직 구성에는 기술이 아닌 Biz 역량을 중심으로 팀을 나눈다. 팀은 cross-functional한 특성을 가져야 하며 UI, DB, 프로젝트 관리 등 필요한 모든 기술을 갖추어야 한다. Cross-functional 팀은 각 제품을 개발하고 운영할 책임을 가지며, 각 제품은 메세지 버스를 이용하여 통신하는 여러 개의 서비스로 구성한다. 아마존에서 Microservice 팀은 피자 두 판, 12명을 넘지 않도록 했다.

 

분권 거버넌스

 

모든 것을 팀이 알아서 결정한다.

개발 언어, 개발 도구, 프레임워크, 개발 방법론 등 어느 것이든 팀에서 찾아서 활용하고 필요하면 공유한다.

지금 당장 필요한 것만 꼭 개발하며, 불필요한 표준이나 문서 등으로 개발에 방해를 받아서는 안된다.

스크럼 팀은 기본 기술에 대해서만 표준을 따를 뿐, Microservice 내부 구조는 팀이 알아서 결정한다.

 

인프라 자동화

 

CI(Continuous Integration)/CD(Continuous Delivery)

SW 품짐을 위한 테스트 자동화

새로운 환경으로의 배포 자동화(automated deployment)

 

분권 데이터 관리

 

단일 데이터베이스를 유지하는 방식은 벤더의 라이센스 Model과 데이터베이스의 기능 확장에 뿌리를 둔다.

Microservice는 Polyglot Persistence 접근방법을 선택하며, 서비스 별로 데이터베이스를 갖도록 설계한다.

데이터 일관성(consistency)을 유지하기 위해 두 서비스 간의 트랜젝션이 아닌 협업을 강조

데이터 일관성 목표가 조금 늦게 달성되더라도 원래대로 돌려놓는 시나리오가 Biz 개념에 적합

 

똑똑한 끝지점 단순한 파이프

 

통신을 위해서 ESB 등과 같은 똑똑한 제품을 사용 - 라우팅, 변환, 비즈룰, 조율

Microservice는 커뮤니티는 "smart endpoints and dumb pipes" 방식을 선호

도메인 로직은 서비스 속에 높은 결함(high cohesion) 되어야 하고, 연결은 낮은 결합(loose coupling) 되어야 한다.

따라서 REST와 같은 단순한 도구를 WebService, BPEL과 같은 복잡한 도구 보다 선호

HTTP 요청/응답을 자원 API와 함께 사용하거나 경량 메시지 버스 (Rabbit MQ, Zero MQ)를 주로 사용

고운 입자(fine-grained) 인터페이스를 거친 입자(coarse-grained)로 변경하여 사용

 

실패를 위한 설계

 

서비스는 언제든 실패할 수 있으며, 실패해서 더 이상 진행할 수 없을 때, 자연스럽게 대응할 수 있도록 설계해야 한다.

제품화 단계에서 다양한 실패에 대비하여 자동으로 테스트 할 수 있는 환경을 마련해야 한다.

기술 요소와 Biz 내용에 대한 실시간 모니터링 체계를 갖추어야 한다.

이러한 설계는 애플리케이션이 긴급 상황에 빠르고 유연하게 대응할 수 있도록 한다.