ტექნოლოგიები და ინფრასტრუქტურა - Serverless მიდგომა და ფუნქციები

Serverless მიდგომა და ფუნქციები

1) რა არის serverless და როდის არის ეს საჭირო

Serverless არის მოდელი, სადაც ღრუბელი იღებს სერვერების კონტროლს, სკალირებას და პატჩებს, ხოლო გუნდი წერს ღონისძიების დამამზადებლებს და იყენებს FaaS (Functions-as-Service) და BaaS (მართავს სერვისებს: რიგები, BD, საცავი). თქვენ იმარჯვებთ მიწოდების სიჩქარეზე, იხდით რეალურ შესრულებას და მარტივად ააფართოებთ „ვარდისფერ“ დატვირთვებს.

• ვებჰუკი PSP/KYC (ბევრი მოკლე მოთხოვნა, არაპროგნოზირებადი მწვერვალები).
• ანტიფროდი/მორიელი (ღონისძიების ფუნქციები, enrichment, feature store).
• ანგარიში/CDC/DWH (პაკეტის და ნაკადის დამუშავება).
• მარკეტინგი/CRM (გამომწვევი მოვლენები, იარაღი, კუპონები, სეგმენტი).
• მსუბუქი backend-API და სამსახურებრივი დავალებები (throttling, cron ფუნქციები).

• საჭიროა მუდმივი დაბალი P99 ლატენტობა (ქვე-10ms) უყოყმანოდ.
• გრძელი ნაერთები/ოქმები (მაღალი სიხშირის რეალური დრო მარიონეტული გარეშე).
• დიდი, stateful გამოთვლები გრძელი CPU/GPU და tight coupling.

2) არქიტექტურული აგურები

2. 1 FaaS

ღონისძიებების დამუშავება: HTTP/API კარიბჭე, რიგები, ნაკადები, ტაიმერები, ობიექტის საცავი, BD ტრიგერები.
თხელი დაწყება/შეფუთვა: ფენების/გამოსახულების ფუნქციები, დათბობა.

2. 2 BaaS და ინტეგრაცია

ხაზები/ნაკადი (at-least-once), Pub/Sub დომენის მოვლენებისთვის.
საცავი: ობიექტი (ნედლეული/არტეფაქტები), KV/ქეში, დოკუმენტები/რელე.
ორკესტრი: state machines/step functions, საგნები და კომპენსაცია.
API კარიბჭე: ავთენტიფიკაცია (OAuth/OIDC/HMAC), ლიმიტები, ტრანსფორმაციები.

2. 3 ქსელის კონტური

საჯარო ფრონტი (edge/API კარიბჭე) + პირადი ფუნქციები VPC- ში მონაცემთა ბაზაში/საიდუმლოებებზე წვდომისთვის/PSP.
Egress კონტროლი: allow სია PSP/KYC, ფიქსირდება NAT-IP.

3) პროდუქტიულობა: ცივი დასაწყისი, კონკურენცია, ხანგრძლივობა

ცივი დასაწყისი: ფუნქციის კონტეინერის პირველი გაშვება სისუსტის შემდეგ.
Mitigirute: მინიმუმამდე დაიყვანეთ დამოკიდებულება, გამოიყენეთ „დათბობა“, შეინარჩუნეთ ფუნქციები იმავე ზონაში წყაროებით, გამოიყენეთ გრძელი ტაიმაუტები ფრთხილად.
კონკურენტუნარიანობა: დაუსვით 'max _ concurrency' და ლიმიტები წყაროზე (რიგები/კარიბჭე) ისე, რომ არ „დაასხით“ PSP/BD.
შესრულების ხანგრძლივობა: გრძელი დავალებებისთვის - დაყოფა ნაბიჯებზე + ორკესტრაცია (ეტაპი), მძიმე გამოთვლებისთვის - batch/containers.

4) საიმედოობა: idempotence, retrai, DLQ

Idempotence: 'Idempotence-Key '/deduplication მიღებაზე (გასაღები + TTL საცავი).
Retrai: ექსპონენციალური backoff + jitter, მცდელობების შეზღუდვები; გამოყავით ბიზნეს შეცდომები (4xx) დროებითი (5xx/timeout).
DLQ (dead-letter queue): შეტყობინებებისთვის, რომლებმაც არ გაიარეს N მცდელობები; სავალდებულოა replay კონსოლი და კვალი.
Exactly-once (პრაქტიკულად): outbox/inbox შაბლონები, გარიგების ღონისძიებების ჟურნალი.

