파이썬 서비스 디스커버리 구현법 DNS SRV 조회부터 캐시 TTL 헬스체크 라운드로빈까지

파이썬 서비스 디스커버리 구현법 DNS SRV 조회부터 캐시 TTL 헬스체크 라운드로빈까지

📌 마이크로서비스 환경에서 안정적으로 백엔드 주소를 찾는 파이썬 보편 레시피를 공유합니다

대규모 트래픽을 다루는 시스템일수록 “이 서비스는 지금 어디에서 동작 중이냐”를 빠르고 정확하게 알아내는 게 중요해집니다.
IP를 하드코딩해 두면 배포 한 번, 장애 한 번에 곧바로 깨지기 때문에 요즘은 서비스 디스커버리 계층을 따로 두는 경우가 많습니다.
특히 마이크로서비스 구조라면 더 그렇습니다.
각 마이크로서비스 인스턴스의 위치를 동적으로 찾아가서 연결해야 하고, 죽은 인스턴스는 자동으로 피해 가야 하죠.
이 글은 파이썬으로 그런 동적 라우팅을 직접 구현하려는 분들을 위한 가이드입니다.
현업에서 많이 쓰는 접근 방식 그대로, DNS SRV 레코드를 조회해 후보 엔드포인트를 얻고, TTL에 따라 캐싱하고, 헬스가 나쁜 애들은 거르고, 남은 서버들 중에서 라운드로빈으로 균등하게 선택하는 흐름까지 단계별로 짚어봅니다.

정리하자면 핵심은 다음과 같습니다.
우리는 파이썬 코드에서 DNS SRV 레코드를 조회해 현재 사용 가능한 서비스 엔드포인트 목록을 받아옵니다.
그 결과를 TTL 동안만 캐시에 담아두고, TTL이 만료되면 다시 DNS를 조회합니다.
또한 각 엔드포인트가 진짜 살아있는지 헬스 체크를 통해 확인하고 비정상 노드는 과감하게 제외합니다.
마지막으로 남은 정상 후보들에 대해 라운드로빈 방식으로 순환 선택을 돌려 트래픽을 균등하게 분산합니다.
이 방식은 외부 서비스 레지스트리나 복잡한 사이드카 없이도 비교적 단순하게 적용할 수 있어서 “보편 레시피”처럼 재사용되는 패턴입니다.
아래 목차에서 순서대로 살펴보면 전체 흐름이 자연스럽게 이어지도록 구성했습니다.

🔍 서비스 디스커버리란? DNS SRV 기반 구조

서비스 디스커버리는 간단히 말해 “지금 살아 있는 서비스 인스턴스가 어디에 있는지 동적으로 찾아내는 과정”입니다.
예를 들어 결제 서비스, 주문 서비스, 재고 서비스처럼 마이크로서비스가 여러 개로 나뉘어 있는 환경에서는 각 서비스의 위치(IP, 포트)가 고정돼 있지 않은 경우가 많습니다.
컨테이너 오토스케일, 롤링 업데이트, 리스타트 같은 이벤트가 일어날 때마다 주소가 바뀔 수 있기 때문입니다.
그래서 코드 안에 http://10.1.2.3:8080 같은 식으로 박아두면 금방 깨지고, 결과적으로 장애까지 이어집니다.

이 문제를 풀기 위한 전형적인 해법이 바로 DNS 기반 서비스 디스커버리입니다.
우리는 DNS 서버에 서비스 엔드포인트 정보를 등록해두고, 애플리케이션은 실행 시점 또는 호출 직전에 DNS를 조회해서 “현재 쓸 수 있는 인스턴스 목록”을 받아옵니다.
여기서 중요한 게 SRV 레코드입니다.
SRV 레코드는 특정 서비스 이름에 대해 실제 호스트와 포트를 알려주는 DNS 레코드 유형으로, 흔히 _service._proto.example.com 같은 형식을 사용합니다.
예를 들어 _api._tcp.myservice.internal 같은 이름으로 질의하면 결과 안에 우선순위(priority), 가중치(weight), 포트(port), 대상 호스트(target)가 들어옵니다.
즉 단순히 ‘이 도메인은 어디 IP야?’ 수준의 A 레코드보다 한 단계 더 풍부한 연결 정보를 내려준다는 점이 핵심입니다.

이 글에서 다루는 파이썬 보편 레시피는 아래 흐름을 기반으로 합니다.
우선 DNS SRV 조회로 서비스 인스턴스 후보들을 받아옵니다.
그다음 TTL(Time To Live) 동안만 이 결과를 캐시에 저장하고 재사용합니다.
TTL은 DNS가 알려주는 유효 기간으로, TTL이 끝나면 다시 DNS를 조회해 최신 인스턴스 목록을 확보합니다.
캐시만 믿고 오래 끌면 이미 내려간 인스턴스를 계속 호출하게 되므로 TTL을 지키는 게 안정성 면에서 매우 중요합니다.

