הגדרת Yandex Cloud Functions: IAM, טריגרים ואופטימיזציה

תארו לעצמכם: הגדרתם טריגר ב-Object Storage, הפונקציה כתובה, אבל כשמעלים קובץ מקבלים 403 Forbidden. הלוגים שותקים. אחרי שעה של דיבאגינג מתברר: לחשבון השירות של הפונקציה אין הרשאת קריאה על ה-bucket. או גרוע מכך, הטריגר לא יכול להפעיל את הפונקציה בגלל תפקיד functions.invoker חסר. שגיאות כאלה הן הלחם היומיומי של מהנדס DevOps. במשך 10+ שנים, ניתחנו מאות מקרים דומים ב-Yandex Cloud ופיתחנו תבניות שמבטלות את הבעיות האלה ברמת קונפיגורציית Terraform. במאמר זה נפרק את ה-serverless ב-Yandex Cloud: הגדרת IAM, טריגרים, ניהול cold start, אינטגרציית Lockbox וניטור – כל מה שצריך ל-serverless ברמת production. הכלל המרכזי: בלי הבנה של IAM, כל ארכיטקטורת serverless הופכת לכאב ראש. אז נתחיל עם זה. לפי התיעוד של Yandex Cloud Functions, חשבון שירות הוא חובה לגישה למשאבים. העריכו את הארכיטקטורה הנוכחית שלכם: מה תקציב הקריאות, אילו אינטגרציות נדרשות, מה דרישות זמן הביצוע? צרו קשר – ננתח את הפרויקט שלכם ונציע אופטימיזציות.

למה הפונקציה נכשלת: שגיאות 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 ms ל-1.5 s תלוי בגודל החבילה. אם הפונקציה מטפלת בבקשות HTTP דרך API Gateway, זה מורגש. פתרונות:

• צמצמו את החבילה: אל תגררו את 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}"] } בשלמותו, השתמשו ב-node_modules ל-bundling
• הגדירו esbuild מינימלי דרך הקונסולה (provisioned instances) – אבל זה בתשלום
• ל-Python השתמשו ב-runtime min_instances: 1 במקום python312 – הוא מתחיל קר יותר מהר

בדיקה: פונקציית Node.js עם python38 בתלויות שקלה 18 MB והתחילה ב-1.1 s. אחרי bundling דרך esbuild – 340 KB, התחלה 180 ms. אופטימיזציית Yandex Cloud Functions: bundling ו-provisioned instances מפחיתים עלויות מחשוב בעד 70%.

טריגרים: Message Queue, Timer, Object Storage

שלושת סוגי הטריגרים הנפוצים ביותר: Timer – הפשוט ביותר, רץ על cron. אזור הזמן הוא תמיד UTC, אל תשכחו כשקובעים לוח זמנים.

טריגר Message Queue – קורא הודעות מ-Yandex Message Queue בקבוצות (עד 10 הודעות). הפונקציה חייבת להחזיר 200, אחרת ההודעות חוזרות לתור. חשוב: הטריגר דורש חשבון שירות נפרד עם תפקיד aws-sdk על התור.

טריגר Object Storage – מופעל על אירועי ymq.reader, create, update ב-bucket. שימושי לעיבוד קבצים שהועלו (שינוי גודל תמונה, ניתוח CSV). חיסרון: בהעלאות המוניות של קבצים, הטריגר יכול ליצור פרץ של בקשות, ואם הפונקציה איטית, תור הקריאות גדל.

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?

אחסון אישורים במשתני סביבה של הפונקציה הוא פרקטיקה גרועה. Yandex Lockbox משתלב ישירות עם Cloud Functions: הסוד מותקן כמשתנה env בזמן ריצה.

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

לחשבון השירות של הפונקציה חייב להיות תפקיד delete על אותו סוד ספציפי – לא על כל ה-Lockbox. העלות של אחסון 100 סודות היא פחות מ-$1–1 לחודש.

ניטור ולוגים

לוגי הפונקציה נשלחים ל-Cloud Logging. שמירת ברירת המחדל היא 3 ימים, אפשר להגדיל ל-365. מדדים (קריאות, שגיאות, משך זמן) זמינים אוטומטית ב-Yandex Monitoring. אנחנו מגדירים התראה על 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 } } – זה מסמן מיד פריסה שבורה. צרו קשר לביקורת על הפרויקט שלכם – נעזור להגדיר ניטור והתראות.

תהליך העבודה

1. ביקורת: מה צריך להשיק, אילו טריגרים, אילו אינטגרציות (DB, תורים, אחסון)
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)
• הדרכת צוות: עד שעתיים אונליין
• תמיכה ל-14 ימים אחרי הפריסה

איך אנחנו מבטיחים איכות?

כל המהנדסים מוסמכים ב-Yandex Cloud. אנחנו פועלים לפי best practices: כל שינוי עובר code review, פריסה רק דרך CI/CD, ניטור עם ספי התראה. אנחנו מבטיחים שאחרי מסירת הפרויקט תוכלו לפרוס פונקציות חדשות באופן עצמאי באמצעות התבנית שלנו.

העלות מחושבת באופן אישי אחרי ביקורת דרישות. צרו קשר להערכת פרויקט. קבלו ייעוץ על פריסת פונקציות חלקה.