Escolha uma estratégia de acesso a ficheiros para o Funções do Azure

files = container_client.list_blobs(name_starts_with="reference/")
for blob in files:
    stream = container_client.download_blob(blob.name)

for file_path in Path("/mnt/reference").iterdir():
    with open(file_path, "rb") as f:

reference_data = container.query_items(
    query="SELECT * FROM reference WHERE id IN (...)"
)

Caso de uso: Tem 1.000 tarefas de análise que precisam todas de ler do mesmo conjunto de ficheiros de dados de referência (por exemplo, modelos de ML, tabelas de consulta ou dados de corpus).

O problema: Sem suportes, temos duas opções subótimas:

• Empacota os ficheiros de referência com a tua função: Esta abordagem resulta num enorme artefacto de implementação, arranques lentos a frio e redundância de armazenamento.
• Descarregar sempre a partir do Armazenamento de Blobs: Esta abordagem introduz latência de rede em cada invocação de função e desperdiça largura de banda.

A solução baseada em montagens: Todas as instâncias leem diretamente da partilha montada. Após a inicialização da montagem, não há overhead de rede por pedido nem armazenamento redundante.

┌─────────────────────────┐
│  Function Instance 1    │
│  Function Instance 2    ├──→  /mnt/models/  ──→  Azure Files share
│  Function Instance 3    │     (shared mount)
└─────────────────────────┘

Padrão de implementação: (Python)

import os
from pathlib import Path

MOUNT_PATH = "/mnt/models"

def analyze_data(item: str) -> dict:
    """Activity function: reads from shared mount."""
    model_path = Path(MOUNT_PATH) / "model.pkl"
    
    # Direct file I/O — no SDK call, no network overhead
    with open(model_path, "rb") as f:
        model = pickle.load(f)
    
    result = model.predict(item)
    return {"item": item, "score": result}

Pontos principais:

• Todas as instâncias da tua app de funções veem a mesma montagem.
• As leituras de ficheiros são compatíveis com POSIX. Usas APIs padrão do sistema de ficheiros.
• Não é necessário autenticar por leitura (a montagem é autenticada uma vez no arranque).
• As alterações escritas por uma instância são imediatamente visíveis para as outras.

Considerações de segurança:

• Chave da conta de armazenamento: Os montagens de armazenamento Ficheiros do Azure no Flex Consumption autenticam-se usando uma chave de acesso à conta de armazenamento configurada nas definições de montagem da aplicação funcional. Identidade gerida com Storage File Data SMB Share Contributor RBAC não é suportada para montagens SMB no Funções do Azure. Mantenha a sua chave de acesso segura e rode-a periodicamente.
• Opção só de leitura: Se a sua carga de trabalho não precisar de escrever, restringa a montagem a apenas leitura.
• Quotas: Defina quotas de partilha do Ficheiros do Azure para evitar custos excessivos caso as instâncias escrevam ficheiros grandes.

Caso de uso: Tens de correr um binário grande de terceiros (500+ MB) em cada instância, mas não queres incluí-lo com o teu código de função. Tais binários podem incluir ffmpeg, ImageMagick e outros.

O problema:

• Sem montagens:

  • Binário de pacote no artefacto de implementação: 500+ MB por instância, implementação lenta, desperdício de largura de banda.
  • Descarregar do Blob em cada invocação: chamada de rede em cada execução, mais devagar do que o acesso local.

• Utilização de ações montadas

  Carrega o binário uma vez para o Ficheiros do Azure. Todas as instâncias acedem-no a partir da montagem.

  ┌─────────────────────────────────────────────────┐
  │  Deployment package: 10 MB (just your code)     │
  ├─────────────────────────────────────────────────┤
  │  Mount: /mnt/binaries/ffmpeg                    │
  │  (500 MB binary, shared across all instances)   │
  ├─────────────────────────────────────────────────┤
  │  Execution: your code calls the mounted binary  │
  └─────────────────────────────────────────────────┘
  

Padrão de implementação: (Python)

import subprocess
from pathlib import Path

FFMPEG_PATH = "/mnt/binaries/ffmpeg"
TEMP_PATH = "/mnt/binaries/temp"

def process_video(video_file: str) -> str:
    """Activity function: calls ffmpeg from mount."""
    input_file = Path(TEMP_PATH) / video_file
    output_file = Path(TEMP_PATH) / f"{video_file}.mp4"
    
    result = subprocess.run(
        [FFMPEG_PATH, "-i", str(input_file), "-codec", "libx264", str(output_file)],
        capture_output=True,
        timeout=300
    )
    
    if result.returncode != 0:
        raise Exception(f"FFmpeg error: {result.stderr.decode()}")
    
    return str(output_file)

Pontos principais:

• O binário é montado, não embalado.
• O artefacto de implantação mantém-se pequeno.
• Os arranques a frio são mais rápidos (menos para abrir o fecho).
• Todas as instâncias podem chamar o mesmo binário em simultâneo.

Implicações no desempenho:

• Primeira execução: A inicialização da montagem SMB adiciona aproximadamente 200-500 milissegundos.
• Execuções subsequentes: Acesso direto a ficheiros com sobrecarga mínima.
• Cache binária: O sistema operativo armazena o binário em cache na memória, reduzindo as leituras repetidas do disco.

Caso de uso: Tem a Aplicação A (produtora de dados) e a Aplicação B (consumidora de dados) a correr na mesma região. A Aplicação A escreve os dados processados, e a Aplicação B lê-os.

O problema: Sem montagens, normalmente utilizarias o Armazenamento de Blobs do Azure (desacoplado, mas com sobrecarga de rede) ou o Armazenamento de Filas do Azure com passagem de mensagens (consistência eventual).

A solução baseada em montagens: Ambas as aplicações montam a mesma partilha de ficheiros Azure. A Aplicação A escreve, e a Aplicação B lê. Sem passagem de mensagens, sem consistência eventual.

┌──────────────────────┐
│  App A (Producer)    ├──write──┐
└──────────────────────┘         │
                           ┌─────┴─────────────────┐
                           │  /mnt/shared/         │
                           │  Azure Files share    │
                           │  (single source of    │
                           │   truth)              │
                           └─────┬─────────────────┘
┌──────────────────────┐         │
│  App B (Consumer)    ├──read───┘
└──────────────────────┘

Padrão de implementação:

App A (Produtor):

from pathlib import Path
import json

MOUNT_PATH = "/mnt/shared"

def write_results(data: dict) -> None:
    """Write results to shared mount."""
    output_file = Path(MOUNT_PATH) / "latest_results.json"
    with open(output_file, "w") as f:
        json.dump(data, f)

App B (Consumidor):

from pathlib import Path
import json

MOUNT_PATH = "/mnt/shared"

def read_results() -> dict:
    """Read results from shared mount."""
    results_file = Path(MOUNT_PATH) / "latest_results.json"
    if not results_file.exists():
        return {}
    with open(results_file, "r") as f:
        return json.load(f)

Pontos principais:

• Ambas as aplicações precisam de configuração de montagem referenciando a mesma conta de armazenamento e chave de acesso.
• Use bloqueios de ficheiros (por exemplo, fcntl no Linux ou APIs de bloqueio equivalentes na sua linguagem) para evitar condições de corrida de leitura/escrita.
• O Ficheiros do Azure suporta leituras simultâneas; As escritas devem ser sequenciais ou bloqueadas.