운영 관점 MSA: Gateway·Discovery·Observability
Discovery·Gateway·Observability로 장애 전파를 통제하고 레이트리밋·서킷브레이커를 운영 장치로 설계하는 방법
요약 (5–7줄)
운영 가능한 MSA의 기준은 “잘 설계됐는가”가 아니라 장애가 났을 때 통제 가능한가다.
Discovery, Gateway, Observability는 기능이 아니라 운영 비용을 선불로 지불하는 장치다.
서킷브레이커는 장애를 막지 못하며, 전파를 늦추고 범위를 제한한다.
레이트리밋은 공정성 문제가 아니라 폭주 시 생존성의 문제다.
관측성은 로그·메트릭·트레이스를 섞는 것이 아니라 각각 다른 질문에 답하게 분리해야 한다.
이 편의 결론은 단순하다: 운영을 고려하지 않은 MSA는 실패한다.
1. 정의
운영 관점 MSA란, 정상 시 성능보다 비정상 시 행동이 정의된 시스템이다.
Discovery/Gateway/Observability는 개발 편의를 위한 도구가 아니라,
장애 시 판단과 개입을 가능하게 하는 인프라다.
2. 직관
운영에서 중요한 질문은 세 가지다.
- 지금 무슨 일이 일어났는가?
- 얼마나 심각한가?
- 왜 그렇게 되었는가?
이 질문에 즉시 답하지 못하면,
아키텍처는 이미 운영에 실패한 상태다.
3. 작동원리 개요
1) 서비스 위치는 고정되지 않는다 → Discovery
2) 외부 트래픽은 통제 지점이 필요하다 → Gateway
3) 문제를 감지·분석·회복해야 한다 → Observability
이 세 축은 함께 작동한다.
하나라도 빠지면 운영은 수동 대응으로 전락한다.
4. Service Discovery (Eureka)
4.1 필요한 조건
- VM 기반 배포
- 서비스 IP가 동적으로 변함
- 인스턴스 수가 수시로 변동
4.2 필요 없는 조건
- 쿠버네티스 환경(개념적으로는 DNS/서비스가 대체)
- 서비스 메시가 위치 추적을 담당
핵심 판단 기준:
“서비스 주소를 코드에 쓰고 싶은가?”
YES라면 Discovery가 필요하다.
5. API Gateway의 책임 범위
5.1 반드시 포함해야 할 책임
- 라우팅: 요청을 어디로 보낼 것인가
- 인증/인가: 최소한의 1차 방어선
- 레이트리밋: 폭주 차단
- 서킷브레이커: 장애 전파 지연
- 관측성 헤더 전파: trace-id, correlation-id
5.2 포함하면 안 되는 책임
- 비즈니스 로직
- 데이터 조합
- 도메인 판단
Gateway는 스마트한 프록시이지
두 번째 백엔드가 아니다.
6. 서킷브레이커 (Resilience4j)
6.1 핵심 파라미터
- failure rate threshold
- slow call threshold
- sliding window size
- wait duration in open state
6.2 가장 흔한 오해
- ❌ “장애를 막아준다”
- ✅ “장애가 전파되는 속도와 범위를 늦춘다”
서킷브레이커는 회복 시간을 벌어주는 장치다.
장애 자체를 제거하지 않는다.
7. 레이트리밋을 Redis로 구현할 때 주의점
7.1 정확성
- 초당 정확한 카운트 vs 근사치
- 토큰 버킷/슬라이딩 윈도우 선택
7.2 분산
- 단일 Redis 장애 = 전체 차단
- 클러스터/복제 고려
7.3 폭주
- 레이트리밋 자체가 병목이 되지 않도록
- 실패 시 fail-open / fail-close 전략 명시
레이트리밋은 보안이 아니라 생존 전략이다.
8. Observability의 3요소
8.1 Logs — “무슨 일이?”
- 사건 기록
- 상세 원인 파악
8.2 Metrics — “얼마나?”
- 수치 기반 상태
- 임계치 감지
8.3 Traces — “왜?”
- 요청 흐름
- 병목/의존성 분석
이 셋을 섞으면 아무 질문에도 답하지 못한다.
각각의 질문을 분리해야 한다.
9. 트레이드오프
- 장점: 빠른 탐지, 제한된 장애 범위, 자동 복구 가능성
- 비용: 인프라 복잡도, 설정·튜닝 부담
운영 인프라는 수익을 만들지 않지만,
없으면 수익을 지킨다.
10. 최소 예시
10.1 Toy 예시: 장애 전파 시나리오
- 서비스 B 다운
- 서비스 A가 동기 호출
- 전체 요청 대기 → 스레드 고갈 → 전체 다운
차단 설계
- Gateway 레이트리밋
- A→B 서킷브레이커
- B 헬스체크 기반 라우팅 제외
결과: 부분 장애로 제한
10.2 실무 예시: 대시보드 핵심 지표 8개
1) 요청 수 (RPS)
2) 에러율 (4xx/5xx)
3) p95/p99 지연
4) 활성 인스턴스 수
5) CPU 사용률
6) 메모리 사용률
7) 외부 의존성 지연
8) 서킷브레이커 상태
이 중 하나라도 안 보이면 운영은 눈 감고 운전이다.
11. 실무 함정 → 해결 패턴
| 함정 | 결과 | 해결 패턴 |
|---|---|---|
| Discovery 미사용 | 하드코딩 | 등록/해제 자동화 |
| Gateway 과도한 책임 | 단일 장애점 | 책임 최소화 |
| 로그만 수집 | 원인 추적 실패 | Trace 연계 |
12. 오해/실수 3개 + 교정
1) “운영은 나중 문제” → 설계 단계 문제
2) “서킷브레이커면 안전” → 전파만 지연
3) “로그만 있으면 된다” → 메트릭/트레이스 필수
13. 판단 기준
사용해야 할 때
- 서비스 수가 3개 이상
- 외부 트래픽 존재
- 부분 장애를 허용해야 함
쓰지 말아야 할 때
- 단일 서비스
- 내부 배치 작업
- 운영 인력 전무
14. 재학습 체크리스트 (10–14)
- 서비스 주소가 코드에 박혀 있는가?
- Gateway 책임이 명확한가?
- 레이트리밋 기준이 정의돼 있는가?
- 서킷브레이커 파라미터를 설명할 수 있는가?
- 장애 시 자동 차단이 가능한가?
- 로그/메트릭/트레이스가 분리돼 있는가?
- trace-id가 전파되는가?
- 외부 의존성 지연을 볼 수 있는가?
- 대시보드가 한 화면에 있는가?
- 알람 기준이 명시돼 있는가?
- 운영 개입 지점이 문서화돼 있는가?
- 부분 장애 시 전체가 살아남는가?