Service Discovery in a Microservices Architecture
Service Discovery in a Microservices Architecture에 대한 요약이다.
Service Discovery
REST API, Thrift API등을 가진 서비스를 호출하려고 할때 네트워크 주소(IP, Port)를 알고 있어야 한다.
기존 방식에서는 일반적으로 물리적 하드웨어 주소는 고정(static)적 이고 가끔 변경된 경우 설정파일을 수정해주면 됐다.
요즘처럼 클라우드 기반의 MSA 어플리케이션인 경우에 네트워크 주소가 동적(dynamic)으로 할당된다.
따라서 클라이언트가 서비스를 호출하기위해서 서비스를 찾는 매커니즘(service discovery mechanism)이 필요하다.
Client-Side/Server-Side Discovery Pattern 두가지 패턴을 살펴보자.
The Client-Side Discovery Pattern
사용가능한 서비스의 네트워크 주소를 찾고 로드밸런싱된 요청을 보내는 일이 클라이언트에서 이뤄진다.
즉, 클라이언트가 service registry에 질의를 해서 네트워크 주소를 얻고,
로드밸런싱 알고리즘을 통해 서비스를 선택 후 요청(request)을 생성한다.
서비스가 실행될 때 Service Registry에 자신의 네트워크 주소를 등록하고, 종료될 때 Service Registry에서 삭제한다.
Netflix OSS가 client-side discovery pattern의 대표적인 사례이다.
- Netflix Eureka: service registry
- Netflix Ribbon: Eureka와 함께 동작하여 로드밸런싱된 요청(requests)을 생성
Client-Side Discovery Pattern 장점
- 비교적 간단하다.
- 클라이언트가 사용가능한 서비스를 알고 있기 때문에
서비스별로 알맞은 로드밸런싱 방법을 선택할 수 있다.
Client-Side Discovery Pattern 단점
- 클라이언트와 service registry간 의존성이 생긴다.
- 클라이언트에서 service를 찾는(discovery)하는 로직을 구현해야 된다.
The Server-Side Discovery Pattern
클라이언트는 로드밸런서를 통해 서비스에 요청을 보낸다.
로드밸런서는 service registry에 서비스의 네트워크 주소를 질의한 뒤, 사용가능한 서비스로 각 요청을 라우팅한다.
Client-Side Discovery와 동일하게 각 서비스는 Service Registry에 등록되고 해제된다.
AWS Elastic Load Balancer(ELB)가 Server-Side Discovery 라우터의 예이다.
ELB는 일반적으로 인터넷에서 들어오는 외부 트래픽을 로드밸런싱하는데 사용된다.
클라이언트는 DNS 이름을 사용하여 ELB를 통해 요청을 보낸다.
등록되어 있는 EC2 인스턴스나 ECS 컨테이너들이 사이에서 트래픽을 로드밸런싱한다.
별도의 Service Registry가 있는 것은 아니고 EC2나 ECS가 ELB에 직접 등록한다.
Kubernetes나 Marathon과 같은 배포환경은 클러스터내의 각 호스트에서 프록시(proxy)를 실행한다.
이 프록시는 Server-Side Discovery 로드밸런서 역할을 수행한다.
클라이언트는 서비스에 요청을 보내기위해서, IP나 port정보를 사용한다.
프록시는 클러스터내의 사용가능한 서비스 인스턴스로 해당 요청을 포워딩한다.
Server-Side Discovery Pattern 장점
- discovery 관련된 세부내용을 클라이언트로 부터 분리할 수 있다.
- 클라이언트는 discovery관련 로직을 구현 할 필요가 없다.
- 앞서 언급한 몇몇 배포환경에서는 이 기능을 무료로 제공한다.
Server-Side Discovery Pattern 단점
- 로드밸런서는 배포환경에 구축되어야 한다.
- 즉, 높은 가용성이 요구되는 시스템 컴포넌트를 설정하고 관리해야한다.
The Service Registry
service registry는 service discovery에서 매우 중요한 부분으로,
서비스 인스턴스들의 네트워크 주소를 가지고 있는 데이터베이스이다.
높은 가용성이 보장되어야 하고 항상 최신정보를 유지해야한다.
- REST API를 통해 서비스 인스턴스를 등록하거나 조회할 수 있다.
- POST 방식으로 서비스 인스턴스의 네트워크 주소를 등록
- PUT 방식으로주기적으로(30초) 등록정보를 리프레쉬
- DELETE 방식으로 서비스 인스턴스 등록정보를 삭제
- GET 방식으로 등록된 서비스 인스턴스 정보를 조회
- 참고: Configuring Eureka in AWS Cloud
- 고가용성, 분산된, 일관성있는 key-value 저장소
- 설정을 공유하고, service discover를 위해 사용된다.
- Kubernetes와 Cloud Foundry에서 사용 중
- 서비스들을 발견discover하고 설정(configure)하기 위한 툴
- 서비스를 등록하고 찾기위한 API를 제공
- health check를 통해 서비스 가용여부를 판별한다.
- 분산된 어플리케이션을 위해 널리사용되는 고사양 코디네이션(coordination) 서비스
Service Registration Options
서비스 인스턴스들은 service registry에 등록되거나 해제되어야 한다.
서비스의 등록/해제를 다루는 두가지 방식이 있다.
The Self-Registration Pattern
서비스 인스턴스는 service registry에 스스로 등록/해제할 책임이 있다.
필요하다면 등록정보가 만료되지 않게 하기위해 heartbeat를 service registry에 보내야한다.
Netflix OSS Eureka client
- Eureka client는 Eureka(service registry)에 서비스 등록/해제를 자동으로 처리한다.
- 서비스의 Java Configuration 클래스에 @EnableEurekaClient 어노테이션만 달아주면 된다.
Self-Registration 장점
- 비교적 단순하다.
- 별도의 시스템 컴포넌트가 추가될 필요가 없다.
Self-Registration 단점
- 서비스 인스턴스와 Service Registry간의 높은 결합도(coupling)이 생긴다.
- 서비스에서 등록/해제 관련된 코드를 구현해야된다.
The Third-Party Registration Pattern
서비스 인스턴스가 직접 service registry에 등록/해제에 대한 책임이 없다.
대신, 서비스 등록기(service registrar)가 service registry에 등록을 해준다.
서비스 등록기는 실행중인 서비스 인스턴스들에 polling을 하거나 이벤트를 구독하는 등의
작업을 통해서 서비스의 변경을 감지하고, service registry에 등록/해제를 한다.
- Docker 컨테이너로 배포된 서비스 인스턴스들을 자동으로 등록/해제 하는 오픈소스 프로젝트
- etcd 나 Consul 같은 다양한 service registry를 지원한다.
- non-JVM 언어로 작성된 서비스를 위해 같이 실행시켜서 Eureka에 등록/해제를 한다.(sidecar application)
Third-Party Registration 장점
- 서비스 인스턴스와 service registry가의 결합도를 끊을(decoupled) 수 있다.
- 서비스에 별도의 등록/해제 로직을 구현할 필요가 없다.
Third-Party Registration 단점
- 운영환경에 추가적인 시스템 컴포넌트가 필요하다.
- 이 시스템은 설치 및 관리되어야 하고, 고가용성을 유지해야 한다.
Summary
마이크로서비스 어플리케이션은 서비스 인스턴스가 동적으로 변경되고 네트워크 주소도 동적으로 할당된다.
따라서 클라이언트에서 서비스에 요청을 보내려면 service discovery 메카니즘이 필요하다.
service discovery에서 매우 중요한 부분이 service registry이다.
service registry는 사용가능한 서비스 인스턴스의 목록을 관리하고,
서비스 등록/해제/조회 등을 할 수 있는 API를 제공해야 한다.
service-discovery 패턴에는 client-side와 server-side discovery 패턴이 있다.
service registry에 등록/해제 하는 방법에는 self-registration과 third-party registration 패턴이 있다.