하지만 여기서 끝이 아닙니다.
DNS가 알려줬다고 해서 그 인스턴스가 진짜 정상이라는 보장은 없습니다.
예를 들어 애플리케이션 레벨에서는 /health 엔드포인트 등으로 헬스 체크를 수행해 응답이 정상인 대상만 남기고, 비정상 노드는 목록에서 제외합니다.
마지막으로 살아 있는 후보들 중 하나를 골라야 하는데, 이때 많이 쓰는 방식이 라운드로빈입니다.
라운드로빈은 단순히 순환하면서 하나씩 선택하는 방식이라 구현이 직관적이고 공평하게 트래픽을 돌리기 좋습니다.

정리하면, 파이썬에서의 서비스 디스커버리 보편 레시피는 다음 단계로 구성됩니다.

• 📡DNS SRV 레코드를 조회해서 서비스 인스턴스 후보의 호스트와 포트를 얻는다.
• 🗂️DNS가 준 TTL 기준으로 캐시에 저장하고 TTL이 지나면 새로 조회한다.
• 🩺각 엔드포인트에 헬스 체크를 보내서 실제로 응답 가능한 것만 필터링한다.
• 🔄남은 정상 인스턴스들 사이에서 라운드로빈으로 하나를 선택해 호출한다.

이 방식의 장점은 외부에 거대한 서비스 레지스트리(예: Consul, etcd, ZooKeeper 등)를 따로 두지 않아도 된다는 점입니다.
기존 DNS 인프라와 SRV 레코드만 잘 관리해도 파이썬 애플리케이션이 스스로 “지금 살아 있는 동료 서비스”를 알아내고 균형 있게 트래픽을 분산할 수 있습니다.
즉, DNS SRV 조회 → TTL 기반 캐시 → 헬스 필터 → 라운드로빈 선택이라는 흐름만 잘 지켜주면, 코드 한 덩어리로도 꽤 안정적인 서비스 디스커버리 계층을 만들 수 있다는 뜻입니다.

💬 핵심 포인트:
DNS SRV는 단순 도메인 → IP 매핑이 아니라 “이 서비스는 어느 호스트의 몇 번 포트에서 제공 중인지”까지 알려준다.
파이썬 쪽에서는 이 정보를 기반으로 동적으로 대상 서버를 고르고, 죽은 서버를 자동으로 피해 간다.

# 파이썬 서비스 디스커버리 보편 레시피 개념 흐름 (의사코드)

# 1. DNS SRV 조회 - 후보 엔드포인트 확보
records = dns_srv_lookup("_api._tcp.myservice.internal")

# 2. TTL 기반 캐시 저장
cache.store("myservice", records, ttl=records.ttl)

# 3. 헬스 체크로 살아 있는 엔드포인트만 남기기
healthy = [r for r in records if check_health(r.host, r.port)]

# 4. 라운드로빈으로 다음 대상 선택
target = round_robin_picker(healthy)

# 5. 실제 요청 전송
send_request(target.host, target.port)

결국 파이썬에서의 서비스 디스커버리는 “지금 당장 신뢰할 수 있는 엔드포인트 1개”를 얻는 기술이 아니라, “신뢰 가능한 후보 집합을 주기적으로 유지하고 그 안에서 안전하게 선택하는 전략”에 가깝습니다.
DNS SRV 조회, TTL 캐시, 헬스 필터링, 라운드로빈 선택은 따로 떨어진 기능처럼 보이지만 실제 운영에서는 한 세트로 굴러가며 서로를 보완합니다.
이 조합이 바로 많은 팀에서 재사용하는 보편 레시피입니다.

🐍 파이썬으로 DNS SRV 레코드 조회하기

파이썬에서 DNS SRV 레코드를 조회하려면 일반적으로 dnspython 라이브러리를 사용합니다.
표준 라이브러리만으로는 SRV 타입 조회가 지원되지 않기 때문에 별도의 모듈을 추가로 설치하는 것이 일반적입니다.
이 모듈은 DNS 레코드를 직접 질의하고 TTL 정보까지 함께 받아올 수 있어서 서비스 디스커버리 구현에 매우 유용합니다.

먼저 패키지를 설치합니다.

pip install dnspython

그 다음, SRV 레코드를 질의하는 코드는 아래처럼 간단하게 작성할 수 있습니다.

