파이썬 requests 장애주입 DNS 실패 연결 리셋 지연 시뮬레이션 회복력 테스트

파이썬 requests 장애주입 DNS 실패 연결 리셋 지연 시뮬레이션 회복력 테스트

🧪 실서비스 전에 네트워크 실패를 고의로 만들고 관찰해 문제를 미리 잡는 법

현실의 네트워크는 언제나 완벽하지 않다는 점에서 시작합니다.
DNS 조회가 틀어지거나, 원격 서버가 연결을 갑자기 끊어 버리거나, 평소보다 수배 느려지는 일은 생각보다 자주 일어납니다.
이때 애플리케이션이 멈추지 않고 부드럽게 복구되도록 설계되어 있는지가 서비스 품질을 가릅니다.
파이썬에서 가장 널리 쓰이는 HTTP 클라이언트인 requests는 간단한 코드로도 이런 실패를 재현하고, 타임아웃과 재시도 같은 회복력 옵션을 검증하기에 좋습니다.
오늘은 운영과 관찰성을 주제로, DNS 실패와 연결 리셋, 지연 주입을 시뮬레이션하고 결과를 계측하는 실용적인 흐름을 정리했습니다.
테스트 환경을 깔끔히 분리하면서도 실제 장애 같은 증상을 만드는 안전한 방법에 집중합니다.

이 글은 파이썬 requests로 실패를 만들어 보는 구체적 기술과, 그 과정에서 꼭 챙겨야 할 관찰 지표를 함께 다룹니다.
단위 테스트만으로는 놓치기 쉬운 네트워크 경계의 문제를 재현하고, 재시도 백오프, 타임아웃, 회로차단기 같은 패턴이 기대대로 동작하는지 검증하는 흐름을 제공합니다.
또한 로컬과 CI 환경에서 안전하게 적용할 수 있는 도구 선택과 설정 팁을 정리해, 실서비스 배포 이전에 장애 내성을 수치로 확인할 수 있도록 안내합니다.
핵심은 간단한 코드와 최소한의 설정으로 신뢰할 수 있는 실패 시나리오를 만들고, 관찰 가능성을 높여 원인 파악 시간을 단축하는 것입니다.

🔎 파이썬 requests로 장애주입 개요

네트워크는 언제든 불안정해질 수 있고, 이런 현실을 코드 차원에서 검증하려면 의도적으로 실패를 만들어 보는 접근이 필요합니다.
운영과 관찰성 관점에서 파이썬 requests > 운영·관찰성 > 장애주입: DNS 실패/연결 리셋/지연 시뮬레이션·회복력 테스트는 핵심 아젠다입니다.
여기서는 requests를 중심에 두고, 장애를 안전하게 주입해 재시도와 타임아웃, 관찰 지표가 기대대로 작동하는지 확인하는 방법을 큰 그림으로 정리합니다.
핵심은 테스트 환경에서만 실패를 만들고, 그 결과를 수치로 남겨 동일 조건에서 재현 가능한 실험을 반복하는 것입니다.

🧭 장애주입이 필요한 이유

단위 테스트는 정상 경로를 검증하는 데 강하지만, DNS 실패나 연결 리셋처럼 외부 세계의 불확실성은 충분히 가리지 못합니다.
장애주입은 실패를 통제된 방식으로 발생시켜 애플리케이션의 회복력을 점검합니다.
이 과정에서 실패 유형별로 명확한 기대 동작을 정의하고, 타임아웃·백오프·회로차단기 같은 방어 패턴이 실제로 사용자의 체감 시간을 줄이는지 확인할 수 있습니다.

🛠️ requests로 실험을 구성하는 법

requests는 간결한 API와 함께 세션, 어댑터, 타임아웃, 재시도(Retry)를 설정할 수 있어 실패 시나리오를 검증하기 적합합니다.
실험은 보통 세 단계로 나눕니다.
첫째, 실패를 유발하는 테스트 대상 환경을 준비합니다.
둘째, 클라이언트 측 방어 설정을 구성합니다.
셋째, 호출 전후의 지표를 수집합니다.
이때 코드 레벨에서 재시도 횟수, 백오프 간격, 연결·읽기 타임아웃을 명시적으로 지정하고, 로깅에 소요 시간과 예외 타입을 남겨야 재현성이 확보됩니다.

