Partilhar via

Compreenda o pipeline HTTP e as tentativas de reenvio no Azure SDK para Python

Quando faz uma chamada para qualquer serviço Azure usando o Azure SDK para Python, o seu pedido não vai diretamente para o serviço Azure. Não importa se é Azure Blob Storage, Azure Key Vault, Azure Cosmos DB ou qualquer outro serviço baseado em HTTP. Em vez disso, o seu pedido flui através de um pipeline HTTP sofisticado que lida automaticamente com questões transversais críticas.

Entender como o pipeline HTTP funciona é essencial para criar aplicativos robustos e de alto desempenho. O pipeline:

  • Gerencia repetições para falhas transitórias.
  • Trata da autenticação.
  • Fornece capacidades de registo.
  • Permite adicionar comportamentos personalizados quando necessário.

Esse conhecimento ajuda você a depurar problemas de desempenho, otimizar a resiliência e personalizar a interação do seu aplicativo com os serviços do Azure.

O que é o pipeline HTTP?

O SDK do Azure para Python usa uma arquitetura de pipeline HTTP interna para processar todas as solicitações e respostas. Este pipeline consiste numa série de políticas que são executadas em sequência. Cada política é responsável por um aspeto específico da comunicação HTTP. Pense no pipeline como uma cadeia de etapas de processamento:

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

Cada política em preparação pode:

  • Modifica o pedido antes de ser enviado.
  • Processa a resposta depois de recebida.
  • Efetue ações como tentar novamente as solicitações falhadas.
  • Adicionar cabeçalhos, informação de registo ou implementar lógica personalizada.

Principais políticas em preparação

O SDK do Azure para Python inclui várias políticas internas que lidam com cenários comuns:

  • RetryPolicy: Retenta automaticamente pedidos que falham devido a erros transitórios. Esta política implementa uma lógica de repetição inteligente com recuo exponencial para evitar sobrecarregar os serviços durante interrupções.
  • BearerTokenCredentialPolicy: Gerir a autenticação através da aquisição e atualização automática dos tokens de acesso. Esta política garante que os seus pedidos incluem credenciais de autenticação válidas sem necessidade de gestão manual de tokens.
  • NetworkTraceLoggingPolicy: Captura informações detalhadas sobre pedidos HTTP e respostas para fins de depuração. Esta política é inestimável quando resolve problemas de comunicação.
  • HttpTransport: A camada mais baixa do pipeline que realmente envia pedidos HTTP pela rede. No Azure SDK para Python, esta política é normalmente implementada através do uso de requests ou aiohttp para operações assíncronas.

Outras políticas

  • RedirectPolicy: Gere automaticamente os redirecionamentos HTTP.
  • DistributedTracingPolicy: Integra-se com sistemas de rastreio distribuído para monitorização.
  • ProxyPolicy: Encaminha pedidos através de proxies HTTP quando configurado.
  • UserAgentPolicy: Adiciona informação de versão do SDK aos cabeçalhos de pedido.

Comportamento de repetição

O SDK do Azure para Python implementa a lógica de repetição inteligente para lidar com falhas transitórias automaticamente. Compreender esse comportamento ajuda a criar aplicativos mais resilientes.

Condições repetidas automaticamente

O SDK tenta novamente solicitações para esses códigos de status HTTP:

  • 408 Request Timeout: O servidor esgotou o tempo de espera pelo pedido.
  • 429 Muitas Solicitações: Limitação de velocidade está em vigor.
  • Erro do Servidor Interno 500: Problema temporário no servidor.
  • 502 Bad Gateway: Problema temporário na rede.
  • Serviço 503 Indisponível: Serviço temporariamente indisponível.
  • 504 Gateway Timeout: timeout de gateway ou proxy.

Configuração de repetição padrão

As configurações de repetição padrão fornecem um bom equilíbrio entre resiliência e desempenho:

  • Máximo de tentativas: 3
  • Modo de retentar: Retrocesso exponencial
  • Atraso na base: 0,8 segundos
  • Atraso máximo: 60 segundos
  • Tempo máximo total de retentativa: 120 segundos

O cálculo de retrocesso exponencial segue este padrão:

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

Personalizar tentativas

Pode personalizar o comportamento das tentativas de nova tentativa ao configurar clientes SDK para satisfazer os requisitos específicos para a sua aplicação.

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
)

Desativar tentativas

Para cenários em que as novas tentativas não são apropriadas:

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
)

Diagnosticar e depurar o comportamento de tentativas repetidas

Entender quando e por que ocorrem novas tentativas é crucial para solucionar problemas de desempenho.

Habilitar o registro em log do SDK

O SDK do Azure para Python usa a estrutura de log padrão do 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

Identificar padrões de repetição

Procure entradas de log como:

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

Armadilhas comuns de repetição

  • Repetição de erros não transitórios: O SDK não repete erros do cliente (4xx), com exceção de 408 e 429.
  • Ignorar a latência de reintento: É importante lembrar que os reintentos adicionam latência às operações falhadas.
  • Configuração de tempo de espera insuficiente: Certifique-se de que o tempo de espera total da sua operação tem em conta os atrasos nas retentativas.

Avançado: Adicionar políticas personalizadas

Você pode estender o pipeline com políticas personalizadas para cenários especializados.

Criar uma política personalizada

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

Aplicar políticas personalizadas

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
)

Política de encomenda

As políticas são executadas em uma ordem específica:

  • Políticas por chamada (executadas uma vez por operação).
  • Política de reintentos.
  • Políticas por retentativa (executadas em cada tentativa).
  • Política de autenticação.
  • Transporte HTTP.

Melhores práticas

Use as configurações padrão quando possível

A configuração de repetição padrão funciona bem para a maioria dos cenários. Personalize apenas quando tiver requisitos específicos.

Diretrizes de personalização

Quando personaliza o comportamento de tentativa de nova execução:

  • Use recuo exponencial: Use para evitar serviços sobrecarregados durante a recuperação.
  • Defina limites razoáveis: Limite o tempo total de retentativa para evitar espera indefinida.
  • Monitorizar métricas de tentativas repetidas: Acompanhe as taxas de tentativas repetidas em produção para identificar problemas.
  • Considere disjuntores: Implemente padrões de disjuntores para cenários de alto volume.

O que não tentar novamente

Evite repetir estes tipos de erros:

  • Falhas de autenticação (401, 403): Os erros de autenticação exigem corrigir credenciais, não tentar novamente.
  • Erros do cliente (400, 404): Erros do cliente indicam problemas com o próprio pedido.
  • Erros de lógica de negócio: Erros específicos da aplicação que não se resolvem com tentativas.

Excelência operacional

  • IDs de correlação de log: Inclua x-ms-client-request-id nos registos para suporte do Azure.
  • Defina tempos apropriados: Equilíbrio entre fiabilidade e experiência do utilizador.
  • Comportamento de repetição no teste: Verifica se a tua aplicação gere as repetições com elegância.
  • Desempenho do monitor: Acompanhe as latências P95/P99 (métricas de latência baseadas em percentil), incluindo sobrecarga de retentativa.

Conteúdo relacionado

  • Last updated on