서비스 디스커버리 (Service Discovery)

서비스 디스커버리(Service Discovery): 분산 시스템의 전화번호부

서비스 디스커버리란?

서비스 디스커버리(Service Discovery)는 분산 시스템과 마이크로서비스 아키텍처에서 서비스 인스턴스의 네트워크 위치(IP 주소와 포트)를 자동으로 찾고 추적하는 메커니즘입니다. 전화번호부가 사람의 이름으로 전화번호를 찾듯이, 서비스 디스커버리는 서비스 이름으로 실제 네트워크 엔드포인트를 찾습니다.

클라우드 환경에서는 서비스 인스턴스가 동적으로 생성되고 삭제되며, IP 주소가 계속 변합니다. 컨테이너는 재시작할 때마다 다른 IP를 받고, 오토스케일링은 인스턴스 수를 자동으로 조정하며, 장애 발생 시 인스턴스는 다른 호스트로 이동합니다. 이런 환경에서 하드코딩된 IP 주소나 정적 설정 파일은 통하지 않습니다.

서비스 디스커버리는 이 문제를 해결합니다. 서비스 인스턴스는 시작할 때 자신을 레지스트리에 등록하고, 다른 서비스는 레지스트리를 조회하여 필요한 서비스를 찾습니다. 레지스트리는 지속적으로 헬스 체크를 수행하여 장애 인스턴스를 자동으로 제거합니다. 이 모든 과정이 자동화되어 운영자의 개입 없이 시스템이 스스로 적응합니다.

Netflix의 Eureka, HashiCorp의 Consul, Kubernetes의 내장 서비스 디스커버리, Apache Zookeeper 같은 도구들이 널리 사용되며, 현대 클라우드 네이티브 애플리케이션의 필수 인프라가 되었습니다.

서비스 디스커버리가 해결하는 문제

마이크로서비스 아키텍처로 전환하면서 발생하는 도전 과제들을 살펴봅시다.

동적 환경의 복잡성이 첫 번째 문제입니다. 전통적인 모놀리식 애플리케이션에서는 몇 개의 고정된 서버만 관리하면 되었습니다. 하지만 마이크로서비스 환경에서는 수십, 수백 개의 서비스가 있고, 각 서비스는 여러 인스턴스를 가지며, 인스턴스는 수시로 생성되고 삭제됩니다. 컨테이너 오케스트레이션이 인스턴스를 다른 노드로 이동시키고, 오토스케일링이 부하에 따라 인스턴스 수를 조정하며, 배포 시 롤링 업데이트로 인스턴스가 교체됩니다.

하드코딩의 한계도 명확합니다. 설정 파일에 IP 주소를 직접 넣으면 IP가 변경될 때마다 설정을 업데이트하고 재배포해야 합니다. DNS는 TTL과 캐싱 때문에 변경이 즉시 반영되지 않고, 로드 밸런서의 정적 설정은 동적 환경에 적합하지 않습니다.

로드 밸런싱과 가용성 문제도 있습니다. 서비스의 여러 인스턴스 중 어디로 요청을 보낼지 결정해야 하고, 장애가 발생한 인스턴스는 자동으로 제외해야 하며, 새로 추가된 인스턴스는 즉시 트래픽을 받을 수 있어야 합니다.

서비스 간 의존성 관리도 복잡합니다. 어떤 서비스가 어떤 서비스를 호출하는지 추적하기 어렵고, 순환 의존성을 감지하고 방지해야 하며, 서비스 토폴로지를 시각화하고 이해할 수 있어야 합니다.

환경별 차이 문제도 있습니다. 개발, 스테이징, 프로덕션 환경마다 서비스 위치가 다르고, 환경별로 다른 설정을 관리하는 것은 오류가 발생하기 쉬우며, 코드는 환경에 독립적이어야 합니다.

서비스 디스커버리는 이러한 문제들을 자동화된 레지스트리와 조회 메커니즘으로 해결합니다.