import time
import logging
import requests
from requests.adapters import HTTPAdapter
from urllib3.util.retry import Retry

logging.basicConfig(level=logging.INFO, format="%(asctime)s %(levelname)s %(message)s")

def build_session():
    retry = Retry(
        total=3,                 # 총 재시도 횟수
        connect=3,               # 연결 오류에 대한 재시도
        read=3,                  # 읽기 오류에 대한 재시도
        backoff_factor=0.5,      # 지수 백오프: 0.5, 1.0, 2.0 ...
        status_forcelist=(500, 502, 503, 504),
        allowed_methods=frozenset(["GET","POST","PUT","DELETE","PATCH"])
    )
    adapter = HTTPAdapter(max_retries=retry, pool_connections=10, pool_maxsize=10)
    s = requests.Session()
    s.mount("http://", adapter)
    s.mount("https://", adapter)
    return s

def timed_get(url, timeout=(2.0, 2.0)):
    s = build_session()
    start = time.perf_counter()
    try:
        r = s.get(url, timeout=timeout)
        latency = (time.perf_counter() - start) * 1000
        logging.info("status=%s latency_ms=%.1f", r.status_code, latency)
        return r
    except requests.exceptions.RequestException as e:
        latency = (time.perf_counter() - start) * 1000
        logging.warning("error=%s latency_ms=%.1f", type(e).__name__, latency)
        raise

🧪 어떤 실패를 대상으로 할까

장애주입의 기본 축은 세 가지입니다.
DNS 실패, 연결 리셋, 지연 주입입니다.
DNS 실패는 호스트 이름을 해석하지 못해 ConnectionError나 Timeout으로 전파될 수 있습니다.
연결 리셋은 TCP 레벨에서 연결이 끊기므로 읽기 중단이나 재시도 트리거를 검증하기에 적합합니다.
지연 주입은 응답 시간을 늘려 사용자 체감 성능과 타임아웃 경계값을 세밀하게 맞추는 데 유용합니다.
각 실패는 관찰 지표(요청 지연, 에러율, 재시도 횟수, 타임아웃 비율)와 함께 살펴봐야 개선 효과를 명확히 판단할 수 있습니다.

• 🧩실패 유형을 DNS 실패, 연결 리셋, 지연으로 구분해 목표 행동을 정의합니다.
• ⏱️연결/읽기 타임아웃, 재시도 횟수, 백오프를 코드로 고정하고 버전 관리합니다.
• 📝로그에 예외 타입, 재시도 카운트, 전체 대기 시간(ms)을 구조화해 남깁니다.
• 🔒실험 트래픽을 프로덕션과 분리하고 실제 사용자 요청에는 절대 장애를 주입하지 않습니다.

💬 장애주입의 목적은 고장내기가 아니라, 고장나도 버티는 시스템을 수치로 증명하는 데 있습니다.

🌐 DNS 실패 시뮬레이션 방법

DNS 실패는 가장 흔하면서도 초기에 감지하기 어려운 장애 중 하나입니다.
도메인 이름을 IP로 변환하지 못하면 애플리케이션은 requests.exceptions.ConnectionError 또는 gaierror를 발생시키고, 재시도가 없는 경우 즉시 중단됩니다.
이를 재현하기 위해선 로컬 또는 테스트 환경에서 의도적으로 잘못된 DNS를 반환하거나, 가짜 도메인으로 요청을 보내면 됩니다.

🔧 로컬에서 DNS 실패 만들기

로컬 개발 환경에서는 /etc/hosts 파일을 이용하거나 임시 DNS 서버를 설정하여 요청이 실패하도록 할 수 있습니다.
간단히는 존재하지 않는 도메인을 사용하거나, 127.0.0.1로 매핑해 포트가 닫힌 상태를 만들 수도 있습니다.
다음은 requests로 DNS 실패를 관찰하는 기본 예제입니다.

import requests
from requests.exceptions import ConnectionError

try:
    response = requests.get("http://nonexistent.domain.test", timeout=3)
