Eureka 이론

document/discovery/eureka_theory.md

@@ -22,19 +22,107 @@ AWS 기준으로 가용지역마다 유레카 서버가 복제되어 있다.
 
 #### 용어 정리
 
+**Eureka 행동 및 구성 요소**
+
 * Service Registration: Client(마이크로서비스)가 자신의 정보를 유레카에 등록하는 행동을 의미한다.
 
 * Service Registry: Client의 정보들(목록, 가용 Client의 위치)을 저장하는 위치를 의미한다.
 
 * Service Discovery: 클라이언트가 Service Registry에서 요청을 보내야하는 대상을 찾는 과정을 의미한다.
 
+* Eureka Client: 다른 서비스의 위치 정보를 알아내기 위해 유레카 서버에 질의하는 서비스를 말한다.
+                 유레카 입장에서는 자신에게 등록되어 있는 서비스를 소비하는 입장(정확히는 사용)이기 때문에 Service Consumer로 볼 수 있다.
 
+* Eureka Service: 유레카 Client가 요청하였을 때 발견의 대상이 되는 서비스 즉, 유레카에 등록되어 있는 Service라고 볼 수 있다. 
+                  유레카 입장에서는 서비스를 제공(자신에게 등록)하는 입장이기 때문에 Service Provider로 볼 수 있다.
 
+* Eureka Server: 유레카 서비스가 자기 자신을 등록(Service Registration)하고 Eureka Client가 Eureka Service를 찾기 위해 가용 서비스 목록(Service Registry)를 요청하는 서버다.
 
+* Eureka Instance: 유레카에 등록되어 Service Registry에서 조회 가능한 Eureka Service를 의미한다.
 
+* Renew:
+  * Client는 유레카에 등록된 이후 설정된 주기마다 heartbeat를 전송하여 자신의 존재를 알린다. (eureka.instance.lease-renewal-interval-in-seconds(default: 30))
+  * 유레카 서버는 설정된 시간동안 heartbeat를 받지 못하면 heartbeat를 전송하지 않은 Eureka Instance를 Service Registry에서 제거한다. (eureka.instance.lease-expiration-duration-in-seconds(default: 90))
+  * Renew Interval은 서버 내부적으로 유레카 클라이언트를 관리하는 로직이 있기 때문에 변경하는 것을 권장하지 않는다.
+
+* Fetch Registry: Client는 Server로 부터 Service Registry 정보를 가져와서 로컬 캐시로 저장해두고 일정 주기마다 업데이트 한다. (eureka.client.registryFetchIntervalSeconds(default: 30))
+
+* Cancel: Client가 종료될 때 유레카 서버로 Cancel 요청을 보내서 Service Registry에서 즉시 제거되도록 한다.
+
+* Time Lag: 유레카 서버의 Service Registry가 변경되어도 Client가 새로 Fetch 하기 전까지는 데이터의 차이가 있을 수 있다. 이러한 차이를 Time Lag라고 부른다.
 
 ---
 
