Spring Cloud Eureka 상세 설정

목차

1. 유레카 설정 구분

2. 자기 보호 모드

3. 레지스트리 등록 여부 / 캐싱 여부

4. 레지스트리 갱신 - 서비스 등록 관련

5. 레지스트리 갱신 - 서비스 해제 관련

6. IP 주소 우선

7. 유레카 피어링 설정

 

 

---

1. 유레카 설정 구분

• eureka.server. : Eureka Server 관련 설정
• eureka.client. : Eureka Client가 레지스트리에서 다른 서비스의 정보를 얻을 수 있는 설정
• eureka.instance. : 이름, 포트 등 현재 Eureka Client에 대한 정보를 재정의하는 설정

 

 

---

2. 자기 보호 모드

2.1 서버 측 설정

• eureka.server.enable-self-preservation
  • 일시적인 네트워크 장애 등으로 인한 서비스 해제를 막기 위한 자기 보호 모드 설정 (default : true, 운영 시에 반드시 true로 설정)
  • true로 설정했을 시에 지정된 시간 안에 Heartbeat가 일정 횟수 이상 들어오지 않아야 서비스가 해제되는데, false로 변경할 경우 지정된 시간 안에 Heartbeat 들어오지 않으면 바로 서비스 제거

eureka:
  server:
    enable-self-preservation: false

 

 

---

3. 레지스트리 등록 여부 / 캐싱 여부

3.1 서버 측 설정

• eureka.client.registrer-with-eureka
  • 레지스트리에 자신을 등록할지에 대한 여부 (default : true)
  • 클러스터링 모드의 Eureka Server 구성은 서로 peering 구성 가능 (Eureka Server 설정에 정의된 peering node 찾아서 레지스트리 정보 동기화)
• eureka.client.fetch-registry
  
  • 해당 인스턴스(서버나 클라이언트)가 다른 Eureka 서버로부터 레지스트리 정보를 가져올지 결정 (default: true)
  • true로 설정 시 원하는 서비스를 탐색할 때마다 Eureka Server를 호출하는 대신, 레지스트리 정보가 로컬로 캐싱되어 확인 가능
  • Eureka 서버 자체에 이 옵션의 값을 false로 적용할 경우, 해당 Eureka 서버가 다른 Eureka 서버로부터 레지스트리 정보를 가져오지 않는 것을 의미
  • 30초마다 Eureka Client가 레지스트리 변경 사항 여부 재확인함

구현할 Eureka Server에서는 자신을 등록하고, 레지스트리의 정보를 로컬로 캐싱할 필요가 없기 때문에 설정 값들을 false로 지정해 줬습니다.

eureka:
  client:
    register-with-eureka: false
    fetch-registry: false

 

3.2 클라이언트 측 설정

설명은 서버 측 설정에서와 동일합니다.

하지만 Eureka Client는 레지스트리에 자신을 등록하고, 레지스트리의 정보를 로컬로 캐싱해서 확인할 필요가 있기 때문에 설정 값들을 true로 지정해 줍니다.

eureka:
  client:
    register-with-eureka: true
    fetch-registry: true

 

3.3 설정 확인

Eureka Client 측의 eureka.client.register-with-eureka 설정에 대한 값을 false로 지정할 경우, 자신을 레지스트리에 등록하지 않는다는 뜻입니다.

따라서 Eureka Server Application을 실행시킨 후, Client로 지정한 서비스를 실행시키고 Eureka Server 측에서 지정한 Port를 사용하여 http://localhost:8761 에 접속해 보면 해당 클라이언트가 보이지 않는 것을 확인할 수 있습니다.

 

 

---

4. 레지스트리 갱신 - 서비스 등록 관련

Eureka Client 등록 시, 최장 딜레이 시간

eureka.server.response-cache-update-interval-ms (Eureka Server의 캐싱 업데이트 주기, 30초)
+
eureka.client.registry-fetch-interval-seconds (서비스 목록을 캐싱할 주기, 30초)
=
60초

 

4.1 서버 측 설정

• eureka.server.response-cache-update-interval-ms
  • Eureka Server의 로컬 캐시를 업데이트하는 주기 (default : 30,000 ms)
    • 이 캐시는 클라이언트로부터의 상태 정보를 포함하며, 서버가 자체 레지스트리 정보(즉, 자신에게 등록된 클라이언트의 상태)를 주기적으로 갱신해 캐시에 저장
  • Eureka Server 실행 후 /eureka/apps API 실행 시 아무것도 나오지 않음
    클라이언트 인스턴스 실행 수 /eureka/apps 실행 시 여전히 아무것도 나오지 않음
    30초가 지나고 /eureka/apps 실행 시 클라이언트 인스턴스 조회됨.
  • Eureka Server의 대시보드 (유레카 서버 IP:8761/) 에 등록된 인스턴스가 표시될 때에는 캐시 사용하지 않음

