728x90
MSA(Microservices Architecture) 서비스는 하나의 애플리케이션을 여러 개의 독립적인 마이크로서비스로 나누어 개발, 배포, 운영하는 아키텍처입니다. 이 방식은 각각의 서비스가 독립적으로 작동하며, 특정 도메인 기능에만 집중하도록 설계됩니다.
MSA 서비스를 구현하려면, 시스템을 독립적인 마이크로서비스로 나누고 이를 연결하는 기반을 마련해야 합니다. 이를 구현하기 위한 과정을 이커머스 플랫폼 예제를 중심으로 자세히 설명하겠습니다.
1. 서비스 설계
먼저 각 서비스를 분리합니다. 이커머스 플랫폼의 경우 다음과 같이 나눌 수 있습니다:
- 사용자 서비스: 사용자 등록, 인증, 프로필 관리.
- 상품 서비스: 상품 등록, 조회, 수정.
- 주문 서비스: 주문 생성, 상태 관리.
- 결제 서비스: 결제 처리 및 상태 관리.
- 추천 서비스: 개인화된 상품 추천.
설계 원칙
- 단일 책임 원칙(Single Responsibility Principle): 각 서비스는 하나의 기능에만 집중.
- 독립 배포: 하나의 서비스가 업데이트되더라도 다른 서비스에 영향을 주지 않아야 함.
- 독립 데이터베이스: 각 서비스가 독립적인 데이터베이스를 관리(Ex. 사용자 서비스: MongoDB, 주문 서비스: MySQL).
2. 통신 방식 결정
서비스 간 통신은 다음 중 하나를 사용합니다:
- 동기 통신: REST API, gRPC
- 예: 사용자 서비스가 주문 서비스에 사용자 정보를 요청.
GET /users/{userId} HTTP/1.1 Host: user-service.example.com - 비동기 통신: 메시지 큐(Kafka, RabbitMQ)
- 예: 주문 생성 시 결제 서비스로 메시지를 전달.
{ "orderId": "12345", "userId": "67890", "totalAmount": 100.00 }
3. 데이터 관리
데이터베이스 선택 및 분리
- 사용자 서비스: MongoDB (NoSQL)
- 상품 서비스: PostgreSQL (SQL)
- 주문 서비스: MySQL (SQL)
- 결제 서비스: Redis (빠른 트랜잭션 로그 저장)
데이터 일관성
- 이벤트 소싱(Event Sourcing) 또는 사가 패턴(Saga Pattern) 을 활용해 분산 트랜잭션 관리.
4. 배포 환경 설정
컨테이너화
모든 서비스는 Docker를 사용해 컨테이너화.
- Dockerfile 예시 (사용자 서비스):
FROM node:16 WORKDIR /app COPY package*.json ./ RUN npm install COPY . . CMD ["npm", "start"]오케스트레이션
Kubernetes를 사용해 서비스 배포 및 관리.
- Kubernetes Deployment 예시:
apiVersion: apps/v1 kind: Deployment metadata: name: user-service spec: replicas: 3 selector: matchLabels: app: user-service template: metadata: labels: app: user-service spec: containers: - name: user-service image: user-service:latest ports: - containerPort: 30005. API Gateway
API Gateway를 통해 클라이언트 요청을 라우팅.
- 역할:
- 인증 및 권한 관리.
- 요청 로드 밸런싱.
- 서비스 간 통신을 단순화.
- 도구: Nginx, Kong, AWS API Gateway.
- 예: https://api.example.com/orders → 주문 서비스로 라우팅.
6. 모니터링과 로깅
도구
- 모니터링: Prometheus, Grafana
- 로깅: ELK Stack (Elasticsearch, Logstash, Kibana)
예시
- Prometheus 메트릭으로 각 서비스의 CPU 사용량 및 요청 처리량 추적.
- Kibana 대시보드에서 주문 실패 로그를 분석.
7. 실제 워크플로우
주문 생성 프로세스 예시
- 사용자 요청: 클라이언트가 상품 구매 요청을 API Gateway에 전송.
- POST /orders
- 주문 서비스: 주문 생성 후 메시지 큐에 결제 요청 메시지를 발행.
- 결제 서비스: 메시지를 소비하고 결제를 처리. 성공 시 상태 업데이트.
- 주문 서비스: 결제 완료 이벤트를 수신하고 최종 주문 상태를 업데이트.
8. 장점과 고려 사항
장점
- 독립 배포 및 확장 가능.
- 기술 스택 다양성 허용.
- 장애 격리가 가능.
고려 사항
- 초기 설정 및 설계 복잡성.
- 서비스 간 통신 실패 처리.
- 로그 및 모니터링의 추가적 관리.
728x90