서비스 디스커버리의 핵심 개념

효과적인 서비스 디스커버리 시스템의 주요 구성 요소를 이해해봅시다.

서비스 레지스트리 (Service Registry)

역할: 모든 서비스 인스턴스의 네트워크 위치를 저장하는 중앙 데이터베이스입니다. 서비스 이름을 키로, 인스턴스 목록을 값으로 저장합니다.

데이터 구조: 각 엔트리는 서비스 이름, 인스턴스 ID, IP 주소, 포트, 메타데이터(버전, 태그, 가용성 존), 헬스 상태, 등록 시간을 포함합니다.

요구사항: 고가용성이 필수적이고(레지스트리가 다운되면 전체 시스템이 영향받음), 일관성을 유지해야 하며(모든 클라이언트가 같은 뷰를 봐야 함), 빠른 읽기와 쓰기를 제공해야 합니다.

구현: Consul, Eureka, etcd, Zookeeper 같은 전용 도구나, Kubernetes 같은 오케스트레이션 플랫폼의 내장 기능을 사용합니다.

서비스 등록 (Service Registration)

자가 등록(Self-Registration): 서비스 인스턴스가 시작할 때 스스로 레지스트리에 등록합니다. 인스턴스는 자신의 IP, 포트, 메타데이터를 레지스트리에 전송하고, 주기적으로 하트비트를 보내 살아있음을 알리며, 종료 시 명시적으로 등록을 해제합니다.

제3자 등록(Third-Party Registration): 별도의 등록 서비스(Registrar)가 인스턴스를 관찰하고 등록/해제합니다. 서비스 코드는 디스커버리를 인식할 필요가 없고, 중앙에서 일관되게 관리할 수 있지만, 추가 컴포넌트의 복잡성이 증가합니다.

하이브리드 접근: Kubernetes처럼 플랫폼이 자동으로 등록하되, 서비스는 readiness probe로 준비 상태를 알립니다.

서비스 조회 (Service Lookup)

클라이언트 측 디스커버리(Client-Side Discovery): 클라이언트가 직접 레지스트리를 조회하고 로드 밸런싱을 수행합니다. Netflix Ribbon이 대표적이며, 클라이언트가 모든 인스턴스 정보를 알고 있어 지능적인 라우팅이 가능하지만, 클라이언트 로직이 복잡해집니다.

서버 측 디스커버리(Server-Side Discovery): 클라이언트는 로드 밸런서나 API 게이트웨이로 요청하고, 이들이 레지스트리를 조회하여 라우팅합니다. AWS ELB, Kubernetes Service가 이 방식이며, 클라이언트가 단순해지지만 추가 네트워크 홉이 발생합니다.

DNS 기반 디스커버리: 서비스 이름을 DNS 레코드로 해석합니다. Consul DNS, Kubernetes CoreDNS가 사용하며, 표준 DNS 프로토콜을 사용하여 호환성이 좋지만, TTL과 캐싱으로 인한 지연이 있습니다.

헬스 체크 (Health Check)

능동적 헬스 체크(Active Health Check): 레지스트리나 플랫폼이 주기적으로 인스턴스에 헬스 체크 요청을 보냅니다. HTTP GET /health, TCP 연결 확인, gRPC health check를 수행하며, 실패 시 자동으로 레지스트리에서 제거합니다.

수동적 헬스 체크(Passive Health Check): 실제 트래픽을 통해 헬스를 판단합니다. 연속된 실패 응답이 있으면 인스턴스를 제외하고, 일정 시간 후 재시도하여 복구를 확인합니다.

하트비트 메커니즘: 인스턴스가 주기적으로 "살아있음" 신호를 보내고, 일정 시간 동안 신호가 없으면 제거합니다. Eureka가 이 방식을 사용합니다.

메타데이터와 태그

메타데이터: 서비스 버전, 환경(dev/prod), 리전/존, 가중치(로드 밸런싱용), 커스텀 속성을 포함합니다.

