Service Discovery 개념, 종류, 특징

Service Discovery란?

• MSA와 같은 분산 환경에서의 동작은 서비스 간의 원격 호출(API 호출)로 구성
  → 원격 호출은 각 서비스의 IP 주소와 PORT 번호를 기반으로 요청
• 클라우드 환경이 기반이 되면서 서비스가 AutoScaling 등에 의해 동적으로 생성되거나, 컨테이너 기반의 배포로 인해 서비스의 IP가 동적으로 변경되는 일이 잦아짐
  • 하지만, 이러한 변경은 클라우드에서 일어난 것이기 때문에 동적으로 변하는 IP를 하나 하나 확인하여 수동으로 대응 불가
• 따라서, 클라우드 환경에서 서비스 클라이언트가 서비스를 호출할 때 서비스의 위치(IP 주소와 PORT 번호)를 알아낼 수 있는 기능이 필요한데 이것을 Service Discovery라고 함
• Service Discovery를 구현하는 방법으로는 크게 두 가지가 존재
  1. Client Side Discovery 방식
  2. Server Side Discovery 방식
• Service Discovery의 기본적인 기능은 서비스 등록, 등록된 서비스의 목록을 반환
• 추가로 등록된 서비스들의 Health check를 통해 현재 서비스가 가능한 서비스의 목록만 리턴하거나 서비스 간의 부하 분산 비율을 조정하는 등의 기능 추가가 가능

AutoScaling
오토스케일링은 클라우드 컴퓨팅의 유연성(필요에 따라 서비스를 확장하거나 축소)을 돋보이게 하는 기술로 CPU, 메모리, 디스크, 네트워크 트래픽과 같은 시스템 자원들의 메트릭(Metric) 값을 모니터링하여 서버를 자동으로 늘리거나 줄이는 것을 의미

제공하는 서비스에 대해서 사용자가 몰려 트래픽이 증가했을 때는 서버를 자동으로 늘리고, 여유로운 시간대에는 서버를 줄여 비용 부담을 줄이고 원활한 서비스를 제공할 수 있다는 장점을 가짐

 

---

Client Side Discovery

• Service instance가 생성(구동)될 때 IP 주소, Port번호, 서비스명 등이 Service Registry에 등록
• Service Client가 Service Registry에 Query를 보내 서비스의 위치를 반환받는 방식이며, 호출 시에는 로드밸런싱 알고리즘을 통해 서비스 호출
• Service Instance가 종료될 때 Service Registry에서 삭제
• Service Instance의 등록 및 삭제는 Heartbeat 매커니즘에 따라 주기적으로 refresh

장점

• 클라이언트가 사용 가능한 서비스 인스턴스에 대해 알고 있기 때문에 각 서비스별 로드 밸런싱 방법을 선택 가능

단점

• 클라이언트 ↔ 서비스 레지스트리 사이의 의존성이 생성
• 서비스 클라이언트에서 사용하는 각 프로그래밍 언어 및 프레임워크에 대해서 클라이언트측 Service Discovery 로직(Register나 Discovery)을 구현

Client side discovery의 대표적인 예와 특징

• Netflix OSS의 Netflix Eureka
• Netflix Eureka는 서비스 인스턴스의 등록을 관리
• 사용 가능한 인스턴스를 조회하기 위한 REST API를 제공
• Netflix Ribbon은 Eureka와 함께 쓰이며 호출 시 로드밸런싱 역할

---

Server Side Discovery

• Client Side Discovery에서 Service Client 위치에 Load Balancer를 넣은 뒤 Service Client가 Load Balancer를 호출
• Load Balancer가 서비스의 위치를 물어보고 반환받아 사용 가능한 Servcie Instance를 라우팅
• Client Side Discovery과 마찬가지로 Service Instance가 생성(구동)될 때 Service Registry에 생성되고 종료 시 삭제

장점

• Discovery의 기능이 클라이언트로부터 분리되어 의존성 감소
  → 분리되어 있는 클라이언트는 단순히 로드밸런서에 요청만 수행
• 클라이언트 측에서 각 프로그래밍 언어 및 프레임워크에 대한 검색 로직을 구현할 필요가 없음
• 일부 배포 환경에서는 Server Side Discovery 기능을 무료로 제공
  Kubernetes Cluster, AWS Elastic Load Balancer 등

단점

• 로드밸런서가 배포 환경에 제공되어야 함
• 제공되어있지 않다면 설정 및 관리해야 하는 또 다른 고가용성 시스템 구성 요소

Server Side Discovery의 대표적인 예

• AWS Elastic Load Balancer(ELB)
• Kubernetes

---

Service Registry

 

