Python용 Azure SDK에서 HTTP 파이프라인 이해 및 다시 시도

Python용 Azure SDK를 사용하여 Azure 서비스를 호출하는 경우 요청이 Azure 서비스로 직접 이동하지 않습니다. Azure Blob Storage, Azure Key Vault, Azure Cosmos DB 또는 다른 HTTP 기반 서비스인지는 중요하지 않습니다. 대신 요청은 중요한 교차 절단 문제를 자동으로 처리하는 정교한 HTTP 파이프라인을 통해 흐릅니다.

HTTP 파이프라인의 작동 방식을 이해하는 것은 강력하고 성능이 좋은 애플리케이션을 빌드하는 데 필수적입니다. 파이프라인:

  • 일시적인 오류에 대한 재시도를 관리합니다.
  • 인증을 처리합니다.
  • 로깅 기능을 제공합니다.
  • 필요한 경우 사용자 지정 동작을 추가할 수 있습니다.

이 지식은 성능 문제를 디버그하고, 복원력을 최적화하고, Azure 서비스와 애플리케이션의 상호 작용을 사용자 지정하는 데 도움이 됩니다.

HTTP 파이프라인이란?

Python용 Azure SDK는 내부 HTTP 파이프라인 아키텍처를 사용하여 모든 요청 및 응답을 처리합니다. 이 파이프라인은 순서대로 실행되는 일련의 정책으로 구성됩니다. 각 정책은 HTTP 통신의 특정 측면을 담당합니다. 파이프라인을 처리 단계의 체인으로 간주합니다.

Client Request → Retry Policy → Authentication Policy → Logging Policy → HTTP Transport → Azure Service
                                                                                              ↓
Client Response ← Retry Policy ← Authentication Policy ← Logging Policy ← HTTP Transport ← Response

파이프라인의 각 정책은 다음을 수행할 수 있습니다.

  • 요청을 보내기 전에 수정합니다.
  • 응답을 받은 후 처리합니다.
  • 실패한 요청 다시 시도와 같은 작업을 수행합니다.
  • 헤더를 추가하거나, 정보를 기록하거나, 사용자 지정 논리를 구현합니다.

파이프라인의 주요 정책

Python용 Azure SDK에는 일반적인 시나리오를 처리하는 몇 가지 기본 제공 정책이 포함되어 있습니다.

  • RetryPolicy: 일시적 오류로 인해 실패한 요청을 자동으로 다시 시도합니다. 이 정책은 중단 중에 압도적인 서비스를 방지하기 위해 지수 백오프를 사용하여 지능형 재시도 논리를 구현합니다.
  • BearerTokenCredentialPolicy: 액세스 토큰을 자동으로 획득하고 새로 고침하여 인증을 관리합니다. 이 정책은 요청에 수동 토큰 관리 없이 유효한 인증 자격 증명을 포함하도록 합니다.
  • NetworkTraceLoggingPolicy: 디버깅을 위해 HTTP 요청 및 응답에 대한 자세한 정보를 캡처합니다. 이 정책은 통신 문제를 해결할 때 매우 중요합니다.
  • HttpTransport: 네트워크를 통해 실제로 HTTP 요청을 보내는 파이프라인의 가장 낮은 계층입니다. Python용 Azure SDK에서 이 정책은 일반적으로 비동기 작업에 요청 또는 aiohttp를 사용하여 구현됩니다.

기타 정책

  • RedirectPolicy: HTTP 리디렉션을 자동으로 처리합니다.
  • DistributedTracingPolicy: 모니터링을 위해 분산 추적 시스템과 통합됩니다.
  • ProxyPolicy: 구성된 경우 HTTP 프록시를 통해 요청을 라우팅합니다.
  • UserAgentPolicy: 요청 헤더에 SDK 버전 정보를 추가합니다.

다시 시도 동작

Python용 Azure SDK는 일시적인 오류를 자동으로 처리하는 지능형 재시도 논리를 구현합니다. 이 동작을 이해하면 복원력 있는 애플리케이션을 빌드하는 데 도움이 됩니다.

자동으로 다시 시도된 조건

SDK는 다음 HTTP 상태 코드에 대한 요청을 다시 시도합니다.

  • 408 요청 시간 제한: 서버가 요청을 기다리는 데 시간이 초과되었습니다.
  • 429 너무 많은 요청: 속도 제한이 적용됩니다.
  • 500 내부 서버 오류: 임시 서버 문제.
  • 502 잘못된 게이트웨이: 임시 네트워크 문제.
  • 503 서비스를 사용할 수 없음: 서비스를 일시적으로 사용할 수 없습니다.
  • 504 게이트웨이 시간 제한: 게이트웨이 또는 프록시 시간 제한입니다.

기본 다시 시도 구성

기본 재시도 설정은 복원력과 성능 간에 적절한 균형을 제공합니다.

  • 최대 재시도 횟수: 3
  • 다시 시도 모드: 지수 감산 대기
  • 기본 지연: 0.8초
  • 최대 지연 시간: 60초
  • 최대 총 재시도 시간: 120초

지수 백오프 계산은 다음 패턴을 따릅니다.

delay = min(base_delay * (2 ** retry_attempt), max_delay)

재시도 설정 사용자 지정

애플리케이션의 특정 요구 사항에 맞게 SDK 클라이언트를 만들 때 재시도 동작을 사용자 지정할 수 있습니다.

from azure.storage.blob import BlobServiceClient
from azure.core.pipeline.policies import RetryPolicy