활용: 버전별 라우팅(카나리 배포), 지역 기반 라우팅(지연 최소화), 환경 격리(개발/프로덕션 분리), 가중치 기반 로드 밸런싱을 구현합니다.

주요 서비스 디스커버리 솔루션

각 도구의 특징과 사용 사례를 살펴봅시다.

Netflix Eureka

아키텍처: 순수 클라이언트 측 디스커버리로, 각 서비스가 Eureka 클라이언트를 내장하고, Eureka 서버는 레지스트리를 유지하며, AP(Availability-Partition tolerance)를 선택합니다.

특징: Spring Cloud와 완벽히 통합되고, 자가 등록과 하트비트를 사용하며, 피어 투 피어 복제로 고가용성을 달성합니다. 넷플릭스 OSS 스택(Ribbon, Hystrix, Zuul)과 함께 사용됩니다.

장점: 구현이 간단하고 Spring Boot 통합이 쉬우며, 네트워크 분할 시에도 작동합니다(최종 일관성).

단점: 일관성이 약하고(eventual consistency), 헬스 체크가 다소 느리며, 엔터프라이즈 기능이 부족합니다.

적합한 경우: Spring 기반 마이크로서비스, 높은 가용성이 중요한 경우, 상대적으로 작은 규모입니다.

HashiCorp Consul

아키텍처: 클라이언트-서버 모델로, Consul 에이전트가 각 노드에서 실행되고, Consul 서버는 Raft로 합의를 달성하며, CP(Consistency-Partition tolerance)를 선택합니다.

특징: DNS와 HTTP API 지원, 강력한 헬스 체크(HTTP, TCP, Script, Docker, gRPC), KV 저장소 내장, 멀티 데이터센터 지원, 서비스 메시 기능(Connect)을 제공합니다.

장점: 강한 일관성, 풍부한 기능, 멀티 데이터센터, 액티브 커뮤니티를 가집니다.

단점: 설정이 복잡하고, Raft 합의로 인한 쓰기 지연이 있으며, 클라이언트 에이전트가 필요합니다.

적합한 경우: 다양한 언어 스택, 멀티 데이터센터 환경, 서비스 메시 필요, 엔터프라이즈 기능 필요한 경우입니다.

etcd

아키텍처: Raft 기반 분산 KV 저장소로, Kubernetes의 백엔드로 설계되었으며, gRPC API를 제공하고, CP를 선택합니다.

특징: 강한 일관성과 선형화 가능성, watch 기능으로 변경 통지, lease와 TTL 지원, 클러스터링과 고가용성을 제공합니다.

장점: 매우 안정적이고, Kubernetes 생태계 통합, 강한 일관성 보장을 합니다.

단점: 범용 KV 저장소로 서비스 디스커버리 전용 기능이 부족하고, 클라이언트 라이브러리가 제한적이며, 헬스 체크를 직접 구현해야 합니다.

적합한 경우: Kubernetes 환경, 강한 일관성 필요, 간단한 디스커버리 요구사항입니다.

Apache Zookeeper

아키텍처: 합의 기반 조율 서비스로, ZAB(Zookeeper Atomic Broadcast) 프로토콜을 사용하고, 계층적 네임스페이스(znode)를 제공하며, CP를 선택합니다.

특징: 원자적 broadcast, 순서 보장, 임시 노드(ephemeral nodes)로 세션 관리, watch 메커니즘을 제공합니다.

장점: 검증된 안정성, 순서 보장, Hadoop/Kafka 생태계 통합을 제공합니다.

단점: 설정과 운영이 복잡하고, Java 중심이며, 현대적 API가 부족하고, 대용량 데이터에 부적합합니다.

적합한 경우: 레거시 시스템, Hadoop/Kafka 통합, 순서 보장 필요한 경우입니다.

Kubernetes Service Discovery

