Miqyaslandırma və deploy: balanslaşdırma, backend‑xidmət klasterləri, blue/green və canary

1. Bu mühazirə nədən bəhs edir və niyə vacibdir

Təsəvvür edin ki, GiftGenius‑u elə mərhələdə saxlamısınız ki, o, Vercel‑də tək yaşayır: bir MCP‑gateway instansı (həm MCP‑ni çöldə reallaşdırır, həm də sizin REST‑servislərinizə gedir), agentlər üçün bir backend — “necəsə işləyir”. Bu, pet‑layihə və ilk 100 istifadəçi üçün hələ dözüləndir.

Amma OpenAI sizin App‑i Store‑a əlavə edib, o, qəfil Miladdan əvvəl əsas seçməyə düşən kimi “3000 portunda bir gateway” çox kədərli hekayəyə çevriləcək: tool çağırışlarının növbəsi, timeout‑lar, 500 səhvləri, Store‑da reytinqin düşməsi və marketinqdən “bəs niyə satış pikində hər şey yıxıldı?” tərzində məktublar.

Bu mühazirədəki vəzifəmiz — GiftGenius‑a (və istənilən ChatGPT App‑ə) balanslaşdırıcı arxasında eyni instanslardan ibarət bir sistem kimi yanaşmağı öyrənməkdir. Üstəlik — səliqəli release strategiyalarını və “nə isə səhv gedərsə, necə tez geri qayıdırıq” sxemini anlamaq.

2. Üfüqi miqyaslandırma və stateless‑dizayn

Baza ideyadan başlayaq: əgər sizin MCP Gateway və ya daxili backend‑xidmət prosesin yaddaşında vacib vəziyyəti saxlayırsa, onu üfüqi şəkildə normal miqyaslandırmaq demək olar ki, mümkün deyil.

Şaquli və üfüqi miqyaslandırma

Əvvəlcə terminləri dəqiqləşdirək.

Şaquli miqyaslandırma — bir serverə “əzələ artırmaqdır”: daha çox CPU, daha çox RAM. Bu, sürətlidir, bəzən startda ucuzdur, amma sərt həddi var və bir instansı single point of failure edir: bu güclü “canavar” yıxılarsa, hər şey yıxılır.

Üfüqi miqyaslandırma — balanslaşdırıcı arxasında servisin bir neçə nüsxəsini işə salmaqdır. Hər instans nisbətən kiçikdir, yaddaşda kritik heç nə saxlamır, vəziyyət isə xarici saxlamalara gedir (Postgres, Redis, obyekt yaddaşı). Yükə görə instansları sərbəst əlavə edib çıxarmaq olar.

MCP Gateway və backend‑servislər (Gift REST API, Commerce REST API, Analytics Service / REST API və s.) üçün üfüqi miqyaslandırma faktiki olaraq şərtdir: ChatGPT sizə qəfil dəfələrlə çox trafik yönləndirə bilər (mövsüm, Store‑da promo, hansısa viral TikTok), və siz “bir server tab gətirsin” deyə dua etmək yox, sadəcə daha çox instans əlavə etməlisiniz.

MCP Gateway və backend‑lər kontekstində stateless‑xidmət nədir

Üfüqi miqyaslandırmanın işləməsi üçün servis maksimal dərəcədə stateless olmalıdır.

Stateless bizim kontekstdə belə deməkdir:

• servis yaddaşda istifadəçinin biznes‑loqikadan asılı olan unikal, uzunömürlü vəziyyətini saxlamır;
• istənilən vacib vəziyyət xarici DB‑də, növbədə, keşdə, S3‑bənzər saxlamada saxlanılır;
• əgər konkret instans yıxılarsa, başqa instans xarici saxlama vasitəsilə konteksti “götürüb” istifadəçini servis etməyə davam edə bilir.

GiftGenius üçün bu o deməkdir ki:

• istifadəçinin hədiyyə seçimləri tarixi, like/dislike‑ları və səbəti, məsələn, Postgres‑də saxlanılır;
• uzunmüddətli tapşırıqların növbələri (kütləvi seçim generasiyası, email‑seçim göndərişi) Redis/Cloud Queue tipli brokerdə saxlanılır;
• əgər mürəkkəb agent workflow‑ları üçün ayrıca servisiniz varsa, o, checkpoint‑ləri və uzunömürlü yaddaşı RAM‑də yox, öz storunda saxlayır.

