Benchmarking შესრულება

1) რატომ არის iGaming ბენჩმარკის პლატფორმა

ტევადობის დაგეგმვა: დაადასტუროს, გაუძლებს თუ არა პრემიერ დროის ინფრასტრუქტურა, ტურნირი ან ახალი პროვაიდერი.
ტექნოლოგიის არჩევანი: მონაცემები, SQL/OLAP ძრავები, ნაკადი, FS/ML სერვინგი, ქეში, API კარიბჭეები.
რეგრესიების კონტროლი: გამოშვებების შემდეგ, სქემების/ფიგურების მიგრაცია, მოდელების განახლება.
ბიუჯეტი და TCO: შედარება „პროდუქტიულობა დოლარისთვის“ და „ლატენტობა დოლარად“.

შედეგი: გადაწყვეტილება „შეიძინოს/ოპტიმიზაცია/გადადება“ რიცხვების საფუძველზე, და არა შეგრძნებები.

2) მეთოდოლოგია: როგორ არ მოვატყუოთ თავი

1. ყველაფერი დააფიქსირეთ: მონაცემთა/კოდის ვერსიები, კლასტერის კონფიგურაცია, სავარძლები, მონაცემთა კატა.
2. დათბობა (warm-up) არის სტაბილური პლატო და დეგრადაცია: ჩვენ მხოლოდ პლატოზე ვზომავთ.
3. რეპლიკაცია: 3 პროგონი; ნდობის ინტერვალი 95%.
4. რეალისტური პროფილები: დატვირთვის მწვერვალები/„ სუნთქვა “, think დრო, ცხელი ღილაკების ჯიბეები.
5. იგივე სემანტიკა: იგივე SQL/fich Joines/KPI, იდენტური ფანჯრები და ფილტრები.
6. ქეში ჰიგიენა: ტესტები „გაათბეთ ქეში“ და „ცივი სტარტი“ - ცალკე.
7. დამოუკიდებლობა: ბენჩის სტენდი იზოლირებულია პროდ/დაკავშირებული ექსპერიმენტებისგან.
8. გაჩერების კრიტერიუმები: SLO ირღვევა ან მიღწეულია - ჩვენ ვასრულებთ ტესტს.

3) სამუშაო დატვირთვის პორტფელი (workload mix)

3. 1 Ingestion/ETL (Bronze → Silver → Gold)

მეტრიკა: events/s, end-to-end freshness, წარმატება/retrai, ღირებულება/1000 შეტყობინება.
ტესტები: burst ნაკადები PSP/პროვაიდერები, „ბინძური“ მონაცემები, schema drift.

3. 2 SQL/OLAP (DWH/კუბი)

მეტრიკა: latency p50/p95/p99, throughput (QPS), სკანერები/ბაიტი/ბირთვში, cost/query.
მოთხოვნები: GGR/NET day/week, შეკავების კოჰორტები, დეპოზიტების ძაბვები, heavy joins.

3. 3 ნაკადი (თამაშის რაუნდი, გადახდის სიგნალები)

მეტრიკა: E2E ფანჯრის ლატენტობა, watermark შეფერხება, exactly-once, Consumer.
სკრიპტები: პროვაიდერის „ნახტომი“ X3, ერთი წვეულების დაკარგვა, აღდგენა.

3. 4 Feature Store და offline ტრენინგი

მეტრიკი: წერტილოვანი დროული ჯონი, throughput fich/s, ჯგუფის მატერიალიზაციის დრო, სიახლე.
სკრიპტები: მასობრივი გადატვირთვა, ისტორიის რეპლიკაცია (backfill).

3. 5 ML serving (ონლაინ/batch/stream)

მეტრიკა: p95/p99, error rate, feature freshness, hit-rate ქეში, cost/1k სკორინგები, ცივი დასაწყისი.
სკრიპტები: spike გადახდაზე (KUS/ანტიფროდი), RG- მორიელი აქციების დროს.

3. 6 API ანალიტიკოსები და მეტრიკა

მეტრიკა: სამიზნე p95, success-rate, cache hit, cost/მოთხოვნა, FX/TZ შეზღუდვები.
სკრიპტები: პარტნიორი პანელები, მასობრივი მოხსენებები, გრძელი tail ფილტრები.

4) მეტრიკა და SLI/SLO

გარდა ამისა, ML: ASE/კალიბრაცია დატვირთვის ქვეშ, PSI/შესასვლელი დრიფტი მწვერვალზე.

5) ექსპერიმენტის დიზაინი

