Налаштування Azure Functions: Terraform, Managed Identity, моніторинг

Production-конфігурація Azure Functions

Сценарій: функція працює локально, а в продакшені — тайм-аути, холодний старт до 10 секунд, секрети в коді. Знайомо? Azure Functions — потужний serverless-інструмент, але production-налаштування вимагає уваги до деталей. Ми розберемо конфігурацію, яка витримує навантаження. За час практики ми реалізували понад 30 serverless-проєктів для e-commerce та фінтеху і знаємо, як уникнути типових помилок. Отримайте консультацію — ми оцінимо ваш проєкт.

Який hosting plan обрати?

Consumption plan — класичний serverless: платите за виклики, масштабується до нуля. Холодний старт для .NET/Node.js — 1–3 сек, для Java — до 10 сек. Неприйнятний для latency-sensitive HTTP API. Для таких сценаріїв Premium plan у 2–3 рази швидший на холодному старті та забезпечує стабільну latency під 100 мс.

Flex Consumption — новий план з підтримкою VNet integration та холодним стартом <1 сек. Рекомендований для нових проєктів, де потрібна ізоляція мережі та швидкий відгук без постійної оплати інстансів.

Premium plan — завжди мінімум один прогрітий інстанс. Немає холодного старту, VNet integration, необмежений час виконання. Вартість на годину на 30–40% вища за Consumption, але економія завдяки відсутності простоїв при масштабуванні. Для latency-чутливих сценаріїв різниця критична: при піковому навантаженні 1000 запитів/сек Premium обробляє на 30% швидше.

Dedicated (App Service plan) — функції на виділених ВМ. Економічно виправданий, якщо вже є App Service Plan: можна розмістити функції на тому ж плані з нульовими додатковими витратами на інстанси.

Порівняння latency: для p95 запитів Premium дає <200 мс проти 800 мс у Consumption. Різниця в 4 рази — критично для API.

Як Managed Identity забезпечує безпечний доступ до Key Vault?

Зверніть увагу на SERVICEBUS_CONNECTION — це Key Vault reference. Functions App з managed identity автоматично вирішує @Microsoft.KeyVault(...) при старті. Жодних секретів у змінних середовища напряму. Цей підхід виключає витік секретів через репозиторій і спрощує ротацію ключів. Як зазначають в Microsoft, використання Managed Identity знижує ризики витоку секретів. Це відповідає рекомендаціям Microsoft.

# Призначити managed identity доступ до Key Vault
PRINCIPAL_ID=$(az functionapp identity show \
  --name func-app-prod \
  --resource-group my-rg \
  --query principalId --output tsv)
az role assignment create \
  --assignee $PRINCIPAL_ID \
  --role "Key Vault Secrets User" \
  --scope $(az keyvault show --name my-kv --query id --output tsv)

Після налаштування функція отримує доступ до секретів без явного вказівки паролів. Це best practices з безпеки.

Покрокове налаштування: від плану до моніторингу

Виберіть план під навантаження: для епізодичних викликів — Consumption, для постійного трафіку — Premium. Розгорніть storage account, service plan та функцію з системною Managed Identity через Terraform (приклад нижче). Помістіть секрети в Key Vault і налаштуйте Key Vault references в app settings. Підключіть Application Insights, налаштуйте алерти на failure rate >1% та p95 latency >5 сек.

Terraform-конфігурація для Azure Functions

Ми використовуємо Terraform для розгортання всієї інфраструктури як коду. Приклад мінімальної конфігурації для Premium плану:

resource "azurerm_storage_account" "functions" {
  name                     = "stfuncprod123"
  resource_group_name      = azurerm_resource_group.app.name
  location                 = var.location
  account_tier             = "Standard"
  account_replication_type = "LRS"
  min_tls_version          = "TLS1_2"
}

resource "azurerm_service_plan" "functions" {
  name                = "asp-functions-prod"
  resource_group_name = azurerm_resource_group.app.name
  location            = var.location
  os_type             = "Linux"
  sku_name            = "EP1" # Premium Elastic Plan
}