MCP Gateway və ya istənilən backend‑xidmət instansı “ev heyvanı yox, mal‑qara” modelinə çevrilir: onu amansızcasına öldürüb yenidən yaratsanız da, biznes məlumatları itirilmir.

Mini nümunə: vəziyyəti yaddaşdan xarici saxlamaya daşımaq

Tutaq ki, vaxtilə çox sadə bir MCP‑tool add_to_cart yazmısınız; gateway vasitəsilə daxili loqikaya müraciət edir və o, səbəti prosesin yaddaşında saxlayır (bəli, demo‑larda bəzən belə edirlər — və siz bunun prod‑da olmaz olduğunu anladığınız müddətcə bu normaldır):

// PİS: səbət backend xidmət prosesinin yaddaşında
const inMemoryCarts = new Map<string, string[]>();

export async function addToCart(userId: string, sku: string) {
  const cart = inMemoryCarts.get(userId) ?? [];
  cart.push(sku);
  inMemoryCarts.set(userId, cart);
  return cart;
}

Burada üfüqi miqyaslandırma mümkün deyil: bir sorğu A instansına, digəri B instansına düşəcək, və istifadəçinin səbətləri fərqli olacaq.

Düzgün variant — səbəti xarici DB və ya keşə çıxarmaqdır. Şərti (çox sadələşdirilmiş):

// YAXŞI: səbət xarici yaddaşda
import { db } from "./db";

export async function addToCart(userId: string, sku: string) {
  await db.cartItems.insert({ userId, sku }); // sadələşdirilmiş
  const cart = await db.cartItems.findMany({ where: { userId } });
  return cart;
}

Artıq sorğunu hansı backend‑instansının gateway vasitəsilə emal etməsi fərq etmir: səbət hamı üçün birdir.

3. Yükün balanslaşdırılması: trafik backend‑xidmət klasterlərinə necə düşür

Sizdə bir servisdən çox instans olan kimi, onlar arasında sorğuları paylayacaq biri lazımdır. Bu, məşhur pizza restoranında sifariş paylayıcısı kimidir: çoxlu kuryer, çoxlu müştəri, loqika olmayanda — xaos.

L4 vs L7 və niyə əsasən L7 bizi maraqlandırır

Balanslaşdırıcı müxtəlif səviyyələrdə işləyə bilər:

• L4 (TCP/UDP) sadəcə baytları müştəridən backendlərdən birinə ötürür, hansı protokol olduğunu elə də anlamır;
• L7 (HTTP) qarşısındakı HTTP sorğudur, path‑a, başlıqlara, cookie‑lərə, bəzən hətta gövdəyə baxmağı bacarır.

MCP Gateway və REST‑servislərlə ChatGPT App arxitekturası üçün bizə demək olar ki, həmişə L7‑balanslaşdırıcı lazımdır: hər şey HTTP/SSE ilə danışır və path, domen, başlıqlar (məsələn, canary‑release üçün) üzrə marşrutlaşdırmaq və health‑check‑lər etmək istəyirik.

Health‑check‑lər və “xəstə” instansların rotasiyadan çıxarılması

Balanslaşdırıcı periodik olaraq instansların canlı olduğunu yoxlamalıdır. Ən sadə yol — GET /health və ya /readyz endpoint‑inin olmasıdır; hər şey yaxşıdırsa, 200 OK qaytarır.

MCP Gateway və ya backend kimi işləyən Node/TypeScript servisində health‑check belə görünə bilər:

// apps/gateway/src/http/health.ts
import { type Request, type Response } from "express";

export function healthHandler(req: Request, res: Response) {
  res.json({
    status: "ok",
    version: process.env.RELEASE_ID ?? "dev",
  });
}

Balanslaşdırıcı hər N saniyədən bir /health ünvanına müraciət edir. Cavablar 5xx və ya timeout‑la gəlməyə başlayarsa, bu instans rotasiyadan çıxarılır və yeni trafik ora düşmür.

Streaming / SSE üçün xüsusiyyətlər

MCP Gateway tez‑tez SSE (Server‑Sent Events) ilə işləyir, xüsusən də qismən nəticələri stream edirsinizsə. Balanslaşdırıcı aşağıdakını bacarmalıdır:

• uzunmüddətli HTTP bağlantılarını dəstəkləmək;
• instans seçərkən belə bağlantıları nəzərə almaq (bəzi LB‑lər aktiv bağlantı sayını da, təkcə RPS‑i yox, nəzərə ala bilir).

Bu vacibdir, çünki 2 dəqiqə ərzində mətn stream edən bir “çox danışan” tool çağırışı aktiv bağlantı kimi asılı qalır. Belə bağlantılar bir instansda həddindən artıq çoxdursa, həmin instans müvəqqəti “boşaldılmalıdır” — yeni bağlantılar başqalarına göndərilməlidir.

4. Backend‑xidmət klasterləri: tapşırıqlara görə bölürük, hər şeyi bir yerə yığmırıq

Sonrakı məntiqli addım — bir “böyük backend‑xidməti” haqqında düşünməyi dayandırmaq və sistemi yüklərin xarakterinə və kritikliyinə görə bir neçə klasterə bölməkdir.

GiftGenius üçün klasterlər üzrə arxitektura nümunəsi

16‑cı moduldakı toplanmış məlumatlar GiftGenius üçün belə bir sxemi tövsiyə edir:

Əslində bu, bulkheads (bölmələr) pattern‑inin tətbiqidir: klaster B mürəkkəb mətnləri generasiya edərkən qəfil “CPU‑nu tokenlərlə yandırmağa” başlasa belə, ödəniş klasteri C öz resurs hovuzu və öz miqyaslandırması olduğundan işləməyə davam edəcək.

Gateway vasitəsilə bu necə görünür

Modulun birinci mühazirəsində təsvir olunan MCP Gateway daxil olan bütün MCP trafikinə baxır və onu backend klasterləri üzrə marşrutlaşdırır. Təxminən belə:

• list_gifts, suggest_gifts tool çağırışları → klaster A (Gift REST API);
• generate_greeting_card tool çağırışları və ya mürəkkəb agent‑workflow‑lar → klaster B (Agents REST‑xidməti və ya worker‑lər);
• create_order, confirm_payment alətləri → klaster C (Commerce REST API).

Bunun arxasında bir ümumi balanslaşdırıcı və ya bir neçə balanslaşdırıcı dayana bilər (məsələn, commerce qarşısında ayrıca L7‑LB qoyaraq daha da izolə etmək üçün).

Ümumi şəkli belə göstərmək olar:

flowchart LR
    ChatGPT((ChatGPT))
    GW[MCP Gateway]
    LBA[LB Gift API Cluster A]
    LBB[LB Agents/Workers Cluster B]
    LBC[LB Commerce API Cluster C]

    A1[Gift REST API A-1]
    A2[Gift REST API A-2]
    B1[Agents Service B-1]
    B2[Agents Service B-2]
    C1[Commerce REST API C-1]
    C2[Commerce REST API C-2]

    ChatGPT --> GW
    GW -->|tools: gifts| LBA
    GW -->|agents workflows| LBB
    GW -->|commerce| LBC

    LBA --> A1
    LBA --> A2
    LBB --> B1
    LBB --> B2
    LBC --> C1
    LBC --> C2

Sxem bir qədər ideallaşdırılıb, amma əsas prinsipi əks etdirir: fərqli yük tipləri — bir MCP Gateway arxasında fərqli backend‑klasterlər.

5. Deploy strategiyaları: niyə blue/green və canary lazımdır

İndi isə bütün bunları elə yeniləməkdən danışaq ki, istifadəçilər hiss etməsin, siz isə gecələr rahat yatın.

Anti‑nümunə: produn “üzərinə” deploy

Ən sadə və ən təhlükəli strategiya: mövcud klasteri (məsələn, Gift REST API A klasteri) götürür, yeni imici köhnəsinin üzərinə qaldırır, konteynerləri əvəz edir və ya prosesləri yenidən başladırsınız.

Buradakı problemlər:

• instansların bir hissəsi artıq yenidir, digəri köhnə — xüsusən DB sxemi dəyişibsə, sistem özünü gözlənilməz apara bilər;
• nə isə səhv gedərsə, rollback “necə vardı”ya yeni deploy deməkdir və bu, dəqiqələr çəkə bilər;
• deploy anında elə vəziyyət ola bilər ki, hələ heç bir instans qalxmayıb, qısa downtime alırsınız.