+#### Peering
+
+여러대의 유레카 서버를 사용하면 서로 통신할 수 있도록 구성해야하는데 이것을 Peering 구성이라고 한다.
+여러대의 유레카 서버는 설정에 정의되어 있는 Peering 노드를 찾아서 Service Registry 정보의 Sync를 맞춘다.
+
+* eureka.client.register-with-eureka: Peering을 사용할 것인지 Standalone으로 구성할 것인지 설정한다.
+* eureka.server.registry-sync-retrires: Peering된 노드로부터 registry를 갱신할 수 없을 때 재시도할 횟수를 지정한다.
+* eureka.server.wait-time-in-ms-when-sync-empty: Peering된 노드로 부터 service registry의 정보를 갱신할 수 없을 때 대기하는 시간을 지정한다.
+
+---
+
+#### Self-Preservation Mode(자가보존모드)
+
+유레카 서버는 Service Registry에 등록된 유레카 인스턴스로 부터 주기적으로 Heartbeat를 전송받는다.
+만약 Heartbeat를 받을 수 없는 경우 일반적으로 Service Registry에서 인스턴스를 제거한다.
+유레카 인스턴스가 요청을 처리할 수는 있지만 단순 Heartbeat를 전송하지 못하는 상황을 대비하여 self-preservation을 사용하여 registry에서 문제된 인스턴스를 지정한 시간동안 제거하지 않을 수 있다.
+
+EvictionTask가 매분 예상한 Heartbeats수와 실제 Heartbeats의 수를 비교하여 self-preservation모드의 여부를 결정한다.
+eureka.server.eviction-interval-timer-in-ms(default: 60 * 1000)
+
+* Expected heartbeats updating scheduler: 기본적으로 매 15분(renewal-threshold-update-interval-ms)마다 수행되며 preservation mode로 가기위한 임계값을 계산한다.
+예를 들어 인스턴스의 개수가 N이고 renewal-percent-threshold값이 0.85이면 계산식은 아래와 같다.
+
+최소 1분 이내에 받아야 할 heartbeat의 총 수는 2(분당 2번의 heartbeat) * N * 0.85
+
+---
+
+### Eureka Client와 Eureka Server간 Communication
+
+* Self-Identification & Registration
+  * Instance 실행 시점
+    * eureka.instance/client 설정값으로 Server Registry에 등록하기 위한 Eureka Instance 정보를 생성한다.
+    * Heartbeat Scheduler를 통해 Eureka Server에 heartbeat를 전송한다.
+    * Server Registry에 Instance 정보를 등록한다.
+  * 등록 결과 확인
+    * 유레카 접속주소/eureka/apps의 경로에서 Service Registry에 등록되어 있는 인스턴스의 정보를 확인할 수 있다.
+    * Eureka Instance가 요청을 처리할 준비가 되면 Status가 STARTING에서 UP으로 변경된다.
+  * 등록 이후 Heartbeat 전송
+    * eureka.instance.lease-renewal-interval-in-seconds(Default: 30)에 설정된 주기마다 스케쥴러가 작동하여 Heartbeat를 실행한다.
+    * Eureka Server는 Heartbeat의 전송 주기에 따라 Service의 Status를 판단한다. 
+      만약 마지막 Heartbeat 이후에 전송 시점이 되어도 Heartbeat를 받지 못한다면 eureka.instance.lease-expiration-duration-in-seconds에 설정된 시간만큼 대기하고 해당 인스턴스를 Registry에서 제거한다.
+  * Instance Info Replication
+    * Instance 등록 이후 정보가 변경되면 Service Registry의 정보를 갱신하기 위한 API를 eureka.client.instance-info-replication-interval-seconds에 설정된 주기마다 호출한다.
+  * Eureka server info refresh
+    * Eureka Client는 eureka.client.eureka-service-url-poll-interval-seconds에 설정된 시간마다 Eureka Server의 상태를 갱신한다.
+
+* Service Discovery(Gateway)
+  * Instance 실행 및 등록 시점에 Eureka Server로 부터 Service Registry를 fetch 한다.
+  * Instance 등록 이후 eureka.client.registry-fetch-interval-seconds(default: 30)에 설정된 주기마다 로컬에 저장되어 있는 Registry의 정보를 갱신한다.
+
+![](image/gateway_process.png)
+
+---
+
+### Peering 구성되어 있는 Eureka Server Node간의 통신
+
+* Self-Identification & Registration
+  * Instance 실행 시점
+    * Peering node를 찾아서 Service Registry의 Sync를 맞추는 작업을 한다.
+    * eureka.server.registry-sync-retrires 값을 통해 Peering node의 Service Registry 정보를 얻기 위한 재시도 횟수를 조정할 수 있다.
+    * eureka.server.wait-time-in-ms-when-sync-empty 값을 통해 Peering node로 부터 Service Registry 정보를 얻기 위해 얼마나 대기할 것인지 조정할 수 있따.
+    * Eureka Server 또한 Eureka Client이기 때문에 동일한 방식으로 작동한다.
+
+---
+
+지금까지 Spring Cloud Netflix Eureka에 대해서 알아보았다.
+다음 장에서는 직접 유레카 서버를 구축하는 방법에 대해서 알아본다.
+
 Spring Cloud Netflix Eureka에 대한 설명의 아래의 글을 재해석 하였음.
 
-- 참고한 자료: https://coe.gitbook.io/guide/
+**참고한 자료:** 
+- https://coe.gitbook.io/guide/service-discovery/eureka
+- https://coe.gitbook.io/guide/service-discovery/eureka_2