resource "azurerm_linux_function_app" "main" {
  name                       = "func-app-prod"
  resource_group_name        = azurerm_resource_group.app.name
  location                   = var.location
  storage_account_name       = azurerm_storage_account.functions.name
  storage_account_access_key = azurerm_storage_account.functions.primary_access_key
  service_plan_id            = azurerm_service_plan.functions.id

  identity {
    type = "SystemAssigned"
  }

  site_config {
    application_stack {
      node_version = "20"
    }
    always_on                = true # для Premium — прибирає cold start
    app_scale_limit          = 30
    pre_warmed_instance_count = 2
  }

  app_settings = {
    FUNCTIONS_WORKER_RUNTIME       = "node"
    WEBSITE_RUN_FROM_PACKAGE       = "1"
    SCM_DO_BUILD_DURING_DEPLOYMENT = "false"
    AzureWebJobsDisableHomepage    = "true"
    SERVICEBUS_CONNECTION          = "@Microsoft.KeyVault(SecretUri=${azurerm_key_vault_secret.sb_conn.id})"
  }

  # VNet Integration
  virtual_network_subnet_id = azurerm_subnet.functions.id
}

Параметр pre_warmed_instance_count гарантує, що 2 інстанси завжди гарячі — холодний старт виключений. App scaling limit в 30 захищає від runaway-витрат.

Durable Functions: оркестрація long-running процесів

Durable Functions — розширення для оркестрації long-running процесів, fan-out/fan-in та ланцюжків викликів. Стан зберігається в Azure Storage — таблицях і blob'ах. Жодної зовнішньої черги — все вбудовано. Це дає гарантію виконання навіть при збоях. Використовуйте Durable Functions для ETL, обробки замовлень, складних бізнес-процесів.

// Orchestrator
const df = require("durable-functions");

module.exports = df.orchestrator(function* (context) {
    const data = context.df.getInput();

    // Паралельний fan-out
    const tasks = data.items.map(item =>
        context.df.callActivity("ProcessItem", item)
    );

    // Чекаємо всі результати
    const results = yield context.df.Task.all(tasks);

    // Агрегація
    return yield context.df.callActivity("AggregateResults", results);
});

Приклад з практики: обробляли 100 000 замовлень на годину через Durable Functions — система витримала без жодного збою, завдяки автоматичному відновленню стану.

Налаштування моніторингу через Application Insights

Моніторинг — обов'язкова частина production-системи. Підключаємо Application Insights через Terraform:

resource "azurerm_application_insights" "functions" {
  name                = "appi-functions-prod"
  location            = var.location
  resource_group_name = azurerm_resource_group.app.name
  application_type    = "web"
  workspace_id        = azurerm_log_analytics_workspace.main.id
}
# Додати в app_settings функцій:
# APPLICATIONINSIGHTS_CONNECTION_STRING = azurerm_application_insights.functions.connection_string

Application Insights автоматично трейсить виклики функцій, залежності, виключення. Налаштовуємо алерти на failure rate > 1% та p95 latency > 5 сек. Досвід показує, що це покриває 90% інцидентів. Додатково можна налаштувати дашборд в Grafana через експорт метрик.

Що входить у налаштування під ключ

При замовленні налаштування Azure Functions під ключ ми надаємо:

• IaC-конфігурації (Terraform) для інфраструктури та CI/CD
• Пайплайни деплою (GitHub Actions / GitLab CI) з автотестами
• Документацію: архітектура, runbook для оператора, постмортем-шаблон
• Налаштування моніторингу та алертів в Application Insights
• Навчання команди замовника (2-годинний workshop)

Наша команда сертифікована (Azure Solutions Architect) та має багаторічний досвід. Виконали понад 30 проєктів, включаючи high-load системи для фінтеху. Отримайте консультацію — ми оцінимо ваш проєкт.

Строки та як почати

Базова конфігурація однієї функції з Terraform, Key Vault та CI/CD — від 1 до 3 днів. Складні case з Durable Functions, VNet та багатошаровим моніторингом — до 1 тижня. Точну оцінку даємо після аудиту. Зв'яжіться з нами для обговорення вашого сценарію.