5) მდგომარეობა და ორკესტრი

ფუნქციების მდგომარეობის გარეშე, სახელმწიფო - გარე საცავებში.
სახელმწიფო აპარატები: გადახდის/გამოსვლის ნაბიჯები, KYC-workflow, ანტიფროდიული შემოწმება; შეცდომების/კომპენსაციის მკაფიო მოდელი.
საგები: „დაცვა, დადასტურება და ანაზღაურება“ უკან დახევის დროს.

6) უსაფრთხოება და შესაბამისობა

IAM მინიმალური პრივილეგიების პრინციპის შესაბამისად: პერ-ფუნქციის როლები, რიგის/ბაკეტების/ცხრილების შეკრება.
საიდუმლოებები: საიდუმლოების მენეჯერი/KMS, როტაცია, HSM დონე გასაღებისთვის.
mTLS/HMAC ვებჰუკებისთვის, სხეულის ხელმოწერა, დროის ფანჯარა ± 5.
ჩაშენებული WAF/bot დაცვა API კარიბჭეზე, rate-limits/ítas.
სეგმენტი: prod/stage, სერვისული ანგარიშები, პირადი sabsets.
PII/PCI: PAN ტოქსიკაცია, ლოგოების შენიღბვა, „მონაცემების შემცირება“.
აუდიტი: უცვლელი ლოგოები (WORM), ზარის კვალი, რეგულირების შენახვა.

7) დაკვირვება და ხარისხის კონტროლი

მეტრიკა: RPS, P50/P95/P99, კოდების შეცდომები, ხანგრძლივობა, ცივი სტარტები, ჭიდაობის კონვეიერი, DLQ size.
Tracing (OTel): 'trace _ id' კორელაცია კარიბჭის საშუალებით - BD/PSP ხაზის ფუნქციას; სავალდებულო ეტიკეტები 'ap_ version', 'region', 'partner'.
ლოგოები: სტრუქტურირებული, PII შენიღბვით.
სიმპტომების ალერტები: burn-rate SLO, Retrais ზრდა, P99 კუდი.
სინთეზური: შემოწმებები სამიზნე ქვეყნებიდან (TR/BR/EU), ვებჰუკების იმიტაცია.

8) FinOps და ღირებულება

გადაიხადეთ „გამოწვევები და მილიწამები“. თვალყურის დევნება: გაშვების სიხშირე, ხანგრძლივობა, მეხსიერება, ტრაფიკი.
დაპროგრამეთ ცხელი მარშრუტები: გააკეთეთ მძიმე დამოკიდებულება ფენაში/გამოსახულებაში, დააკონკრეტეთ ნაერთები.
შეინარჩუნეთ გულშემატკივართა (მასობრივი პარალელური გამოწვევები) შეზღუდვები და პეპელა.
აღიარეთ „გაჟონვა“: გაუთავებელი რელეები, შეტყობინებები DLQ- ში დამუშავების გარეშე.
დაგეგმეთ პიკის ფანჯრები (ტურნირები/ტირაჟი) - წინასწარი დათბობა და კვოტები.

9) CI/CD და ვერსიების კონტროლი

IaC: Terraform/CloudFormation/SAM/CDK - ფუნქციების, რიგების, უფლებების, კარიბჭეების შაბლონები.
შეფუთვა: დამოკიდებულების პირადი ფაილები, მინიმალური სურათი/ფენა.
ტესტირება: კონტრაქტის ტესტები (OpenAPI/gRPC), ინტეგრაცია ადგილობრივ რანტიმთან, იდემპოტენტურობის ტესტები.
eploy: canary/blue-green, feature flags, სწრაფი rollback.
API- ს ვერსია: '/vN/' ან მედია; Deprecation/Sunset და მოვლენების სქემების თავსებადობა.

10) ნიმუშები iGaming/fintech