except ConnectionError as e:
    print("DNS lookup failed:", e)

이 경우 requests는 내부적으로 socket.gaierror를 감싸 ConnectionError로 변환합니다.
즉, DNS 단계에서 이미 실패했기 때문에 TCP 연결 시도조차 일어나지 않습니다.
이를 이용해 애플리케이션이 올바르게 예외를 처리하고 재시도 로직을 수행하는지 검증할 수 있습니다.

🧰 가상 네트워크 도구 활용

더 체계적인 테스트를 원한다면 toxiproxy, chaos-mesh, mitmproxy 같은 오픈소스 네트워크 장애주입 도구를 사용할 수 있습니다.
이 도구들은 DNS 실패, 패킷 손실, 지연, 연결 끊김 등을 시뮬레이션할 수 있어 requests 기반 시스템의 내성을 손쉽게 검증합니다.
Docker 네트워크에서 컨테이너 단위로 테스트를 실행하면 실제 서비스 환경과 유사한 조건을 만들 수 있습니다.

📊 관찰 지표 설정

DNS 실패 시엔 단순히 오류 로그를 남기는 것을 넘어, 재시도 횟수, 실패율, 평균 복구 시간(MTTR)을 추적해야 합니다.
이를 위해 Prometheus, Grafana, Datadog 같은 모니터링 도구에서 error_type=”DNSFailure” 라벨로 메트릭을 집계하면 문제 발생 빈도와 트렌드를 시각화할 수 있습니다.
이런 데이터는 실제 장애 대응 전략 수립의 근거로 쓰이므로, 코드 수준에서 이미 측정이 가능하도록 설계하는 것이 좋습니다.

💬 DNS 실패는 코드 한 줄로 재현할 수 있지만, 이를 모니터링하지 않으면 수많은 요청이 실패한 뒤에야 발견됩니다.

🔁 연결 리셋과 타임아웃 재현

DNS 실패가 이름 해석 단계에서의 문제라면, 연결 리셋은 TCP 연결 도중 발생하는 장애입니다.
이 문제는 클라이언트가 요청을 보낸 직후 서버가 RST 패킷으로 응답을 끊는 상황으로, 실제 서비스에서는 로드밸런서나 방화벽 설정에 의해 흔히 발생합니다.
이러한 장애를 재현하면, requests의 재시도 로직이 정상적으로 작동하는지, 그리고 타임아웃이 올바르게 설정되어 있는지를 확인할 수 있습니다.

⚙️ 연결 리셋을 재현하는 방법

연결 리셋(Connection Reset)을 인위적으로 만들기 위해선 서버 측에서 의도적으로 연결을 끊는 스크립트를 실행하거나, toxiproxy 같은 프록시 도구를 활용할 수 있습니다.
아래는 간단한 예시로, 서버가 요청을 받은 뒤 응답을 보내기 전에 강제로 연결을 닫는 코드입니다.

from http.server import BaseHTTPRequestHandler, HTTPServer
import socket

class ResetHandler(BaseHTTPRequestHandler):
    def do_GET(self):
        # 클라이언트 연결을 강제로 끊음
        self.connection.shutdown(socket.SHUT_RDWR)
        self.connection.close()

server = HTTPServer(('0.0.0.0', 8080), ResetHandler)
server.serve_forever()

이 서버에 requests로 접근하면 즉시 ConnectionResetError가 발생합니다.
이 상태에서 재시도 정책을 조정하거나, 타임아웃 설정이 적용되는지 확인하면 됩니다.
실제 운영 환경에서는 네트워크 경계 장비, 프록시, 또는 API Gateway가 이런 현상을 만들어내기도 하므로 반드시 대비가 필요합니다.

⏳ 타임아웃 테스트와 설정 팁

requests는 두 가지 타임아웃 값을 제공합니다.
첫 번째는 연결 타임아웃(connect timeout), 두 번째는 읽기 타임아웃(read timeout)입니다.
이 둘을 분리하여 설정하면 네트워크의 어떤 단계에서 지연이 발생하는지 세밀하게 구분할 수 있습니다.

import requests
from requests.exceptions import ReadTimeout, ConnectTimeout

