반응형

MSA란?

가장 작은 단위의 서비스로 나눈 독립적으로 배포 가능한 서비스들로 구성하는 구조

 

MSA 장점

  • 필요 서비스만 배포 가능
  • 서비스 확장 가능 (Scale-out) + cloud
  • 신기술 적용 용이

MSA 단점

  • 성능하락  - 서비스간 통신에 많은 비용이 들어감
  • 트랜잭션 - MS간의 통신으로 인한 트랜잭션 관리 힘듦

 

Monolithic -> MSA 로 바꾼 이유

  • 플랫폼 사업 - 필요한 기능만 묶어서 제공  => 다양한 제품군으로 적용 가능
  • 그로 인한 장점은 테스트/배포가 빨라지고, 추후 사업 진행 상황에 따른 scale-out 용이 (=cloud 장점)

 

MSA 의 구성

  • 가장 작은 / 독립된 MS들로 서비스 구성 => DDD(도메인 주도 설계)
  • MS가 많아서 찾기/관리 어려움
    • API Gateway (Zuul,Kong,nginx) : 외부에서 하나의 Endpoint만 알면 접근/관리 가능해서 편리 (+서비스 디스커버리,라우팅, 로드밸런싱, 보안)
      • Non java 서비스는 sidecar로 등록(polyglot) => Eureka는 java 어플
      • Sidecar :  MS의 트래픽을 관리하는 컨테이너를 생성해서 관리
  • MS간의 통신
    • Service Mesh (Istio) : MS간 통신 담당,  API GW와 같은 역할이지만 MSA 내부에서 접근용도
      • API GW와 같은 역할이지만 둘 다 있는 게 효과적 : GW에 먼저 라우팅(인증,에지 라우팅) -> MESH 라우팅(관찰/제어) 점점 통합되는 중...
      • Backing Service (Kafka, RMQ, AMQ) :  큐를 이용한 비동기 통신
  • 개발
    • CI/CD (Jenkins, Gitlab) : 개발 후 소스 통합/배포 자동화
    • 컨테이터 환경 (Docker, k8s) : 서비스들을 실행하는 환경을 관리
  • 모니터링 및 서비스 관리
    • Telemetry (Zipkin+ Sleuth, Grafana, Prometheus, EFK, ELK ) : 서비스 모니터링 및 log/프로세스 추적 가능
반응형

'개발 > MSA' 카테고리의 다른 글

MSA (2) - 아키택쳐 개요 정리  (1) 2021.11.23
MSA(1) - MSA란? (MSA Overview)  (1) 2021.11.22
반응형

 

 

MSA(1) - MSA란? (MSA Overview)

1. MSA 란? "The microservice architectural style is an approach to developing a single application as a suite of small services, each running in its own process and communicating with lightweight me..

fire-programmer.tistory.com

1. Inner architecture

: 내부 서비스를 어떻게 잘 쪼개는지에 대한 설계

 

DDD를 많이 사용하기는 하지만,
Inner Architecture는 비즈니스/서비스/시스템 마다 특성이 달라서 표준이 없다

=> 그래서 가장 어려운 설계이기도 하다 

  1. 마이크로 서비스를 어떻게 정의
  2. DB access 구조를 어떻게 설계
  3. 서비스내 API를 어떻게 설계
  4. 논리적인 컴포넌트 layer를 어떤 방식으로 설계

 