გადახდების/დასკვნების ვებსაიტები: ხელმოწერის მიღება - შესაბამისობა - იდემპოტენტობა და მოვლენის გამოქვეყნება "payout. განახლება 'საფულე/ანგარიშების განახლებების ორკესტრი.
ანტიფროდიული სკორინგი: ფუნქცია-enricher (IP/devais/geo/ისტორია), ასინქრონული გამოსავალი, ტაიმაუტები და fallback სტრატეგიები.
KYC/AML pipline: პარალელური შემოწმებები (დოკუმენტები, სანქციები, PEP), შედეგების აგრეგაცია, საგნები განმეორებითი მოთხოვნებისთვის.
ტურნირები/რეიტინგები: რაუნდის მოვლენები - ნაკადის აგრეგაცია, ლიდერების ცხრილების განახლება, TTL ქეში კითხვისთვის.
რეგულატორებისთვის მოხსენება: CDC არის მონაცემთა სიახლეების ფანჯრების DWH, SLA ტრანსფორმაციის ფუნქციები.
მარკეტინგი/CRM: ქცევის გამომწვევები, კუპონები/ქვემეხები, დეპოზიტები და მომხმარებლის შეზღუდვები.

11) ფრაგმენტების მაგალითები

11. 1 ვებჰუკის იდემპოტენტური ტექნიკა (ფსევდოკოდი)

python def handler(event):
assert verify_hmac(event. headers, event. body, secret)
key = f"idemp:{event. headers['Idempotency-Key']}"
if kv. exists(key):
return kv. get (key) # repeat - give the same result result = process (event. body) # public event, state record kv. set(key, result, ttl=86400)
return result

11. 2 თანხების გატანის ორკესტრი (სახელმწიფო მანქანა, იდეა)

1. 'validate _ request' (2) 'lock _ balance', 3) 'call _ psp' (თხრილებით)

2. 'await _ webhook' (taimaut - ანაზღაურება) - 5) 'finalize/notify'.

12) serverless- ის ჩეკის სია

1. განისაზღვრება ღონისძიებების წყაროები და ხელშეკრულებები (სქემები/ვერსიები).
2. კონკურენტუნარიანობის შეზღუდვები და „ფრთხილად“ ჭიდაობა, არის DLQ და replay.
3. კერძო ქსელები/VPC, egress-allow-list, ფიქსირებული IP PSP.
4. IAM ყველაზე მცირე პრივილეგიების საფუძველზე, საიდუმლოებები KMS/Secret Manager- ში.
5. Observability: OTel კვალი, P99/შეცდომები/ცივი დაწყება.
6. FinOps: ბიუჯეტები, ფასების ალერტები, ხანგრძლივობის/მეხსიერების კონტროლი.
7. CI/CD: canary/blue-green, კონტრაქტების/idempotence გზატკეცილები.
8. დოკუმენტაცია: DevPortal/Postman კოლექციები, მაგალითები payload's, Deprecation/Sunset.

13) ანტი შაბლონები

„სქელი“ ფუნქციები ქლიავის დამოკიდებულებით არის ნელი ცივი დასაწყისი.
იდემპოტენტურობისა და ვებჰუკების ხელმოწერების არარსებობა არის დუბლიკატები/თაღლითობა.
Fan-out გარეშე limites, ქარიშხალი კონკურენცია, trottling პროვაიდერზე.
ლოგიკა ტაიმერებში/გვირგვინებში ტრეკერის/ალერტების გარეშე არის SLA- ს „მშვიდი“ წარუმატებლობა.
პროდუქტების შერევა გარემოში ცვლადი დაშიფვრის გარეშე.
ღონისძიების კონტრაქტები Schema Registry- ს გარეშე და თავსებადობის წესები.

14) შედეგი

Serverless არის ღრუბლის მოვლენის ოპერაციული სისტემა: თქვენ ფოკუსირდებით ბიზნეს ლოგიკაზე, ხოლო სკალირება და ინფრასტრუქტურა „მოთხოვნით“. დააკავშირეთ FaaS + კონტროლირებადი სერვისები, დაამატეთ იდემპოტენტურობა, ორკესტრი და დაკვირვება, დისციპლინური ღირებულება - და მიიღეთ პლატფორმა, რომელიც გაუძლებს მწვერვალებს, სწრაფად ვითარდება და რჩება ეკონომიური.