try:
    requests.get("https://example.com", timeout=(2.0, 3.0))
except ConnectTimeout:
    print("연결 타임아웃 발생")
except ReadTimeout:
    print("읽기 타임아웃 발생")

위 설정에서 첫 번째 값은 서버와의 연결이 이루어지는 데 허용되는 시간, 두 번째 값은 서버 응답을 기다리는 시간입니다.
이 두 값을 분리해 조정하면 느린 네트워크나 갑작스러운 끊김 상황에서 시스템이 멈추지 않고 복구하도록 만들 수 있습니다.

🧩 안정적 회복을 위한 패턴

네트워크 실패가 감지되면 단순히 재시도하는 것을 넘어, 지수 백오프(exponential backoff)와 회로 차단기(circuit breaker) 같은 패턴을 조합하는 것이 좋습니다.
이 방식은 장애가 반복될 때 시스템이 과도한 요청으로 붕괴되는 것을 막고, 일정 시간 이후에만 재연결을 시도하도록 조정합니다.
특히 분산 환경에서는 타임아웃과 리셋이 급증할 수 있으므로, 로컬 재시도 외에도 중앙 모니터링 지표를 연동해야 합니다.

• 🔁연결 리셋을 인위적으로 만들어 재시도 로직이 올바르게 동작하는지 검증
• ⏱️connect/read 타임아웃을 분리해 설정하여 구간별 지연 분석
• 📊재시도 횟수, 실패율, 평균 복구 시간 등 주요 메트릭을 시각화
• 🧠백오프 및 회로 차단기 패턴으로 복구 로직의 안정성 확보

💬 타임아웃은 느린 서버를 기다리기 위한 설정이 아니라, 전체 시스템을 보호하기 위한 최소한의 안전장치입니다.

⏱️ 지연 주입과 성능 저하 테스트

지연(latency)은 사용자 경험에 직접적인 영향을 주는 요소입니다.
DNS 실패나 연결 리셋과 달리 요청 자체는 성공하지만, 응답 속도가 급격히 느려질 때 시스템은 예상치 못한 부하를 겪습니다.
이럴 때 지연 주입(delay injection) 기법을 사용하면 requests 기반 애플리케이션이 느린 응답 환경에서도 안정적으로 동작하는지 검증할 수 있습니다.

🧪 인위적인 응답 지연 시뮬레이션

간단한 방식으로는 Flask 같은 로컬 서버에서 time.sleep()을 이용해 응답을 늦추는 방법이 있습니다.
이 방법은 requests의 read timeout이 언제 동작하는지를 손쉽게 관찰할 수 있게 해줍니다.

from flask import Flask
import time

app = Flask(__name__)

@app.route("/slow")
def slow_response():
    time.sleep(5)  # 응답 지연
    return "done"

if __name__ == "__main__":
    app.run(port=5000)

이제 클라이언트에서 다음과 같이 요청을 보내면 타임아웃 조건을 쉽게 확인할 수 있습니다.

import requests
from requests.exceptions import ReadTimeout

try:
    requests.get("http://localhost:5000/slow", timeout=(1, 2))
except ReadTimeout:
    print("응답 지연으로 타임아웃 발생")

응답 지연 테스트는 단순히 실패를 보는 것이 아니라, 느려진 환경에서 백엔드 쓰레드 풀이 고갈되는지, 비동기 큐가 정체되지 않는지를 함께 관찰해야 합니다.
이런 테스트는 특히 외부 API 연동, 파일 업로드, 데이터베이스 트랜잭션을 수행하는 서비스에서 필수적입니다.

⚡ 네트워크 지연 도구 활용

운영 환경과 유사한 수준의 지연을 만들어내기 위해선, 시스템 단의 네트워크 시뮬레이터를 사용하는 것이 가장 현실적입니다.
대표적으로 tc (Traffic Control) 명령어나 netem 모듈을 이용하면 리눅스 커널 수준에서 지연, 패킷 손실, 재정렬 등을 정확히 제어할 수 있습니다.

# 200ms 지연 추가
sudo tc qdisc add dev eth0 root netem delay 200ms

