Serverless ֆունկցիաներ

01Գաղափարը՝ ֆունկցիաներ սերվերների փոխարեն

Դասական սերվերի վրա ձեր հավելվածն աշխատում է անընդհատ, և վճարում եք մեքենայի համար՝ անկախ նրանից, զբաղված է այն, թե ոչ։ Serverless-ը (ավելի ճշգրիտ՝ Functions as a Service, FaaS) շրջում է դա. դուք deploy եք անում ֆունկցիա, պլատֆորմը այն պահում է քնած վիճակում, և երբ իրադարձություն է գալիս, գործարկում է կատարման միջավայր, աշխատեցնում ձեր handler-ը և հետո սառեցնում կամ ոչնչացնում այն։ Պատկերացրեք տաքսի՝ սեփական մեքենայի փոխարեն. ոչ կայանատեղի, ոչ սպասարկում, վճարում եք ըստ ուղևորության, բայց ամեն ուղևորության համար մի փոքր սպասում եք, և հետևում եք տաքսի ընկերության կանոններին։ «Serverless»-ը չի նշանակում, որ սերվերներ չկան. նշանակում է, որ սերվերները provider-ի խնդիրն են։ Հիմնական պլատֆորմներն են AWS Lambda-ն, Google Cloud Run functions-ը, Azure Functions-ը և edge պլատֆորմներ, ինչպիսիք են Cloudflare Workers-ը, Vercel Functions-ը և Netlify Functions-ը։

02Ինչպես է կանչն աշխատում ներքուստ

Երբ իրադարձություն է գալիս, և ազատ տաք միջավայր չկա, պլատֆորմը կատարում է cold start. ստեղծում է micro-VM (Lambda-ն օգտագործում է Firecracker) կամ V8 isolate (Cloudflare Workers), ներբեռնում ձեր կոդը, գործարկում runtime-ը և handler-ից դուրս գտնվող ինիցիալիզացիայի կոդը։ Հետո կանչում է handler-ը իրադարձությամբ։ Պատասխանից հետո միջավայրը որոշ ժամանակ տաք է մնում և կարող է սպասարկել հաջորդ հարցումը՝ առանց init-ի ծախսի։ Դասական Lambda-ում յուրաքանչյուր միջավայր միաժամանակ մշակում է մեկ հարցում, ուստի 100 զուգահեռ հարցումը նշանակում է 100 միջավայր։ Մոդուլի մակարդակի կոդը կատարվում է մեկ անգամ յուրաքանչյուր միջավայրի համար, և հենց այնտեղ եք ստեղծում բազայի client-ները և բեռնում կոնֆիգուրացիան։ Հիշողությունում կամ /tmp-ում գտնվող ամեն ինչ կարող է պահպանվել կանչերի միջև, բայց դա երբեք երաշխավորված չէ։

• Cold start. init + առաջին կանչ, հաճախ 100 ms-ից մինչև 1 վայրկյանից ավելի՝ կախված runtime-ից և փաթեթի չափից։
• Warm start. միայն handler-ը, սովորաբար մի քանի միլիվայրկյան overhead։
• Concurrency. միևնույն պահին աշխատող միջավայրերի քանակը։

03AWS Lambda ֆունկցիայի գրում

Lambda ֆունկցիան handler է, որը ստանում է event և context։ HTTP-ի համար այն դնում եք Function URL-ի կամ API Gateway-ի հետևում, որը HTTP հարցումը վերածում է event օբյեկտի, իսկ ձեր վերադարձրած արժեքը՝ պատասխանի։ Ներկայիս managed runtime-երից են Node.js 24-ը (nodejs24.x) և Python 3.14-ը Amazon Linux 2023-ի վրա, x86_64 կամ arm64 (Graviton, սովորաբար ավելի էժան) ճարտարապետությամբ։ Հիշողությունը կարգավորվում է 128 MB-ից մինչև 10,240 MB, և CPU-ն մասշտաբավորվում է դրա հետ. առավելագույն timeout-ը 15 րոպե է. սինքրոն հարցման և պատասխանի payload-ները սահմանափակված են 6 MB-ով։ SDK client-ները ինիցիալիզացրեք handler-ից դուրս, որպեսզի տաք կանչերը նորից օգտագործեն դրանք։