아키텍처: 플랫폼 네이티브 디스커버리로, etcd를 백엔드로 사용하고, kube-proxy와 CoreDNS가 라우팅을 처리하며, Service와 Endpoints 리소스를 사용합니다.

특징: 완전히 통합된 경험, DNS 기반 자동 디스커버리, 헬스 체크와 readiness probe, ClusterIP/NodePort/LoadBalancer 지원을 제공합니다.

장점: 설정 불필요(자동), Kubernetes 네이티브, 배우기 쉽고, 강력한 추상화를 제공합니다.

단점: Kubernetes 전용이고, 크로스 클러스터 디스커버리가 제한적이며, 고급 라우팅 기능이 부족합니다.

적합한 경우: Kubernetes 환경, 간단한 요구사항, 플랫폼 네이티브 솔루션 선호입니다.

실전 구현 패턴

다양한 환경에서 서비스 디스커버리를 구현하는 방법을 살펴봅시다.

Spring Cloud + Eureka

Spring Boot 애플리케이션에서 Eureka를 사용하는 간단한 예제입니다.

Eureka 서버 설정: Spring Boot 애플리케이션에 @EnableEurekaServer 어노테이션을 추가하고, 피어 복제를 위한 설정을 추가합니다.

서비스 등록: 각 마이크로서비스에 Eureka 클라이언트 의존성을 추가하고, @EnableDiscoveryClient 어노테이션을 사용하며, application.yml에서 서비스 이름과 Eureka 서버 URL을 설정합니다.

서비스 조회: RestTemplate이나 WebClient에 @LoadBalanced를 추가하면, 서비스 이름으로 호출 시 자동으로 디스커버리하고 로드 밸런싱합니다.

Ribbon과 통합: Ribbon이 자동으로 Eureka에서 인스턴스 목록을 가져오고, 클라이언트 측 로드 밸런싱을 수행하며, 장애 인스턴스를 자동 제외합니다.

Consul 기반 디스커버리

서비스 등록 (JSON): Consul HTTP API나 설정 파일로 서비스를 등록하고, 헬스 체크를 정의하며, 태그와 메타데이터를 추가합니다.

DNS 조회: 표준 DNS 쿼리로 서비스를 찾을 수 있고, SRV 레코드로 포트 정보도 얻으며, 어떤 언어에서도 사용 가능합니다.

HTTP API 조회: REST API로 더 상세한 정보를 얻고, 헬스 체크 상태를 필터링하며, 특정 태그의 인스턴스만 조회합니다.

Consul Template: 설정 파일을 동적으로 생성하고, 서비스 변경 시 자동 업데이트하며, Nginx/HAProxy 설정에 활용합니다.

Kubernetes 네이티브 디스커버리

Service 리소스: Deployment를 생성하면 여러 Pod가 실행되고, Service 리소스가 Pod들을 묶어서 안정적인 엔드포인트를 제공합니다.

DNS 기반 조회: Pod 내에서 서비스 이름으로 직접 호출할 수 있고, CoreDNS가 자동으로 Service IP로 해석하며, 네임스페이스 내에서는 짧은 이름, 외부에서는 FQDN을 사용합니다.

환경 변수: Kubernetes가 각 Service에 대한 환경 변수를 자동 주입하고, {SERVICE_NAME}_SERVICE_HOST와 {SERVICE_NAME}_SERVICE_PORT로 접근합니다.

Headless Service: ClusterIP를 None으로 설정하면, DNS가 개별 Pod IP를 직접 반환하고, StatefulSet과 함께 사용하며, 클라이언트가 직접 Pod를 선택할 수 있습니다.

클라이언트 라이브러리 구현

범용 디스커버리 클라이언트의 기본 구조입니다.

인터페이스 정의: 서비스 조회, 등록, 해제 메서드를 정의하고, 헬스 체크 콜백을 제공하며, 변경 통지를 위한 리스너를 지원합니다.

캐싱: 레지스트리 조회 결과를 로컬 캐시하고, TTL이나 이벤트 기반으로 갱신하며, 레지스트리 다운 시 캐시로 폴백합니다.