# 5% 패킷 손실 시뮬레이션
sudo tc qdisc change dev eth0 root netem loss 5%

이 방식은 로컬뿐 아니라 Docker 컨테이너 네트워크에도 적용할 수 있어, CI/CD 파이프라인에 포함하기 좋습니다.
테스트 결과를 메트릭화하면 평균 지연 증가에 따른 응답 성공률, 타임아웃 빈도, 에러율을 객관적으로 비교할 수 있습니다.

📈 관찰 포인트

지연 주입 실험 후에는 다음과 같은 데이터를 반드시 관찰해야 합니다.

• 📊평균 응답 시간(latency mean), 95/99 퍼센타일 지연(P95/P99)
• 🔁재시도 빈도 및 성공률
• ⚙️CPU 및 메모리 사용률 변화
• 🧠타임아웃 임계값과 실제 지연의 상관관계

💬 지연 주입 실험의 목표는 ‘더 빠른 시스템’이 아니라, ‘느려져도 안전한 시스템’을 만드는 것입니다.

📈 관찰성 지표와 회복력 패턴

장애주입을 통해 얻는 데이터는 단순한 로그가 아니라 시스템의 회복력을 판단하는 핵심 근거입니다.
관찰성(Observability)은 로그, 메트릭, 트레이스의 결합으로 문제의 원인을 좁혀가게 합니다.
DNS 실패, 연결 리셋, 지연 같은 네트워크 장애 시 어떤 지표를 수집하고 대시보드와 경고를 설계해야 하는지 명확히 정의해두면, 장애 대응 속도와 정확도가 크게 향상됩니다.
이 섹션에서는 핵심 메트릭, 권장 레이블, 예시 쿼리, 그리고 SLO/에러버짓과 회복력 패턴을 실무적으로 연결하는 방법을 정리합니다.

📊 핵심 메트릭 (Metrics)

장애주입 실험에서 반드시 수집해야 할 메트릭은 다음과 같습니다.
요청 수(requests_total), 성공률(request_success_total), 실패 유형별 카운트(request_failure_total with error_type 라벨), 레이턴시 분포(request_latency_seconds histogram), 재시도 횟수(retries_total), 타임아웃 비율(timeouts_total) 등입니다.
레이블로는 service, endpoint, environment, error_type, retry_count 등을 포함하면 나중에 쿼리로 필터링할 때 유용합니다.
이 메트릭들은 Prometheus로 스크래핑해 Grafana 대시보드에서 P95/P99 추세와 장애 발생 시의 변화량을 분석하는 데 사용됩니다.

🔎 권장 로그와 트레이스

로그는 구조화된 JSON 형식으로 남겨야 자동 분석과 집계가 쉬워집니다.
로그에는 timestamp, request_id, trace_id, span_id, service, endpoint, status_code, error_type, latency_ms, retry_count 같은 필드를 포함합니다.
트레이싱은 분산 경계(예: DNS 해석, TCP 연결, TLS 핸드셰이크, 애플리케이션 레벨 처리)를 색인화해 어떤 단계에서 지연이나 실패가 발생했는지를 보여줍니다.
OpenTelemetry를 통해 자동 계측하면, 하나의 요청이 어디서 지연되는지 스팬 타임라인으로 빠르게 파악할 수 있습니다.

# Python: prometheus_client로 기본 메트릭 계측 예시
from prometheus_client import Counter, Histogram, start_http_server
import time, requests

REQUESTS = Counter("requests_total", "Total HTTP requests", ["service", "endpoint", "status"])
FAILURES = Counter("request_failures_total", "Failed requests", ["service", "endpoint", "error_type"])
LATENCY = Histogram("request_latency_seconds", "Request latency seconds", ["service","endpoint"])

def call(url):
    endpoint = "/api"
    with LATENCY.labels("myservice", endpoint).time():
        try:
            r = requests.get(url, timeout=(2.0,3.0))
            REQUESTS.labels("myservice", endpoint, str(r.status_code)).inc()
            return r
        except requests.exceptions.RequestException as e:
            FAILURES.labels("myservice", endpoint, type(e).__name__).inc()
            raise