1// index.mjs  (runtime: nodejs24.x, handler: index.handler)
2import { DynamoDBClient, GetItemCommand } from "@aws-sdk/client-dynamodb";
3 
4const db = new DynamoDBClient({}); // created once per environment
5 
6export const handler = async (event) => {
7  const id = event.pathParameters?.id;
8  if (!id) return { statusCode: 400, body: JSON.stringify({ error: "id required" }) };
9 
10  const res = await db.send(new GetItemCommand({
11    TableName: process.env.TABLE_NAME,
12    Key: { pk: { S: `product#${id}` } },
13  }));
14  if (!res.Item) return { statusCode: 404, body: "{}" };
15  return { statusCode: 200, headers: { "content-type": "application/json" },
16           body: JSON.stringify({ id, name: res.Item.name.S }) };
17};

04Event trigger-ներ. ավելին, քան HTTP

Serverless-ի իրական ուժը cloud-ի ամբողջ տարածքում իրադարձություններին արձագանքելն է։ AWS-ում ֆունկցիան կարող է գործարկվել, երբ օբյեկտ է հայտնվում S3-ում, հաղորդագրություն է գալիս SQS-ում, տող է փոխվում DynamoDB Streams-ում, EventBridge-ի կանոն կամ ժամանակացույց է աշխատում, կամ Kinesis stream-ը գրառումներ է ստանում։ Կանչերը լինում են սինքրոն (կանչողը սպասում է, ինչպես HTTP-ի դեպքում), ասինխրոն (պլատֆորմը հերթագրում է իրադարձությունը և սխալի դեպքում կրկնում՝ dead-letter նպատակակետով), կամ event source mapping-ների միջոցով, որոնք poll են անում հերթը կամ stream-ը և փոխանցում batch-եր։ Քանի որ ասինխրոն և հերթային trigger-ները կրկնում են, նույն իրադարձությունը կարող է մշակվել մեկից ավելի անգամ. handler-ները պետք է լինեն idempotent։ SQS batch-երի դեպքում հայտնեք մասնակի ձախողումները, որպեսզի կրկնվեն միայն ձախողված հաղորդագրությունները։

1// SQS trigger with partial batch failures
2// (enable ReportBatchItemFailures on the event source mapping)
3export const handler = async (event) => {
4  const batchItemFailures = [];
5  for (const record of event.Records) {
6    try {
7      const job = JSON.parse(record.body);
8      await processOnce(job.id, job); // idempotent: skips already-done ids
9    } catch (err) {
10      console.error({ messageId: record.messageId, err: String(err) });
11      batchItemFailures.push({ itemIdentifier: record.messageId });
12    }
13  }
14  return { batchItemFailures };
15};

05Edge ֆունկցիաներ. կոդը օգտատիրոջ մոտ

Edge ֆունկցիաներն աշխատում են աշխարհի բազմաթիվ վայրերում՝ օգտատիրոջ մոտ, մեկ տարածաշրջանի փոխարեն։ Cloudflare Workers-ը կոնտեյներների փոխարեն օգտագործում է V8 isolate-ներ. isolate-ը գործարկվում է միլիվայրկյաններում, ուստի cold start-երը գրեթե անտեսանելի են, բայց միջավայրը վեբ ստանդարտների runtime է (fetch, Request, Response, Web Crypto)՝ սահմանափակ Node.js API-ներով և ավելի խիստ CPU սահմաններով։ Դրանք իդեալական են redirect-ների, auth ստուգումների, A/B թեստավորման, header-ների վերագրման, գեոլոկացիայի և edge storage-ով (KV, D1, R2, Durable Objects) աշխատող թեթև API-ների համար։ Բազայի հետ ծանր աշխատանքի դեպքում հեռավոր բազան չեզոքացնում է օգուտը. Սիդնեյում գտնվող edge ֆունկցիան, որը կանչում է Ֆրանկֆուրտում գտնվող բազա, ավելի դանդաղ է, քան բազայի կողքին տեղադրված տարածաշրջանային ֆունկցիան։ Vercel-ի Functions-ն այժմ լռելյայն օգտագործում են Node.js runtime «Fluid compute»-ով, որը թույլ է տալիս մեկ instance-ին սպասարկել մի քանի զուգահեռ հարցում։

1// Cloudflare Worker: geo-based redirect at the edge
2export default {
3  async fetch(request: Request): Promise<Response> {
4    const url = new URL(request.url);
5    const country = (request as any).cf?.country ?? "US";
6    if (url.pathname === "/" && country === "DE") {
7      return Response.redirect(new URL("/de", url).toString(), 302);
8    }
9    return fetch(request); // pass through to origin
10  },
11};

06Deploy՝ infrastructure as code-ով

