Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.supertoneapi.com/llms.txt

Use this file to discover all available pages before exploring further.

이 문서는 영어 원문을 기반으로 자동 번역되었습니다. 표현이 어색하거나 모호한 부분이 있을 수 있으니, 정확한 내용은 영어 원문을 함께 확인해 주세요.
일시적인 실패(429, 408, 500, 네트워크 단절)는 네트워크 기반 서비스에서 흔히 발생합니다. 올바른 대응은 지터를 적용한 지수 백오프를 재시도 가능한 오류에만 적용하는 것입니다. 두 SDK 모두 설정 가능한 재시도 정책을 기본 제공합니다.

재시도 대상

상태 / 실패 유형재시도 가능 여부비고
408 Request Timeout서버 측 — 잠시 기다린 후 재시도하세요.
429 Too Many Requests요청 수 제한 — 백오프를 적용하세요.
500 Internal Server Error일시적인 문제로 처리하세요.
502, 503, 504네트워크/업스트림 — 백오프와 함께 재시도하세요.
네트워크 오류 (DNS, broken pipe, connect timeout)재시도하세요 — 순수 전송 계층의 일시적 실패입니다.
400, 401, 402, 403, 404, 413, 415호출자 측 문제 — 요청을 먼저 수정해야 합니다.

SDK 설정

두 SDK 모두 클라이언트 레벨과 호출 단위 모두에서 재시도 설정을 받습니다.
from supertone import Supertone
from supertone.utils.retries import RetryConfig

client = Supertone(
    api_key=os.environ["SUPERTONE_API_KEY"],
    retry_config=RetryConfig(
        strategy="backoff",
        backoff={
            "initial_interval": 500,        # ms
            "max_interval": 60_000,         # ms
            "exponent": 1.5,
            "max_elapsed_time": 3_600_000,  # ms (1 hour cap)
        },
        retry_connection_errors=True,
    ),
)
이 설정은 SDK의 기본 재시도 대상 상태 코드(429, 5xx)에 대해 지수 백오프 방식으로 재시도하며, 재시도 간 최대 1분, 총 1시간으로 상한을 둡니다. 수치는 서비스의 지연시간 SLO에 맞춰 조정해 주세요.

수동 재시도 패턴

REST API를 직접 호출하거나, SDK 위에 자체 로직을 감싸고자 한다면 다음 패턴을 사용할 수 있습니다.
import random
import time

def call_with_backoff(fn, *, max_attempts=5, base_ms=500, max_ms=60_000):
    for attempt in range(max_attempts):
        try:
            return fn()
        except (
            errors.TooManyRequestsErrorResponse,
            errors.InternalServerErrorResponse,
            errors.RequestTimeoutErrorResponse,
        ) as e:
            if attempt == max_attempts - 1:
                raise
            delay_ms = min(base_ms * (2 ** attempt), max_ms)
            # Jitter to avoid thundering herd
            delay_ms = delay_ms / 2 + random.uniform(0, delay_ms / 2)
            time.sleep(delay_ms / 1000)

적절한 백오프 선택

  • 요청 수 제한으로 인한 429 — 초기 대기 5001,000 ms에서 시작해 3060초까지 두 배씩 증가시키고, 재시도 횟수는 3~5회로 제한합니다.
  • 일시적 오류로 인한 500/5xx — 같은 형태이되, 보통 빠르게 해소되므로 조금 더 공격적으로 설정합니다(초기 300 ms).
  • 스트리밍 요청 — 재생을 시작하기 전이라면 일부분 수신된 스트림을 재시도해도 무방하지만, 재생이 이미 시작된 후에는 새로운 오디오를 이어 붙이기보다 실패시키는 편이 보통 더 낫습니다. UX 기준으로 결정하세요.
  • 장문 자동 청크 처리 — 두 SDK 모두 내부 분할된 각 세그먼트에 동일한 재시도 정책을 적용하므로, 단일 장문 호출은 세그먼트별로 재시도 예산을 갖습니다.

멱등성

Supertone API 호출은 효과 측면에서 멱등성을 가집니다 — 동일한 요청은 동일한 오디오 결과를 생성합니다(미세한 합성 변동성은 제외). 성공했으나 중단된 요청을 재시도해도, 원래 요청이 과금 대상 오디오를 생성하지 않았다면 크레딧이 이중 청구되지 않습니다. 보이스 클로닝 업로드의 경우, 업로드가 완료되면 재시도가 매번 별도의 보이스를 생성합니다. 네트워크 단절 후 재업로드할 때는 이전 시도가 실제로 완료되었는지 먼저 확인하세요. 그렇지 않으면 list_custom_voices에 중복된 보이스가 남게 됩니다.

피해야 할 안티 패턴

  • 429 외의 4xx 재시도 — 시간이 지나도 해결되지 않습니다. 요청을 먼저 수정하세요.
  • 상한 미설정 — 시도 횟수와 총 경과 시간에 반드시 상한을 두세요.
  • 지터 미적용 — 고정 간격 재시도는 광범위한 장애 상황에서 thundering-herd 현상을 유발합니다.
  • 루프 안에서 백오프 없이 재시도 — 크레딧과 요청 제한 예산을 수 초 만에 소진시킵니다.

관련 문서

요청 수 제한

애초에 429가 발생하는 조건을 확인하세요.

오류 처리

오류 코드와 SDK 오류 클래스의 전체 레퍼런스를 확인하세요.