로드 밸런싱: 라운드 로빈, 랜덤, 최소 연결, 가중치 기반 알고리즘을 구현하고, 장애 인스턴스는 자동 제외하며, 지역 우선(zone-aware) 라우팅을 지원합니다.

재시도 및 폴백: 조회 실패 시 재시도하고, 캐시된 데이터 사용을 허용하며, 서킷 브레이커와 통합합니다.

고급 기능 및 패턴

프로덕션 환경에서 필요한 고급 기능들을 살펴봅시다.

멀티 데이터센터 / 멀티 리전

리전 간 디스커버리: 각 리전에 독립적인 레지스트리를 두고, WAN gossip이나 페더레이션으로 연결하며, 지역 우선 라우팅으로 지연을 최소화합니다.

Consul의 접근: 각 데이터센터가 독립적인 Consul 클러스터를 실행하고, WAN gossip으로 서로 인지하며, prepared query로 크로스 DC 조회를 지원합니다.

글로벌 로드 밸런싱: 지리적으로 가까운 인스턴스를 우선하고, 로컬 리전 장애 시 다른 리전으로 폴백하며, 글로벌 트래픽 매니저(GTM)와 통합합니다.

버전별 라우팅 및 카나리 배포

메타데이터 활용: 각 인스턴스에 버전 태그를 붙이고, 클라이언트가 특정 버전을 조회하며, 점진적으로 트래픽을 이동시킵니다.

가중치 기반 분배: v1: 90%, v2: 10%로 시작하고, 모니터링하며 점진적으로 v2 비율을 증가시키며, 문제 발생 시 즉시 롤백합니다.

헤더 기반 라우팅: 특정 사용자나 요청을 새 버전으로 라우팅하고, A/B 테스트를 구현하며, 내부 직원에게만 베타 기능을 노출합니다.

서비스 메시와의 통합

Istio + Pilot: Pilot이 Kubernetes Service Discovery를 확장하고, Envoy 사이드카에 동적 설정을 푸시하며, 세밀한 트래픽 제어를 제공합니다.

Consul Connect: Consul의 서비스 메시 기능으로, 자동 mTLS, 인텐트 기반 접근 제어, L7 트래픽 관리를 제공합니다.

Linkerd: 경량 서비스 메시로 Kubernetes 서비스 디스커버리를 활용하고, 자동 로드 밸런싱과 재시도를 제공하며, 메트릭과 추적을 자동 수집합니다.

보안 고려사항

인증 및 암호화: TLS로 레지스트리 통신을 암호화하고, ACL로 등록/조회 권한을 제어하며, 서비스 간 mTLS로 인증합니다.

네트워크 격리: 레지스트리를 private 네트워크에 배치하고, VPC 피어링이나 VPN 사용을 고려하며, 퍼블릭 노출을 최소화합니다.

비밀 관리: 레지스트리에 비밀 정보를 저장하지 않고(Vault 사용), 메타데이터의 민감 정보를 암호화하며, 감사 로그를 활성화합니다.

성능 및 확장성

대규모 환경에서 서비스 디스커버리를 최적화하는 방법입니다.

캐싱 전략

클라이언트 측 캐싱: 조회 결과를 로컬에 캐시하고, 백그라운드에서 주기적으로 갱신하며, 레지스트리 다운 시 캐시로 작동합니다.

TTL 설정: 짧은 TTL(30초-2분)로 신선도를 유지하되, 네트워크 부하를 고려하고, 이벤트 기반 무효화를 활용합니다.

계층적 캐싱: 로컬 캐시 → 리전 캐시 → 글로벌 레지스트리 구조로, 계층별 TTL을 다르게 설정하며, 지역 장애 시 상위 계층으로 폴백합니다.

레지스트리 확장

수평 확장: 레지스트리 서버를 여러 개 실행하고, 읽기 요청을 분산하며, 쓰기는 합의 프로토콜로 조율합니다.