import dns.resolver

def lookup_srv(service, protocol, domain):
    target = f"_{service}._{protocol}.{domain}"
    answers = dns.resolver.resolve(target, "SRV")
    
    results = []
    ttl = answers.rrset.ttl
    
    for rdata in answers:
        results.append({
            "priority": rdata.priority,
            "weight": rdata.weight,
            "port": rdata.port,
            "target": str(rdata.target).rstrip('.')
        })
    
    return results, ttl

records, ttl = lookup_srv("api", "tcp", "myservice.internal")
print(records)
print(f"TTL: {ttl}s")

위 코드는 _api._tcp.myservice.internal 이라는 SRV 레코드를 조회해 가용 엔드포인트 목록을 가져옵니다.
각 레코드에는 우선순위(priority), 가중치(weight), 포트(port), 대상 호스트(target)가 포함됩니다.
그리고 함께 반환되는 TTL(Time To Live) 값은 캐시 유효기간으로 활용됩니다.

SRV 응답의 우선순위(priority)는 낮을수록 우선 연결되는 서버를 의미합니다.
가중치(weight)는 동일한 우선순위 내에서의 선택 확률을 나타냅니다.
이 두 값이 조합되어 DNS 클라이언트가 어떤 인스턴스에 먼저 트래픽을 보내야 할지를 결정하게 됩니다.
하지만 실제 애플리케이션 레벨에서는 이런 규칙을 그대로 따르기보다는 헬스 체크와 캐싱 정책에 따라 재조정하기도 합니다.

📘 SRV 응답 데이터 구조 살펴보기

이제 SRV 응답의 TTL을 이용해 캐시를 만들고, 주기적으로 갱신하는 방법을 다음 단계에서 다뤄보겠습니다.
이 TTL 값이 단순한 숫자처럼 보여도, 실제 운영 환경에서는 캐시 정책과 헬스 필터링의 핵심 타이밍을 결정하는 중요한 기준이 됩니다.

⏳ TTL 캐싱 전략과 만료 처리

DNS SRV 조회 결과는 항상 TTL(Time To Live) 값을 포함합니다.
이 TTL은 해당 레코드가 유효하다고 DNS 서버가 보장하는 시간(초 단위)입니다.
예를 들어 TTL이 60이라면, 그동안은 같은 결과를 재사용해도 괜찮다는 의미죠.
서비스 디스커버리에서는 이 TTL을 캐시의 만료 기준으로 삼습니다.
즉, TTL 내에서는 DNS 재조회 없이 저장된 엔드포인트 목록을 그대로 사용하고, TTL이 만료되면 다시 DNS를 조회해 최신 정보를 반영합니다.

이렇게 하면 DNS 부하가 줄고, 불필요한 네트워크 왕복이 줄어들어 성능이 개선됩니다.
다만 TTL을 너무 길게 잡으면 이미 종료된 인스턴스를 계속 호출할 위험이 있습니다.
반대로 너무 짧으면 DNS 서버에 과도한 질의 요청을 날리게 됩니다.
실무에서는 30~120초 사이의 TTL이 가장 안정적이며, 서비스의 동적 변화 주기(예: 오토스케일 빈도)에 따라 조정하는 것이 좋습니다.

파이썬에서는 간단한 캐시 매니저 클래스를 만들어 TTL 기반 캐싱을 구현할 수 있습니다.
아래 예시는 메모리 캐시 방식으로, TTL 만료 시간을 함께 저장해 관리하는 기본 구조입니다.

import time

class TTLCache:
    def __init__(self):
        self.store = {}

    def get(self, key):
        item = self.store.get(key)
        if not item:
            return None
        value, expire_at = item
        if time.time() > expire_at:
            del self.store[key]
            return None
        return value

    def set(self, key, value, ttl):
        expire_at = time.time() + ttl
        self.store[key] = (value, expire_at)
        return value

# 사용 예시
cache = TTLCache()
cache.set("srv_records", ["host1:8080", "host2:8080"], ttl=60)
print(cache.get("srv_records"))  # 60초 동안은 캐시 사용

이 방식은 단순하지만, 대부분의 중소 규모 서비스에서는 충분히 효과적입니다.
SRV 결과를 TTLCache에 저장하고, 다음 요청 시 캐시가 존재하면 그대로 사용합니다.
TTL이 만료되면 새로 DNS를 조회해 업데이트하면 됩니다.
이 과정을 주기적으로 수행하면 ‘적당히 최신’이면서도 ‘불필요한 재조회 없는’ 균형 잡힌 구조가 만들어집니다.

🧩 TTL 캐시 전략별 비교