eureka:
  server:
    response-cache-update-interval-ms: 5000

 

Eureka Server 측에서 eureka.client.fetch-registry: false 로 지정하면
eureka.server.response-cache-update-interval-ms 설정이 의미가 없어지나 했는데 아니었습니다..

Eureka 서버에서 eureka.client.fetch-registry: false로 설정하더라도 서버는 자신에게 직접 등록된 클라이언트의 상태 변화를 계속해서 감지하고 업데이트합니다.
eureka.server.response-cache-update-interval-ms는 Eureka Server 자체에 등록된 Client의 상태 및 캐시를 갱신하는 데 영향을 미치므로 여전히 유효합니다. (캐시 업데이트는 서버가 자신의 레지스트리 정보와 캐시를 일치시키는 주기를 의미하는 것이므로, 다른 Eureka Server의 데이터가 필요 없음..)

즉, eureka.client.fetch-registry: false 설정이 다른 서버로부터 정보를 가져오는 기능에만 영향을 줄 뿐, 자체에 등록된 클라이언트의 상태 갱신 및 캐시 반영에는 영향을 미치지 않습니다.

 

4.2  클라이언트 측 설정

• eureka.client.registry-fetch-interval-seconds
  • 서비스 목록을 설정한 시간마다 캐싱 (default : 30초)
  • eureka.client.fetch-registry 설정 값을 false로 지정했을 경우, eureka.client.registry-fetch-interval-seconds 설정에 대한 값이 무의미해짐 (해당 설정은 Eureka Server로부터 등록된 서비스 목록을 캐싱하는 주기를 결정하는 것인데, eureka.client.fetch-registry: false인 경우 Eureka Server로부터 서비스 목록 캐싱하지 않겠다는 의미이므로)
• eureka.client.disable-delta
  • 캐싱 시에 변경된 부분만 업데이트할 것인지 여부 (default : false)
  • false로 설정 시 대역폭 낭비이므로 true로 설정할 것

eureka:
  client:
    registry-fetch-interval-seconds: 10
    disable-delta: true

 

 

---

5. 레지스트리 갱신 - 서비스 해제 관련

2절에서 설명한 자기 보호 모드(eureka.server.enable-self-preservation) 설정에 대한 값을 false 로 지정해도 레지스트리에서 클라이언트가 등록 해지되는 시간은 오래 걸립니다.

 

그 이유는 아래와 같습니다.

lease-renewal-interval-in-seconds 에 의해 클라이언트는 서버로 30초 (디폴트 값) 마다 Heartbeat를 전송하고,
lease-expiration-duration-in-seconds 에 의해 서버는 Heartbeat를 받지 못하면 90초 (디폴트 값) 동안 하트비트가 수신되지 않으면 서비스 등록을 해지하기 때문입니다.

 

이 2가지 설정들은 서버 내부적으로 클라이언트를 관리하는 로직에 영향을 미칠 수 있으므로 설정을 변경하지 않는 것이 권장됩니다.

 

Eureka Client 등록 해제 시 최장 딜레이 시간

eureka.server.response-cache-update-interval-ms (Eureka Server 의 캐싱 업데이트 주기, 30초)
+
eureka.instance.lease-expiration-duration-in-seconds (Eureka Server 가 마지막 하트비트로부터 서비스 등록 해제 전 대기 시간, 90초)
=
120초

 

5.1 서버 측 설정

클라이언트 등록 해지 작업 시에 서버 측에서도 설정을 변경해 줘야 하는데, 'Evict 백그라운드 태스크' 때문입니다.

클라이언트로부터 Heartbeat가 계속 수신되는지 점검을 하는 태스크인데, 기본 값인 60초마다 실행되기 때문에 아래 설명에 나오는 클라이언트 측의 설정 값들을 작은 값으로 설정해도 서비스 인스턴스를 제거하는데 최대 60초가 소요됩니다.

• eureka.server.eviction-interval-timer-in-ms
  • 클라이언트로부터 Heartbeat가 계속 수신되는지 점검 (default : 60초)

eureka:
  server:
    eviction-interval-timer-in-ms: 10000

 

5.2 클라이언트 측 설정

• eureka.instance.lease-renewal-interval-in-seconds
  • 설정된 시간(second) 마다 Eureka Server로 Heartbeat 전송 (default : 30초)
• eureka.instance.lease-expiration-duration-in-seconds
  • 디스커버리는 서비스 등록을 해제하기 전에, 마지막으로 받은 Heartbeat에서부터 설정된 시간(second) 동안 Heartbeat가 수신되지 않으면 서비스 등록을 해제 (default : 90초)
  • 단, Eureka Instance가 정상적으로 종료된 경우는 레지스트리에서 바로 제거
  • 해당 설정의 값은 'lease-renewal-interval-in-seconds' 보다 커야 함

