MicroService Architecture를 설명하기 위해서는 Monolithic Architecture의 개념에 대해 이해가 필요하다.

 

1. Monolithic Architecture

 

cloud 등장 이전, 전통적인 IT 환경에서 쓰이는 아키텍처는 Monolithic Architecture라 칭함.
일반적으로 대규모 프로젝트(3~5년 이상의)는 완전무결한 구조로 가고자 하는 니즈가 많다.

완전무결한 구조를 위해 cloud 이전 IT 프로젝트에서는 단일구조 형식을 선호하게 되었음.


* Monolithic Architecture의 특징
1) 단일화된 통합 데이터베이스를 사용
2) 서비스를 이루고 있는 전체 기능을 단 하나의 코드베이스로 개발(일원화된 코드 체계)

 

* Monolithic Architecture의 단점
1) 기술이 끊임없이 바뀌는 환경에서 기존 framework에 의존성이 생기며, 잠재적인 이슈가 발생할 가능성이 커짐.
2) 기능이 많아지고 규모가 커져 복잡해질수록 지속적인 통합/배포(CI/CD) 및 유지보수가 어렵다.
3) SPOF(Single Point of Failure, 한 가지 기능 장애 발생 시 전체 서비스 장애 및 사용불가)가 발생

4) 빠르게 변하는 트렌드를 따라잡기 어렵다. (서비스 수정 시, 배포등을 위해 전체 재기동 등의 이슈가 발생할 가능성이 높음)

-> 위 단점을 해결하고자 전용망과 고가의 HW 구입, 안정적인 유지보수를 제공하는 기업용 SW를 통해 서비스를 개발함
(장애 가능성을 원천적으로 최소화하기 위한 노력)

위와 같은 Monolitic 구조를 어떻게 보완할지에 대한 대응 방안이 바로 MSA

 

 

2. MSA(Mirco Service Architecture)

 

MSA는 기존 IT 체계에서 사용하던 Monolithic Architecture의 단점을 보완하기 위하여 등장하였다.
아마존, 넷플릭스와 같이 cloud 환경을 성공적으로 활용하는 회사들이 공통적으로 도입하고 있는 아키텍처.
서비스들이 다중 복합적으로 구성되어서 사용자에게 하나의 서비스 화면을 만들어주는 형태의 구조.

(아래 아마존 홈페이지 캡처본에서 붉은 테두리로 표기된 각각의 항목이 하나의 서비스) 

아마존 홈페이지(23.05.19)

각 서비스들은 API를 통해 데이터를 송수신하며, 분업을 극대화시킨 구조이다,

 

Monolithic Architecture과 MicroService Architecture를 그림으로 비교하면 아래와 같다.

파란원으로 표기된 Business Logic는 서비스와 동일한 개념이다.

 

출처 : https://sterling.com/microservices-vs-monolithic/

 

* MSA의 구성원칙
1) 단일 책임의 원칙(Single Responsibility) : 각 서비스는 하나의 책임만 가짐.
2) 독립적인 배포(Independently Deployable) : 각 서비스를 독립적으로 배포할 수 있음.
3) 느슨한 결합(Loosely Coupled) : 각 서비스 간 의존성을 최소화함. (서비스 간의 통신은 API를 통해서 진행)
4) 높은 유지성, 테스트 가능성(Highly Maintainable and Testable) : 분리된 서비스별 관리 및 유지가 편하고 테스트도 독립적으로 가능함. (각각 서비스는 변경도 되고 끊임없이 바뀌지만 별도의 다운타임 없이 사용자에게  서비스를 제공해 주는 구성이 가능함.)
5) 팀 단위 구성이 가능(Owned by a Small Team) : 서비스 단위로 팀 구성을 하여 개발/운영이 가능. (DevOps와 이어짐)

* MSA의 장점
1) 서비스별 독립적인 배포가 가능함.
2) 스케일링(Scailing, 특정 서비스 부하로 스케일링이 필요할 경우 해당 서비스만 확장) 가능
3) 장애 대응 용이(전체 서비스 제공에 미치는 영향을 최소화)

-> 일부 서비스에 이슈가 발생할 경우, 이슈가 발생한 서비스만 내리고 나머지 서비스는 제공하므로서, 사용자 입장에서는 이슈가 있었는지도 모를 정도로 유연하게 대응이 가능함.
4) 다중언어(Polyglot, 각 서비스마다 다양한 언어/환경 구성 가능) 지원 -> 신기술 적용이 용이

 

* MSA의 단점

1) 유지보수가 어려움 

(여러 서비스가 합쳐진 통합테스트를 진행하게 될 경우, 통합된 시스템이 아니므로 유지보수의 난이도와 복잡도가 크게 증가한다.)

2) 애매한 업무분장(도메인) (각 서비스별 업무분장, 도메인을 제대로 정하지 않을 경우, 업무에 비효율성을 초래)

 

 

* 왜 MSA 쓰는지?

cloud는 가상화 기능을 사용하게 되고 가상화 기능의 특성상,  물리서버보다 장애에 취약함.
물론 cloud 업체들이 보완기능을 제공하고 있지만, 전통적인 IT 환경보다는 장애 가능성이 더 높다.

-> 장애 취약점을 보완하기 위해 MSA를 활용하기 시작.

'IT > Cloud' 카테고리의 다른 글

클라우드의 비용 체계  (0) 2023.06.22
클라우드의 주요개념  (0) 2023.06.19
Managed Service  (0) 2023.05.15
클라우드의 종류  (0) 2023.05.15
전통적 IT와 클라우드의 차이  (0) 2023.04.30

+ Recent posts