해당 포스팅은 Spring Cloud의 Eureka, Spring Cloud Gateway 등, 클라우드 환경의 서비스 구성에 대해 공부하며 접하게 된 Service Discovery에 대한 개념 정리입니다.
(프로그래밍적인 관점에서 바라본 Service Discovery에 대한 정리입니다.)
0. Service Discovery란?
on-premise 서버 기반의 Monolithic Architecture의 문제점을 보완하기 위해 클라우드 환경을 이용하여 서버를 구성하는 Micro Service Architecture(MSA)가 몇 년 전부터 대세로 떠오르고 있습니다.
MSA와 같은 분산 환경에서의 동작은 서비스 간의 원격 호출(API 호출)로 구성되며, 원격 호출은 각 서비스의 ip 주소와 port를 기반으로 요청되는데요.
클라우드 환경이 기반이 되면서 서비스가 AutoScaling 등에 의해 동적으로 생성되거나, 컨테이너 기반의 배포로 인해서 서비스의 ip가 동적으로 변경되는 일이 잦아졌습니다.
그러나 이러한 변경은 클라우드에서 일어난 것이기 때문에 동적으로 변하는 ip를 하나하나 확인하여 수동으로 대응할 수는 없는데요.
때문에 클라우드 환경에서는 서비스 클라이언트가 서비스를 호출할 때, 서비스의 위치(ip 주소와 port)를 알아낼 수 있는 기능이 필요한데, 이것을 바로 Service Discovery라고 하며, 서비스 디스커버리를 구현하는 방법으로는 크게 Client Side Discovery 방식과 Server Side Discovery 방식이 있습니다.
+++
Service Discovery의 기본적인 기능은 서비스를 등록하고 등록된 서비스의 목록을 반환하는 기능이지만, 등록된 서비스들의 Health check를 통해 현재 서비스가 가능한 서비스의 목록만 리턴한다거나, 서비스 간의 부하 분산 비율을 조정하는 등의 기능을 추가할 수 있습니다.
/*
온프레미스(on-premise)란,
IT 서비스를 운영하는 회사가 자체적으로 보유한 공간(전산실)에 물리적으로 하드웨어 장비를 가지고 직접 서버를 운영하는 방식으로, 클라우드 컴퓨팅 기술이 나오기 전까지 일반적으로 사용되던 인프라 구축 방식입니다.
*/
/*
AutoScaling
오토스케일링은 클라우드 컴퓨팅의 유연성(필요에 따라 서비스를 확장하거나 축소)을 돋보이게 하는 기술로 CPU, 메모리, 디스크, 네트워크 트래픽과 같은 시스템 자원들의 메트릭(Metric) 값을 모니터링하여 서버를 자동으로 늘리거나 줄이는 것을 이야기합니다.
제공하는 서비스에 대해서 사용자가 몰려 트래픽이 증가했을 때는 서버를 자동으로 늘리고, 여유로운 시간대에는 서버를 줄여 비용 부담을 줄이고 원활한 서비스를 제공할 수 있다는 장점이 있습니다.
*/
1. Client Side Discovery
service client가 service registry에 query를 통해 서비스의 위치를 물어보고 호출하는 방식이며, 호출 시에는 로드밸런싱 알고리즘을 통해 서비스가 호출됩니다.
service instance가 생성될 때(구동될 때) ip 주소, port, 서비스명 등이 service registry에 등록되며, service instance가 종료될 때 service registry에서 삭제됩니다.
(service instance의 등록 및 삭제는 heartbeat mechanism에 따라서 주기적으로 refresh 됩니다.)
[ 장점 ]
- 클라이언트가 사용 가능한 서비스 인스턴스에 대해서 알고 있기 때문에 각 서비스별 로드밸런싱 방법을 선택할 수 있습니다.
[ 단점 ]
- 클라이언트와 서비스 레지스트리 사이의 의존성이 생기며, 서비스 클라이언트에서 사용하는 각 프로그래밍 언어 및 프레임워크에 대해서 클라이언트 측 service discovery 로직(register나 discovery)을 구현해야 합니다.
client side discovery의 대표적인 예로 Netflix OSS의 Netflix Eureka가 있는데요.
Netflix Eureka는 서비스 인스턴스의 등록을 관리하고, 사용 가능한 인스턴스를 조회하기 위한 REST API를 제공하며, Netflix Ribbon은 Eureka와 함께 쓰이며 호출 시 로드밸런싱 역할을 해줍니다.
2. Server Side Discovery
호출되는 서비스 앞에 Load Balancer를 넣는 방식으로 service client가 Load Balancer를 호출하면 Load Balancer가 service register로 서비스의 위치를 물어보고 가용할 수 있는 서비스 인스턴스를 라우팅 합니다.
client side discovery와 마찬가지로 서비스 인스턴스가 생성될 때(구동될 때) service registry에 생성되고 종료될 때 삭제됩니다.
[ 장점 ]
- Discovery의 기능이 클라이언트로부터 분리되어 있어 의존성이 낮아지고, 분리되어 있는 클라이언트는 단순히 로드밸런서에 요청만 합니다.
- 클라이언트 측에서 각 프로그래밍 언어 및 프레임워크에 대한 검색 로직을 구현할 필요가 없습니다.
- 일부 배포 환경에서는 server side discovery 기능을 무료로 제공합니다.
(Kubernetes Cluster, AWS Elastic Load Balancer 등)
[ 단점 ]
- 로드밸런서가 배포 환경에 제공되어야 한다는 특징이 있으며, 제공되어있지 않다면 설정 및 관리해야 하는 또 다른 고가용성 시스템 구성 요소가 됩니다.
대표적인 server side discovery로는 AWS Elastic Load Balancer(ELB), Kubernetes가 있습니다.
3. Service Registry
service registry는 service discovery의 핵심 부분으로 서비스 인스턴스의 네트워크 location을 포함하는 데이터베이스와 같습니다.
높은 가용성이 보장되어야 하고 항상 최신 정보를 유지해야 한다는 특징이 있으며, 서비스 레지스트리는 일관성을 유지하기 위해 복제 프로토콜을 사용하는 서비스 클러스터로 구성됩니다.
대표적인 service registry로는 Netflix Eureka, Apache Zookepper, etcd, HashiCorp의 Consul가 있습니다.
/*
Kubernetes, Marathon 같은 몇몇 시스템에는 명시적인 service registry가 없는데요. Kubernetes나 Marathon과 같은 배포 환경은 클러스터 내의 각 호스트에서 프록시(proxy)를 생성하는데, 이 프록시가 Server Side Discovery의 로드밸런서 역할을 수행합니다.
클라이언트는 서비스에 요청을 보내기 위해서 ip나 port 정보를 사용하며, 프록시는 클러스터 내의 사용 가능한 서비스 인스턴스로 해당 요청을 포워딩하게 됩니다.
*/
< 참고 자료 >
https://www.nginx.com/blog/service-discovery-in-a-microservices-architecture/
'Programming > Spring Cloud' 카테고리의 다른 글
| spring cloud config 개념 및 동작 원리 (0) | 2022.12.15 |
|---|---|
| Spring Cloud Gateway를 이용한 API Gateway 구축해보기 (0) | 2022.11.27 |
| API Gateway란? 개념과 주요 기능 (0) | 2022.11.20 |