Retry

출처: Traefik HTTP Retry Documentation

본문

Retry

retry 미들웨어는 백엔드 서버가 응답하지 않으면 그 서버에 요청을 지정된 횟수만큼 재시도합니다. 서버가 응답하는 순간 응답 상태와 관계없이 미들웨어는 재시도를 멈춰요.

Retry 미들웨어는 지수 백오프(exponential backoff)를 활성화하는 선택적 구성을 갖고 있습니다.

구성 예시

구조화된 (YAML)

# 지수 백오프로 4회 재시도
http:
  middlewares:
    test-retry:
      retry:
        attempts: 4
        initialInterval: 100ms
        timeout: 60s
        maxRequestBodyBytes: 1024
        status: 
          - "400"
          - "500-599"
        disableRetryOnNetworkError: true
        retryNonIdempotentMethod: true

구조화된 (TOML)

# 지수 백오프로 4회 재시도
[http.middlewares]
  [http.middlewares.test-retry.retry]
    attempts = 4
    initialInterval = "100ms"
    timeout = "60s"
    maxRequestBodyBytes = 1024
    status = ["400","500-599"]
    disableRetryOnNetworkError = true
    retryNonIdempotentMethod = true

Labels

# 지수 백오프로 4회 재시도
labels:
  - "traefik.http.middlewares.test-retry.retry.attempts=4"
  - "traefik.http.middlewares.test-retry.retry.initialinterval=100ms"
  - "traefik.http.middlewares.test-retry.retry.timeout=60s"
  - "traefik.http.middlewares.test-retry.retry.maxrequestbodybytes=1024"
  - "traefik.http.middlewares.test-retry.retry.status=400,500-599"
  - "traefik.http.middlewares.test-retry.retry.disableretryonnetworkerror=true"
  - "traefik.http.middlewares.test-retry.retry.retrynonidempotentmethod=true"

Tags

// 지수 백오프로 4회 재시도

{
  // ...
  "Tags" : [
    "traefik.http.middlewares.test-retry.retry.attempts=4",
    "traefik.http.middlewares.test-retry.retry.initialinterval=100ms",
    "traefik.http.middlewares.test-retry.retry.timeout=60s",
    "traefik.http.middlewares.test-retry.retry.maxrequestbodybytes=1024",
    "traefik.http.middlewares.test-retry.retry.status=400,500-599",
    "traefik.http.middlewares.test-retry.retry.disableretryonnetworkerror=true",
    "traefik.http.middlewares.test-retry.retry.retrynonidempotentmethod=true"
  ]
}

Kubernetes

# 지수 백오프로 4회 재시도
apiVersion: traefik.io/v1alpha1
kind: Middleware
metadata:
  name: test-retry
spec:
  retry:
    attempts: 4
    initialInterval: 100ms
    timeout: 60s
    maxRequestBodyBytes: 1024
    status: 
      - "400"
      - "500-599"
    disableRetryOnNetworkError: true
    retryNonIdempotentMethod: true

구성 옵션

| Field | Description | Default | Required | | attempts | 요청을 재시도해야 하는 횟수. | | Yes | | initialInterval | 지수 백오프 수열의 첫 대기 시간. 최대 간격은 initialInterval의 두 배로 계산됩니다. 지정하지 않으면 요청이 즉시 재시도됩니다. 초 단위 또는 유효한 기간 형식으로 정의하며, time.ParseDuration을 참고하세요. | 0 | No | | timeout | 미들웨어가 요청을 재시도할 수 있는 시간. 초 단위 또는 유효한 기간 형식으로 정의하며, time.ParseDuration을 참고하세요. | 0 | No | | maxRequestBodyBytes | 요청 본문의 최대 크기를 정의해요. 자세한 내용은 여기. | 2MB | No | | status | 재시도할 HTTP 상태 코드의 범위를 정의해요. 자세한 내용은 여기. | [] | No | | disableRetryOnNetworkError | 이 옵션은 서버로 요청을 전송하는 중 오류가 발생하면 재시도를 비활성화해요. 자세한 내용은 여기. | false | No | | retryNonIdempotentMethod | 비멱등(non-idempotent) 메서드(POST, LOCK, PATCH)에 대한 재시도를 활성화해요. | false | No |

maxRequestBodyBytes

maxRequestBodyBytes 옵션은 서버에 전송될 요청 본문의 최대 크기를 제어합니다.

⚠️ 중요한 보안 고려 사항

maxRequestBodyBytes가 -1로 설정되면 요청 본문 크기에 제한이 없다는 뜻이에요. 이는 상당한 보안 및 성능 영향을 미칠 수 있습니다:

• 보안 위험: 공격자가 매우 큰 요청 본문을 보내 DoS 공격이나 메모리 고갈을 일으킬 수 있어요.

• 성능 영향: 큰 요청 본문은 메모리와 처리 리소스를 소비해 전체 시스템 성능에 영향을 줍니다.

• 리소스 소비: 본문 크기 제한이 없으면 예기치 않은 리소스 사용 패턴이 생길 수 있어요.

권장 구성

사용 사례에 적절한 maxRequestBodyBytes 값을 설정하는 것을 강력히 권장합니다:

# 대부분의 웹 애플리케이션 (1MB 제한)
maxRequestBodyBytes: 1048576  # 1MB in bytes

# 더 큰 페이로드를 기대하는 API 엔드포인트 (10MB 제한)  
maxRequestBodyBytes: 10485760  # 10MB in bytes

# 파일 업로드 인증 (100MB 제한)
maxRequestBodyBytes: 104857600  # 100MB in bytes

maxRequestBodyBytes 설정 지침

• 웹 폼: 대부분의 폼 제출에는 보통 1-5MB면 충분해요.

• API 엔드포인트: 가장 큰 예상 JSON/XML 페이로드에 버퍼를 더한 값을 고려하세요.

• 파일 업로드: 최대 예상 파일 크기를 기준으로 설정하세요.

• 트래픽이 많은 서비스: 리소스 고갈을 막기 위해 더 작은 제한을 사용하세요.

disableRetryOnNetworkError와 status

disableRetryOnNetworkError 옵션은 TCP 계층에서 서버로 요청을 전송하는 중 오류가 발생하면 재시도를 비활성화합니다. 하지만 특정 HTTP 상태 코드에 대해서만 재시도하고 싶다면, 재시도할 관련 상태 코드로 status 옵션을 구성할 수 있어요.

disableRetryOnNetworkError가 true로 설정되면 status 옵션을 반드시 정의해야 합니다. 그렇지 않으면 미들웨어가 구성 오류를 발생시킵니다.

더 알아보기 (Learn more)

• Traefik 공식 문서