들어가며
이번 시간에는 유레카에 대해서 정리한다. 기본적인 개념 정리와 테스트에 대핸 내용을 정리했다.
시리즈 1 - MSA
https://sjparkk-dev1og.tistory.com/151
Eureka
- 로드 밸런싱과 클라이언트와 어플리케이션 서버 사이에서 장애 시 장애 조치 처리를 목적으로 한 REST 기반 서비스
- Eureka는 마이크로 서비스 기반의 아키텍처의 핵심 원칙 중 하나인 Service Discovery의 역할을 수행
- MSA에서 각 서비스별로 어플리케이션이 나뉘어 있는데 각 어플리케이션들은 서로 간의 통신을 위해 서로 연결 정보 (IP, hostname, port) 를 알아야 하는데 이 연결 정보들을 로드 밸런서에 다 등록하게 됨. 하지만 MSA 구조를 클라우드에 구축을 하게 되면 각 서비스 어플리케이션들의 연결 정보는 계속해서 바뀌게 되는데(MSA에서는 서비스의 IP와 Port가 일정하지 않고 지속적으로 변화함) 이때 마다 로드 밸런서에 구성된 설정들을 바꿔야하기에 이러한 문제점을 해결하기 위해 나온 것이 Eureka
- Eureka는 클라우드 환경에서의 연결 정보의 등록(Registering)과 해지(De-registering)를 바로바로 적용할 수 있게 해줌
Service Discovery & Registry
- Discovery : 다른 서비스의 정보를 찾는 것
- Registry : 서비스의 정보를 등록하는 것
- 즉, Registry를 통해 등록 된 서비스들의 정보를 찾는 것이 Discovery
Eureka의 구성
- 유레카는 Eureka Client와 Eureka Server로 구성
Eureka Server
- 유레카 서버는 Registry에 유레카 클라이언트들을 등록
- 유레카 클라이언트 들이 보낸 meta data들을 유레카 서버는 Registry에 등록
- 유레카 서버는 클라이언트들로부터 30초마다 (디폴트값) 클라이언트들이 작동 중임을 알 수 있는 Heartbeat를 수신
- Heartbeat가 오지 않는 경우 Server는 클라이언트가 죽었다고 판단하여 90초 내에 해당 클라이언트의 정보를 Registry에서 삭제
- 이렇게 유지된 Registry 정보를 서버는 클라이언트들에게 전달
Eureka Client
- MSA에서 각 서비스들은 유레카 클라이언트
- 유레카 클라이언트들은 스스로를 유레카 서버에 등록 (설정 값 필요)
- 유레카 클라이언트들은 자신들의 연결 정보(ip, hostname, port)의 meta data들을 유레카 서버에 등록
- 유레카 클라이언트들은 유레카 서버에 저장된 Registry 정보를 수신하고, 자신의 로컬환경에 저장
- 유레카 클라이언트들은 유레카 서버에게 전달 받은 Registry 정보를 통해 다른 클라이언트들의 정보를 알 수 있음
유레카 클라이언트는 어떻게 유레카 서버로부터 서비스 목록을 받아오는가?
- 유레카 클라이언트는 유레카 서버로부터 다른 클라이언트의 연결 정보가 등록되어 있는 Registry를 받음
- REST endpoint /eureka/apps를 통해 등록된 인스턴스 정보를 확인 가능
- 인스턴스란 유레카에 등록되어 목록에서 조회 가능한 유레카 서비스를 의미
Eureka Server & Client 설정값
eureka.client
- register-with-eureka : 유레카에 등록할지 여부
- fetch-registry : 유레카에서 조회할지 여부
- registry-fetch-interval-seconds: 클라이언트 측에서 eureka registry를 캐싱하는 시간
- disable-delta: 마지막으로 시도한 값에서 변경된 내용만 가지고 오도록 설정. false로 설정 시 바뀌지 않은 내용도 다 가지고 옴
eureka.server
- enable-self-preservation : 네트워크 같은 장애 발생 시 모든 서비스가 eureka에서 일괄 해제되는 현상을 막기 위해 사용, true 일 때 동작
- eviction-interval-time-in-ms: client로부터 heartbeat가 계속 수신되는지 점검, 셋팅 된 시간동안 heartbeat가 없다면 제거 하게 됨
- response-cache-update-interval-ms: eureka rest api에서 응답을 캐시하는 시간. 해당 시간이 지나야지만 rest api에서 client 등록 정보가 바뀐 것을 표시
eureka.instance
- instance-id : eureka에 등록되는 id 값. 중복되게 되는 경우 마지막 instance만 동작
- lease-renewal-interval-in-seconds : health heartbeat 시간. server가 아닌 client에서 셋팅. 따라서 client 마다 다른 기준으로 보낼 수 있게 됨
- lease-expiration-duration-in-seconds: 해당 시간 동안 heartbeat이 수신되지 않으면 eureka에서 해당 instance를 제거. 이 역시 server가 아닌 instance에서 셋팅
- prefer-ip-address: 호스트 대신 ip를 사용. eureka dashboard에서 해당 instance를 누르게 되면 ip로 이동
Eureka Server & Eureka Client Settings
테스트 환경
- Local Test
- SpringBoot 2.6.6
- Eureka Server - 8686(port)
- Eureka Client1 (Member) - 8787
- Eureka Client2 (Store) - 8989
설정 방법
Eureka Server
1. Dependency 추가
- implementation("org.springframework.cloud:spring-cloud-starter-netflix-eureka-server")
2. Annotation 추가 - 서버의 자격으로 등록
3. application.yml 설정 추가
- register-with-eureka & fetch-registry 관련 설정을 false로 하는 것은 만약 true로 하게 되면 이 서비스 디스커버리도 마이크로 서비스로 인식이 되기 때문에 false로 처리
- enable-self-preservation : 자기보존모드 on/off, 네트워크 같은 장애 발생 시 모든 서비스가 Eureka에서 일괄 해제되는 현상을 막기 위해 사용
Eureka Client
1. Dependency 추가
- implementation("org.springframework.cloud:spring-cloud-starter-netflix-eureka-client”)
2. Annotation 추가
3. application.yml 설정 추가
- register-with-eureka : 유레카에 등록할지 여부
- fetch-registry : 유레카에서 조회할지 여부
- defaultZone : 유레카 서버를 바라보도록 설정
- application-name : 웹에서 보여지는 Application명과 더불어 FeignClient 통신시 FeignClient 어노테이션 옵션 값 name과 매칭시켜 통신
테스트
- Eureka Server Run
2. Eureka Client1 & Eureka Client2 Run
3. Log 확인
- 서버측
- 클라이언트측
+ 추가 내용
Eureka Client 설정 시 설정하는 Annotation 종류가 두가지 있어 둘의 차이를 정리함
@EnableDiscoveryClient & @EnableEurekaClient
- EnableDiscoveryClient는 Eureka 이외에 consul, zooleeper들이 구현되어 있으며, spring-cloud-commons에 기반을 두고 있음
- EnableEurekaClient는 Eureka 관련만 의존해 있으며, spring-cloud-netflix에 기반을 두고 있음
- 만약 MSA를 Eureka 기반으로 구성한다면 EnableEurekaClient를 사용하면 되고, 그 외에는 EnableDiscoveryClient를 사용하면 됨
댓글