MSA 기초 정리

최근 MSA에 관심이 생겨 이것저것 아티클을 보다가 좋은 블로그 포스팅 시리즈를 발견하였습니다.

그냥 흘려보내기가 아까워 보면서 메모를 했는데, 같이 공유하면 좋을 것 같아 포스팅합니다.

자세한 내용은 아래 블로그를 참고해주세요.

https://velog.io/@tedigom/MSA-%EC%A0%9C%EB%8C%80%EB%A1%9C-%EC%9D%B4%ED%95%B4%ED%95%98%EA%B8%B0-1-MSA%EC%9D%98-%EA%B8%B0%EB%B3%B8-%EA%B0%9C%EB%85%90-3sk28yrv0e

MSA 제대로 이해하기 -(1) MSA의 기본 개념

 

MSA의 기본 구조

• inner architecture
  • 내부의 서비스를 어떻게 잘 쪼갤지에 대한 설계
  • 비즈니스, 서비스, 시스템마다 각각의 특성이 있어 딱히 정해진 표준은 없음
  • MSA 설계 시 가장 어려운 부분
  • 요즘은 도메인 단위로 분리하는 사례가 많은 듯?
• outer architecture
  • api gateway
  • service mesh
  • backing service
  • telemetry
  • CI/CD automation

---

API Gateway

• 클라이언트와 마이크로서비스들을 연결해준다
• api서버 앞단에서 모든 api 서버들의 엔드포인트를 단일화해주는 또다른 서버
• 주요 기능
  • 인증/인가 : 공통로직 중복 방지
  • 요청 절차의 단순화 : 클라이언트에서 여러 서비스마다 다른 호출해야하는 불편함을 없애줌
  • 라우팅 및 로드벨런싱 : 클라 요청에 따라 적절한 서비스를 호출 & 서비스 인스턴스 부하 분산
  • 서비스 오케스트레이션 : 다수의 마이크로서비스를 묶어 새로운 서비스를 만드는 개념
  • 서비스 디스커버리 : 클라우드 환경에서는 동적인 환경에서 배포되기 때문에 고정IP가 아님. 이런 서비스의 위치(IP+port)를 찾는 것

---

Service mesh

• 통신 및 네트워크 기능을 비즈니스 로직과 분리한 네트워크 통신 인프라
• api gateway와의 차이점

  	API Gateway	Service Mesh
  라우팅 주체	서버	요청하는 서비스
  적용되는 위치	마이크로서비스 그룹 외부 경계	경계 내부
  아키텍쳐 형태	중앙집중형	분산형
  패턴	Gateway proxy pattern	Sidecar proxy pattern
  역할	내부 서비스를 보호 및 제어	서비스를 관리하는 구조

• 3가지 유형
  • PaaS(Platform as a Service)의 일부로 서비스 코드에 포함
    • MS Azure Service fabric, lagom, SENECA, ...
  • 라이브러리로 구현되어 API 호출을 통해 Service mesh에 결합
    • Spring Cloud, Netflix OSS(Ribbon, Hystrix, Eureka, Archaius), finagle, ...
  • Sidecar proxy pattern을 이용하여 Service mesh를 마이크로서비스에 주입 추천
    • Istio/Envoy, Consul, Linkerd, ... (service mesh 프레임워크들)
• 주요 기능
  • service discovery
  • load balancing
  • dynamic request routing
  • circuit breaking
  • 암호화 (TLS)
  • 보안
  • health check, retry and timeout
  • metric 수집

🚙  Sidecar proxy pattern (컨테이너 배포방식의 경우) 모든 응용 프로그램 컨테이너에 추가로 sidecar 컨테이너가 배포됨 비즈니스 로직이 포함된 실제 서비스와 sidecar가 병렬 구성되어, 서비스 호출에서 서비스를 직접 호출하지 않고 proxy를 통해 호출 가능

---

Backing service

• 어플리케이션이 실행되는 가운데 네트워크를 통해 사용할 수 있는 모든 서비스
• MySQL등의 데이터베이스, 캐시 시스템, SMTP서비스 등 (attached resources)
• 메세지큐를 활용한 비동기 통신 패턴을 많이 사용

이벤트 기반, message queue

• 생산자(producer, publisher)와 소비자(consumer, subscriber) 사이에 위치하는 미들웨어
• 송신자 수신자가 직접 통신하지 않고 메세지큐를 활용하여 비동기적으로 통신
  • 비동기/약결합
  • Redundancy : 서비스 실패하더라도 재처리 가능
  • Resilience : 전체 시스템에 대한 영향 낮고, 회복탄력성 높음
  • 보장성 : 메세지큐에 들어간 메세지는 최소 한번은 처리됨
  • 확장성 : 다수의 메세지큐를 두어 많은 요청에 대해 유연하게 확장 가능

🔠
Redundancy : a situation in which something is unnecessary because it is more than is needed (너무 많아서 노필요. 과잉)
Resilience : the ability of a substance to return to its usual shape after being bent, stretched, or pressed (회복력 굿)

• 만약 api를 직접 호출하면 호출받는쪽에서 장애 발생 시 호출하는 곳 까지도 장애가 번짐
• 메세지큐를 활용하여 트랜잭션 분리하는 전략을 많이 씀
• 장애 발생 시에도 서비스의 영속성 유지 가능
  • 영속성 : event message가 consumer에 전달되는 것을 보장
• 데이터 변경, 보상 트랜잭션 관련한 처리는 메세지큐를 활용한 비동기 처리가 효율적
• Apache Kafka
  • pub/sub구조에 특화된 메세지큐
  • 분산 환경(대용량 및 실시간 처리)에 특화되어 설계되어있음
  • RabbitMQ, ActiveMQ 대비 높은 처리량과 성능
  • 단순 TCP기반 프로토콜 → 낮은 오버헤드
  • 메모리X. 파일시스템에 메세지 저장
  • OS의 페이지캐시 이용 → 빠른 속도
  • consumer가 pull방식으로 메세지 받음
  • batch처리 가능

---

Telemetry

• 분산환경 관리 모니터링 및 서비스별 이슈 대응 환경 구성
• 오픈소스로 직접 구현하는 방법
  • Grafana, Prometheus, EFK, ...
• 상용 솔루션 이용하는 방법
  • Datadog, ...
• SaaS 이용하는 방법
  • AWS Cloud watch, GCP Stackdriver, ...
• 주요 기능
  • monitoring
  • logging : 로그 수집
    • AWS Amazon Elastic Search, EFK(Elastic Search - FluentD - Kibana)
  • tracing : 마이크로서비스 아키텍처에서 발생한 이벤트를 순서대로 나열하여 추적할 수 있게 해주는 기능
    • AWS Amazon X-ray, Zipkin, Jaeger, ..