MSA 란?

1. MSA 란?

Micro Service Architecture -> MSA

: 하나의 큰 어플리케이션을 여러개의 작은 어플리케이션으로 쪼개어 변경과 조합이 가능하도록 만든 아키텍처

: small services, each runnung in its own process (스스로 동작하는 작은 서비스)
: independently deployable (독립적으로 배포가능)

 

 

 

장점

- 서비스 별 개별 배포 가능: 빠른 요구사항 반영
- 서비스 별 확장 용이: 수정에 대한 전체 시스템에 대한 영향력이 낮음
- 장애가 전체 서비스로 활대될 가능성이 낮음

단점

- 서비스 간 호출에 따른 성능 저하
- 서비스 분리로 인한 테스트/트랜잭션 이 복잡하고 많은 자원 필요로함
- 서비스 분리로 인해 데이터 조회 및 관리가 어려움

 

 

2. MSA 구조

Inner Architecture

- 내부 서비스와 관련된 아키텍처
- 서비스 정의, DB 구조, 내부 API, 컴포넌트 layer 설계 등 내부 시스템 설계
- 정해진 규칙 없음

 

Outer Architecture

- 1. External Gateway
- 2. Service Mesh
- 3. Container Management
- 4. Backing Services
- 5. Telemetry
- 6. CI/CD Automation

 

 

2.1. External Gateway

- 외부로부터 들어오는 접근을 처리하기 위한 요소

- 내부 비즈니스 로직을 드러내지 않음 (보안↑)

- 각각의 서비스에 접근하는 번거로움을 API Gateway 하나로 해결

- API Gateway를 통한 제어: API 를 통한 메시지 전달(routing), REST/JSON 기반

API Gateway 주요 기능 1. 인증 및 인가 (Authentication and Authorization) - 인증: 유저가 누구인지 - 인가: 특정 자원에 대한 권한이 있는지 2. 요청 절차의 단순화 - 클라이언트 / 백엔드 간 API 통신량을 줄여 효율성을 높임 3. 라우팅 및 로드밸런싱 - 클라이언트 요청을 적절한 서비스에 연결(=라우팅) - 서비스 인스턴스들의 부하 분산 4. 서비스 오케스트레이션 (Orchestration) - 여러개의 서비스를 묶어 새로운 서비스를 만들 수 있음 5. 서비스 디스커버리 - 서비스의 위치(예: IP주소 + 포트번호)를 찾는 기능 API Gateway 적용시 고려 사항 1. API Gateway를 내부 마이크로서비스와 결합시 ESB의 문제점(필요하지 않지만 결합을 위한 구현=낭비+복잡)이 발생 2. API Gateway 로 인해 병목현상이 발생 할 수 있다. 3. API Gateway 에 의한 추가적인 계층은 네트워크 latency 를 증가

 

 

2.2. Service Mesh

- 서비스 구성 요소간의 네트워크를 제어하는 역할

- 통신 및 네트워크 기능을 비즈니스 로직과 분리한 네트워크 통신 인프라
- 서비스 간 통신을 추상화하여 안정성, 신뢰성, 탄력성, 표준화, 가시성, 보안성 등을 확보
- 복잡한 서비스 간 통신 상황에서 네트워크를 안정적으로 다루기 위해 등장

 

Service Mesh 기능 - Service Discovery - Load Balancing - Circuit Breaking - Retry and Timeout - TLS - Distributed Tracing - Metrics 수집 - etc... API Gateway 와의 차이 - API Gateway는 서비스 노출부분(External)에 위치하여 내부서비스를 보호 및 제어 - Service Mesh는 내부 서비스(Internal)에 위치하여 서비스를 관리 Service Mesh의 종류 1. PaaS (Platform as a Service) - 일부로 서비스 코드에 포함 (강결합) - 프레임워크 기반의 프로그래밍 모델 2. 라이브러리를 통해 API 로 결합 (중결합) - 프레임워크 라이브러리를 사용 3. Side car proxy를 이용하여 Service mesh를 마이크로서비스에 주입 (약결합) - sidecar proxy 형태로 동작 - 서비스메시와 무관하게 코드 작성 Sidecar pattern? - 어플리케이션 컨테이너에 sidecar 컨테이너가 포함 - sidecar 컨테이너에 주고받는 네트워크 트래픽 처리 (서비스 직접 호출이 아닌 proxy를 통한 호출) - 별도 작업 없이 서비스의 연결, 로깅, 모니터링, 보안, 트래픽 제어 등의 기능 제공

 

 

2.3. Container Management

- 컨테이너 기반 어플리케이션 운영 - 유연성, 자율성 확보

- 예: Kubernetes

2.4. Backing Services

- 어플리케이션이 실행중에 네트워크를 통해 사용할 수 있는 모든 서비스
- 데이터베이스, SMTP(Simple Mail Transfer Protocol) 서비스 등 어플리케이션과 통신하는 Attached Resources 의 포괄적인 개념

- Message queue: 메시지 송/수신자는 메시지 큐를 통해 비동기적으로 통신 수행 -> 데이터 변경/보상에 대한 트랜잭션 션 관리를 효율적으로 하기 위함
- 예: Apache Kafka

 

Message queue 특징 - 비동기 통신 / 약결합 - Redundancy: 서비스가 실패해도 재처리 - Resilence: 전체 시스템에 대한 영향이 적음 - 보장성: queue 에 들어간 Message는 최소 한번은 처리 됨 - 확장성: 다수의 queue 를 두어 요청에 유연하게 확장 가능

 

 

2.5. Telemetry

- Monitoring, Logging, Tracing

- 이슈 대응 환경 구성

 

Monitoring 예 1. 오픈소스: Gafanda, Prometheus, EFK 2. 솔루션: Datadog 3. Public cloud의 SaaS: AWS Cloud watch, GCP Stackdriver, Azure Monitor Logging 예 1. Amazon Elastic Search 2. ELK stack(Elastic Search, Logistash, Kibana) Tracing 예 1. Amazon X-Ray 2. Zipkin Jaeger

 

 

2.6. CI/CD Automation

- 지속적인 통합(Continuous Integration), 지속적인 전달(Continuous Delivery), 지속적인 배포(Continuous Deployment) 의 자동화

 

 

 

* 참고: https://velog.io/@tedigom