2. Outer architecture
: 서비스들 간의 구조에 대한 설계

  • External Gateway
    • 기능 : 서비스 외부에서 오는 접근을 내부 구조를 드러내지 않고 처리
    • 역할 : 사용자 인증, 권한 정책 관리
    • API Gateway
      : 서버의 앞에서 모든 API 호출을 받아 인증후에 적절한 서비스에 라우팅(메시지 전달) => zuul + Eureka
  • Service Mesh
    • 기능 : 마이크로 서비스 사이 통신 / 네트워크 제어
    • Service discovery, service routing , 트래픽 관리, 보안 을 수행
    • API Gateway와 비슷 (ex. Istio)
  • Container Management
    • 컨테이너 기반의 어플리케이션이 유연성 및 자율성을 갖고, 개발자가 쉽게 접근/운영할 수 있어 MSA에 적합
    • Kubernetes(+Docker)가 가장 대표적인 컨테이너 관리 환경
  • Backing Services
    • 실행중인 어플리케이션이 사용할 수 있는 모든 서비스
      (DB, SMTP. 캐시 시스템과 통신하는 리소스들을 포함하는 개념 )
    • MSA에서는 Message Queue를 이용한 비동기 통신을 지향

      그렇지 않는 다면 여러 서비스를 걸치는 실시간 트랜잭션 처리시, 하나의 서비스가 죽으면 트랜잭션이 끊김 
      -> 서비스 요청 보존 불가 & 에러 발생
      따라서 데이터 변경 or 보상 트랜잭션에 관련된 처리는 Message Queue를 활용한 비동기 처리가 효율적
      Kafka, rabbitMQ, AMQ
  • Telemetry
    • Tele(먼거리) + Metry(측정) 
    • 분산 환경에서 운영되는 MS의 상태를 일일이 모니터링/대응하기 어려움 => Telemetry가 서비스 모티너링 + 서비스별 이슈에 대응 하는 환경 구성
    • Logging + Monitoring + Tracing
    • Grafana, Prometheus, EFK, ELK 등의 OSS로 직접 구현
    • datadog  같은 사용 솔루션 사용
  • CI/CD Automation
    • CI : 지속적인 통합 , CD: 지속적인 전달/배포를 통해 배포가 잦은 MSA의 개발 단계를 자동화 => jenkins, gitlab
반응형

'개발 > MSA' 카테고리의 다른 글

MSA 이해 요약본  (1) 2021.11.24
MSA(1) - MSA란? (MSA Overview)  (1) 2021.11.22
반응형

1. MSA 란?

"The microservice architectural style is an approach to developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms, often an HTTP resource API. These services are built around business capabilities and independently deployable by fully automated deployment machinery."

small services(작은 서비스)
each running in its own process(스스로 실행 가능)
independently deployable(독립적 배포 가능)

-> 작고, 독립적으로 배포가능한 기능을 마이크로 서비스로 나누어, 독립적인 배포/ 다른 기술 스택을 사용 가능

 

2. 기존 Legacy(Monolithic)의 문제점

 

  1. 조금만 수정해도 전체 배포 => (경험담) 배포&재시작만 10분
  2. 서비스를 유연하게 가져가기 힘들다 (scale-out : 서버의 대수를 늘려 처리 능력 향상, scale-up은 서버 자체 용량등을 늘림)
  3. 부분의 장애 -> 전체 장애
  4. 서비스가 커질수록 영향도 파악, 시스템 구조 파악이 어려움

 

3. MSA의 장점 (독립+별도 배포)

  1. 서비스별 배포 가능 (전체 서비스 중단 X )
  2. 특정 서비스 확장 가능 (특히 클라우드 사용에 적합)
  3. 장애 - 부분적 장애에 대한 격리가 수월
  4. 신기술 적용에 유연
  5. 서비스를 polyglot 하게 개발/운영 (=여러 언어를 사용)

사실상, 독립적으로 배포 할 수 있는게 가장 중요

  • 독립 배포 가능 -> 전체 서비스 중단X없이 서비스별 배포 or 확장 가능
  • 독립된 서비스라 장애가 격리되고, 신기술 적용하기 좋음

 

4. MSA의 단점

  1. 성능 하락 - 서비스간 호출시 API를 사용해서 통신 비용 & Latency(지연)이 늘어남
  2. 테스트 / 트랜잭션의 어려움 - 분리된 서비스이기 때문에 트랜잭션의 복잡도가 증가 & 많은 자원이 필요
  3. 데이터 관리 - 데이터가 쪼개져서 여러 서비스에 분산되기 때문에, 한번에 조회하기 어렵고, 정합성 관리가 어려움

 

 

5. Monolithic -> MSA 이유

  1. MS를 조합해서 다양한 플랫폼 서비스 가능(이전에는 주석 처리 or 새 프로젝트 생성)
  2. Scale-out 이 힘들고, lon-transaction은 서비스 구조를 전체 개선해야함
  3. 부분의 장애가 전체의 장애
  4. 여러 컴포넌트가 하나의 서비스에 강하게 결합
  5. 배포 오래걸림

 

반응형

'개발 > MSA' 카테고리의 다른 글

MSA 이해 요약본  (1) 2021.11.24
MSA (2) - 아키택쳐 개요 정리  (1) 2021.11.23

+ Recent posts

티스토리툴바