SPRING CLOUD MSA
Spring Cloud는 마이크로서비스 아키텍처(MSA)를 구축하기 위한 일련의 도구를 제공하는 SPRING의 프로젝트다
API Gateway
역할
-
단일 진입점 + 라우팅 + 로드밸런싱
- Spring Cloud Gateway는 시스템의 입구 역할을 하는 API 게이트웨이
- 모든 클라이언트 요청은 gateway의 단일 진입점을 통해 각 서비스로 라우팅
FE → 모든 요청 → API Gateway(단일 진입점) ↓ 라우팅 - 회원 요청 → localhost:8083 (Member Service) - 상품 요청 → localhost:8082 (Product Service)변경 전/후 예시
- 기존 : localhost:8080/member/create, localhost:8080/ordering/create
- 변경 : localhost:8080/member-service/member/create, localhost:8080/order-service/ordering/create
-
공통 기능 처리
- CORS 설정, 토큰 인증 처리 (JWT 검증) 등 서버 공통 사항을 단일 진입점에서 처리하여 중복 방지
장점
- 코드 중복 제거: 각 서비스마다 인증 로직 구현 X
- 빠른 피드백: Gateway에서 에러 발생 시 즉시 FE에 응답
문제점: 서버 확장 시
Order 서버 확장 → 8084 포트 추가
→ API Gateway 코드 수정 → 서버 재시작 필요 ❌
→ **무중단 서비스 원칙 위배**Eureka (서비스 디스커버리)
역할
- Eureka 서버는 모든 마이크로서비스의 위치 정보를 가지고 있으며, 마이크로서비스의 위치를 탐색하는 서비스디스커버리(서비스레지스트리) 역할 수행
- eureka를 통해 마이크로서비스의 위치(IP 주소, 포트)가 변경되어도 서비스명과 매핑된 마이크로서비스의 위치를 자동으로 감지
작동 방식
- 각 MSA 컴포넌트들이 Eureka 서버로 자신의 위치를 등록하고, 서비스들은 유레카에 주기적으로 Heartbeat를 보내어 가용 상태를 알림
- 다른 서비스가 특정 서비스의 위치를 필요로 할 때, Eureka 서버를 통해 조회
- 각 서비스들은 언제든지 확장될수 있기에 port와 ip정보가 고정적이지 않지만, eureka를 통해 고정적인 서비스명으로 각 서비스로 접근가능
서버 확장 시 해결 방식
서비스 등록: 각 서버가 Eureka에 자신의 위치(포트) 등록
동적 조회: API Gateway가 Eureka에 질의 → 사용 가능한 서버 리스트 반환동작 흐름
1. Order 서버(8082, 8084) → Eureka에 등록
2. FE 요청 → API Gateway
3. Gateway → Eureka 질의: "Order 서버 어디있어?"
4. Eureka → "8082, 8084 사용 가능" 응답
5. Gateway → 로드밸런싱으로 분배Gateway의 Eureka 클라이언트가 로드밸런싱을 수행한다.
로드밸런싱은 부하분산 알고리즘으로, Round Robin(순차/무작위), Least Connection(가장 한가한 서버) 등이 있다.
즉, Eureka가 반환한 서버 리스트 중 Gateway가 로드밸런싱 알고리즘으로 분배하는 것
로드밸런싱이란?
Eureka가 반환한 서버들(8082, 8084) 중
Round Robin 또는 부하량 기준으로 균등 분배
서비스 간 통신도 동일
Order ←→ Eureka ←→ Product
Order ←→ Eureka ←→ Member결과: 서버 추가/제거 시 코드 수정 없이 자동 대응, 무중단 확장 가능
서비스 모듈 간 통신
- 동기 통신
- 비동기 통신
예시 시나리오) Order ↔ Product: 재고 조회 → 주문 발생 → 재고 감소
재고 조회는 Product에서 반드시 기다렸다가 주문을 발생해야 하므로 HTTP 요청으로 동기 처리
하지만 재고 감소는 비동기로 처리
주문 발생 → Kafka 메시지 발행 → Product가 메시지 소비 → 재고 감소설계 이유
재고 조회: 동기(HTTP) ← 정확성 최우선
재고 감소: 비동기(Kafka) ← 성능 최우선, 재고 일관성보다 처리량 중시장점 (Kafka 비동기)
- HTTP 동기 재고 감소의 문제: Product 서버 다운 → 재고 감소 실패
- Kafka 비동기 장점:
- Product 서버 다운 중에도 메시지 저장 보장
- 서버 복구 → 누적 메시지 순차 처리
- 메시지 안정성 확보 → 비동기 이벤트 기반 통신
MSA 부가 개념
Config Server
환경 설정 중앙화
각 서비스별 분산된 설정:
• Member: DB URL, Redis 호스트
• Order: Kafka 토픽, DB 연결정보
• Product: Redis TTL, DB 풀사이즈
→ Config Server로 통합 관리장점
• 설정 변경 → 각 서버 재시작 ❌
• Git 연동 → 코드처럼 버전관리
• 환경별 설정(Dev/Staging/Prod) 분리Circuit Breaker
"회로 차단기" 패턴
정상: Order → Product (HTTP 호출)
↓ Product 느리거나 불안정
서킷 OPEN → Order 즉시 실패 응답 (대기 X)
↓ 일정시간 후
서킷 HALF-OPEN → Product 테스트 호출
↓ 성공 → CLOSE / 실패 → OPEN 유지상태 전환
CLOSED → OPEN: 연속 실패 N회
OPEN → HALF: 일정시간 경과
HALF → CLOSED: 테스트 성공Product 서버 문제 예시
1. 완전 다운 → Circuit Breaker OPEN → 빠른 실패 응답 ✓
2. 좀비 상태(응답 30초) → 사용자 대기 30초 → 타임아웃
→ Circuit Breaker가 3초 내 응답없음 판단 → OPEN ✓결과: 느린 서버로부터 빠른 실패 보장, 시스템 전체 안정성 확보
Eazy하게