결국 TTL 캐시는 서비스 디스커버리에서 ‘시간’ 개념을 책임지는 핵심 축입니다.
SRV 조회는 ‘누가 살아 있는가’를 알려주고, TTL은 ‘언제까지 믿을 수 있는가’를 알려줍니다.
이 둘이 조화를 이룰 때 캐시가 진짜 안정성 도구로 작동합니다.

🩺 헬스 체크와 비정상 엔드포인트 필터링

DNS SRV 레코드와 TTL 캐싱만으로는 아직 충분하지 않습니다.
DNS는 단지 “서비스가 어디에 있어야 하는가”만 알려줄 뿐, “지금 실제로 살아 있는가”는 보장하지 않기 때문입니다.
그래서 헬스 체크(Health Check) 과정이 반드시 필요합니다.
이 단계에서는 각 엔드포인트에 직접 요청을 보내 응답 상태를 확인하고, 비정상 노드는 호출 대상에서 제외합니다.

헬스 체크는 단순히 HTTP 200 응답을 받는 것 이상입니다.
서비스마다 헬스 상태를 알려주는 전용 엔드포인트(예: /health, /status, /ping 등)를 두는 것이 일반적이며, 그 응답 내용에 따라 ‘정상’, ‘부분 장애’, ‘비정상’을 구분하기도 합니다.
파이썬에서는 requests 모듈을 이용해 간단히 구현할 수 있습니다.

import requests

def check_health(host, port, timeout=1.5):
    url = f"http://{host}:{port}/health"
    try:
        response = requests.get(url, timeout=timeout)
        if response.status_code == 200:
            return True
    except requests.RequestException:
        pass
    return False

# 예시
endpoints = [
    {"host": "service1.local", "port": 8080},
    {"host": "service2.local", "port": 8080},
    {"host": "service3.local", "port": 8080},
]

healthy = [e for e in endpoints if check_health(e["host"], e["port"])]
print(f"정상 노드: {healthy}")

이 코드에서는 각 서비스의 /health 엔드포인트에 요청을 보내고, 응답이 정상(200)인 경우만 남깁니다.
이렇게 필터링된 결과는 다음 단계의 라운드로빈 로직에서 균등 분배 대상이 됩니다.

🧠 헬스 체크 결과 관리 방식

헬스 체크를 단순 필터링에만 사용하지 않고, 지속적으로 기록하면 다음과 같은 이점을 얻을 수 있습니다.

• 📈엔드포인트별 가용률(availability rate)을 장기적으로 추적해 신뢰도 높은 서버를 식별할 수 있습니다.
• 🧩일시적 오류를 감안해 연속 실패 횟수가 일정 횟수 이상일 때만 장애로 판단할 수도 있습니다.
• 🔁비정상 노드가 복구되면 자동으로 다시 후보군에 추가하는 재가용 로직을 붙일 수 있습니다.

이처럼 헬스 체크를 단순한 필터링 수준에서 ‘상태 추적 시스템’으로 확장하면, 트래픽 분산과 장애 대응이 한층 더 유연해집니다.
SRV + TTL 캐시 구조 위에 헬스 모니터링 계층을 얹으면, DNS 수준에서는 파악할 수 없는 세밀한 서비스 상태까지 감지할 수 있습니다.

결국, 서비스 디스커버리에서 헬스 체크는 ‘DNS가 보지 못하는 현실’을 보완하는 역할을 합니다.
DNS는 이상적으로 구성된 세계를 알려주고, 헬스 체크는 실제로 작동하는 현실을 보여줍니다.
이 두 세계를 조화시키는 것이 파이썬 네트워킹 확장의 핵심입니다.

🔄 라운드로빈 로드밸런싱 선택 로직

DNS SRV 조회와 TTL 캐시, 헬스 체크를 통해 최종적으로 ‘정상 인스턴스 목록’을 확보했다면 이제 그 중 하나를 선택해야 합니다.
이때 단순 무작위(random)보다 더 균형 잡힌 방법이 바로 라운드로빈(Round Robin)입니다.
라운드로빈은 모든 인스턴스에 순서대로 요청을 돌리는 방식으로, 구현이 간단하면서도 부하를 공평하게 분산할 수 있습니다.

예를 들어 서버가 3개 있다면 요청은 다음 순서로 흘러갑니다.
1번째 요청은 서버 A, 2번째는 서버 B, 3번째는 서버 C, 4번째는 다시 서버 A.
이렇게 순환하면서 모든 서버가 균등하게 사용되도록 합니다.
파이썬에서는 라운드로빈 인덱스를 전역 변수나 클래스 멤버로 유지하면서 다음 요청마다 인덱스를 1씩 증가시키는 식으로 구현할 수 있습니다.

