본문 바로가기

끄적대기

MSA : Micro Service Architecture

728x90
반응형

˙MSA : Micro Service Architecture

 

 단일 프로그램들을 각각의 컴포넌트 별로 나누어 구성한 것으로, 각각의 컴포넌트 별로 나누어진 서비스의 형태이다. 각각의 컴포넌트 별로 구성된 서비스들은 독립된 구성으로 서로 다른 서비스와 종속되지 않는다. 따라서, 독립적인 서비스 배포와 운영이 가능하고, Scale-Up/Out*등의 선택적 확장도 서비스 단위별로 가능하고, 장애나 OOM(Out-Of-Memory)등의 서비스 적인 이슈도 서비스 단위별로 최소화할 수 있으며, 빌드 및 테스트 시간에 대한 시간도 최소화할 수 있다. 단, 독립적인 서비스로 이루어졌기 때문에, 통신은 API 호출을 통하여 이루어지기 때문에 속도가 비교적 느리고, 통신에 사용하기 위한 값을 모델로 변환시키는 등의 메모리 작업에 의한 오버헤드가 발생할 수 있다.

 

˙API GateWay

 MSA 구조는 대규모 서비스 내에 각각의 서비스(개발/운영의 아키텍처)로 운영되는 형태로, Client에서 직접적으로 해당 서비스를 직접 호출하는 구조라면, 각각의 서비스별로 인증 등의 공통 로직 필요하다. 수많은 API 관리가 필요하고, 내부 구조적으로 보안이 취약할 수 있다. 따라서, API GateWay를 통하여 모든 API Server에 대한 EndPoint를 단일화하고, 서비스별로 인증 기능을 담당하며, Application 내부에 존재하는 MSA의 라우팅(로드밸런싱)의 역할을 지원한다. Server 또는 Client-Side를 기준으로 하여 Service Discovery*를 구현한다. API GateWay 구성시, 해당 지점에 병목 현상이 발생할 수 있으므로 주기적인 모니터링이 필요한다. 또한, API GatwWay 계층(단계/구조)이 존재함에 따라 통신에 대한 Latency(지연시간)이 발생할 수 있다.

 

 

 

 * Scale-Up/Out : 특정 서버 등에 대하여 성능을 향상(Up) 시키는 행위, 장비를 추가(Out) 시키는 행위

 * Service Discovery : Service Client가 Service를 호출할 때 Service의 위치(IP, PORT)를 알아낼 수 있는 기능

     (클라우드 환경으로 인하여 Service가 동적으로 생성되는 등의 동작으로 인하여, Service IP가 동적으로 변경되는 일이 빈번하게 발생)

728x90
반응형