Eureka 시나리오별 등록 과정 + 빠른 배포하기

사진: Unsplash 의 Fabio Bracht

 

종종 배포할때 느린 마이크로서비스 등록 과정 때문에 빠르게 확인할 수 없어서 답답했다

단독 모놀리스면 바로 확인이 가능했지만 마이크로서비스는 정상 기동 후 1분 정도를 기다려야 503 Service Available이 없어진 후 확인이 가능했다

그러나 이건 잘못됐다. 등록은 사실 바로 된 것이다. 문제는 다른 곳에 있었다.

이걸 위해서는 Spring Cloud Nexflix이자 Service Discovery인 Eureka에 대해 알아야 한다

 

Eureka는 Service Discovery의 Server로, Netflix가 MSA에 관련해서 만든 것 중 하나이다 (Gateway 등)

그건 중요하지 않다 (응?)

 

등록 과정

Eureka에는 Server 와 Client가 있다

client는 자신의 IP, Port 등 메타 정보를 server에 등록하여 자신의 네트워크 상 위치를 알려준다

server는 각 마이크로 서비스가 등록한 인스턴스 메타 정보를 매니징하는 관리 주체이다

 

마이크로 서비스(이하 MS)는 기동시 유레카와 등록됨과 함께 유레카로부터 registry를 가져온다 (fetch registry)

정확히 말하자면 client가 server에게 polling 방식으로 요청한다

 

이때 이 registry 정보를 통해서 "유레카를 거치지 않고" MS끼리 통신을 한다

 

DNS와 운영체제의 host 파일을 떠올리면 될 것 같다

인터넷의 DNS를 굳이 거치지 않아도 내 로컬의 host파일을 먼저 참조함으로써 네트워크 IO를 더 줄이는 것이다

 

상품 서비스, 주문 서비스 등 비즈니스 성격의 앱 뿐만 아니라, 게이트웨이 또한 Eureka Client이다

즉, 게이트웨이(이하 GW) 또한 Registryt를 바탕으로 라우팅을 한다 (중요하다! 기억해두자)

 

 

문제의 상황

게이트웨이의 역할은 여러가지가 있지만 주 역할은 요청이 오면 MS로 서빙하는 것이다 (라우팅)

큰 문제는 아니나, 빈번한 배포시 이곳에서 배포 지연이 발생한다

 

MS를 배포하면 유레카와 연결이 끊기고 다시 커넥션을 맺는다 (1)

이때 GW는 유레카로부터 받은 이전의 regisrty 정보로 인해 최신이 아닌 과거 MS의 IP, port를 알고 있다

그리고 MS의 port는 대게 랜덤으로 생성한다

 

만일 이때 사용자가 요청을 한다면 (2)

GW는 존재하지 않는 장소로 라우팅을 한다

즉, 503 service unavailable이 뜨게 되는 것이다

 

그리고 뒤늦게 Registry 정보를 갱신하고 사용자 요청을 잘 받는다 (3)

 

해결법 (?)

해결법은 간단하다

(3)에서 일어나는 지연 시간을 없애면 된다.

즉, GW가 Registry 정보를 polling하는 간격을 줄이면 된다  ( registry.fetch.interval )

개발 환경의 경우 저 간격을 줄임으로써 배포 시간의 30초~1분의 delay를 없앨 수 있다

운영 환경은 성능 이슈를 고려해야 하기 때문에 조사하고 이 값을 수정해야 한다

 

 

그 외

그 외에도 유레카에서 MS 등록이 해제되는 과정도 알아보자

MS는 유레카에게 일정 주기로 Heart Beat를 보낸다

유레카 서버가 각 MS의 마지막으로 도착한 Heart Beat 시각을 체크하다가,

Time Table의 일정 시간을 초과하면 해당 MS를 유레카 목록에서 제거한다

 

Graceful Shutdown의 경우 MS가 정상적으로 유레카에거 등록 해지 요청을 한다