읽기/쓰기 분리: 리더가 쓰기를 처리하고, 팔로워가 읽기를 처리하며, 최종 일관성을 허용합니다.

샤딩: 서비스 이름으로 샤딩하고, 각 샤드가 독립적인 레지스트리를 실행하며, 일관된 해싱을 사용합니다.

네트워크 최적화

로컬 에이전트: 각 노드에 경량 에이전트를 실행하고, 로컬 조회를 처리하며, 업스트림 레지스트리와 동기화합니다.

배치 처리: 여러 조회를 묶어서 한 번에 요청하고, 등록/해제를 배치로 처리하며, 네트워크 호출을 최소화합니다.

압축: gRPC나 Protobuf로 메시지 크기를 줄이고, HTTP 응답을 gzip 압축하며, 대역폭을 절약합니다.

장애 처리 및 복원력

서비스 디스커버리 시스템의 안정성을 높이는 방법입니다.

레지스트리 장애 대응

캐시 폴백: 레지스트리가 다운되어도 캐시된 데이터로 작동하고, "오래된 데이터라도 없는 것보다 낫다" 원칙을 따르며, 복구 시 자동으로 동기화합니다.

다중 레지스트리: 여러 레지스트리 인스턴스를 배포하고, 클라이언트가 하나 실패 시 다른 것으로 폴백하며, 합의 프로토콜로 일관성을 유지합니다.

Static Fallback: 최후의 수단으로 정적 설정 파일을 준비하고, 모든 디스커버리 실패 시 사용하며, 최소한의 기능은 유지합니다.

부분 장애 처리

헬스 체크 타임아웃: 느린 인스턴스를 빠르게 감지하고, 타임아웃을 적절히 설정하며(예: 5초), 연속 실패를 요구합니다.

점진적 제거: 인스턴스를 즉시 제거하지 않고, "의심" 상태로 표시하여 트래픽 비율을 줄이고, 복구되면 점진적으로 복원합니다.

서킷 브레이커 통합: 디스커버리와 서킷 브레이커를 결합하고, 반복적으로 실패하는 인스턴스를 자동 차단하며, 주기적으로 재시도하여 복구를 확인합니다.

네트워크 분할

AP 시스템 (Eureka): 가용성을 우선하고, 각 파티션이 독립적으로 작동하며, 재결합 시 최종 일관성으로 수렴합니다.

CP 시스템 (Consul, etcd): 일관성을 우선하고, 과반수 파티션만 쓰기 가능하며, 소수 파티션은 읽기 전용이 됩니다.

하이브리드 접근: 읽기는 느슨하게(캐시 허용), 쓰기는 엄격하게(합의 필요) 처리하며, 비즈니스 요구사항에 따라 선택합니다.

모니터링 및 관찰성

서비스 디스커버리 시스템의 건강을 추적하는 방법입니다.

핵심 메트릭

등록 메트릭: 등록된 서비스 수, 인스턴스 수, 등록/해제 빈도를 추적하고, 급격한 변화는 문제를 의미합니다.

조회 메트릭: 초당 조회 수, 조회 지연시간(p50, p95, p99), 캐시 히트율을 측정하고, 조회 실패율을 모니터링합니다.

헬스 체크 메트릭: 헬스 체크 성공/실패율, 평균 응답 시간, 비정상 인스턴스 수를 추적하고, 플래핑(반복된 상태 변경)을 감지합니다.

레지스트리 메트릭: 레지스트리 서버의 CPU/메모리 사용량, 디스크 I/O, 네트워크 대역폭을 모니터링하고, 합의 지연(Raft lag)을 추적합니다.

알림 전략

임계값 기반 알림: 비정상 인스턴스 비율이 50% 초과, 레지스트리 응답 시간이 1초 초과, 조회 실패율이 5% 초과 시 알림합니다.