Console-ում ֆունկցիաներ կտտացնելով հավաքելը չի մասշտաբավորվում և չի դիմանում թիմի փոփոխությանը։ Ֆունկցիաները, trigger-ները, թույլտվությունները և միջավայրը սահմանեք կոդով՝ AWS SAM, Serverless Framework, AWS CDK, SST կամ Terraform։ Յուրաքանչյուր ֆունկցիա պետք է ունենա իր IAM role-ը՝ միայն անհրաժեշտ թույլտվություններով։ Գաղտնիքները գալիս են Secrets Manager-ից կամ Parameter Store-ից, ոչ թե ռեպոզիտորիայում պահված սովորական միջավայրի փոփոխականներից։ Կախվածությունները փաթեթավորեք զգուշորեն. փոքր bundle-ներն ավելի արագ են գործարկվում, ուստի bundle արեք esbuild-ով և բացառեք AWS SDK-ն, եթե runtime-ն արդեն տրամադրում է այն (Node.js runtime-երը ներառում են SDK v3)։

1# template.yaml (AWS SAM)
2AWSTemplateFormatVersion: "2010-09-09"
3Transform: AWS::Serverless-2016-10-31
4Resources:
5  GetProduct:
6    Type: AWS::Serverless::Function
7    Properties:
8      Runtime: nodejs24.x
9      Architectures: [arm64]
10      Handler: index.handler
11      MemorySize: 512
12      Timeout: 10
13      Environment: { Variables: { TABLE_NAME: !Ref Products } }
14      Policies: [ { DynamoDBReadPolicy: { TableName: !Ref Products } } ]
15      Events:
16        Api: { Type: HttpApi, Properties: { Path: /products/{id}, Method: get } }
17  Products:
18    Type: AWS::Serverless::SimpleTable

07Ծախսեր, սահմանափակումներ և երբ այն այլևս էժան չէ

Lambda-ն հաշվարկում է ըստ հարցման գումարած GB-վայրկյաններ (հիշողություն՝ բազմապատկած տևողությամբ, 1 ms քայլով), ամսական անվճար շեմով։ Պոռթկումային կամ ցածր տրաֆիկի դեպքում սա շատ ավելի էժան է, քան միշտ միացված սերվերը։ Կայուն, բարձր տրաֆիկի դեպքում անընդհատ աշխատող ֆունկցիան կարող է ավելի թանկ արժենալ, քան նույն աշխատանքն անող կոնտեյները կամ VPS-ը, իսկ API Gateway-ը, NAT gateway-երը և լոգավորումը հաճախ ավելի թանկ են, քան ֆունկցիան ինքը։ Հետևեք account-ի concurrency սահմաններին (լռելյայն 1,000 մեկ տարածաշրջանում, կարելի է բարձրացնել), reserved concurrency-ին՝ downstream բազաները պաշտպանելու համար, և timeout-ներին։ Օգտակար կանոն. serverless-ը իդեալական է իրադարձությունների «սոսինձ» կոդի, webhook-ների, պլանավորված job-երի և թռիչքաձև API-ների համար. երկարատև, կապերով ծանր կամ կայուն workload-ներին ավելի լավ են համապատասխանում կոնտեյներները։

08Կատարման միջավայրի կյանքի ցիկլի ներսում

Lambda-ի կատարման միջավայրն ունի երեք փուլ։ Init. պլատֆորմը գործարկում է extension-ները, runtime-ը և կատարում ձեր մոդուլի մակարդակի կոդը. այս փուլն ունի իր սեփական 10 վայրկյանի սահմանը։ Invoke. handler-ն աշխատում է յուրաքանչյուր իրադարձության համար՝ մեկ միջավայրում մեկը մյուսի հետևից։ Shutdown. երբ պլատֆորմը վերամշակում է միջավայրը, extension-ները ստանում են կարճ պատուհան՝ տվյալները flush անելու համար։ Կանչերի միջև միջավայրը սառեցված է, ուստի առանց await գործարկված ֆոնային աշխատանքը (await չարված promise, timer) կարող է կանգ առնել կիսատ և վերսկսվել հետագա կանչում, ինչը շփոթեցնող բագեր է առաջացնում։ Միշտ await արեք ամեն ինչ վերադարձնելուց առաջ, կամ օգտագործեք response streaming, երբ ուզում եք բայթերը շուտ ուղարկել։ SnapStart-ը, որը հասանելի է Java-ի, Python-ի և .NET-ի համար, snapshot է անում ինիցիալիզացված միջավայրը և վերսկսում դրանից, ուստի եզակի արժեքները, ինչպես random seed-երը և կապերը, պետք է թարմացվեն վերականգնումից հետո։