class RoundRobinPicker:
    def __init__(self):
        self.index = 0

    def pick(self, endpoints):
        if not endpoints:
            raise ValueError("엔드포인트 목록이 비어 있습니다.")
        selected = endpoints[self.index % len(endpoints)]
        self.index += 1
        return selected

# 사용 예시
endpoints = ["srv1:8080", "srv2:8080", "srv3:8080"]
picker = RoundRobinPicker()

for _ in range(5):
    print(picker.pick(endpoints))

위 코드를 실행하면 서버가 순환하면서 선택되는 것을 확인할 수 있습니다.
이 간단한 방식만으로도 요청이 특정 서버에 집중되는 현상을 줄일 수 있습니다.
특히 헬스 체크로 비정상 노드를 이미 제거했기 때문에, 이 라운드로빈 로직은 ‘정상 노드 사이의 공평한 분배’에 초점을 맞춥니다.

⚙️ 라운드로빈의 응용 변형

라운드로빈은 기본형 외에도 다양한 응용이 가능합니다.
일부 서버에 더 많은 부하를 줄 수 있도록 ‘가중치(Weighted)’를 적용할 수도 있고, 최근 응답 시간이 느린 서버는 임시로 스킵하도록 개선할 수도 있습니다.

이 중에서도 파이썬 네트워킹 확장에서 가장 보편적인 구현은 Health-aware Round Robin입니다.
DNS SRV 조회로 얻은 인스턴스 중 헬스 체크를 통과한 노드만 순환 대상에 넣고, TTL 만료 시 전체 목록을 다시 초기화합니다.
즉, SRV → 캐시 → 헬스 필터 → 라운드로빈이 자연스럽게 하나의 루프처럼 돌아가는 셈입니다.

정상 노드만 남긴 후 라운드로빈으로 순환하면, 서비스 트래픽은 자연스럽게 분산되고 장애 대응력도 높아집니다.
이 구조는 별도 로드밸런서를 두지 않고도 파이썬 코드 레벨에서 자체 로드밸런싱을 수행할 수 있는 가장 간결하면서 실용적인 패턴입니다.

❓ 자주 묻는 질문 (FAQ)

🧭 DNS SRV를 활용한 파이썬 서비스 디스커버리의 완성

지금까지 살펴본 구조는 단순히 DNS를 조회하는 수준을 넘어, 동적 서비스 연결을 가능하게 하는 파이썬 네트워킹의 기본 골격입니다.
DNS SRV 조회로 인스턴스 목록을 가져오고, TTL을 기반으로 캐시를 관리하며, 헬스 체크로 실제 상태를 검증하고, 라운드로빈 방식으로 공평하게 트래픽을 분산합니다.
이 4단계의 흐름은 로컬 환경이든 클라우드든 변하지 않는 ‘보편 레시피’로 널리 쓰이고 있습니다.

이 패턴의 진짜 강점은 단순함입니다.
복잡한 외부 시스템 없이도 코드 몇 줄만으로 신뢰성 높은 서비스 디스커버리 계층을 직접 구성할 수 있습니다.
또한 장애 상황에서도 TTL과 헬스 필터가 함께 작동해, 사용자는 자연스럽게 살아 있는 인스턴스로 라우팅됩니다.
운영자가 DNS SRV 레코드만 갱신해도, 파이썬 애플리케이션은 자동으로 이를 감지해 최신 엔드포인트로 전환하죠.

정리하자면, 서비스 디스커버리의 완성은 다음 네 가지 원칙에 있습니다.

• 🌐DNS SRV 조회로 서비스 위치를 동적으로 확인한다.
• ⏳TTL 캐시를 통해 효율적으로 재조회 시점을 제어한다.
• 🩺헬스 필터로 실제로 동작 중인 인스턴스만 남긴다.
• 🔄라운드로빈으로 트래픽을 균등하게 분산한다.

이 네 가지 단계를 순환 구조로 묶으면, 애플리케이션은 항상 살아 있는 엔드포인트를 자동으로 선택합니다.
결과적으로 운영자는 장애 복구나 확장 시에도 코드를 수정할 필요가 없습니다.
DNS SRV를 업데이트하는 것만으로도 전체 서비스 트래픽이 즉시 새 인스턴스로 향하죠.

🏷️ 관련 태그 : 파이썬네트워킹, DNS서비스, SRV레코드, 서비스디스커버리, TTL캐시, 헬스체크, 라운드로빈, 마이크로서비스, 네트워크프로그래밍, 시스템안정화