MSA Flashcards
MSA
[정의] 서비스 적시성,확장성 제공위해 Polyglot,API G/W기반 기능단위 서비스 제공 가능하도록 만든 아키텍처
[모놀리틱 한계점] 시스템 확장성 한계, 개발주기(고정 cycle)/운영 한계(적시적 Scale Up/Out 난해)
[특성]
1) 서비스 확장성, 변경 용이성 향상 (기능단위 서비스 분리, 경량화)
2) 지속적 배포 환경 제공 (Agile, DevOps)
3) Cloud기반 운영효율성 제공 (Auto Scale Up/Out, 모듈격리 SPOF 방지)
4) SOA (단일목적 갖는 기능중심의 서비스 구조)
5) Loosely Coupled Elements (서비스간 영향도 최소화한 연계 구조)
6) Bounded Context (독립적인 개발 및 서비스 구조)
* 서비스 적시성의 중요성 향상에 따라 기업의 서비스 아키텍처로 활용 확산 중
* API, Polyglot 구조 기반의 표준화, 개발 다양성을 제공하는 아키텍처 구축 가능
[핵심 구성요소]
1. API 기반 서비스 : HTTP, REST API, URI 표준기술
2. API G/W : End Point통합, API 라우팅, 인증/로깅 공통기능 처리, Gateway Offloading 역할
3. Vertical Slicing : DDD, Polyglot개발 환경, 서비스별 DB 환경
4. DevOps : PaaS기반, CI/CD, Cross Function Team, OSS기반 Tool-chain자동화
* MSA 전환은 조직 및 기술의 급격한 구조적 변화를 야기하므로 도입전략 수립 필요
[장단점]
- (장) 제약없는 언어, DB, 자원 효율성
- (단) 추적성 부족(형상 테일러), 속도저하(클라우드), 디버깅(JUNIT)
[아키텍터 구성]
1. Outer Architecture : External Gateway, Service Mesh, CI/CD 오토메이션
2. Inner Architecture : 서비스 정의, 서비스 API, DB Access 구조
모놀리틱
[정의] 하나의 서비스에 모든 비즈니스 로직이 포함되어 있는 아키텍처
[특징] 일체식 어플리케이션 설계, 여러 개의 모놀리스를 수평으로 확장
[비교] 모놀리틱 vs MSA
- 배포 : 전체 배포 / 기능 단위 독립적 배포
- DB : 단일 DB / 서비스별 다른 종류 DB
- 결합력 : 서비스별 높은 결합력 / 서비스별 낮은 결합력
- 확장성 : 여러 개의 모놀리스를 수평으로 확장 / 서비스 기반의 수직,수평 확장 가능
- 변경성 : 시스템 변화시 전체 모듈에 영향 / 변경 영향도 낮음, 유지보수 용이
- 개발언어 : 선택된 하나의 개발 언어에 의존적 / 다양한 개발 언어 사용
MSA 전환
[전환 필요성]
- 확장성 : API 연계, Loosely Coupled 환경
- 안전성 : 고가용성/고내장성, 분산 아키텍처
- 적시성 : 빠른 CI/CD, Container 기반
[전환 절차]
1. 사전 준비 : MSA 환경 자가 점검, 규모 확장성 고려, Micro 서비스 설계
2. MSA 설계 : MSA 구성, API 설계, 테스트 체계 구성, CI/CD 설계, 모니터링 체계 설계
3. MSA 구축 : MSA 구현 및 배포, MSA 조직 구성, MSA 지속적 교육
SAGA패턴
[정의] MSA환경에서 분산 트랜잭션 없이 데이터 일관성 유지하는 로컬 트랜잭션 메커니즘
[특징] 이벤트 Trigger 기반(서비스의 로컬트랜잭션 완료시 메시지 발행), 보상 트랜잭션 활용(실패시 Rollback 수행)
[전통적 분산 처리의 문제점]
- 성능 : 2PC 방식의 locking으로 성능 이슈 발생
- 장애 : 특정 서비스 장애 발생시 전체 서비스 장애 발생 (SPOF)
[유형]
1. Choreography SAGA (코레오그라피) : 각 서비스 마다 자신의 트랜잭선을 관리하고 상태 변경 이후 이벤트를 발생시켜 다른 서비스로 전달
2. Orchestrator SAGA : 오케스트레이터가 명령을 중계하는 브로커(MessageQueue)를 사용 처리
[트랜잭션] 보피재보
- 1. 보상가능 트랜잭션(Rollback 지원) 2. 피봇 트랜잭션(SAGA의 진행/중단 결정) 3.재시도 가능 트랜잭션(Rollback 불필요 완료 보장 Tx) 4.보상 트랜잭션 (피봇 실패시 이전 단계 변경분 UNDO)
* SAGA 트랜잭션 모델은 ACD로 인한 격리성 부족으로 이상현상 발생, 격리성 보장 방안 필요
[차별화] SAGA 패턴을 활용한 MSA 환경의 격리성 보장 방안 시값교
- 시멘틱 락 (APP 수준의 Lock 제어), 값 다시 읽기(최종정보 확인 통한 Lost Update 방지), 교환적 업데이트
* MSA 환견의 트랙잭션 관리 방안 설계시 높은 동시성 보장 트랜잭션은 2PC, 낮은 가용성 중심 트랜잭션은 SAGA 패턴을 활용하는 방식으로 비즈니스 risk 고려 필요
서킷 브레이커 패턴
[정의] 특정 오류의 전체 서비스 장애 전파 방지 목적 Closed,Open,Half-Open 상태 활용, 오류 기능에 대한 요청 거부 및 Fall-back 통한 장애내성 구현 디자인 패턴
[필요성] 오류전파 방지, 복구 안정성 향상
[구성요소] (상태변경 기준요소)
1. Closed : Application 요청 Routing 수행 (Failure Counter)
2. Open : Application 요청 즉시 실패, 예외 반환 (Timeout, Timer)
3. Half-Open : 제한된 수의 Application 요청 수행 (Success Counter)
* 패턴 구현시 다양한 예외 상황에 대한 처리, 상태전환 시점 결정의 최적화 방안 고려 필요
[차별화] 서킷 브레이커 패턴의 구축 최적화 위한 고려사항
- Fall-back 메시징 활용 : Request에 대한 예외 반환 시 Rule 기반의 대체작업 또는 특정 메시지 Return
- 상태 엔드포인트 모니터링 패턴 활용 : 서비스 상태 테스트 통한 전환 시점 선정
* 최근 MSA 서비스 Mesh 환경의 장애 대응 기술로 활용 확산
서비스 메시
[정의] MSA 트래픽 복잡성 문제를 해결하기 위해 경량화된 Proxy를 이용 내부 통신을 담당하는 분산 아키텍처
[필요성] 상호운용성 향상, 장애 전파 현상 방지, 서비스 검색 기능 강화, 서비스 다운타임 최소화
[구성요소]
- 아키텍처 : Control Plane (트래픽 경로를 설정하고 관리하는 영역), Data Plane(서비스간 Proxy 통해 데이터 흐름 처리)
- 컴포넌트 : Sidecar Proxy(서비스간 트래픽 통제, 보안/로드 밸런싱/장애 처리), Circuit Breaker (장애 전파 차단), Service Discovery(서비스의 IP 및 Port를 동적 탐색)
- 비즈니스 : Business Logic(핵심 비즈니스 기능 수행) , MicroService (Pod 단위 관리)
* 오픈소스 구현체로 쿠버네티스 기반 솔루션인 이스티오(istio)를 주로 사용
[차별화] 서비스 메시 vs API Gateway
- 목적 : 내부 트래픽 라우팅 관리 / 외부 트래픽을 내부에 배포
- 특징 : 분산형 아키텍처 / 중앙 집중형 아키텍처
- 패턴 : SiceCar Proxy 패턴 사용 / Gateway Proxy 패턴 사용
* API Gateway 외부 통신과 Service Mesh 의 내부 서비스 연계로 안정성, 경량성, 확장성 용이한 MSA 구축 가능
사이드카 패턴
[리드] 서비스 메시의 핵심
[정의] 어플리케이션 컨테이너의 변경이나 수정없이 독립적으로 운영가능하게 하는 컨테이너 배치 패턴
[특징] 프록시를 통한 호출, 컨테이너 확장 및 교체 용이, 낮은 상호 의존성
[주요기능]
- 로직 변경 없이 신규 기능 추가 : 사이드카 컨테이너 통한 신기능 추가
- 동적 설정값 변경 : Config Directory 를 감시 변경 사항을 메인 컨테이너에게 전달
- 컨테이너 재사용 : 사이드카 컨테이너 확장
- 간단한 PaaS 구현 : 메인 컨테이너가 실행 환경, 사이트카 컨테이너가 로직을 정의 플랫폼 배치
Service Discovery
[정의] 클라우드기반 분산 서비스 환경에서 서비스의 IP 및 Port를 동적으로 탐색하기 위한 기술
[필요성] 동적 IP 할당(오토스케일링,재할당), 서버 HA 운용(장애시 자동 서비스 전환)
* 탐색 주체에 따라 Client와 Server Side 방식으로 구분
[유형]
1. Client Side Service Discovery : Client가 로드밸런싱 역할
- 서비스 인스턴스의 네트워크 위치를 찾고 로드벨런싱 역할을 클라이언트가 담당
- (구성) : Service Client - (Service Registory) - Service Farm(복수)
- (특징) 개별정책 가능, 개별 적용으로 오버헤드 발생, 클라이언트 난이도 증가
2. Server Side Service Discovery : 별도 Load Balancer가 존재
- Client가 플랫폼 라우터(API GW)로 서비스 호출을 위임하는 방식
- (구성) : Service Client - (LB, Service Registory, Register) - Service Farm(복수)
- (특징) : 중앙집중(클라이언트 난이도 감소), LB 장애 대비 HA 필요
* MSA 구조에서는 일반적으로 API G/W가 서비스 클라이언 요청을 수행
API Gateway
[정의] HTTP/JSON 기반의 경량화된 Restful 통신기반 단일 접점 API 라우팅 지원 서비스 통합 솔루션
[특징] 메시지 경량화(HTTP/Json 기반 REST API), 서비스 단순화(클라이언트 접점 일원화, 라우팅, Proxy 기능), 관리 효율성 향상(인증,인가,사용량 제어, 요청/응답 변조 공통
* 내부 서버-서버 중점의 ESB와 달리 외부 API 서비스 클라이언트 - 서버, 외부-내부 서버 간 확장까지 고려
[주요기능]
- 인증 및 인가 : 인증성, SSL, 프로토콜 변환
- 요청 절차 단순화 : 캐시를 이용한 빠른 응답
- 라우팅/로드밸런싱 : 라우팅 정책, Polyglot 지원
- 오케스트레이션 : 로깅 및 모니터링
MSA 성능 향상 방안
[성능저하] 물리적으로 다른 서버에 존재하는 서비스를 일대다(One-to-Many) 호출 방식은 성능 저하
[성능 향상 방안]
<Network>
1. Inter-Microservice 간 Pub/Sub 통신
- 개념 : Publisher와 Subscriber, 메시지 브로커로 구성된 비동기식 메시징 패턴
- 구성요소 : Client, Producer, Consumer, Broker
- 성능이점 : 비동기, 분산, 확장성
2. Proxy 패턴 기반 Circuit Breaker
- 개념 : 장애가 발생하는 경로를 차단하는 기능 제공
- 구성요소 : Open, Half-Open, Close
- 성능이점 : 장애 확산 방지, 리소스 사용률 향상
2. Proxy 패턴 기반 Rate Limiting
- 개념 : DoS나 요청 트래픽 증폭시 요청의 속도와 회수를 제한하는 Throttling기능
- 구현 알고리즘 : Leaky Bucket, Token Bucket, Sliding Window
- 성능이점 : 서비스 가용성 확보, DDoS 방어
</Network>
메시지 큐
[리드] 메시지 지향 미들웨어 구현
[정의] 다른 응용 프로그램 간 데이터 송수신을 위해 비동기 메시지 이용한 메시지 지향 미들웨어 구현 시스템
[특징] 비동기 처리(Queue 이용 지연처리), 확장성
* Producer가 메시지를 Queue에 넣으면 Consumer가 메시지를 가져가는 처리 방식
[유형]
- RabbitMQ : AMQP 프로토콜, Broker, Exchange (메시지 분배, 공평한 분배, 수신 통보)
- ActiveMQ : Java 메시지 기반 미들웨어 (JMS준수, 다양한 APP 통합, Ajax 지원)
- Kafka : Pub/Sub 모델, Broker, Topic, Offset (고가용성, 확장성, 분산처리 가능)
* Kafka는 대용량 실시간 로그 처리에 특화되어 다양한 환경에서 많이 사용
[차별화] RabbitMQ vs ActiveMQ vs Kafka
- 실시간 모니터링 및 관리 용이, OpenSSL 필요 / 다양한 언어지원, REST API, 모니터링 미지원 / 파일 시스템 저장, 메시지 중복 이슈