• Service Discovery의 핵심 부분으로 Service Instance의 네트워크 location을 포함하는 데이터베이스의 역할
• 높은 가용성이 보장되어야 하고 항상 최신 정보를 유지해야 함
• 서비스 레지스트리는 일관성을 유지를 위해 복제 프로토콜을 사용하는 서비스 클러스터로 구성

 

Service Registry의 대표적인 예

• Netflix Eureka
• Apache Zookepper
• etcd
• HashiCorp의 Consul

 

Service Registry가 필요 없는 경우

• Kubernetes, Marathon 같은 몇몇 시스템에는 명시적인 Service Registry가 없음
• Kubernetes, Marathon과 같은 배포 환경은 클러스터 내의 각 호스트에서 프록시(proxy)를 생성
  → 이 프록시가 Server Side Discovery의 로드밸런서 역할을 수행
• 클라이언트는 서비스에 요청을 보내기 위해서 IP나 PORT 정보를 사용
  → 프록시는 클러스터 내의 사용 가능한 서비스 인스턴스로 해당 요청을 포워딩

---

Service Registry 종류별 특징

넷플릭스 Eureka

• 서비스 인스터스를 등록하거나 검색(Query)할 수있는 REST API 제공
• POST요청을 통해 등록, PUT 요청을 통해 30초마다 이 등록을 Refresh
• HTTP DELETE 요청이나 Time out을 통해 등록 정보 삭제
• Client는 HTTP GET 요청을 통해 등록된 서비스 인스턴스를 조회 가능
• Java client 라이브러리
• Synchronous Microservices를 위해 다른 Netflix OSS를 활용하면서 쓰기에 좋음
  

 

Apache Zookeeper

• 분산된 어플리케이션을 위해 널리 사용되는 고사양 코디네이션(coordination) 서비스
• Hadoop world에 originated
• Hadoop 안의 다양한 component 유지에 Good
• Server Cluster가 running되면 모든 Node 사이의 설정값을 zookeeper가 공유

 

etcd

• 고가용성, 분산된, 일관성있는 key-value 저장소
• 설정을 공유하고 Service Discovery를 위해 사용
• Kubernetes와 Cloud Foundry에서 사용 중

 

HashiCorp의 consul

• 서비스들을 발견(Discovery)하고 설정(Configure)하기 위한 툴
• 서비스를 등록, 검색 API를 제공
• Health Check를 통해 서비스 가용여부 판별

 

 

	Zookeeper	Etcd	Consul
확장성 및 고가용성	- 매우 확장성이 뛰어나지만 쿼럼 기반 합의 프로토콜에 의존 - Etcd나 Consul보다 가용성이 낮을 수 있음	- 매우 확장성이 뛰어나고 클러스터링을 통해 고가용성을 지원 - 많은 수의 노드를 처리 가능 - 노드 장애를 허용할 수 있음	- 매우 확장성이 뛰어나고 Raft 합의 프로토콜을 통해 강력한 일관성과 가용성을 제공
사용 및 설정의 용이성	- Consul 및 Etcd에 비해 러닝 커브가 높고 수동 구성이 더 많이 필요	- Zookeeper에 비해 더 간단 - 가벼운 아키텍처를 갖추고 있어 배포와 관리가 더 쉬움	- 사용자 친화적인 인터페이스를 제공 - 설정과 구성이 비교적 쉬움
기능 세트	- 서비스 검색 외에도 분산 동기화, 그룹 멤버십 및 리더 선거를 포함한 광범위한 기능을 제공	- 주로 분산 조정 및 구성 관리에 중점 - 추가 툴을 통해 서비스 검색도 사용 가능	- 서비스 검색 기능 - 상태 검사 및 부하 분산에 대한 기본 제공 지원 기능
생태계 및 통합	- Zookeeper는 Apache Hadoop 생태계에서 널리 사용 - 기존 Hadoop 인프라를 갖춘 조직에 더 적합할 수 있음	- Kubernetes 생태계의 핵심 구성 요소 - Kubernetes 기반 환경에 적합	- 인기 있는 인프라 도구와 긴밀하게 통합 - 이미 해당 도구를 사용하고 있는 팀에게 좋은 선택

 

선택 기준 권장 (?)

• Kubernetes 사용 시 Etcd
• 풍부한 기능 세트를 갖춘 범용 서비스 검색 솔루션일 경우 Consul
• Apache Hadoop을 사용하는 경우 Zookeeper

 

---

 

참고 자료

https://wildeveloperetrain.tistory.com/202

https://blog.naver.com/ithink3366/221368902485

https://blog.naver.com/ithink3366/221373410313

https://www.quora.com/How-should-I-choose-between-Zookeeper-Consul-and-Etcd-for-service-discovery