5. 1 დატვირთვის პროფილები

Ramp-up 10-15 წთ - Plateau 30-60 წთ - Ramp-down.
მწვერვალები: „ტურნირის“ პროფილი (10 წთ X3), „გამომავალი აქცია“ (2 საათი X1. 8), „flash dil“ (5 წთ X5).
Think-time и key-skew (80/20) для API/Feature Store.

5. 2 ცვლადის კონტროლი

წვეულებების/რეპლიკების ზომების დაფიქსირება, კონექტორების ლიმიტები, აუზის სიზი.
ჭკვიანი ავტომობილების გამორთვა ან მათი პატიოსნება.
ცალკეული საყრდენები with/without ქეში.

5. 3 სტატისტიკა და ანგარიში

მედიანა, IQR, ნდობის ინტერვალი.
გრაფიკები ჰისტოგრამების, დროის სერიის, სატურნის გრაფიკები.
ცალკეული ბლოკი „გაურკვევლობა და ხელშეუხებლობის საფრთხე“.

6) არტეფაქტების ნაკრები

6. 1 საცხობი პასპორტი (შაბლონი)

მიზანი: (მაგალითად, დაადასტუროს p95 API-300 ms X3- ზე)

დატვირთვა: (SQL TPC-like, API მიქსი, ML სკორინგი 200 QPS...)

მონაცემები: მოცულობა, ცხელი ღილაკების ჯიბეები, სნაიპშოტის ვერსია

კონფიგურაცია: მტევანი, ვერსიები, ლიმიტები, დროშები

მეტრიკი/SLO: სია, ბარიერები, ალერტები

სტენდი: იზოლაცია, რეგიონები, დაშიფვრის გასაღებები

რისკები: ცივი დაწყება, ქსელის ხაზები, ქეშების პოლიტიკა

6. 2 YAML დატვირთვის პროფილი (ესკიზი)

yaml name: analytics_api_peak_oct ramp_up: PT10M plateau: PT40M ramp_down: PT5M mix:
- endpoint: /v2/metrics/revenue qps: 180 group_by: [date, brand, country]
cache_ratio: 0. 6
- endpoint: /v2/metrics/retention qps: 60 window: ROLLING_28D cache_ratio: 0. 3 limits:
concurrency: 800 per_ip_qps: 50 think_time_ms: {p50: 80, p95: 250}

6. 3 გაშვების სია

• მონაცემები/ჭურვები დაფიქსირდა, ქეში გაიწმინდა (ცივი რუნისთვის).
• ჩამორთმევა/ვერსიები ჩაწერილია პასპორტში; დამონტაჟებულია.
• ალერტები SLO- ში შედის; კვალი და პროფილერები აქტიურია.
• უკან დახევის/შეჩერების გეგმა SLO დარღვევით.
• არხი # bench-status, დაინიშნა პასუხისმგებელი on-call.

7) iGaming დომენის სპეციფიკა

7. 1 პროვაიდერი დამნაშავეები და ტურნირები

სიმშვიდე მიანიჭეთ თამაშებს/პროვაიდერებს, „ფანჯრის ეფექტს“ (ერთი ან ორი თამაში იძლევა ტრაფიკის 40-60%).
ჩართეთ ლობის პერესტროიკა, როგორც რეაქცია დეგრადაციაზე.

7. 2 გადახდა/PSP

ორფაზიანი გარიგებები, რეტრაები, რიგები, იდემპოტენტობა.
პარალელურად, შეამოწმეთ მარშრუტების ვარიანტები (primary/backup PSP).

7. 3 RG/ანტიფროდი/KYC

შეამოწმეთ tail-latenty და fallback-eurics (როდესაც მოდელი მიუწვდომელია).
ცალკეული პროფილები VIP/თხელი ფაილებისთვის (thin-file).

8) ინსტრუმენტები და პრაქტიკა

დატვირთვის გამომუშავება: k6/JMeter/locust (API), მოვლენების საკუთარი რეგისტერი (stream).
პროფილირება: მოთხოვნის კვალი, flamegraphs, GC/alloc, GPU util.
Observability: ეტიკეტები build/commit მეტრიკებში და ლოგოებში, მფლობელთა პასუხისმგებლობა.
Cost მეტრიკა: $/1k მოთხოვნა, $/საათი პლატოზე, „SLO ღირებულება“.

9) ანალიზი და ინტერპრეტაცია

