Налаштування Yandex Cloud Functions: IAM, тригери та оптимізація

Уявіть: ви налаштували тригер на Object Storage, функція написана, але при завантаженні файлу отримуєте 403 Forbidden. Логи мовчать. Через годину дебагу з'ясовується: сервісний акаунт функції не має прав на читання бакета. Або, що гірше, тригер не може викликати функцію через відсутність ролі functions.invoker. Такі помилки — хліб DevOps-інженера. Ми за 10+ років розібрали сотні подібних кейсів на Yandex Cloud і виробили шаблони, які виключають ці проблеми на рівні Terraform-конфігурації. У цій статті розбираємо serverless на Yandex Cloud: налаштування IAM, тригерів, управління холодним стартом, інтеграцію з Lockbox та моніторинг — усе, що потрібно для продакшн-grade serverless. Головне правило: без розуміння IAM будь-яка serverless-архітектура перетворюється на головний біль. Тому почнемо з нього. Оцініть вашу поточну архітектуру: який бюджет на виклики, які інтеграції потрібні, які вимоги до часу виконання. Зв'яжіться з нами — ми проаналізуємо ваш проєкт і запропонуємо оптимізації.

Чому функція не працює: типові помилки IAM?

Кожна функція в Yandex Cloud Functions прив'язана до сервісного акаунту. Це не опціональне налаштування — без неї функція не зможе звернутися до Object Storage, Managed PostgreSQL, секретів у Lockbox або відправити повідомлення в Message Queue. Найчастіша помилка: функція створена, тригер налаштований, але в логах 403 Forbidden — тому що сервісний акаунт функції забули наділити потрібними ролями.

Мінімальний Terraform для функції з доступом до Object Storage:

resource "yandex_function" "handler" {
  name = "my-handler"
  runtime = "nodejs18"
  entrypoint = "index.handler"
  memory = 256
  execution_timeout = "30"
  service_account_id = yandex_iam_service_account.fn_sa.id
  content {
    zip_filename = "function.zip"
  }
  environment = {
    BUCKET_NAME = yandex_storage_bucket.data.bucket
    LOG_LEVEL = "info"
  }
}

resource "yandex_function_iam_binding" "invoker" {
  function_id = yandex_function.handler.id
  role = "functions.functionInvoker"
  members = ["serviceAccount:${yandex_iam_service_account.trigger_sa.id}"]
}

Як зменшити cold start?

Cold start у Node.js-функцій на YC — від 300 мс до 1.5 с залежно від розміру пакета. Якщо функція обробляє HTTP-запити через API Gateway, це помітно. Рішення:

• Мінімізувати пакет: не тягти node_modules цілком, використовувати esbuild для бандлінгу
• Поставити мінімальний min_instances: 1 через консоль (provisioned instances) — але це вже платно
• Для Python використовувати python312 runtime замість python38 — він холодає швидше

Тест: функція на Node.js з aws-sdk у залежностях важила 18 МБ і стартувала за 1.1 с. Після бандлінгу через esbuild — 340 КБ, старт 180 мс. Оптимізація Yandex Cloud Functions: бандлінг і provisioned instances знижують витрати на обчислення до 70%.

Тригери: Message Queue, Timer, Object Storage

Три найуживаніші типи тригерів:

Timer — найпростіший, працює за cron. Часовий пояс завжди UTC, не забувати при налаштуванні розкладу.

Message Queue trigger — читає повідомлення з Yandex Message Queue батчами (до 10 повідомлень). Функція повинна повернути 200, інакше повідомлення повернуться в чергу. Важливо: тригер потребує окремого сервісного акаунту з роллю ymq.reader на чергу.

Object Storage trigger — спрацьовує на події create, update, delete у бакеті. Корисний для обробки завантажених файлів (ресайз зображень, парсинг CSV). Мінус: при масовому заливанні файлів тригер може створити burst запитів, і якщо функція повільна — черга викликів зростає.

resource "yandex_function_trigger" "s3_trigger" {
  name = "process-uploads"
  object_storage {
    bucket_id = yandex_storage_bucket.uploads.id
    create = true
    suffix = ".csv"
  }
  function {
    id = yandex_function.processor.id
    service_account_id = yandex_iam_service_account.trigger_sa.id
  }
}

Замовте аудит ваших тригерів — оптимізуємо їх під навантаження.

Як зберігати секрети в Yandex Cloud Functions?

Зберігати credentials у змінних оточення функції — погана практика. Yandex Lockbox інтегрується з Cloud Functions напряму: секрет монтується як env-змінна в runtime.

secrets {
  id = yandex_lockbox_secret.db_password.id
  version_id = yandex_lockbox_secret_version.v1.id
  key = "DB_PASSWORD"
  environment_variable = "DB_PASSWORD"
}

Сервісний акаунт функції повинен мати роль lockbox.payloadViewer на конкретний секрет — не на весь Lockbox. Вартість зберігання 100 секретів менше 50 ₴ на місяць.

Моніторинг та логи

Логи функцій йдуть у Cloud Logging. За замовчуванням retention — 3 дні, можна збільшити до 365. Метрики (invocations, errors, duration) доступні в Yandex Monitoring автоматично. Налаштовуємо алерт на functions.errors_per_second > 5 — це одразу сигналізує про битий деплой. Зв'яжіться з нами для аудиту вашого проєкту — ми допоможемо налаштувати моніторинг та алерти.

Процес роботи

1. Аудит: що потрібно запустити, які тригери, які інтеграції (БД, черги, сховище)
2. Проєктування IAM: сервісні акаунти, ролі, Lockbox для секретів
3. Написання Terraform-конфігурації під функції та тригери
4. Налаштування CI/CD для Yandex Cloud Functions (GitLab CI / GitHub Actions)
5. Налаштування моніторингу та алертів
6. Документація: схема залежностей, опис змінних оточення, процедура деплою

Що входить у роботу

• Повна документація схеми IAM та залежностей
• Terraform-конфігурації для функцій, тригерів, Lockbox
• Налаштування CI/CD пайплайну (GitLab CI / GitHub Actions)
• Навчання команди: до 2 годин онлайн
• Підтримка протягом 14 днів після деплою

Як ми гарантуємо якість?

Всі інженери сертифіковані Yandex Cloud. Ми дотримуємося best practices: кожна зміна проходить код-рев'ю, деплой тільки через CI/CD, моніторинг з порогами алертів. Гарантуємо, що після передачі проєкту ви зможете самостійно розгортати нові функції за нашим шаблоном.

Вартість розраховується індивідуально після аудиту вимог. Зв'яжіться з нами для оцінки вашого проєкту. Отримайте консультацію з безшовного запуску функцій.