티스토리 뷰

728x90
반응형

 포스팅에서는 MSA의 개념과 이후 개발 패러다임에 대해 알아보도록 하겠습니다.

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하는 추세로 전환되고 있습니다.

 

Monolithic 아키텍처

기존 legacy System의 경우 monolithic 아키텍처를 따르는 large 어플리케이션들은 다음과 같은 개발/운영상의 문제들에 직면하게 됩니다.

① 일부 모듈의 변경사항 때문에 전체 어플리케이션 개발/운영 프로세스와 패키징에 영향을 준다.

② 모듈별 특성에 맞는 신기술 또는 구조를 적용하기 어렵다.

③ 모듈별 확장이 어렵다.

728x90

 

MSA의 특징

마이크로서비스 아키텍처의 특징은 다음과 같습니다.

① 애플리케이션 로직을 각자 책임이 명확한 작은 컴포넌트들로 분해하고 이들을 조합해서 솔루션을 제공한다.

② 각 컴포넌트는 작은 책임 영역을 담당하고 완전히 상호 독립적으로 배포된다. 마이크로서비스는 비즈니스 영역의 한 부분에서만 책임을 담당한다. 그리고 여러 애플리케이션에서 재사용할 수 있어야 한다.

③ 마이크로서비스는 몇가지 기본 원칙에 기반을 두며, 서비스 소비자와 서비스 제공자 사이의 데이터 교환을 위해 HTTP와 JSON 같은 경량 통신 프로토콜을 사용한다.

④ 애플리케이션은 항상 기술 중립적 프로토콜을 사용해 통신하므로 서비스 구현 기술과는 무관하다. 따라서 마이크로서비스 기반의 애플리케이션을 다양한 언어와 기술로 구축할 수 있다는 것을 의미한다.

⑤ 작고 독립적이며 분산된 마이크로서비스를 사용해 조직은 명확히 정의된 책임 영역을 담당하는 소규모 팀을 보유할 수 있다. 이 팀들은 애플리케이션 출시처럼 하나의 목표를 향해 일하지만, 자기가 개발하는 서비스만 책임진다.

728x90

MSA의 장단점

Microservice가 등장한지는 꽤 되었지만, 사실 중요성을 인지한지는 그리 오래되지 않았습니다. 다만 최근 MSA의 급격한 성장세에 너도나도 뛰어들고 있는 추세입니다. 그렇다면 왜 MSA를 사용하는가에 대한 의문을 갖게되는데요.

바로 다음과 같은 이유입니다.

① 작은 서비스들로 나누고, 각 서비스를 독립적으로 만듦 → loosely-coupled (이로 인해 오는 장점)

② 대용량 분산 환경에 적합

③ 복잡도 감소

④ 유연한 배포

⑤ 재사용성 → 확장성

서비스별 hw/sw 플랫폼/기술의 도입  및 확장이 자유롭다.

개발자가 이해하기 쉽고 개발/운영 매 단계의 생산성이 높다.

지속적인 개발/디플로이가 biz capability 단위로 관련된 소수의 인원의 책임하에 이루어질 수 있다.

fault isolation 특성이 좋다.

 

Microservice의 장점은 위와 같이 강력하지만 이는 단순히 장점만 포함하고 있는 것은 아닙니다. Microservice를 성공적으로 활용하기 위해서는 아래와 같은 문제에 대한 대책을 사전에 마련해야 합니다.

728x90
단점
보완방법

애추적, 모니터링, 매지징이 어렵다.

Sleuth등과 ELK, EFK등의 서비스를 연동하여 사용하는 방안 고려 

여러 서비스에 걸쳐져 있는 feature의 경우, 트랜잭션을 다루기 어렵다.

보상 트랜잭션 또는 부분적으로 composite 서비스로의 병합 고려
여러 서비스에 걸쳐져 있는 feature의 경우, 테스팅이 복잡하다. 테스팅 계획 및 방법에 노력 투자 
서비스 간 dependency가 있는 경우 릴리즈가 까다롭다.

관련 개발조직 간 roll-out 계획 마련 및 dependency의 명백한 관리

서비스 개수가 많고 유동적이기때문에 Continuous Integration/Delivery 및 서비스 관리 상의 문제가 발생할 수 있다. 서비스 레지스트리, 모니터링, 개발~디플로이 자동화 기술 고려 (PaaS 고려)
monolith로 시작한 시스템을 Microservices로 전환할 때 큰 고통이 수반될 수 있다.

B2C웹 또는 SaaS 어플리케이션은 처음부터 Microservices 및 서비스별 조직 구성 고려

References

 

728x90
반응형
댓글
댓글쓰기 폼