Kubernetes və PaaS bunu rolling‑yeniləmələrlə bir az yumşaldır, amma ümumi fikir eynidir: aydın strategiya olmadan sizin “boz zona”nız çoxdur — fərqli kod versiyaları eyni anda trafiki emal edir.

Blue/Green‑deploy: iki mühit və ani keçid

Blue/Green — eyni anda iki demək olar ki, eyni mühitin olması yanaşmasıdır: Blue (cari production) və Green (yeni versiya).

Sxematik proses belədir:

1. Green mühitində yeni versiyanı (v2) qaldırırsınız: bu, eyni gateway + backend‑klaster dəstidir, sadəcə hələ real trafik yoxdur.
2. Green üzərində bütün lazımi testləri keçirirsiniz: autotestlər, smoke ssenariləri, ChatGPT Dev Mode vasitəsilə əl yoxlamaları.
3. Release anında balanslaşdırıcı/marşrutlaşdırmanı elə dəyişirsiniz ki, 100% döyüş trafiki Green‑ə getsin.
4. Blue yaxınlıqda “ehtiyat aerodrom” kimi yaşayır. Nə isə səhv gedərsə, saniyələr içində trafiki geri çevirirsiniz.

GiftGenius üçün bu belə görünə bilər: sizin mcp-gateway-blue.example.com və mcp-gateway-green.example.com var. Production‑dakı ChatGPT App rəsmi MCP‑endpoint‑inə (gateway) “baxır”, release zamanı isə DNS/LB konfiqini elə dəyişirsiniz ki, mcp-gateway.example.com domen adı artıq green‑ə işarə etsin.

Üstünlüklər:

• ani “ora‑bura” açarı;
• istənilən problemi rollbackdən sonra müalicə edə bilərsiniz;
• “klasterin yarısı yeni, yarısı köhnə” halı yoxdur.

Mənfi cəhətlər:

Release vaxtı iki tam mühiti saxlamaq lazımdır, yəni resurs xərci ×2. Ona görə bu strategiya daha çox kritik backend‑servislərə tətbiq olunur — məsələn, commerce klasteri C və elə MCP Gateway‑in özünə; checkout və giriş nöqtəsini heç bir halda sındırmaq olmaz.

Canary‑release‑lər: kömür şaxtasında kiçik “kanareyka”

Canary‑release daha qənaətcildir: iki tam production qaldırmırsınız, yeni versiyanı tədricən trafikin kiçik hissəsinə çıxarırsınız və diqqətlə müşahidə edirsiniz.

Təxmini ssenari:

1. Gift REST API A klasterinin v2 versiyasını eyni hovuzda və ya ayrıca kiçik kanareyka hovuzunda deploy edirsiniz.
2. Balanslaşdırıcını və ya MCP Gateway‑i elə tənzimləyirsiniz ki, məsələn, hədiyyələrlə bağlı tool çağırışlarının 1%‑i v2‑yə, 99%‑i isə v1‑ə getsin.
3. Metrikalara baxırsınız: error rate, gecikmə, spesifik biznes metrikalar (konversiya, uğurlu checkout‑lar).
4. Hər şey yaxşıdırsa, payı tədricən artırırsınız: 1% → 5% → 10% → 50% → 100%. Pisdirsə — təcili rollback edirsiniz.

ChatGPT Apps kontekstində canary yalnız kod üçün yox, prompt eksperimentləri üçün də xüsusilə faydalıdır: agent‑servisi üçün yeni system‑prompt davranışı köklü şəkildə dəyişə bilər; yaxşısı budur ki, əvvəlcə bunu kiçik istifadəçi seçməsində yoxlayasınız.

Qapı (Gateway) və ya LB “kanareyka” sorğusunu müxtəlif əlamətlərlə seçə bilər:

• təsadüfi olaraq (məsələn, bütün sorğuların 1%‑i);
• userId üzrə (istifadəçilərin bir hissəsi daimi olaraq eksperimentə düşür);
• xüsusi başlıq və ya cookie ilə (daxili test üçün).

Gateway‑də ideyanı göstərmək üçün kiçik bir pseudo‑TypeScript marşrutlaşdırma nümunəsi:

// Gateway-də psevdokod: sadə təsadüfi canary 5%
function routeToGiftBackendCluster(ctx: { userId?: string | null }) {
  const rnd = Math.random();
  if (rnd < 0.05) {
    return "gift-api-v2"; // canary
  }
  return "gift-api-v1";   // stable
}

Real həyatda, əlbəttə, bunu runtime kodunda Math.random() ilə etməyəcək, qaydaları konfiq/fidja‑flaqlara çıxaracaqsınız, amma loqika çox oxşardır: trafikin bir hissəsi backend‑xidmətin canary versiyasına, qalanı isə stabilə gedir.

6. Rollback strategiyanın məcburi hissəsi kimi

Çoxdan yaxşı bir qaydanı mənimsəmişəm: rollback düzəlişdən daha sürətli olmalıdır.

Bu o deməkdir ki, release‑dən sonra səhvlər yağmağa başlayıb, istifadəçilər “hər şey sıradan çıxıb” yazanda, production‑da qəhrəmancasına bug düzəltməyə ehtiyac yoxdur. Böyük qırmızı “rollback” düyməsini basmaq lazımdır.

Vercel kimi platformalar (Next.js hissəsini GiftGenius üçün artıq orada yerləşdirmişdik) üçün bu çox təbiidir: hər deploy immutable artefaktdır və Vercel əvvəlkinə sürətlə qayıtmağa imkan verir.

Kubernetes və ya başqa orkestratorda yerləşdirilmiş MCP Gateway və backend klasterləri üçün bu rolu kubectl rollout undo oynayır: əvvəlki pod/image dəstinə qayıdırsınız.

Əsas — hazırda trafiki hansı versiyanın servis etdiyini loglamaq və göstərməkdir. Məsələn:

• version sahəsini /health və digər diaqnostik endpoint‑lərə əlavə etmək (artıq yuxarıda etmişdik);
• release identifikatorunu başlıqlar vasitəsilə loglara ötürmək (məsələn, X-Release-Id).

Mini nümunə: ChatGPT App daxilində widget üçün build versiyasını qaytaran Next.js‑API‑route:

// apps/web/app/api/version/route.ts
export async function GET() {
  return Response.json({
    version: process.env.RELEASE_ID ?? "dev",
    builtAt: process.env.BUILT_AT ?? "unknown",
  });
}

Belə endpoint həm də sazlama üçün faydalıdır: production instansından hazırda hansı versiyanın işlədiyini soruşa bilər və “son build həqiqətən çıxıb?” deyə təxmin etməzsiniz.

7. Capacity planning: GiftGenius üçün neçə instans lazımdır

Artıq yeni versiyaları necə təhlükəsiz çıxarmağı (blue/green, canary) və problemlərdə necə tez qayıtmağı danışdıq. Praktik sual qaldı: real trafiki daşımaq və büdcəni yandırmamaq üçün production‑da ümumiyyətlə neçə instans və hansı klasterlər saxlamaq lazımdır?

Formullara fanatik dalmadan, bir az lazımdır. Miqyaslandırmanı yüklə və iqtisadiyyatla bağlamaq gərəkdir: gündə/saniyədə neçə sorğu, neçə ağır LLM çağırışı, bunun pula dəyəri nə qədərdir.

Sadəlik üçün böyüklüklərlə düşünmək olar:

• 10k günlük sorğuda (təxminən orta 0.1 RPS) asanlıqla bir‑iki MCP Gateway instansı və bir cüt Gift REST API/Agents worker‑i ilə yaşayırsınız;
• 100k günlük sorğuda (1–2 orta RPS, pikdə — daha çox) artıq 3–5 gateway instansı + Gift REST API klasteri, ağır agentlər üçün ayrıca B klasteri və ayrılmış commerce klasteri saxlamağa dəyər;
• 1M günlük sorğuda (onlarla RPS, bayramlarda pik yüklər) mütləq klasterlər, LLM agentləri üçün ayrılmış resurslar, aqressiv keş və edge qatı lazım olacaq (bu haqda ayrıca mühazirə var).

Bunlar dəqiq rəqəmlər deyil, yük böyüklüyünü qiymətləndirmək və əvvəlcədən düşünmək üçündür: dar boğazlar haradadır, necə miqyaslandıracaqsınız və bunun dəyəri nə qədər olacaq.