if __name__ == "__main__":
    start_http_server(8000)  # Prometheus가 스크랩하는 엔드포인트
    while True:
        try:
            call("http://example.com")
        except:
            pass
        time.sleep(1)

📈 SLO와 에러버짓 연동

SLO(Service Level Objective)를 정의하면 실험 결과를 운영 목표와 연결할 수 있습니다.
예를 들어 ‘응답 성공률 99.9% (월 기준)’ 같은 SLO가 있으면 장애주입으로 증가한 실패율이 에러버짓을 얼마나 소비했는지 계산할 수 있습니다.
에러버짓 소진이 빠르면 더 강한 회복성 조치(캐시 사용, 폴백 엔드포인트, 트래픽 쉐이핑 등)를 우선 적용해야 합니다.
중요한 점은 장애주입 실험 결과를 통해 SLO 위반 가능성과 운영 대비책의 효과를 수치로 검증해야 한다는 것입니다.

🛠️ 회복력 패턴과 자동화

재시도 정책은 단순 반복이 아니라, 상태에 따른 조건부 재시도가 중요합니다.
예를 들어 DNS 실패(gaierror)에는 짧은 재시도와 캐시된 IP 폴백을 적용하고, 서버 내부 오류(5xx)에는 지수 백오프와 회로차단기를 적용하는 식입니다.
자동화로는 실험 실행 → 메트릭 수집 → 비교 쿼리 실행 → 결과 리포트 생성 흐름을 CI 파이프라인에 포함시키면, 회귀가 생겼을 때 빠르게 알 수 있습니다.
또한 실험마다 태그(예: experiment_id, run_id)를 남겨 결과를 추적 가능하게 만드세요.

• 📌메트릭: requests_total, request_failures_total(error_type), request_latency_seconds(histogram)
• 🔎로그: trace_id, request_id, error_type, latency_ms 포함
• 📉SLO/에러버짓과 실험 결과를 비교해 운영 임계값을 검증
• 🤖실험→수집→분석→리포트 흐름을 CI에 자동화해 회귀 감지

💬 관찰성은 문제를 ‘발견’하는 능력뿐 아니라, 발견한 문제의 ‘원인’을 좁혀 수리 가능한 조치로 연결하는 능력입니다.

❓ 자주 묻는 질문 (FAQ)

🚀 파이썬 requests 장애주입으로 탄탄한 회복력 확보하기

DNS 실패, 연결 리셋, 지연 같은 네트워크 장애는 언제든 발생할 수 있습니다.
이러한 실패를 사전에 시뮬레이션하고 관찰하는 것이 바로 운영 안정성의 핵심입니다.
파이썬 requests 라이브러리를 중심으로 장애주입 실험을 수행하면, 단순한 기능 테스트를 넘어 회복력(resilience)을 수치로 측정할 수 있습니다.
실패 시나리오를 반복적으로 재현하면서, 타임아웃·재시도·백오프·회로차단기 등의 패턴이 실제로 서비스 품질을 유지하는지 확인할 수 있습니다.

관찰성(Observability)은 실험의 결과를 체계적으로 해석하는 도구입니다.
로그, 메트릭, 트레이스 세 축을 연결하면 DNS 문제부터 네트워크 경계까지 어떤 구간에서 병목이 생기는지 명확히 파악할 수 있습니다.
이를 기반으로 SLO를 설계하고 에러버짓을 관리하면, 시스템이 예측 가능한 방식으로 실패하고 복구하는 ‘안전한 실패(fail-safe)’ 상태를 만들 수 있습니다.
결국 장애주입은 시스템을 불안하게 만드는 행위가 아니라, 진짜 안정성을 확보하기 위한 과학적인 절차입니다.

지속적인 회복력 테스트를 통해 장애에도 끄떡없는 서비스를 설계하고, 관찰성 데이터로 개선점을 도출하세요.
코드는 짧아도, 준비된 시스템은 오래갑니다.

🏷️ 관련 태그 : 파이썬requests, 네트워크장애주입, DNS실패테스트, 연결리셋시뮬레이션, 지연주입, 회복력테스트, 운영관찰성, 타임아웃설정, 백오프패턴, 서비스안정성