# Custom retry configuration
retry_policy = RetryPolicy(
    retry_total=5,                    # Maximum number of retry attempts
    retry_backoff_factor=0.5,         # Base backoff time in seconds
    retry_backoff_max=120,            # Maximum backoff time in seconds
    retry_on_status_codes=[429, 500, 502, 503, 504]  # HTTP status codes to retry
)

# Apply custom retry policy to client
client = BlobServiceClient(
    account_url="https://myaccount.blob.core.windows.net",
    credential=credential,
    retry_policy=retry_policy
)

다시 시도 사용 안 함

재시도가 적절하지 않은 시나리오의 경우:

from azure.core.pipeline.policies import RetryPolicy

# Disable retries completely
no_retry_policy = RetryPolicy(retry_total=0)

client = BlobServiceClient(
    account_url="https://myaccount.blob.core.windows.net",
    credential=credential,
    retry_policy=no_retry_policy
)

다시 시도 동작 진단 및 디버그

다시 시도 발생 시기와 이유를 이해하는 것은 성능 문제를 해결하는 데 중요합니다.

SDK 로깅 사용

Python용 Azure SDK는 Python의 표준 로깅 프레임워크를 사용합니다.

import logging
import sys

# Configure logging to see retry attempts
logging.basicConfig(
    level=logging.DEBUG,
    format='%(asctime)s - %(name)s - %(levelname)s - %(message)s',
    stream=sys.stdout
)

# Enable specific Azure SDK loggers
azure_logger = logging.getLogger('azure')
azure_logger.setLevel(logging.DEBUG)

# Now SDK operations will log retry attempts

재시도 패턴 식별

다음과 같은 로그 항목을 찾습니다.

Retry attempt 1 for request [GET] https://myaccount.blob.core.windows.net/container/blob
Waiting 0.8 seconds before retry

일반적인 재시도 문제

  • 일시적이지 않은 오류 다시 시도: SDK는 408 및 429를 제외하고 클라이언트 오류(4xx)를 다시 시도하지 않습니다.
  • 재시도 대기 시간 무시: 다시 시도하면 실패한 작업에 대기 시간이 추가됩니다.
  • 불충분한 시간 초과 제공: 전체 작업 시간 초과가 재시도 지연을 포함하는지 확인하십시오.

고급: 사용자 지정 정책 추가

특수 시나리오에 대한 사용자 지정 정책을 사용하여 파이프라인을 확장할 수 있습니다.

사용자 지정 정책 만들기

from azure.core.pipeline import PipelineRequest, PipelineResponse
from azure.core.pipeline.policies import HTTPPolicy
from typing import Any, Optional

class CustomTelemetryPolicy(HTTPPolicy):
    """Custom policy to add telemetry headers"""
    
    def send(self, request: PipelineRequest) -> PipelineResponse:
        # Add custom header before sending request
        request.http_request.headers['X-Custom-Telemetry'] = 'my-app-v1.0'
        
        # Continue with the pipeline
        response = self.next.send(request)
        
        # Log response time
        print(f"Request to {request.http_request.url} completed")
        
        return response

사용자 지정 정책 적용

from azure.storage.blob import BlobServiceClient

# Create client with custom policy
client = BlobServiceClient(
    account_url="https://myaccount.blob.core.windows.net",
    credential=credential,
    per_call_policies=[CustomTelemetryPolicy()],  # Policies that run per request
    per_retry_policies=[]  # Policies that run per retry attempt
)

정책 순서 지정

정책은 특정 순서로 실행됩니다.

  • 호출별 정책(작업당 한 번 실행).
  • 정책을 다시 시도합니다.
  • 재시도별 정책(각 시도에서 실행).
  • 인증 정책.
  • HTTP 전송.

모범 사례

가능한 경우 기본 설정 사용

기본 재시도 구성은 대부분의 시나리오에서 잘 작동합니다. 특정 요구 사항이 있는 경우에만 사용자 지정합니다.

사용자 지정 지침

재시도 동작을 사용자 지정하는 경우:

  • 지수 백오프 사용: 복구 중에 서비스가 과부하되지 않도록 사용합니다.
  • 적절한 제한을 설정합니다. 무기한 대기를 방지하기 위해 총 재시도 시간을 제한합니다.
  • 다시 시도 메트릭 모니터링: 프로덕션에서 재시도율을 추적하여 문제를 식별합니다.
  • 회로 차단기를 고려합니다. 대량 시나리오에 대한 회로 차단기 패턴을 구현합니다.

다시 시도하지 않을 내용

다음 유형의 오류를 다시 시도하지 마세요.

  • 인증 실패(401, 403): 인증 오류는 다시 시도하지 않고 자격 증명을 수정해야 합니다.
  • 클라이언트 오류(400, 404): 클라이언트 오류는 요청 자체에 문제가 있음을 나타냅니다.
  • 비즈니스 논리 오류: 재시도로 해결되지 않는 애플리케이션별 오류입니다.

운영 우수성

  • 상관 ID: Azure 지원을 위해 로그에 x-ms-client-request-id을 포함합니다.
  • 적절한 시간 제한을 설정합니다. 안정성과 사용자 환경 간의 균형을 조정합니다.
  • 다시 시도 동작 테스트: 애플리케이션이 재시도를 정상적으로 처리하는지 확인합니다.
  • 성능 모니터링: 다시 시도 오버헤드를 포함하여 P95/P99 대기 시간(백분위수 기반 대기 시간 메트릭)을 추적합니다.