GiftGenius üçün xüsusilə bayramlara hazırlaşmaq vacibdir: Yeni il, Milad, Sevgililər Günü, Qara cümə. Yük dəfələrlə arta bilər, siz isə sistemin buna tab gətirməsini istərdiniz.

8. Praktik mini‑nümunə: GiftGenius deployunun təkamülü

Hər şeyi bir yerə toplamaq üçün, GiftGenius deployunun sadə təkamülünü çəkək.
Burada yuxarıda danışdıqlarımızı ardıcıl tətbiq edəcəyik: gateway və backend‑servislərin stateless‑dizaynı, yükün balanslaşdırılması, ayrı klasterlər və release strategiyaları (blue/green, canary).

Baza səviyyə: Vercel/Kubernetes‑də bir gateway + backend

Kursun hansısa anında bunu etmisiniz: Vercel‑də Apps SDK ilə Next.js tətbiqi, onun içində həm MCP‑endpoint, həm də (Gift/Commerce) üçün sadə backend loqika bir xidmətdə yaşayır. Hər şey olduqca monolitdir.

Üstünlüklər aydındır: sadə, ucuz, səhv edəcək yer azdır.

Mənfi cəhət təkdir, amma kritikdir: bu, ciddi trafikdə heç cür miqyaslanmır və yeniləmələri pis keçir.

Səviyyə 2: ayrı MCP Gateway + bir neçə backend‑klaster

Növbəti addım:

• MCP Gateway‑i ayrı xidmətə çıxarırsınız (Node/Go/NGINX+Lua — fərqi yoxdur);
• bir neçə Gift REST API instansı (A klasteri) və agentlər üçün bir neçə worker/xidmət (B klasteri) işə salırsınız;
• commerce üçün ayrı xidmət (C klasteri), bəlkə də — ayrı baza/infrastruktur ayırırsınız.

Artıq burada klassik L7‑balanslaşdırma, health‑check‑lər və imkan daxilində üfüqi miqyaslandırma qoşulur.

Səviyyə 3: Release strategiyaları

Bu səviyyədə əlavə edirsiniz:

• checkout və autorizasiyanın maksimum stabil olması üçün commerce klasteri C (və istəsəniz MCP Gateway) üçün Blue/Green;
• Gift REST API və agent xidmətləri klasterləri üçün Canary‑release‑lər — yeni tool və agent versiyaları ilə bütün production‑u riskə atmadan sakit‑sakit eksperiment etmək üçün.

Sxematik olaraq:

flowchart LR
    ChatGPT((ChatGPT))
    GWBlue[Gateway Blue]
    GWGreen[Gateway Green]
    LB[Traffic Switch]

    subgraph Prod
      LB --> GWBlue
      LB -.canary,% .-> GWGreen
    end

    ChatGPT --> LB

Reallıqda bir az daha mürəkkəb ola bilər (yalnız commerce üçün Blue/Green, yalnız gift klasterləri üçün canary), amma ideyanı illüstrasiya edir: siz həmişə bilirsiniz ki, hansı versiya hara gedir, üstəlik ChatGPT üçün hər şey hələ də bir MCP giriş nöqtəsi (gateway) kimi görünür.

9. Versiyalaşdırma və diaqnostika üçün kiçik kod fraqmentləri

Artıq health‑endpoint və /api/version gördük. Gəlin daha bir nümunə əlavə edək: gateway tərəfində MCP‑tool handler‑ində versiyanı və klasteri necə loglamaq olar ki, sonra metrikaları asan “yığaq”.

Tutaq ki, suggest_gifts tool‑u var; Gift REST API‑də REST‑endpoint kimi reallaşdırılıb və gateway vasitəsilə çağırılır:

import { type McpToolHandler } from "@modelcontextprotocol/sdk";

export const suggestGifts: McpToolHandler<{
  occasion: string;
  budget: number;
}> = async ({ input, meta }) => {
  const releaseId = process.env.RELEASE_ID ?? "dev";
  const clusterId = process.env.CLUSTER_ID ?? "gift-api-A";

  console.log("[suggest_gifts]", {
    releaseId,
    clusterId,
    userId: meta.userId,
    occasion: input.occasion,
  });

  // burada MCP Gateway marşrutlaşdırma cədvəli üzrə Gift REST API-ni çağırır,
  // alət özü isə REST çağırışının nazik bir örtüyü olaraq qalır
  return {
    content: [{ type: "text", text: "Gift ideas..." }],
  };
};

