❓ MSA (Microservices Architecture)란
: 여러개의 소프트웨어 시스템을 작은 독립적인 서비스로 분할하여 구축하는 아키텍처 패턴
✅ MSA(Microservices Architecture)를 사용하는 이유
MSA의 가장 큰 장점 중 하나는 서비스 간 독립성이다.
즉, 하나의 서비스에 장애가 발생해도 전체 시스템이 멈추는 것이 아니라, 문제가 발생한 서비스만 격리되고 나머지 서비스는 정상적으로 동작할 수 있다.
이러한 구조 덕분에 시스템의 신뢰성과 가용성이 높아지고, 장애 발생 시에도 부분적인 기능은 계속해서 사용자에게 제공할 수 있는 유연함을 갖추게 된다.
MSA는 각 서비스가 독립적으로 동작하기 때문에 이들을 외부와 연결하거나 내부적으로 라우팅해주는 게이트웨이가 필요
🔌 API Gateway가 필요한 이유
- 단일 진입점 제공
클라이언트는 여러 마이크로서비스의 주소를 알 필요 없이, Gateway 하나만 알면 됩니다. - 라우팅 기능
클라이언트 요청을 적절한 서비스로 전달해 줍니다. - 공통 기능 처리
- 인증/인가 (JWT 인증 등)
- 로깅, 모니터링
- Rate Limiting (요청 제한)
- CORS 처리
- 응답 캐싱 등
- 보안 측면 강화
직접 서비스에 접근하지 못하고 게이트웨이만 열어둬도 충분하므로, 내부 서비스는 보호됩니다.
🎯 대표적인 API Gateway 예시
| 솔루션 | 설명 |
| Spring Cloud Gateway | Spring 기반 MSA에서 가장 자주 쓰이며, Java 기반. 필터 및 라우팅 기능 제공 |
| Nginx | L7 계층에서 Reverse Proxy 역할, 정적 파일도 처리 가능 |
| Kong / Ambassador / Istio | Kubernetes 환경에서 많이 사용되는 API Gateway/Service Mesh 솔루션 |
✅ EDA (Event-Driven Architecture)란?
: 이벤트 중심 아키텍처로, 시스템의 구성 요소들이 이벤트를 주고받으며 비동기적으로 통신하는 구조입니다.
🔸 핵심 구성 요소
- 이벤트(Event): 시스템 내에서 발생하는 상태 변화 (ex. 결제 완료, 주문 생성 등)
- 이벤트 프로듀서(Producer): 이벤트를 발생시키는 주체 (ex. 주문 서비스)
- 이벤트 브로커(Broker): 이벤트를 전달해주는 중간 매개체 (ex. Kafka, RabbitMQ)
- 이벤트 컨슈머(Consumer): 이벤트를 받아 처리하는 서비스 (ex. 배송 서비스)
🔸 장점
- 서비스 간 느슨한 결합 → 확장성 & 유지보수 용이
- 비동기 처리 가능 → 성능 향상
- 실시간 데이터 흐름 구축에 유리
✅ 서킷 브레이커(Circuit Breaker)란?
장애 전파를 막기 위한 보호 패턴입니다.
외부 서비스 호출이 계속 실패할 경우, 일정 시간 동안 요청을 차단해 시스템 전체가 무너지지 않도록 합니다.
이를 통해 시스템의 장애 확산을 막고, 장애 복구를 도와주며 사용자는 불필요하게 대기하지 않게 된다.
즉, 서킷 브레이커 패턴은 클라이언트 측면에서 장애를 방지하기 위한 도구로써, 실패할 수 있는 작업을 계속 시도하지 않도록 방지
🔸 동작 방식
- Closed(닫힘): 정상 상태, 요청 전달
- Open(열림): 실패가 일정 수치 이상 발생하면 요청 차단
- Half-Open(반열림): 잠시 요청을 일부 열어보고 회복 여부 테스트
🔸 사용 예시
- 주문 서비스 → 결제 서비스 HTTP 호출
→ 결제 서비스가 죽었을 때 계속 요청하지 않고 차단 후 fallback 처리
🔸 대표 라이브러리
- Resilience4j
- Hystrix (이제는 deprecated)
⚙️ 서킷 브레이커 동작 예시
- 일반적으로 외부 서버는 정상 실행중이므로, 서킷이 닫혀있고 요청이 정상적으로 전달됨
- 외부 서버에 장애 발생
- 요청이 계속해서 실패하고, 회로가 Open 상태가 됨
- 이후의 요청들은 더 이상 전달되지 않고 차단되며, 빠르게 에러 또는 실패 응답을 반환함
- 이후에 외부 서버가 정상적으로 복구됨
- 회로가 Open 상태가 된지 특정 시간이 지나고, Half Open 상태로 변경됨
- 일부 요청들이 외부 서버로 전달되고, 응답에 성공하여 Closed 상태됨
- 모든 요청들이 정상적으로 전달됨
✅ SAGA 패턴
분산 트랜잭션을 처리하기 위한 패턴
각 서비스가 자기 트랜잭션을 독립적으로 수행하고, 실패 시 "보상 작업"을 통해 전체 흐름을 조정합니다.
🔹 핵심 개념
- "원자성"이 없는 MSA 환경에서 트랜잭션 흐름의 일관성을 유지하기 위한 방식
- 성공 → 다음 트랜잭션 진행
- 실패 → 이전 단계들에 대해 보상 작업(Compensation) 수행 (즉, "되돌리는 작업")
🧠 👉 성공하면 보상 ❌ / 실패하면 보상 ⭕
→ "보상 트랜잭션"은 실패했을 때만 실행됩니다.
✅ 클린 아키텍처와 DDD의 관계
클린 아키텍처(Clean Architecture)는 애플리케이션의 핵심 비즈니스 로직(도메인)을 중심에 두고 계층을 구성하는 아키텍처 스타일
이 구조는 도메인 주도 설계(DDD, Domain-Driven Design)의 철학과 매우 잘 어울림
🔸 왜 도메인을 중심으로 잡는가?
- 복잡한 비즈니스 요구사항을 효과적으로 표현하기 위해, 시스템의 중심을 "기술"이 아닌 "도메인 지식"에 둔다
- 클린 아키텍처는 도메인 모델이 외부 기술(프레임워크, DB 등)에 의존하지 않도록 격리
- 이를 통해 비즈니스 규칙의 순수성을 유지하고, 외부 변화(프론트, 인프라)에 강한 시스템을 만든다.
✅ MSA로 분산된 서비스를 하나로 묶는 이유
MSA는 서비스별로 분리되어 있어 유연하고 확장에 유리하지만, 그대로 방치하면 복잡성과 보안 문제가 커질 수 있기 때문에
이들을 하나로 묶는 통합 작업(API Gateway 등)이 필수적이다.
1. 🔐 보안 강화
- 서비스가 분산되어 있으면 외부에서 어떤 경로로 접근이 이뤄지는지 추적하기 어려움
- 게이트웨이를 통해 모든 요청을 한 곳에서 통제하면
인증/인가, SSL, IP 필터링 등의 보안 설정을 일괄 적용 가능
2. 🌀 라우팅 및 진입점 확보
- 클라이언트 입장에서 각 서비스의 주소를 알 필요 없이
하나의 입구(API Gateway)를 통해 어디로 요청을 보낼지 결정할 수 있음 - 즉, "어디로 가야 할지"를 알려주는 네비게이터 역할
3. 🌐 하나의 네트워크처럼 구성
- 서비스들이 물리적으로는 분산되어 있어도,
네트워크 상에서는 하나의 내부 네트워크처럼 묶여야
서비스 간 통신, 모니터링, 로깅이 용이함
4. ⚙️ 모듈화 및 단일 진입점 관리
- API 요청 처리, 인증, 로깅, 장애 대응 등 공통된 기능을 각 서비스에 반복 구현하지 않고,
중앙에서 모듈화하여 관리 가능
5. 🔄 유연성과 확장성 확보
- 서비스 간 결합도를 낮추고,
모듈화된 기능을 단일화된 구조로 관리하면
변경, 추가, 배포가 훨씬 유연해짐
💡 webflux (실시간 통신에서 사용할 예정)
: Spring WebFlux는 논블로킹(Non-blocking), 리액티브(reactive) 방식의 웹 프레임워크
🔹 특징
- Reactive Streams 기반 (Project Reactor)
- 비동기 + 논블로킹 처리 가능
- 실시간 데이터 흐름 처리에 유리 (예: SSE, WebSocket과 조합)
- Mono, Flux 타입을 사용
🔹 실시간 통신과의 관계
- WebFlux 자체가 실시간 통신을 직접 제공하지는 않지만,
SSE(Server-Sent Events), WebSocket 등과 함께 쓰면
실시간 데이터 전송에 최적화된 구조를 만들 수 있어요.
✅ 2. SE / RW란?
🔸 SE (Standard Edition)
- 보통 Java에서는 **Java SE (Standard Edition)**의 줄임말로 쓰입니다.
- → 데스크탑, 서버, 애플리케이션에서 사용하는 기본 Java API 세트
🔸 RW (Read/Write)
- 데이터베이스, 캐시, 스토리지 등에서 자주 나오는 표현
- → 읽기(Read) / 쓰기(Write) 분리 전략 또는 권한 의미
예시:
- RW replica: 읽기/쓰기 모두 가능한 DB 인스턴스
- SE(Read-Only) vs RW(Read-Write) 권한
✅ Kafka를 활용한 CDC와 EDA 구성
Kafka는 이벤트 중심 시스템(EDA)과 Change Data Capture(CDC)를 구현하는 데 매우 적합한 플랫폼입니다.
🔸 CDC(Change Data Capture)란?
CDC는 데이터베이스의 변경 사항(Insert, Update, Delete)을 실시간으로 감지해 이를 이벤트 형태로 Kafka에 발행하는 방식입니다.
→ 기존 시스템을 수정하지 않고도 이벤트 중심 구조로 확장 가능하다는 점에서 매우 유용합니다.
🔸 Kafka Connect + Topic 구조
CDC를 구현할 때 가장 많이 사용하는 조합이 바로 Kafka Connect + Debezium + Topic입니다.
- Kafka Connect: DB와 Kafka를 연결해주는 커넥터 프레임워크
- Debezium: MySQL, PostgreSQL 등에서 변경 데이터를 캡처(CDC)하는 오픈소스 도구
- Kafka Topic: 테이블 단위로 생성됨 (예: customers, orders 등)
👉 쉽게 말해, Kafka Topic은 DB 테이블처럼 생각하면 편합니다.
orders 테이블에 변화가 생기면 → orders Topic에 이벤트가 실시간 발행되는 식입니다.
✅ 왜 EC2만으로 MSA 구성은 한계가 있을까?
🔹 1. Docker 네트워크는 단일 호스트 내에서 묶기는 쉬움
- 같은 EC2 인스턴스 안에 있는 컨테이너들은 bridge network로 묶어서 통신이 가능
- 하지만 EC2 인스턴스 간 컨테이너 통신은 직접 네트워크 구성, 포트 매핑, 보안 설정 등 복잡도↑
🔹 2. EC2 간 네트워킹과 오케스트레이션이 어렵다
- 서비스 디스커버리, 로드밸런싱, 자동 복구(헬스체크), 스케일링 등을 수동으로 관리해야 함
- 즉, 운영 부담이 큼
✅ 그래서 나온 대안: Kubernetes (K8s)
Kubernetes는 컨테이너를 위한 자동화된 오케스트레이션 플랫폼이다.
🌐 Kubernetes의 장점
| 기능 | 설명 |
| 서비스 디스커버리 | 클러스터 내에서 서비스 이름만으로 통신 가능 |
| 로드밸런싱 | 여러 Pod에 트래픽 분산 |
| 자동 복구 | 죽은 컨테이너 자동 재시작 |
| 오토스케일링 | 트래픽 증가 시 자동으로 인스턴스 확장 |
| 롤링 업데이트 | 무중단 배포 가능 |
✅ EC2에서 직접 컨테이너 띄우는 구조보다, K8s 위에서 컨테이너 관리가 훨씬 효율적
✅ Spring Cloud로 MSA 구성 시 기대할 수 있는 것
Spring Cloud는 MSA 시스템에서 필요한 기능들을 자동화된 방식으로 제공한다.
🔧 핵심 구성요소
| 기능 | 라이브러리 |
| API Gateway | Spring Cloud Gateway |
| 서비스 디스커버리 | Eureka, Consul |
| Config 서버 | Spring Cloud Config |
| 로드밸런싱 | Spring Cloud LoadBalancer |
| 장애 회복 | Resilience4j, CircuitBreaker |
| 분산 추적 | Sleuth, Zipkin |
| 메시징 | Kafka, RabbitMQ 등과 연동 가능 |
'Spharos Academy' 카테고리의 다른 글
| Spharos Academy - 포트폴리오 특강 (7) | 2025.06.17 |
|---|---|
| 스파로스 아카데미 로드맵 (2025.03.11) (4) | 2025.03.15 |
| 비전공자, 스파로스 아카데미 6기 백엔드 최종 합격기 🚀 (2) | 2025.03.15 |
