Выбор стратегии доступа к файлам для Функций 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 (...)"
)

Вариант использования: У вас есть 1000 задач анализа, которые должны читать из одного и того же набора эталонных данных (например, моделей машинного обучения, таблиц подстановки или данных корпусов).

Проблема: Без креплений у вас есть два неоптимальных варианта:

• Упакуйте справочные файлы вместе с вашей функцией: такой подход приводит к большому артефакту развертывания, медленным холодным запускам и избыточности хранения.
• Скачивание из хранилища BLOB-объектов каждый раз: этот подход вызывает задержку в сети при каждом вызове функции и тратит пропускную способность.

Решение на основе монтирования: Все экземпляры считывают данные непосредственно из монтированной общей папки. После инициализации подключения расходы на сеть для каждого запроса и избыточного хранилища отсутствуют.

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

Шаблон реализации: (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}

Основные моменты:

• Все экземпляры вашего функционального приложения видят одно и то же монтирование.
• Операции чтения файлов соответствуют POSIX. Вы используете стандартные API файловой системы.
• Нет необходимости выполнять проверку подлинности при каждом чтении (подключение аутентифицируется один раз при запуске).
• Изменения, записанные одним экземпляром, сразу же видны другим пользователям.

Рекомендации по безопасности:

• Ключ учетной записи хранения: подключение хранилища Azure Files на Flex Consumption выполняется с использованием ключа доступа к учетной записи хранения, который настроен в параметрах монтирования приложения-функции. Управляемое удостоверение с Storage File Data SMB Share Contributor RBAC не поддерживается для подключений SMB в Функциях Azure. Сохраняйте безопасность ключа доступа и периодически поворачивайте его.
• Параметр только для чтения: если рабочая нагрузка не требует записи, ограничьте подключение только для чтения.
• Квоты: Установите квоты на общий ресурс файлов Azure, чтобы предотвратить неконтролируемое увеличение затрат, если экземпляры записывают большие файлы.

Вариант использования: Вам нужно запустить большой двоичный файл сторонних производителей (500 МБ) на каждом экземпляре, но вы не хотите упаковать его с помощью кода функции. Такие двоичные файлы могут включать ffmpeg, ImageMagick и другие.

Проблема:

• Без креплений

  • Двоичный файл пакета в артефакте развертывания: свыше 500 МБ на экземпляр, медленное развертывание, неэффективное использование пропускной способности.
  • Загрузка из BLOB при каждом вызове: сетевой вызов на каждое выполнение, что медленнее локального доступа.

• Использование объединённых общих папок

  Отправьте двоичные данные один раз в Azure Files. Все экземпляры получают доступ к нему из точки монтирования.

  ┌─────────────────────────────────────────────────┐
  │  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  │
  └─────────────────────────────────────────────────┘
  

Шаблон реализации: (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)

Основные моменты:

• Двоичный файл подключен, а не упаковаен.
• Артефакт развертывания остается небольшим.
• Холодные запуски происходят быстрее (меньше данных для распаковки).
• Все экземпляры могут одновременно вызывать один двоичный файл.

Последствия для производительности:

• Первое выполнение: инициализация монтирования SMB добавляет приблизительно 200-500 миллисекунд.
• Последующие выполнения: прямой доступ к файлам с минимальными затратами.
• Двоичное кэширование: ОС кэширует двоичный файл в памяти, уменьшая повторяющиеся операции чтения дисков.

Вариант использования: У вас есть приложение A (производитель данных) и Приложение B (потребитель данных) в одном регионе. Приложение A записывает обработанные данные, и приложение B считывает его.

Проблема: Без точек монтирования вы обычно используете хранилище BLOB Azure (разъединенное, но с сетевыми издержками), хранилище очередей Azure с передачей сообщений (итоговая согласованность) или Azure Cosmos DB (более сложное, чем требуется для простого общего доступа к файлам).

Решение на основе монтирования: Оба приложения монтируют одну и ту же общую папку Службы файлов Azure. Приложение A записывает и считывает приложение B. Нет передачи сообщений, нет конечной согласованности.

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

Шаблон реализации:

Программа A (производитель):

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)

Приложение B (потребитель):

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)

Основные моменты:

• Оба приложения должны иметь конфигурацию монтирования, ссылающуюся на одну и ту же учетную запись хранения и ключ доступа.
• Используйте блокировки файлов (например, fcntl в Linux или эквивалентных API блокировки на языке), чтобы предотвратить условия гонки чтения и записи.
• Файлы Azure поддерживают одновременные операции чтения; записи должны быть последовательными или заблокированными.