eureka:
  instance:
    lease-renewal-interval-in-seconds: 3
    lease-expiration-duration-in-seconds: 10

 

자기 보호 모드 설정 값을 false로 설정하고, 위 2개 설정을 한다고 해도 서비스 등록 해지가 바로 되는 것은 아닌데, 그 이유는 서버 측 설명에서 기술한 'Evict 백그라운드 태스크' 때문입니다.

 

---

6. IP 주소 우선

인스턴스는 기본적으로 호스트명으로 등록되는데 DNS 가 없는 경우 hosts 파일에 IP를 등록하지 않으면 인스턴스를 찾지 못하게 됩니다.
eureka.instance.prefer-ip-address 설정을 통해 서비스의 IP 주소를 사용할 수 있지만 만일 장비에서 하나 이상의 네트워크 인터페이스가 있는 경우 문제가 발생할 수도 있습니다.

이럴 때, 아래와 같이 무시할 패턴 또는 선호하는 네트워크 주소를 설정하여 해결할 수 있습니다.

 

6.1 클라이언트 측 설정

• eureka.instance.prefer-ip-address
  • 서비스의 호스트 이름이 아닌 IP 주소를 Eureka Server 에 등록하도록 지정 (default : false)
  • 기본적으로 유레카는 호스트 이름으로 접속하는 서비스를 등록하는데 DNS 가 지원된 호스트 이름을 할당하는 서버 기반 환경에서는 잘 동작하지만, 컨테이너 기반의 배포에서 컨테이너는 DNS 엔트리가 없는 임의의 생성된 호스트 이름을 부여받아 시작하므로, 컨테이너 기반 배포에서는 해당 설정값을 false 로 하는 경우 호스트 이름 위치를 정상적으로 얻지 못함
• spring.cloud.inetutils.ignored-interfaces
  • 해당 인터페이스 무시
• spring.cloud.inetutils.preferred-networks
  • 선호하는 IP 주소 설정

spring:
  cloud:
    inetutils:
      ignored-interfaces: eth1*
      preferred-networks: 192.168

eureka:
  instance:
    prefer-ip-address: true

 

 

 

---

7. 유레카 피어링 설정

여러 대의 Eureka Server 를 사용하면 서로 통신이 가능하도록 구성해 줘야 하는데, 이것을 Peering 구성이라고 합니다.

각각의 Eureka Server는 설정에서 정의한 Peering 노드들을 탐색한 후, 레지스트리의 정보를 동기화합니다.

 

해당 설정은 Eureka Server 를 피어링 하여 사용하는 경우에만 설정합니다.

 

7.1 서버 측 설정

• eureka.server.wait-time-in-ms-when-sync-empty
  
  • Eureka 서버가 시작될 때 레지스트리가 비어 있는 경우, 초기 데이터 동기화를 기다리는 시간을 밀리초(ms) 단위로 지정하는 옵션
    • 만약 이 값이 너무 짧다면, 서버는 레지스트리가 비어 있다고 간주하고 바로 동작
    • 반면, 이 값이 적절히 설정되면 서버는 해당 시간 동안 초기 클라이언트 등록을 기다릴 수 있어, 일정량의 클라이언트 데이터가 레지스트리에 채워진 이후에 동작을 시작
  • 분산 환경에서의 서버 시작: 클러스터 내에서 여러 Eureka 서버가 분산된 환경에서 실행될 때, 서버 간의 레지스트리 동기화에 필요한 시간 동안 대기하도록 할 수 있음
  • Eureka Server 가 시작되고 유레카 피어링 노드로부터 Instance 들을 가져올 수 없을 때 기다릴 시간
  • registry 를 갱신할 수 없을 때 재시도를 기다리는 시간
  • 테스트 시 짧은 시간으로 등록해 놓으면 유레카 서비스의 시작 시간과 등록된 서비스를 보여주는 시간 단축 가능
  • 유레카는 등록된 서비스에서 10초 간격으로 연속 3회의 상태 정보(heartbeat)를 받아야 하므로 등록된 개별 서비스를 보여주는데 30초 소요
• eureka.server.registry-sync-retries
  • 유레카 피어 노드로부터 registry 를 갱신할 수 없을 때 재시도 횟수 (default : 5)

eureka:
  server:
    wait-time-in-ms-when-sync-empty: 3000
    registry-sync-retries: 5

 

 

---

참고

https://docs.spring.io/spring-cloud-netflix/reference/configprops.html

Configuration Properties :: Spring Cloud Netflix

 

https://assu10.github.io/dev/2020/12/05/spring-cloud-eureka-configuration/#71-%EC%84%9C%EB%B2%84-%EC%B8%A1-%EC%84%A4%EC%A0%95

Spring Cloud - Spring Cloud Eureka (상세 설정편)