본문 바로가기
Spring/Cloud

[Spring] 서비스 디스커버리의 시작: Spring Cloud Netflix Eureka

by coding_whale 2026. 4. 10.
반응형

스프링 클라우드 개요와 Spring Cloud Netflix Eureka 정리

스프링 클라우드는 MSA 운영에서 반복되는 문제를 공통 컴포넌트로 해결해주는 생태계이고, Eureka는 서비스 주소를 동적으로 등록/ 조회하는 서비스 디스커버리 서바다.

핵심은 "도입"이 아니라 "운영기준(헬스체크, 만료, 종료 순서)"까지 함께 설계하는 데 있다.

 

Spring Cloud로 MSA 흐름 잡기

클라우드 네이티브 시대의 MSA: 구조, 운영, 그리고 Spring CloudMSA는 서비스를 잘게 나누는 유행어가 아니다.변화 속도를 높이면서도 장애 영향을 줄이기 위한 아키텍처 선택지다.다만 분산 복잡도

myblog01150.tistory.com

 

 

1) 스프링 클라우드 간략 정리

스프링 클라우드는 분산 환경에서 자주 부딪히는 문제를 표준화해 처리한다.
예를 들면 설정 관리, API 게이트웨이, 서비스 탐색, 장애 대응 같은 영역이다.
서비스 수가 늘수록 네트워크 복잡도가 커지는데, 이 복잡도를 코드 안으로 밀어 넣지 않게 해준다.

 

2) Eureka가 하는 역할

Eureka는 서비스 인스턴스의 위치 정보를 관리하는 레지스트리다.
호출하는 서비스는 IP/포트를 직접 알 필요 없이 서비스 이름으로 대상 서비스를 찾는다.

구성 요소

구성 역할
Eureka Server 서비스 등록/조회 저장소
Eureka Client 서버에 등록하고 레지스트리 조회
Service ID 서비스의 논리 이름
Registry Cache 조회 성능을 위한 클라이언트 캐시

 

 

3) 동작 흐름

  1. 서비스 인스턴스가 기동되면 Eureka Server에 자신을 등록한다.
  2. 인스턴스는 주기적으로 heartbeat를 보낸다.
  3. 호출 서비스는 Service ID로 인스턴스 목록을 조회한다.
  4. 목록 중 하나를 선택해 요청한다.
  5. heartbeat가 끊긴 인스턴스는 만료 대상이 된다.

 

 

4) 왜 Eureka가 필요한가

마이크로서비스 환경에서는 오토스케일, 롤링 배포, 장애 복구가 반복되면서 인스턴스가 계속 교체되고, 그때마다 IP와 포트도 함께 바뀐다. 이런 변화를 정적 주소로 관리하면 반영이 늦어져 잘못된 인스턴스로 요청이 가기 쉽고, 결국 호출 실패가 빠르게 누적된다.

Eureka가 필요한 이유는 크게 세 가지다.

1. 주소 하드코딩 제거

  • 호출 서비스가 상대 서비스의 실제 IP/포트를 몰라도 된다.
  • 서비스 이름(Service ID) 기준으로 호출하니 배포/확장 시 코드 수정이 줄어든다.

2. 동적 인프라 대응

  • 새 인스턴스가 뜨면 등록되고, 내려가면 만료/해제된다.
  • 트래픽이 살아 있는 인스턴스로 분산되기 쉬워진다.

3. 운영 복잡도 완화

  • 서비스 위치 정보를 중앙에서 관리하니 추적과 장애 분석이 쉬워진다.
  • 게이트웨이/로드밸런서와 조합할 때 라우팅 정책을 일관되게 가져갈 수 있다.

실무에서는 "도입 자체"보다 "운영 규칙"이 더 중요하다.  
heartbeat 주기, lease 만료, deregistration 순서를 같이 맞춰야 Eureka의 장점이 제대로 나온다.

 

5) 실무 보강 포인트

선택 기준

  • 서비스 수가 적고 인프라가 고정이면 정적 라우팅도 가능하다.
  • 서비스가 자주 늘고 줄면 Eureka 같은 디스커버리가 유리하다.
  • Kubernetes 환경이면 K8s 기본 디스커버리와 Eureka 중 운영 표준에 맞춰 선택한다.

트레이드오프

  • 장점: 동적 환경 대응, 배포 유연성, 주소 추상화.
  • 단점: 운영 복잡도 증가, stale 정보 가능성, 잘못된 정책 설정 시 장애 전파.
  • 결론: 코드 단순화와 운영 복잡도 사이 균형이 필요하다.

 

운영 체크포인트

  • Eureka Server 이중화와 네트워크 가용성 확보.
  • heartbeat/lease/eviction 주기 점검.
  • readiness 이후 등록, 종료 전 트래픽 차단 후 deregistration 순서 보장.
  • 레지스트리 메트릭(갱신 실패율, 만료 수, 등록 수) 알람 설정.

 

6) 자주 발생하는 이슈

  • 등록 직후 아직 준비 안 된 인스턴스로 요청이 가는 문제.
  • 레지스트리 갱신 지연으로 종료된 인스턴스를 계속 호출하는 문제.
  • 종료 순서 불일치로 짧은 시간 5xx가 치솟는 문제.
  • self-preservation 동작을 오해해 장애 대응이 늦어지는 문제.

 

정리

스프링 클라우드는 MSA 운영 복잡도를 프레임워크 수준으로 끌어올려 관리하게 해준다.
Eureka는 그중 서비스 탐색을 담당하며, 동적 인프라에서 특히 효과가 크다.
다만 진짜 안정성은 도입 자체보다 운영 규칙에서 나온다.
heartbeat, 만료 정책, 종료 순서, 이중화까지 함께 설계해야 장애 전파를 줄일 수 있다.

반응형