შეადარეთ SLO დონეზე: „დაასრულა/არა“, და მხოლოდ ამის შემდეგ - „რამდენად სწრაფია“.
გამოყავით ქეში მოგება ძრავის/არქიტექტურის გამარჯვებულებისგან.
OLAP- სთვის იხილეთ ბაიტის სკანერები, „ცენტრალიზებული ცხელი წერტილი“ (shuffle, skew).
ML- სთვის - რაოდენობრივი/დისტილაციის ეფექტი და მორიელის ქეშის ჰიტ-რეიტი.

10) ტევადობის დაგეგმვა

შედეგების თარგმნა სკალირების ფორმულაში: QPS/ბირთვი, events/s/ინსტანცია, $/ერთეული.
ააშენეთ headroom (მაგ., 30%) და მიუთითეთ სკეიტის საზღვრები.
შეინარჩუნეთ დეგრადაციის „წითელი ღილაკი“: ამოიღეთ მძიმე ფიჩები/ვიჯეტები, მათ შორის გამარტივებული KPI.

11) როლები და RACI

Data Platform (R): სტენდები, ორკესტრაცია, დაკვირვება, ინსტრუმენტები.
დომენის ობნერები (R): სკრიპტები და SQL/KPI, სისწორის შემოწმება.
ML Lead (R): scoring პროფილები, ქეში/ქვითრები.
SRE (R): ლიმიტები, სკეიტი, ინციდენტები.
უსაფრთხოება/DPO (C): ტესტის მონაცემების კონფიდენციალურობა, ტოქსიკაცია.
Product/Finance (A/C): SLO, cost მიზნები და ბიზნესის ინტერპრეტაცია.

12) გზის განხორციელების რუკა

0-30 დღე (MVP)

1. ბენჩის სკრიპტების კატალოგი: ungestion, OLAP, API, ML.
2. პასპორტი და YAML პროფილი პრემიერ დროის API და გადახდებისთვის.
3. დაშბორდი SLO/Saturation/Cost; ალერტები SLO წარუმატებლობებზე.
4. რეგულაცია „bench before release“ კრიტიკული ცვლილებებისთვის.

30-90 დღე

1. Stream Bench (late data, rebalancing, X3 burst).
2. ML serving: shadow + cold-start, quantization და ქეში.
3. მოხსენებების ავტომატური წარმოება (PDF/Confluence) მეტრიკიდან და პასპორტებიდან.
4. ვიწრო ადგილების ინვენტარიზაცია, ოპტიმიზაციის ბაკალავრი ROI- სთან.

3-6 თვე

1. რეგულარული სეზონური ბენზინი (ზაფხული/შემოდგომა/არდადეგები).
2. Capacity ერთი წლის გეგმა: headroom, ბიუჯეტი, გაფართოების წერტილები.
3. Auto raples ინციდენტები (repro benchi), champion-challenger კონფიგურაცია.
4. გარე პარტნიორობის ტესტები (პროვაიდერები/PSP) ხელმოწერილი ვებჰუკებით.

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

ქეში და ძრავის შერევა ცალკეული ტესტების გარეშე.
პლატოზე ნაცვლად გაათბეთ და მოკლე „სპრინტები“.
Benchi სათამაშოების მონაცემებზე ცხელი გასაღებების და საჭმლის გარეშე.
უგულებელყოფა p99 და GC/IO; „საშუალო სიჩქარე“ კუდის ნაცვლად.
„ვაშლის ფორთოხლის“ შედარება: სხვადასხვა SQL/ფილტრები/ფანჯრები.
განმეორების პროტოკოლი არ არსებობს: შეუძლებელია შედეგის რეპროდუცირება.

14) დაკავშირებული მონაკვეთები

DataOps პრაქტიკა, API ანალიტიკოსები და მეტრიკა, MLOps: მოდელების ექსპლუატაცია, ალერტა მონაცემთა ნაკადებიდან, აუდიტი და ვერსია, მონაცემთა შენახვის პოლიტიკა, უსაფრთხოება და დაშიფვრა, წვდომის კონტროლი.

შედეგი

Benchmarking არის საინჟინრო დისციპლინა და არა „ერთჯერადი პროგონი“. მკაცრი მეთოდოლოგია, iGaming რეალისტური პროფილები, გამჭვირვალე SLO და ხარჯების აღრიცხვა ციფრებს თავდაჯერებულ გადაწყვეტილებად აქცევს: სად უნდა გავაფორმოთ, რა უნდა გავითვალისწინოთ, რა რისკების მიღება და რა უსაფრთხოების ზღვარი უნდა შევინარჩუნოთ შემდეგ მწვერვალზე.