251112 스프링 MSA 처음 유레카 띄우기

그래들 멀티 모듈이 완성된 이후 다음과 같이 실행합니다.

 

처음 실행하면 "블라블라" 오류가 뜹니다. 한번에 되는 경우는 거의 없습니다.

If you want to disable this check, just set the property [spring.cloud.compatibility-verifier.enabled=false]

 

😎 지금 마이크로서비스에서 EUREKA빌드하려고 하는데, 오류뜨는데?

커서에서 요청하는 문제를 직접 해결하지 않고, 지속적으로 요구..

 

에러가 없어지면 , 브라우저에 다음 포트를 입력 후 엔터 

http://localhost:8761/

 

😎  EMERGENCY! EUREKA MAY BE INCORRECTLY CLAIMING INSTANCES ARE UP WHEN THEY'RE NOT. RENEWALS ARE LESSER THAN THRESHOLD AND HENCE THE INSTANCES ARE NOT BEING EXPIRED JUST TO BE SAFE. --> 유레카에서 이것의 뜻이 뭔가 ?

 

🦜

이 에러 메시지는 Eureka 서버가 인스턴스 상태를 실제보다 “정상(UP)”으로 잘못 표시하고 있을 가능성을 경고하는 로그입니다.
하나씩 풀어보면 다음과 같습니다.

---

1. 메시지 원문 분석

"EMERGENCY! EUREKA MAY BE INCORRECTLY CLAIMING INSTANCES ARE UP WHEN THEY'RE NOT."
→ “긴급 상황! Eureka가 실제로 죽은 인스턴스를 살아 있다고 잘못 표시하고 있을 수 있습니다.”

"RENEWALS ARE LESSER THAN THRESHOLD..."
→ “현재 인스턴스들의 갱신(renewal, 즉 heart-beat) 횟수가 임계치(threshold)보다 적습니다.”

"...AND HENCE THE INSTANCES ARE NOT BEING EXPIRED JUST TO BE SAFE."
→ “그래서 안전을 위해 인스턴스들을 만료(expire)시키지 않고 있습니다.”

---

2. 상황 요약

Eureka는 클라이언트(마이크로서비스)들이 주기적으로 “renew” 요청(heartbeat) 을 보내는 것을 기준으로 인스턴스가 살아 있는지를 판단합니다.
보통 eureka.instance.lease-renewal-interval-in-seconds(기본 30초) 간격으로 renew가 들어오고, 서버는 이를 일정 기간(lease-expiration-duration-in-seconds, 기본 90초) 동안 받지 못하면 “죽었다(OUT_OF_SERVICE)”로 처리합니다.

그런데 지금 메시지는,

• 등록된 인스턴스 수 대비 renew(heartbeat) 횟수가 너무 적게 들어오고 있어서,
• Eureka가 정상적인 네트워크/성능 문제일 수도 있으니 조심하자며
  인스턴스를 바로 만료시키지 않고 “살아 있는 것으로 간주”하고 있다는 의미입니다.

---

3. 왜 이런 일이 생기는가

대표적인 원인은 다음과 같습니다:

• 클라이언트 서비스(Eureka Client)에서 heartbeat 요청이 중단됨
  (예: 애플리케이션 멈춤, 네트워크 단절, Docker 내에서 Health check 실패 등)
• Eureka 서버 부하 또는 GC로 인한 heartbeat 처리 지연
• 클러스터링된 Eureka 간 동기화 지연 (replication 지연)
• renewalPercentThreshold 설정값이 너무 높음
  (기본은 0.85, 즉 85% 이상이 renew를 보내야 정상으로 판단)

---

4. 해결 방법

1. 클라이언트 측 확인
   • 로그에서 DiscoveryClient가 Renewing lease for ... 로그를 주기적으로 남기는지 확인
   • 네트워크 단절 여부, Eureka 서버 URL 설정 확인
2. 서버 설정 점검
   • eureka.server.renewal-percent-threshold를 0.5 정도로 완화 (기본 0.85 → 0.5)
   • eureka.server.enable-self-preservation=false 설정 →
     (임시 조치: 자동 보호 모드 비활성화, 테스트 환경에서만 권장)
   • 서버 부하나 GC로 인해 heartbeat가 밀리는 경우 → 인스턴스 수나 JVM 튜닝 필요
3. Eureka 로그 레벨 조정
   • logging.level.com.netflix.eureka=DEBUG 로 상세한 heart-beat 상태 확인

---

5. 정리

즉,
Eureka가 인스턴스들의 heartbeat가 일정 이하로 떨어졌음을 감지했지만, ‘혹시 네트워크 지연일 수도 있으니’ 일단 죽이지 않고 유지하고 있다는 경고입니다.
이 상태가 지속되면 실제 죽은 인스턴스가 계속 “UP”으로 남아 장애를 유발할 수 있으니,
self-preservation 설정과 클라이언트 renew 상태를 점검해야 합니다.

---

원하신다면 실제 application.yml 에서
Eureka의 self-preservation 비활성화와 threshold 튜닝 예시도 같이 제시해드릴까요?