서비스 디스커버리란 무엇인가요?

네트워크 내 서비스를 발견, 추적, 모니터링하는 데 도움이 되는 서비스 디스커버리의 개념을 설명해 드릴게요. 서비스 카탈로그, 이점, 동작 방식, 클라이언트/서버 측 디스커버리, 로드 밸런싱과의 차이를 살펴볼게요.

출처: 문서

본문

서비스 디스커버리는 네트워크 내 서비스를 발견, 추적, 모니터링하는 데 도움이 돼요. 서비스 디스커버리는 모든 서비스의 기록을 서비스 카탈로그에 등록하고 유지해요. 이 서비스 카탈로그는 서비스가 서로를 쿼리하고 통신할 수 있게 하는 진실의 단일 소스(single source of truth) 역할을 해요.

서비스 디스커버리의 이점

서비스 디스커버리는 단순화된 확장성부터 개선된 애플리케이션 복원력까지 모든 조직에 이점을 제공해요. 서비스 디스커버리의 일부 이점은 다음과 같아요:

동적 IP 주소 및 포트 디스커버리
단순화된 수평 서비스 확장
애플리케이션에서 디스커버리 로직 추상화
헬스 체크로 보장되는 신뢰할 수 있는 서비스 통신
정상 서비스 인스턴스 간 요청 로드 밸런싱
고속 디스커버리로 달성되는 더 빠른 배포 시간
자동 서비스 등록 및 등록 해제

서비스 디스커버리는 어떻게 작동하나요?

서비스 디스커버리는 전통적인 접근 정보(IP 주소와 포트) 대신 서비스의 ID를 사용해요. 이를 통해 서비스를 동적으로 매핑하고 서비스 카탈로그 내 변경 사항을 추적할 수 있어요. 서비스 소비자(사용자 또는 다른 서비스)는 DNS를 사용하여 서비스 카탈로그에서 다른 서비스의 접근 정보를 동적으로 검색해요. 서비스의 라이프사이클은 다음과 같을 수 있어요:

서비스 소비자는 서비스 카탈로그가 제공하는 고유 Consul DNS 항목을 통해 "Web" 서비스와 통신해요.

"Web" 서비스의 새 인스턴스는 자신의 IP 주소와 포트와 함께 서비스 카탈로그에 등록돼요. 서비스 카탈로그에 새 인스턴스가 등록되면 서비스 소비자 요청을 처리하는 로드 밸런싱 풀에 참여해요.

서비스의 새 인스턴스가 추가되고 레거시 또는 비정상 서비스 인스턴스가 제거됨에 따라 서비스 카탈로그가 동적으로 업데이트돼요. 제거된 서비스는 더 이상 서비스 소비자 요청을 처리하는 로드 밸런싱 풀에 참여하지 않아요.

마이크로서비스에서의 서비스 디스커버리란?

마이크로서비스 애플리케이션에서는 활성 서비스 인스턴스 집합이 크고 동적인 환경에서 자주 변경돼요. 이러한 서비스 인스턴스는 각 서비스에서 가장 최신의 접근 정보를 얻기 위해 서비스 카탈로그에 의존해요. 마이크로서비스의 서비스 디스커버리에서는 정상적이고 확장 가능하며 응답성이 높은 애플리케이션 운영을 보장하기 위해 신뢰할 수 있는 서비스 카탈로그가 특히 중요해요.

서비스 디스커버리의 두 가지 주요 유형은 무엇인가요?

두 가지 주요 서비스 디스커버리 패턴이 있어요: 클라이언트 측(client-side) 디스커버리와 서버 측(server-side) 디스커버리.

클라이언트 측 디스커버리를 사용하는 시스템에서는 서비스 소비자가 사용 가능한 서비스 인스턴스의 접근 정보를 결정하고 그 사이에서 요청의 로드 밸런싱을 담당해요.

서비스 소비자가 서비스 카탈로그를 쿼리해요.
서비스 카탈로그가 모든 접근 정보를 검색하고 반환해요.
서비스 소비자가 정상 다운스트림 서비스를 선택하고 직접 요청해요.

서버 측 디스커버리를 사용하는 시스템에서는 서비스 소비자가 중개자를 사용하여 서비스 카탈로그를 쿼리하고 요청해요.

서비스 소비자가 중개자(Consul)를 쿼리해요.
중개자가 서비스 카탈로그를 쿼리하고 사용 가능한 서비스 인스턴스로 요청을 라우팅해요.

현대 애플리케이션의 경우 이 디스커버리 방법은 개발자가 서비스 디스커버리 로직을 분리하고 중앙화하여 애플리케이션을 더 빠르고 가볍게 만들 수 있으므로 유리해요.

서비스 디스커버리 vs 로드 밸런싱

서비스 디스커버리와 로드 밸런싱은 백엔드 서비스에 요청을 분산한다는 점에서 유사하지만 여러 중요한 면에서 다르다요.

전통적인 로드 밸런서는 서비스의 빠른 등록 및 등록 해제를 위해 설계되지 않았고 고가용성을 위해 설계되지도 않았어요. 대조적으로 서비스 디스커버리 시스템은 서비스 레지스트리 상태를 유지하는 여러 노드와 어떤 유형의 인프라에서도 복원력을 높이기 위한 피어 투 피어 상태 관리 시스템을 사용해요.

현대 클라우드 기반 애플리케이션의 경우 서비스 디스커버리는 인프라와 무관하게 확장하고 복원력을 유지할 수 있는 능력 덕분에 트래픽을 올바른 서비스 프로바이더로 안내하는 선호 방법이에요.

서비스 디스커버리를 어떻게 구현하나요?

온프레미스든 클라우드든 어떤 유형의 인프라에서도 서비스 디스커버리 시스템을 구현할 수 있어요. 서비스 디스커버리는 Kubernetes나 Nomad 같은 많은 컨테이너 오케스트레이터의 네이티브 기능이에요. 또한 VM 및 서버리스 기술 같은 비컨테이너 워크로드에 대해 플랫폼 독립적인 서비스 디스커버리 방법도 있어요. 복원력 있는 서비스 디스커버리 시스템을 구현하려면 서비스 레지스트리 운영을 유지하고 지원하는 서버 집합을 만들어요. 서비스 디스커버리 시스템을 설치하거나 관리형 서비스 디스커버리 서비스를 사용하여 이를 달성할 수 있어요.

Consul을 다른 서비스 디스커버리 도구와 비교

예시: Etcd, Apache Zookeeper, Eureka

Consul의 서비스 디스커버리 기능은 네트워크 내 서비스를 발견, 추적, 모니터링하는 데 도움을 줘요. Consul은 서비스가 서로를 쿼리하고 통신할 수 있게 하는 진실의 단일 소스 역할을 해요.

Consul을 가상 머신(VM), 컨테이너, 서버리스 기술, 또는 Nomad와 Kubernetes 같은 컨테이너 오케스트레이션 플랫폼과 함께 사용할 수 있어요. Consul은 플랫폼에 구애받지 않아 레거시 플랫폼을 포함한 모든 환경에 잘 맞아요.

서비스 디스커버리란 무엇인가요?