MSA (2) - 아키택쳐 개요 정리

 

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

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
    

• 출처 : 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-2-MSA-Outer-Architecure