MSA
Micro Service Architecture
모놀리식 아키텍쳐 VS 마이크로서비스 아키텍쳐
모놀리식 아키텍쳐(Monolithic Architecture)
소프트웨어의 모든 구성요소가 한 프로젝트에 통합되어 있는 서비스
장점
단순한 아키텍쳐로 개발이 편리
배포 방법이 간단함
로드밸런서를 통해 요청을 분산시켜 확장하기 쉬움
디버깅이 쉬움
단점
부분 장애가 전체 서비스의 장애로 확대될 수 있음
서비스의 특정 부분만 스케일 아웃(Scale-Out)하기 어려움
전체 시스템 구조 파악의 어려움
서비스 변경의 어려움과 수정 시 영향도 파악이 힘듦
빌드 시간 및 테스트, 배포 시간의 급증
마이크로서비스 아키텍쳐(MSA)
단일 프로그램을 각 컴포넌트 별로 나누어 작은 서비스의 조합으로 구축하는 방법
컴포넌트각 컴포넌트는 서비스 형태로 구현
API를 이용해 타 서비스와 통신
서비스각 서비스는 독립된 서버로 타 컴포넌트와 의존성을 가지지 않음
독립된 배포 진행
느슨하게 결합된 서비스의 모임으로 구조화하는 서비스 지향 아키텍처(SOA) 스타일의 일종인 소프트웨어 개발 기법
서비스지향 아키텍쳐 (SOA)
대규모 컴퓨터 시스템 구축 시, 애플리케이션의 기능을 비즈니스 적인 의미를 가지는 기능 단위로 묶어서 표준화된 호출 인터페이스(Rest API 등)를 통해 서비스로 구현하고, 이 서비스들을 업무에 따라 어플리케이션을 구성하는 소프트웨어 개발 아키텍처
특징
API를 통해서만 상호작용 가능
접근점(end-point)를 API형태로 외부에 노출하고, 실질적인 세부사항은 모두 추상화
내부 구현로직, 아키텍처, 프로그래밍 언어와 같은 기술적인 사항들은 API에 의해 가려짐
하나의 기능만 수행
마이크로 서비스는 하나의 비즈니스 범위에 맞춰 만들어짐
다양한 언어와 기술로 구축 가능
SOA에서 사용되는 집중화된 관리체계 사용하지 않음
REST등 가벼운 통신 아키텍쳐, Kafka등을 이용한 message stream 주로 사용
데이터 분리
서비스 별 별도의 데이터베이스 사용
DB 종류 별도로 가져 가거나, 같은 DB를 사용하더라도 나누어서 사용
데이터 분산으로 다른 서비스와 의존성 없음
서비스 독립 개발, 배포, 운영 가능
장점
배포
시스템 전체의 중단 없이 필요한 부분만 업데이트 및 배포 가능
실시간으로 요구사항을 반영하는 유연한 대응 가능
확장
특정 서비스에 대한 확장성 유리
클라우드 기반 서비스 사용에 적합
장애
일부 장애가 전체 서비스로 확장될 가능성 적음
부분적으로 발생하는 장애에 대한 격리 수월
단점
모놀리틱 아키텍쳐에 비해 느린 속도
서비스간 호출을 API통신을 이용함으로 속도 느림
통신에 사용하기 위한 값을 데이터 모델로 변환시켜주는 오버헤드 발생
데이터 분리로 인한 문제
다른 컴포넌트의 데이터는 API를 통해 가져와야하므로 성능상 문제 발생
트랜잭션으로 묶을 수 없음
데이터 관리의 어려움
설계의 어려움
MSA는 모놀리식에 비해 상대적으로 많이 복잡함
서비스가 모두 분산되어 있기 때문에 개발자는 내부 시스템의 통신을 어떻게 가져가야 할지 정해야 함
Spring Cloud의 MSA아키텍쳐
Spring Cloud Gateway
Api Gateway를 구현하는 라이브러리
'API Gateway'는 분리되어 있는 서버들의 End-Point를 단일화하여 클라이언트에게 동일한 base url제공
라우팅, 로드밸런싱, 인증 역할 등을 수행
Spring eureka
디스커버리 서비스 서버와 클라이언트를 구현하는 라이브러리
분리되 서비스(클라이언트)의 Ip/Port/InstanceId 정보를 디스커버리 서버에 저장하고, 특정 서비스의 정보가 필요할떄 저장된 서비스 정보를 반환 (e.g Api Gateway에서 서비스에 접근하고자 하는 경우)
Feign
타 서비스에 API로 접근을 지원해주는 Http Client 라이브러리
어노테이션만으로 편리하게 구성가능
다른 Spring Cloud 기술들과 통합이 편리
Spring Config
분산된 서비스의 모든 애플리케이션 설정 정보를 한곳에서 관리
설정파일 수정으로 서버를 재가동해야하는 불편함 해소
Ref
Last updated