이상 탐지: 베이스라인에서 벗어난 패턴을 감지하고, 머신러닝 기반 이상 탐지를 활용하며, 계절성과 트렌드를 고려합니다.

계단식 알림: 경고 → 위험 → 긴급 단계로 에스컬레이션하고, 심각도에 따라 다른 팀에 알리며, 자동 복구를 시도합니다.

시각화

서비스 토폴로지: 서비스 간 의존성을 그래프로 표시하고, 순환 의존성을 하이라이트하며, 실시간 트래픽 흐름을 애니메이션합니다.

대시보드: 등록된 서비스 목록과 인스턴스 수, 헬스 상태 분포(정상/비정상), 조회 성능 그래프, 레지스트리 건강 상태를 표시합니다.

분산 추적: OpenTelemetry로 서비스 디스커버리 호출을 추적하고, 조회 → 라우팅 → 요청의 전체 경로를 시각화하며, 병목을 식별합니다.

일반적인 함정과 안티패턴

서비스 디스커버리 구축 시 피해야 할 실수들입니다.

과도한 조회

문제: 매 요청마다 레지스트리를 조회하면 성능 저하와 레지스트리 과부하가 발생합니다.

해결: 조회 결과를 캐시하고, 연결 풀링으로 재사용하며, 백그라운드 갱신으로 신선도를 유지합니다.

헬스 체크 과부하

문제: 너무 자주, 너무 무거운 헬스 체크는 인스턴스에 부담을 줍니다.

해결: 간격을 적절히 설정하고(예: 10-30초), 경량 엔드포인트를 사용하며(/health가 아닌 /ping), 타임아웃을 짧게 유지합니다.

서비스 이름 충돌

문제: 다른 서비스가 같은 이름을 사용하면 혼란이 발생합니다.

해결: 네이밍 컨벤션을 정의하고(예: {team}-{service}-{env}), 네임스페이스를 활용하며, 레지스트리에 고유성을 강제합니다.

등록 해제 누락

문제: 서비스가 종료될 때 명시적으로 해제하지 않으면 좀비 엔트리가 남습니다.

해결: Graceful shutdown hook을 구현하고, TTL/Lease로 자동 만료를 설정하며, 헬스 체크로 자동 제거를 보장합니다.

단일 장애 지점

문제: 레지스트리가 하나만 있으면 다운 시 전체 시스템이 영향받습니다.

해결: 고가용성 클러스터를 구성하고, 여러 리전에 배포하며, 클라이언트 캐싱으로 복원력을 확보합니다.

결론

서비스 디스커버리는 현대 마이크로서비스와 클라우드 네이티브 아키텍처의 필수 인프라입니다. 동적으로 변화하는 환경에서 서비스들이 서로를 찾고 통신할 수 있게 하며, 자동화된 장애 감지와 복구를 제공합니다.

도구 선택은 환경과 요구사항에 달려 있습니다. Kubernetes를 사용한다면 내장 서비스 디스커버리로 시작하세요. Spring 기반이라면 Eureka가 자연스럽고, 멀티 언어 환경이나 서비스 메시가 필요하면 Consul이 좋은 선택입니다. 강한 일관성이 중요하면 etcd나 Consul을, 높은 가용성이 우선이면 Eureka를 고려하세요.

핵심 원칙은 단순함을 유지하는 것입니다. 필요 이상으로 복잡한 솔루션을 피하고, 플랫폼 네이티브 기능을 최대한 활용하며, 캐싱과 폴백으로 복원력을 확보하세요. 철저한 모니터링으로 문제를 조기에 발견하고, 카오스 테스트로 장애 시나리오를 검증하세요.

서비스 디스커버리는 보이지 않는 곳에서 조용히 작동하지만, 전체 시스템의 안정성과 확장성에 결정적인 역할을 합니다. 올바르게 구현하면 운영 부담을 크게 줄이고, 팀이 인프라가 아닌 비즈니스 가치에 집중할 수 있게 해줍니다.