좋은 MSA 구조의 Application을 개발하려면?
MSA 애플리케이션을 잘 설계하려면
“서비스를 잘게 나누는 것”보다
“운영·배포·장애·설정·관찰까지 한 흐름으로 관리하는 것”이 더 중요하다.
1. REST API 설계
-
통신 표준화
- 서비스 간 통신을 REST API로 통일
- Swagger / OpenAPI 로 스펙 문서화 → 협업·유지보수 용이
-
자원 중심 설계
-
URI는 자원(Resource)을 의미 있게 표현
/users,/orders/{orderId},/products/{productId}
-
HTTP 메서드로 행위 표현
GET조회,POST생성,PUT/PATCH수정,DELETE삭제
-
-
버전 관리
-
API 변경 시 호환성 유지를 위한 버저닝
/api/v1/users,/api/v2/users
-
구버전 삭제 시점까지 병행 운영 전략 필요
-
2. API Gateway 설정
-
단일 진입점
- 외부 요청은 반드시 Gateway를 통해 유입
- 내부 서비스 URL/포트는 외부에 노출하지 않음
-
공통 기능 집중
- 인증/인가, 로깅, 라우팅, Rate Limiting, CORS 등 공통 로직 처리
- Spring Cloud Gateway, Netflix Zuul 등 사용 가능
-
로드 밸런싱·스케일 아웃
- 서비스 인스턴스를 여러 개 띄워 뒤에 숨기고
- Gateway + Service Discovery(Eureka 등)로 트래픽 분산
3. 구성 외부화 (Config)
애플리케이션 코드는 그대로 두고, 설정만 바꿔도 되게 만드는 것이 핵심이다.
-
공통 개념
- 코드와 설정 분리
- 환경별 설정(dev, stage, prod)을 중앙에서 관리
- 재배포 없이 설정 변경 가능하게
-
Spring Cloud Config Server
- Git / Vault 등에 설정 파일을 두고 중앙 관리
- 클라이언트 서비스가 부팅 시 Config Server에서 설정을 가져감
-
그 외 대안
-
Consul (서비스 디스커버리 + KV 저장소)
-
Kubernetes ConfigMap / Secret
-
클라우드 서비스
- AWS SSM Parameter Store, AppConfig
- HashiCorp Vault (비밀·민감 설정 관리)
-
4. 모니터링
-
메트릭·상태 수집
- Spring Actuator로 기본 Health/Metric 엔드포인트 노출
- Prometheus로 시간 기반 메트릭 수집
-
시각화
- Grafana로 대시보드 구성
- CPU, 메모리, 요청 수, 에러율, DB 연결 수 등 시각화
-
경고(Alert)
- 임계치 넘으면 알림(Slack, 메일 등) 발송
- 장애를 “로그 보고 알게 되는 상황”이 아니라 “알림으로 먼저 알게” 만들기
5. 내결함성(Resilience) 패턴
-
Circuit Breaker
- 특정 서비스 호출이 계속 실패하면 회로를 ‘열어서’ 더 이상 호출하지 않게 함
- 즉시 실패 처리 → 장애 전파 방지
- Netflix Hystrix(레거시), Resilience4j(요즘)
-
Fallback
-
서비스 호출 실패 시
- 기본 응답 반환
- 캐시 데이터 사용
- “일부 기능 제한” 모드로 동작
-
사용자 경험을 완전히 끊지 않기 위한 안전장치
-
6. 로깅 및 분산 추적 (추후 DevOps 쪽에서 더 깊게)
-
중앙 로그 수집 (ELK)
- Elasticsearch : 로그 인덱싱·검색
- Logstash : 로그 수집·파이프라인
- Kibana : 로그 시각화 대시보드
-
분산 추적
- trace-id / request-id 를 각 서비스 호출에 같이 전파
- 하나의 요청이 어떤 서비스들을 거쳤는지 추적 가능
- Zipkin, Jaeger, OpenTelemetry 등 활용
- 클라우드 사용 시 AWS CloudWatch + X-Ray 조합도 흔함
7. CI/CD (추후 DevOps에서 더 자세히)
-
자동화 파이프라인
- 빌드 → 테스트 → 배포 전체 자동화
- Jenkins / GitLab CI / GitHub Actions 등 사용
-
테스트
- 단위 테스트, 통합 테스트, E2E 테스트 자동 실행
- 품질 확보 + 배포 속도 향상
-
롤백 전략
- 배포 실패 시 빠르게 이전 버전으로 복구
- Blue-Green, Canary 배포 같은 전략과 함께 사용
Spring Cloud Config Server 정리
1. MSA에서의 구성 관리 개념
- 코드와 설정을 분리
- 환경별로 설정만 바꾸고 동일한 이미지/컨테이너 재사용
- 설정은 환경 변수/Config Server 등에서 주입
2. Config Server 주요 기능
- 중앙 집중식 설정 관리
- 런타임 중 설정 변경 가능 (Refresh 지원)
- Git 등과 연동하여 버전 관리
- 암호화/복호화로 민감 정보 보호
3. Config Server 측 설정
의존성
implementation 'org.springframework.cloud:spring-cloud-config-server'서버 애플리케이션
@SpringBootApplication
@EnableConfigServer
public class ConfigServerApplication {
public static void main(String[] args) {
SpringApplication.run(ConfigServerApplication.class, args);
}
}설정 (application.yml)
spring:
application:
name: config-server
cloud:
config:
server:
git:
uri: [설정 파일이 있는 Git 레포지토리]- Git 로컬/원격 모두 가능
- private 레포지토리는 계정 또는 SSH 키 설정 필요
4. 서비스 인스턴스(클라이언트) 측 설정
의존성
implementation 'org.springframework.cloud:spring-cloud-starter-config'
implementation 'org.springframework.cloud:spring-cloud-starter-bootstrap'bootstrap.yml
spring:
application:
name: user-service
cloud:
config:
uri: http://localhost:8888 # Config Server 주소
name: user-service-config # 가져올 설정 파일 이름 prefixapplication.yml
spring:
config:
import:
- classpath:/bootstrap.yml- bootstrap.yml 이 application.yml 보다 먼저 로딩됨
- 애플리케이션 이름, Config Server 위치 등을 여기서 지정
Spring Boot Actuator 정리
1. Actuator란?
-
Spring Boot 애플리케이션의 상태·메트릭·환경 정보를 노출하는 모듈
-
운영/모니터링에 특화
- health 체크
- 메트릭 조회
- 빈 정보, 환경 정보 등
2. 설정
의존성
implementation 'org.springframework.boot:spring-boot-starter-actuator'기본 경로 변경
management:
endpoints:
web:
base-path: /management # 기본은 /actuator노출할 엔드포인트 설정
management:
endpoints:
web:
exposure:
include: health,info,beans,conditions
exclude: threaddump,heapdump- 민감한 정보가 많으므로 필요한 것만 선택적으로 노출
- 보통 health, info, metrics 중심으로 오픈하고 나머지는 내부에서만 사용
3. 대표 엔드포인트
/actuator/health(또는/management/health)/actuator/info/actuator/metrics/actuator/env/actuator/loggers/actuator/beans/actuator/threaddump/actuator/httpexchanges
운영 환경에서는 보안·인증과 반드시 같이 묶어서 사용해야 한다.
내결함성(Resilience) 패턴과 적용 예시
1. Circuit Breaker & Fallback 핵심
-
Circuit Breaker
- 서비스 호출 실패가 일정 비율/횟수 이상 → 회로 “열림”
- 일정 시간 동안 해당 서비스 호출 차단
- 이후 상태를 다시 보면서 “닫기/반열림” 상태로 복귀
-
Fallback
-
Circuit Breaker가 열리거나 호출이 실패했을 때 실행할 대체 로직
-
예)
- “현재 서비스가 불안정합니다. 잠시 후 다시 시도해주세요.”
- 할인 정보 조회 실패 시, 할인 없이 주문 진행
-
2. Gateway에서 Fallback 처리 예시
-
흐름
- 클라이언트 → Gateway → user-service 라우팅
- user-service 장애/타임아웃 발생
- Gateway의 Circuit Breaker 필터가 감지
fallbackUri: forward:/fallback/user로 포워딩- Fallback 컨트롤러가 기본 응답 반환
-
장점
- 외부 클라이언트는 “서버 에러” 대신 의미 있는 대체 응답을 받음
- 장애가 내부에서 흡수됨
3. Order 서비스에서 User 서비스 호출 시 Resilience4j 적용
-
상황
- order-service가 주문 생성 시 user-service에서 “사용자 등급/포인트”를 조회
- user-service 장애 시 주문 전체가 실패하면 안 되는 경우
-
처리
-
@CircuitBreaker(name = "userServiceCB", fallbackMethod = "fallbackGetUserGrade")적용 -
fallbackGetUserGrade에서는- 로그를 남기고
- 기본 등급/기본 할인 정책으로 주문을 진행하거나
- “등급 적용 없이” 주문만 생성하도록 처리
-
-
효과
- 일부 기능(user-service)이 죽어도 핵심 기능(order 생성)은 유지
- 사용자는 약간의 기능 저하만 체감, 시스템은 전체 장애를 피함
정리하면,
좋은 MSA 애플리케이션은 단순히 서비스들을 “잘게 나눈 구조”가 아니라
- API 설계
- Gateway·인증
- Config 외부화
- 모니터링·로깅·추적
- 내결함성
- CI/CD
까지 한 세트로 설계된 구조다.
이 퍼즐들이 맞춰질수록 시스템은 “변화에 강하고, 장애에도 버티는” 구조가 된다.
개발자 희망자