Burada biz:

• ətraf mühitdən RELEASE_ID və CLUSTER_ID oxuyuruq;
• onları strukturlaşdırılmış loglara yazırıq;
• sonra analitikada asan istifadə edirik: “hazırda hansı versiya/klasterdə daha çox səhv tökülür?”.

ChatGPT App baxımından bu tam şəffafdır, amma developer kimi sizin üçün böyük üstünlükdür — xüsusilə canary/blue‑green ilə birlikdə.

10. ChatGPT App miqyaslandırma və deploy zamanı tipik səhvlər

Səhv №1: sessiya/istifadəçi vəziyyətini gateway və ya backend prosesinin yaddaşında saxlamaq.
Belə yanaşma üfüqi miqyaslandırmanı öldürür: ikinci instans yaranan kimi vəziyyət onlar arasında “laylanır”. Xüsusilə səbəti, axtarış nəticələrini və ya workflow proqresini yaddaşda saxlamaq təhlükəlidir. Bunların hamısı xarici saxlamada — DB, keş və ya agent vəziyyəti üçün ixtisaslaşmış stor‑da yaşamalıdır.

Səhv №2: “bir güclü server”in kifayət etdiyini düşünmək.
Şaquli miqyaslandırma startda rahatdır, amma real artımda pis işləyir: maşının fiziki həddi var, bir proses single point of failure olur, ChatGPT isə proqnozlaşdırılmayan trafik sıçrayışı gətirə bilər. MCP Gateway və backend klasterləri üçün demək olar ki, həmişə stateless‑dizayn və balanslaşdırıcı arxasında bir neçə instans lazımdır.

Səhv №3: aydın strategiya olmadan yeni versiyaları “produn üzərinə” çıxarmaq.
Əgər sadəcə döyüş klasterində konteynerləri/prosesləri yeniləyirsinizsə, aralıq vəziyyət alırsınız: trafikin bir hissəsi köhnəyə, bir hissəsi yeniyə gedir, səhv olanda isə rollback “bir də deploy et”ə çevrilir. Daha etibarlısı iki mühit saxlamaqdır (blue/green) və ya heç olmasa ayrıca canary backend versiyası — ora trafikin kiçik hissəsi gedir.

Səhv №4: sürətli rollback planının olmaması.
Pis ssenari: release keçdi, metrikalar qırmızıdır, istifadəçilər şikayət edir, siz isə yeni düşünməyə başlayırsınız ki, necə qayıdaq. Düzgün ssenari: əvvəlcədən hazırlanmış ani rollback imkanı (blue/green açarı, rollout undo, Vercel rollback), loglarda və health‑endpoint‑lərdə aydın versiya identifikatorları və sərt qayda “əvvəl rollback, sonra araşdırma”.

Səhv №5: yük növlərinə görə bölünmə olmadan “hər şey üçün bir klaster”.
Əgər təbrik mətni generasiyası (LLM agentləri) və checkout bir klasterdə yaşayırsa, modellər tərəfdəki istənilən problem (gecikmələr, timeouts, token artımı) ödənişi də çökdürə bilər. Tapşırıq tiplərinə görə klasterlərə bölmək (Gift REST API / yüngül alətlər, Agents‑heavy servis, Commerce REST API) və hər klaster üçün ayrıca limitlər/resurslar — dayanıqlılığa gedən mühüm addımdır.

Səhv №6: arxitektura ilə iqtisadiyyat arasında əlaqənin olmaması.
“Asanlıqla “gəlin iki node da qaldıraq” ideyasına aldanmaq olar, amma hər LLM çağırışı və hər instans puldur. Sadə capacity planning (yük və dəyər qiymətləndirilməsi) olmadan ya az miqyaslanıb production‑u yıxa, ya da həddən artıq miqyaslanıb marjinalılığı itirə bilərsiniz. Burada sorğu sayını, ağır LLM əməliyyatlarının faizini və hostinq dəyərini tətbiqin biznes metrikaları ilə bağlamaq faydalıdır.