09Concurrency, մասշտաբավորում և throttling

Concurrency-ն մոտավորապես վայրկյանում հարցումների քանակն է՝ բազմապատկած միջին տևողությամբ. 200 req/s 250 ms-ով պահանջում է մոտ 50 զուգահեռ միջավայր։ Յուրաքանչյուր տարածաշրջան ունի account-ի մակարդակի concurrency քվոտա, որը կիսում են բոլոր ֆունկցիաները, ուստի մեկ անվերահսկելի ֆունկցիան կարող է throttle անել մնացածին։ Reserved concurrency-ն ֆունկցիայի համար սահմանում է և՛ երաշխավորված բաժին, և՛ առավելագույն սահման՝ պաշտպանելով փխրուն downstream համակարգերը։ Provisioned concurrency-ն որոշակի քանակով միջավայրեր պահում է ինիցիալիզացված՝ վերացնելով cold start-երը այդ թողունակության համար, ժամավճարով։ Throttle-ի դեպքում սինքրոն կանչողները ստանում են 429 սխալներ, իսկ ասինխրոն իրադարձությունները լռելյայն կրկնվում են մինչև վեց ժամ։ Հերթային trigger-ների համար event source mapping-ի maximum concurrency-ն սպառողներին սահմանափակելու ավելի անվտանգ եղանակ է, քան reserved concurrency-ն, որը կարող է հաղորդագրությունները հետ ուղարկել հերթ։

1# Cap a function at 50 concurrent executions
2aws lambda put-function-concurrency \
3  --function-name get-product --reserved-concurrent-executions 50
4 
5# Keep 10 environments warm on the "live" alias
6aws lambda put-provisioned-concurrency-config \
7  --function-name get-product --qualifier live \
8  --provisioned-concurrent-executions 10

10Արտադրողականության կարգավորում. հիշողություն, ճարտարապետություն և bundling

Lambda-ում CPU-ն տրամադրվում է հիշողությանը համամասնորեն. 1,769 MB-ի դեպքում ֆունկցիան ստանում է մեկ լիարժեք vCPU-ի համարժեքը։ Ուստի հիշողությունը բարձրացնելը CPU-ով սահմանափակված ֆունկցիաները հաճախ դարձնում է և՛ ավելի արագ, և՛ ավելի էժան, որովհետև տևողությունը նվազում է ավելի շատ, քան աճում է գինը։ Չափեք AWS Lambda Power Tuning-ով, որը գործարկում է ձեր ֆունկցիան հիշողության մի քանի չափերով և գծապատկերում ծախսը արագության համեմատ։ arm64-ը (Graviton) ունի ավելի ցածր գին մեկ GB-վայրկյանի համար և շատ workload-ների համար ավելի արագ է։ Node.js-ի համար bundle արեք esbuild-ով, AWS SDK-ն նշեք որպես external, ինիցիալիզացիայի համար օգտագործեք ES մոդուլներ top-level await-ով և cold ուղիներում խուսափեք ամբողջական SDK-ներ կամ ORM-ներ import անելուց։ Python-ի համար կրճատեք կախվածությունները և մոդուլի մակարդակում խուսափեք ծանր import-ներից, եթե դրանք պետք չեն յուրաքանչյուր կանչի համար։

11Անվտանգության մոդել և տարածված հարձակման մակերեսներ

Յուրաքանչյուր ֆունկցիայի IAM execution role-ը նրա ինքնությունն է. կոտրված ֆունկցիան կարող է անել ամեն ինչ, ինչ թույլ է տալիս այդ role-ը, ուստի սահմանափակեք այն կոնկրետ ռեսուրսներով և գործողություններով։ Իրադարձության տվյալները անվստահելի մուտք են, նույնիսկ երբ գալիս են AWS-ի ներսից. S3 օբյեկտի key-ը կամ SQS-ի body-ն կարող են injection payload կրել։ NONE auth տիպով Function URL-ները հանրայնորեն կանչելի են. օգտագործեք AWS_IAM auth, կամ ինքներդ վալիդացրեք ստորագրությունը կամ token-ը։ Գաղտնիքները պետք է բերվեն Secrets Manager-ից կամ Parameter Store-ից քեշավորմամբ (օգնում է AWS Parameters and Secrets Lambda Extension-ը), ոչ թե ներդրվեն console-ում տեսանելի միջավայրի փոփոխականներում։ Ամրագրեք կախվածությունները և սկանավորեք դրանք, որովհետև supply-chain ռիսկը կենտրոնացած է փոքր bundle-ներում, որոնք ուղիղ գնում են production։