DEV Community: Jamal Ali

Yüksək trafikli AI inference servisi necə qurulur?

Jamal Ali — Sun, 04 Oct 2026 17:37:08 +0000

AI modeli lokal testdə 200 millisaniyəyə cavab verir. Production-a çıxandan sonra isə eyni endpoint bəzən iki saniyə gözlədir, GPU boş görünür, queue böyüyür və autoscaler gec ayılır. Tanış mənzərədir. Modelin sürətli olması, onu təqdim edən sistemin də sürətli olması demək deyil.

Yüksək trafikli AI inference servisində əsas sual budur: dəyişkən yükü qəbul edib GPU-nu səmərəli işlədərkən latency-ni necə nəzarətdə saxlamaq olar? Cavab bir komponentdə deyil. Trafikin girişindən model cavabına qədər bütün yol eyni latency büdcəsini bölüşür.

Request yolu əvvəlcədən məhdudlaşdırılmalıdır

İstifadəçi request-i əvvəlcə gateway-ə çatır. Burada autentifikasiya, request ölçüsü, rate limit və ümumi deadline yoxlanır. Sonra sorğu modelə uyğun queue-ya düşür, scheduler uyğun request-ləri batch edir, inference instance hesablamanı aparır, nəticə post-processing mərhələsindən keçib geri qayıdır.

Diaqram — orijinal məqalədə

Bu axında API gateway həddən artıq böyük input-u və icazəsiz trafiki erkən kəsir. Model queue ani sıçrayışı yumşaldır, amma sonsuz anbar deyil. Batch scheduler eyni modelə gedən uyğun sorğuları qruplaşdırır. Deadline bitibsə, artıq istifadəçiyə faydası qalmayan işi GPU-ya ötürmək əvəzinə timeout cavabı qaytarılır.

Queue üçün həm maksimum uzunluq, həm də maksimum gözləmə vaxtı təyin edilməlidir, çünki əks halda servis overload zamanı cavab vermək əvəzinə köhnə request-ləri yığır. GPU yüz faiz işləyə bilər, lakin istifadəçilər çoxdan cavab gözləməkdən vaz keçiblər.

Bu, faydalı iş deyil.

Batching throughput verir, pulsuz deyil

GPU bir neçə input-u birlikdə emal edəndə çox vaxt resursdan daha yaxşı istifadə edir. NVIDIA Triton-un dynamic batching mexanizmi ayrı inference request-lərini serverdə bir batch daxilində birləşdirir. Burada iki tənzimləmə bir-birinə qarşı işləyir: böyük batch throughput-u yüksəldə bilər, batch-in dolmasını gözləmək isə latency-yə əlavə olunur.

Ona görə max_batch_size rəqəmi GPU yaddaşına sığan ən böyük ədəd kimi seçilmir. Real input ölçüləri ilə sınaq aparılır, sonra p95 və p99 latency büdcəsi aşılmadan ən yaxşı throughput verən nöqtə götürülür. Mətn generasiyasında prompt uzunluqlarının kəskin fərqlənməsi işi daha da qəlizləşdirir. Qısa request uzun request-in arxasında ilişə bilər; uzunluğa görə ayrı queue-lar və ya scheduler siyasəti burada kömək edir.

Batching stateless modellərdə daha rahatdır. Request-lər arasında vəziyyət saxlayan modeldə ardıcıllıq və eyni instance-a yönləndirmə ayrıca qorunmalıdır; hər modeli eyni queue və batch konfiqurasiyasına salmaq rahat görünsə də workload-lar eyni davranmır.

Autoscaling hansı siqnalı görməlidir?

CPU əsasında autoscaling klassik web tətbiqində məntiqli başlanğıcdır. GPU inference servisində isə CPU aşağı olduğu halda queue sürətlə böyüyə bilər. Kubernetes Horizontal Pod Autoscaler resource metric-lərlə yanaşı custom və external metric-lərdən də istifadə edə bilir. Bu imkan queue dərinliyi, queue-da gözləmə müddəti və aktiv inference sayı kimi siqnalları scaling qərarına qatmağa şərait yaradır.

Tək GPU utilization da yetərli deyil. Yüz faiz utilization yaxşı batching nəticəsi ola bilər; eyni göstərici boğulmuş sistem də göstərə bilər. Fərqi queue açır. Queue yaşı və p99 latency artırsa, əlavə capacity lazımdır, queue boş və latency normaldırsa yüksək utilization öz-özlüyündə qəza siqnalı sayılmır.

Yeni replica saniyələr içində hazır olmaya bilər. Yol uzundur: image çəkilir, model faylı endirilir, çəkilər CPU və ya GPU yaddaşına yerləşdirilir, bəzən warmup inference işləyir. Scaling siyasəti bu başlanğıc vaxtından daha gec reaksiya verirsə, pik yük artıq queue-nu doldurmuş olacaq; minimum isti capacity və proqnozlaşdırılan trafik üçün əvvəlcədən scale-out buna görə vacibdir.

Model yüklənərkən health check-ləri ayırmaq lazımdır. Kubernetes startup probe tətbiqin başlanğıcını tamamlamasına vaxt verir; readiness uğursuz olduqda Pod-a trafik göndərilmir, liveness isə bərpa olunmayan vəziyyətdə restart qərarı üçündür. Eyni endpoint-i üçünə də bağlamaq modelin gec yükləndiyi anda boş yerə restart dövrəsi yarada bilər.

Overload nasazlığa çevrilməzdən əvvəl kəsilməlidir

Hər downstream çağırışın deadline-ı ümumi request deadline-dan qısa olmalıdır. Vaxt məhduddur. Pre-processing 300 ms, inference 900 ms, post-processing 200 ms gözləyirsə, gateway-də 1 saniyəlik timeout qoyub möcüzə gözləmək alınmayacaq. Büdcə komponentlər arasında açıq bölünür və qalan vaxt request-lə birlikdə ötürülür.

Retry yalnız keçici xəta və idempotent əməliyyat üçün düşünülməlidir. Kor retry təhlükəlidir. Eyni ağır inference request-i bir neçə client eyni anda dərhal təkrar göndərsə, kiçik nasazlıq ikinci trafik dalğasına çevrilir. AWS-in backoff və jitter izahında təsadüfi gecikmənin rəqabət aparan retry-ları zamana yaydığı göstərilir; limitli cəhd sayı, exponential backoff və jitter birlikdə işləyir, deadline bitəndən sonra isə retry dayandırılır.

Backpressure də məhz burada işə düşür. Queue limiti dolanda gateway yeni işi 429 və ya 503 ilə rədd edir, client isə Retry-After siyasətinə uyğun davrana bilər. Bu cavab xoş deyil, amma on saniyə susub sonra timeout verməkdən daha dürüstdür. Prioritetli workload varsa, məsələn interaktiv sorğu və gecəlik batch işi, onların queue və capacity payları ayrılır.

Model versiyası da production vahididir

Model çəkisi, tokenizer, preprocessing kodu və runtime konfiqurasiyası birlikdə versiyalanmalıdır. Paket bütövdür. Tək model faylını dəyişmək kifayət etmir; tokenizer uyğunsuzluğu servis işlək görünərkən səssiz keyfiyyət itkisi yarada bilər. Deployment əvvəlcə kiçik trafik payına açılır, texniki metriklərlə yanaşı modelə aid göstəricilər də müqayisə edilir.

Burada rollback yalnız container image-i geri çevirmək deyil. Köhnə model artefaktı və onun bütün asılılıqları əlçatan qalmalıdır. Stateful söhbət axınında model versiyasını request ortasında dəyişmək mümkün deyilsə, session routing qaydası da rollout planına daxil edilir.

Müşahidə ediləbilənlik request sərhədində qalmamalıdır. Gateway, queue, scheduler, inference və post-processing eyni trace daxilində görünəndə vaxtın harada itməsi aydınlaşır. OpenTelemetry context propagation trace məlumatını proses və şəbəkə sərhədlərindən keçirərək çağırışları əlaqələndirir. Trace üzərində model adı və versiyası, batch ölçüsü, queue gözləməsi, input ölçüsü və nəticə statusu faydalıdır; prompt, şəxsi məlumat və credential isə telemetry-yə yazılmamalıdır.

İzlənəcək əsas paylanmalar end-to-end p50/p95/p99 latency, queue wait, inference müddəti və batch ölçüsüdür. Bunlara throughput, reject sayı, timeout, retry, GPU yaddaşı və model yükləmə vaxtı əlavə olunur. Orta rəqəm aldadır. İstifadəçilərin ən çox şikayət etdiyi quyruq gecikməsini çox rahat gizlədir.

Capacity testi də tək sabit request sürəti ilə aparılmır. Ani burst, müxtəlif input uzunluğu, model rollout-u, bir GPU-nun itməsi və downstream yavaşıması ayrıca sınanır. Məqsəd sistemin maksimum neçə request qəbul etdiyini tapmaq deyil; latency büdcəsini qoruyaraq hansı yükə qədər faydalı cavab verdiyini görməkdir.

Tez-tez verilən suallar

AI inference servisi hansı metriklə miqyaslanmalıdır?

Tək CPU istifadəsi kifayət etmir. Queue dərinliyi, gözləmə vaxtı, p95/p99 latency, aktiv sorğu sayı və GPU utilization birlikdə izlənməlidir.

Dynamic batching həmişə latency-ni azaldır?

Xeyr. Batching throughput-u artıra bilər, lakin batch toplamaq üçün verilən gecikmə request latency-sinə əlavə olunur. Parametrlər latency büdcəsinə görə ölçülməlidir.

Model yüklənərkən readiness niyə vacibdir?

Proses işlək görünsə də model çəkiləri hələ yaddaşa yüklənməmiş ola bilər. Readiness uğurlu olmayana qədər instance-a trafik göndərilməməlidir.

Mənbələr

Bu yazı süni intellekt köməyi ilə yazılıb, faktları və mənbələri yoxlanılıb.

Zoosk-da real-time rabitə arxitekturası

Jamal Ali — Sun, 04 Oct 2026 17:36:44 +0000

Bir dating tətbiqində chat mesajının yarım saniyə gecikməsi xırda texniki detal kimi görünə bilər. Amma qarşı tərəfin online olduğunu göstərib mesajı gec çatdıranda məhsul istifadəçiyə yalan danışmış olur. Zoosk-un real-time rabitə arxitekturasında əsas məsələ buna görə təkcə sürət deyildi. Presence, bildiriş və şəxsi mesaj eyni anda həm canlı, həm tutarlı, həm də bərpa oluna bilən olmalı idi.

Texnologiyaların bir qismi köhnədir. Verdikləri dizayn sualları isə hələ təzədir: uzunömürlü bağlantılar necə bölünür, tez dəyişən online state axtarışa necə qoşulur, server sıradan çıxanda istifadəçi hara gedir və offline mesaj hansı qatın məsuliyyətidir?

Üç fərqli axını bir protokola yığmaq

Zoosk real-time rabitəni üç istifadəçi davranışı ətrafında qurmuşdu. Presence istifadəçinin online, away, offline və ya görünməz vəziyyətini daşıyırdı. Notification profil baxışı və uyğunlaşma kimi hadisəni client-ə çatdırırdı. Messaging isə iki istifadəçi arasındakı söhbəti aparır, məzmunu sonradan tarixçə kimi göstərmək üçün verilənlər bazasında saxlayırdı.

Bu axınların hamısı XMPP-dən keçirdi. XMPP Core uzunömürlü TCP bağlantısı üzərində persistent XML stream yaradır; tərəflər bağlantı açıq qaldığı müddətdə məlumatı dərhal itələyə bilir. Protokolun əsas vahidi stanza-dır və üç növü var: message, presence və iq. Zoosk üçün bu bölgü əlverişli idi, çünki chat və online vəziyyət eyni transport qatını paylaşsa da, semantik olaraq qarışmırdı.

Mobil və desktop client-lər serverə TCP socket ilə bağlanırdı. Həmin dövrün brauzer imkanları səbəbindən veb client-lər BOSH, yəni uzunömürlü rabitəni ardıcıl HTTP request-ləri ilə təqlid edən mexanizmdən istifadə edirdi. Bu gün XMPP-ni brauzerə çıxarmaq üçün RFC 7395 ilə standartlaşdırılmış WebSocket subprotocol-u daha təbii seçimdir: handshake zamanı xmpp subprotocol-u razılaşdırılır, sonra XMPP frame-ləri WebSocket bağlantısından keçir.

Diaqram — orijinal məqalədə

İstifadəçi veb, mobil və ya desktop client-dən gəlirdi. Load balancer normal halda bağlantıları primary Tigase node-a ötürürdü, health check uğursuz olanda isə trafik secondary node-a yönəlirdi. XMPP routing online istifadəçiyə stanza-nı canlı çatdırır, offline istifadəçi üçün mesaj saxlancına müraciət edirdi. Tigase sənədlərində offline mesajların istifadəçi yenidən daxil olduqda çatdırılması ayrıca server funksiyası kimi göstərilir.

Burada incə məqam var. Failover yeni bağlantını sağlam node-a göndərə bilər, amma mövcud TCP bağlantısını sehrli şəkildə o biri maşına köçürmür; client qırılmanı hiss etməli, yenidən qoşulmalı və sessiyanın itirdiyi məlumat üçün bərpa mexanizminə arxalanmalıdır. Yüksək availability ilə fasiləsiz sessiya eyni vəd deyil.

Fərq vacibdir.

Presence məlumatını axtarışdan ayırmaq

Online state sakit məlumat deyil. İstifadəçi tətbiqi açır, arxa plana keçir, bağlantısını itirir, qayıdır; bir hesab bir neçə cihazdan da qoşula bilər. Bu dəyişikliklərin hər birini əsas axtarış indeksinə yazmaq indeks replikasiyasını və sorğu davranışını lazımsız yerə bir-birinə bağlayardı.

Zoosk bunu ayrıca Online State Manager ilə həll etmişdi. Chat node-ları presence keçidini xüsusi XMPP packet-i kimi bu komponentə göndərirdi. Online State Manager isə Solr serverlərinin yanındakı ehcache nüsxələrini yeniləyirdi. Axtarış sorğusu gələndə sabit profil nəticələri cache-dəki cari online state ilə birləşdirilir, sonra filtr və ya sıralama tətbiq olunurdu.

Diaqram — orijinal məqalədə

Məlumat iki mənbədən gəlir: client bağlantısı və periodik profil indeksi. Client bağlantısı Tigase chat node-da presence keçidi yaradır, Online State Manager bu keçidi hər Solr node-unun yanındakı ehcache-ə yayır. Periodik profil indeksi ilə tez dəyişən state yalnız axtarış sorğusu zamanı görüşür, beləcə profil sənədinin indekslənmə tempi online göstəricinin təzələnmə tempini məhdudlaşdırmır.

Əvəzində eventual consistency yaranır. Gecikmə mümkündür. Cache yenilənməsi vaxtında çatmasa, axtarış nəticəsi istifadəçini qısa müddət online göstərə bilər. Dating məhsulunda bu, adətən qəbul edilən güzəştdir; chat mesajının itməsi isə deyil. Deməli, hər iki məlumat eyni real-time interfeysdə görünsə də, onlara eyni consistency tələbi qoymaq düzgün olmazdı.

Görünməz status ayrıca məhsul qaydasını ortaya çıxarır. İstifadəçi serverə bağlı qala və başqalarının presence məlumatını görə bilər, lakin özü onların siyahısında online görünməz. Buna görə connection state ilə public presence bir boolean sahəyə sıxışdırılmamalıdır. Biri infrastruktur faktıdır, digəri istifadəçiyə göstərilən vəziyyət və məxfilik qərarıdır.

Bildiriş yolu və davamlılıq sərhədi

Real-time hadisələrin hamısı chat serverində yaranmırdı. Məsələn, profilə baxış veb tətbiqdə baş verirdi. Tətbiq asinxron job başladır, job Tigase-ə custom payload-lı XMPP packet-i göndərir, Tigase də onu istifadəçinin aktiv client-inə yönləndirirdi. Client həmin packet-dən toast göstərmək və ya unread badge-i yeniləmək üçün istifadə edirdi.

Bu yanaşmada tətbiqin biznes hadisəsi ilə client bağlantısı arasında aydın sərhəd yaranır: veb tətbiq hansı socket-in hansı node-da olduğunu bilmir, routing işi RTC qatında qalır. Rahat bölgüdür. Lakin custom packet schema-sı versiyalanmasa, server və müxtəlif client buraxılışları arasında uyğunluq tez başağrısına çevrilə bilər. Payload-a versiya əlavə etmək, naməlum sahələri tolerant oxumaq və eyni hadisənin təkrar gəlməsini təhlükəsizliklə qarşılamaq belə sistemdə vacibdir.

Mesajın canlı çatdırılması onun davamlı saxlanması ilə eyni əməliyyat deyil. İstifadəçi online-dırsa packet dərhal client-ə gedə bilər, amma tarixçə üçün database yazısı ayrıca uğursuz ola bilər. Güclü məhsul tələbi varsa, server mesaj ID-si, deduplication və aydın delivery state saxlamalıdır. Yoxsa istifadəçi mesajı ekranda bir an görər, başqa cihazdan daxil olanda isə tapa bilməz.

Miqyaslama rəqəmdən çox bölünmə qərarıdır

Arxitektura çoxlu primary-secondary cütlüyünə bölünmüşdü və hər cütlük ayrıca bağlantı qrupu daşıyırdı. Bu, scale-out üçün rahat sərhəddir: yeni shard əlavə etmək olur, bir node-un yaddaş və socket yükü bütün sistemi sürükləmir, nasazlığın təsir sahəsi də həmin qrupla məhdudlaşır. Müasir Tigase cluster node-larını vahid platforma kimi birləşdirməyi, yükü yaymağı və redundancy yaratmağı dəstəkləyir.

Amma shard seçiminin cavabı ayrıca verilməlidir. İstifadəçi hər qoşulmada təsadüfi cluster-ə düşürsə, session routing və istifadəçilərarası mesajlaşma node-lar arasında əlavə koordinasiya tələb edir. Sabit hash bölgüsü koordinasiyanı azalda bilər, əvəzində node əlavə ediləndə paylanmanı dəyişir. Directory service daha çevikdir, özü kritik asılılığa çevrilir. Burada pulsuz seçim yoxdur.

Monitorinq də yalnız CPU və yaddaş qrafiki deyil. Socket qəbul edilir, amma presence stanza-sı keçmirsə sistem texniki baxımdan ayaqdadır, məhsul baxımından yox. Buna görə synthetic client-in login, presence və mesaj axınını başdan sona yoxlaması; queue ölçüsü, mesaj sayı, emal müddəti və aktiv bağlantı sayının ayrıca izlənməsi məntiqlidir. Qırılmanın istifadəçiyə necə göründüyünü ölçməyən dashboard çox rahat, amma natamam təsəllidir.

Zoosk nümunəsinin əsas dərsi XMPP seçimi deyil. Güclü tərəf connection state, public presence, davamlı mesaj, axtarış indeksi və tez dəyişən cache məlumatını ayrı məsuliyyətlər kimi görməkdir. Onların yenilənmə tempi və nasazlıq nəticəsi fərqlidir. Hamısını “real-time data” adlı bir qutuya yığanda sistem sadələşmir, yalnız sərhədlər gizlənir.

Tez-tez verilən suallar

Zoosk real-time rabitə üçün hansı protokoldan istifadə edirdi?

Sistem XMPP üzərində qurulmuşdu; mobil və desktop client-lər uzunömürlü TCP bağlantısı, brauzer client-ləri isə HTTP üzərindən BOSH istifadə edirdi.

Presence niyə birbaşa axtarış indeksində saxlanmırdı?

Online vəziyyət tez-tez dəyişdiyi üçün onu periodik yenilənən əsas indeksdən ayırmaq daha münasib idi. Sorğu zamanı axtarış nəticəsi ayrıca online-state cache-i ilə birləşdirilirdi.

İstifadəçi offline olanda mesaj nə olurdu?

Mesaj və bəzi bildirişlər server tərəfində saxlanılır, istifadəçi yenidən qoşulanda çatdırılırdı. Chat tarixçəsi üçün mesaj məzmunu ayrıca verilənlər bazasında qalırdı.

Mənbələr

Bu yazı süni intellekt köməyi ilə yazılıb, faktları və mənbələri yoxlanılıb.

Shopify flash sale zamanı yükü necə idarə edir?

Jamal Ali — Wed, 02 Sep 2026 20:43:33 +0000

Bir məhsul buraxılışı elan olunur, geri sayım bitir və minlərlə alıcı eyni saniyələrdə səhifəni yeniləyir. Bir qismi məhsula baxır, digərləri səbətə əlavə edir, ən bahalı qrup isə checkout və ödəniş axınına keçir. Flash sale zamanı sistemin dərdi trafik sayından çox onun formasıdır: yük qəfil gəlir və platformanın kiçik bir hissəsinə yığılır.

Shopify kimi çox mağazalı platformada vəziyyət daha incədir. Bir məşhur mağazanın kampaniyası həmin mağazanı yavaşlada bilər, amma başqa satıcıların biznesini özü ilə aparmamalıdır. Sistem dizaynının əsas sualı buna görə “neçə request qəbul edə bilərik?” deyil. Daha faydalı sual budur: “bir mağazanın qeyri-adi yükünü necə məhdudlaşdırıb alış axınını işlək saxlaya bilərik?”

Flash sale niyə sistemi fərqli sıxır?

Normal gündə baxış, axtarış və alış request-ləri vaxta və mağazalara yayılır. Flash sale isə yüzlərlə fərqli URL-ə bərabər paylanmış trafik yaratmır. Hamı eyni məhsulu istəyir. Keşlənən şəkil və CSS faylı ucuz başa gəlsə də, stok yoxlaması, səbətin dəyişdirilməsi, endirim hesablanması və sifarişin yazılması shared state üzərində işləyir.

Bu fərq capacity planlamada tez gözdən qaçır. Shopify-ın performans testləri haqqında texniki yazısında vurğulandığı kimi, bütün request-lər eyni xərcə malik deyil. Saniyədə yüz min statik fayl cavabı sistemin checkout-da saniyədə daha az sayda write əməliyyatına dözəcəyini sübut etmir. CPU boş görünə bilər, amma database connection pool, lock gözləməsi və ya üçüncü tərəf payment inteqrasiyası artıq boğulur.

Üstəlik, son məhsulu almağa çalışan istifadəçi uğursuz cavabdan sonra sakitcə getmir. Səhifəni yeniləyir, düyməni yenidən basır, mobil tətbiqi açır. Retry nəzarətsizdirsə, ilkin pikdən yaranan problem öz yükünü artıran dövrəyə çevrilir. Ona görə backpressure, timeout və idempotency checkout-un kənar bəzəyi deyil, pik anının əsas müdafiəsidir.

Məsələ burada qəlizləşir.

Sistem bütün request-ləri növbəyə qəbul edib gec də olsa cavablandırmağa çalışsa, queue böyüdükcə istifadəçinin gözləmə müddəti də artır. Client timeout verdikdən sonra görülən iş hətta faydasız ola bilər. Məhdud queue, erkən overload cavabı və exponential backoff sistemi bərpa oluna bilən vəziyyətdə saxlayır; gözləmə otağı isə alıcı axınını checkout-un real tutumuna uyğun tempə sala bilər. Bu tədbirlər satışın biznes qaydaları ilə razılaşdırılmalıdır, çünki texniki baxımdan sağlam throttle ədalətsiz məhsul bölgüsü yarada bilər.

Pod arxitekturası yükü platformadan ayırır

Shopify əvvəl database-i shard-lara bölərək üfüqi miqyaslama qazandı. Təkcə sharding yetərli deyildi: hər hansı shard-a bağlı əməliyyat bütün shard-ları gəzməli olsaydı, bir nasazlıq platforma səviyyəli problemə çevrilə bilərdi. Bunun qarşısını almaq üçün runtime pod-lara bölündü. Buradakı pod Kubernetes pod-u deyil; müəyyən mağazaları ayrıca datastore dəstində saxlayan izolyasiya vahididir.

Shopify-ın pod arxitekturasında hər web request və delayed job bir pod-a aid edilir. Load balancer qarşısındakı routing məntiqi mağazanı tapır, request-ə uyğun pod məlumatını əlavə edir və onu həmin istiqamətə göndərir. Application server də yalnız seçilmiş pod-un datastore-ları ilə işləyir.

Diaqram — orijinal məqalədə

Diaqramdakı sərhəd vacibdir. Məşhur mağaza Pod 1-də ağır yük yaradırsa, onun database vaxtını Pod 2-dəki mağazalarla birbaşa bölüşmür. App server və load balancer kimi bəzi resurslar ortaq qala bilər, lakin bir iş vahidi eyni anda pod-lar arasında gəzişmir. Bu, həm failure blast radius-u kiçildir, həm də yeni pod əlavə etməklə capacity-ni böyütməyə imkan verir.

İzolyasiya pulsuz gəlmir. Routing cədvəli düzgün və sürətli olmalı, background job da web request kimi mağaza kontekstini daşımalı, cross-pod əməliyyatlar isə dizayn səviyyəsində məhdudlaşdırılmalıdır. Əks halda shard var, amma nasazlıq sərhədi kağız üzərində qalır.

Oxuma yolunu ucuzlaşdırmaq, yazma yolunu qorumaq

Flash sale trafikinin böyük hissəsi əvvəlcə storefront-a dəyir. Statik asset-lərin CDN-dən verilməsi və təhlükəsiz oxuma cavablarının cache-də saxlanması origin yükünü azaldır. Lakin stok və qiymət kimi tez dəyişən məlumatı uzun müddət cache-də saxlamaq başqa problem yaradır: sürətli, amma köhnə cavab.

Burada məqsəd hər şeyi cache etmək deyil. Məhsul şəkli ilə “son ədəd qalıb” məlumatının freshness tələbi eyni ola bilməz. Oxuma yolunda qısa TTL, düzgün invalidation və sorğuların birləşdirilməsi origin-i qoruyur; sifariş yaradılan yazma yolunda isə correctness üstün tutulur. Eyni son vahidi iki alıcıya satmamaq üçün stok dəyişikliyi atomik qərar tələb edir.

Checkout da mümkün qədər dar saxlanmalıdır. Analytics, e-poçt və digər yan təsirlər sifarişin qəbul edilməsi üçün məcburi deyilsə, onları sinxron kritik yola yığmaq latency-ni və nasazlıq ehtimalını artırır. Queue bu işləri ayıra bilər, amma sifarişin özündə idempotency açarı lazımdır. İstifadəçi və ya gateway eyni əməliyyatı təkrarlayanda sistem ikinci sifariş yaratmamalıdır.

Queue isə sonsuz anbar deyil. Consumer-lər producer-lərdən uzun müddət geri qalırsa, “sifarişi qəbul etdik” cavabının arxasında saatlarla gecikən əməliyyatlar qala bilər. Queue depth, ən köhnə mesajın yaşı və consumer throughput birlikdə izlənməlidir. Kritik sifariş hadisələri ilə aşağı prioritetli analytics mesajlarını eyni növbədə saxlamaq da təhlükəlidir; ikinci qrupun sıçrayışı birinci qrupun gecikməsini artırmamalıdır.

Pik gün məşq edilmədən idarə olunmur

Capacity rəqəmi production-a yaxın workload olmadan az şey deyir. Bəzən heç nə demir. Load test məlum request səviyyəsinin müəyyən müddət saxlanmasını yoxlayır. Stress test isə yükü tədricən və ya qəfil artıraraq komponentin yuxarı həddini, doyma nöqtəsini, gecikmənin necə dəyişdiyini və hansı formada sıradan çıxdığını göstərir. Bunlar ayrı suallardır və Shopify hər ikisini istifadə edir.

Test trafikinin şəkli də production-a bənzəməlidir. Shopify-ın miqyaslı test prosesində flash sale üçün ayrıca axın var: storefront aktivliyi qəfil artır və simulyasiya edilən istifadəçilər eyni məhsulu almağa çalışırlar. Başqa axınlar gəzinmə, admin əməliyyatları və Storefront API trafikini təkrarlayır. Beləcə bir “orta request” rəqəmi müxtəlif bottleneck-ləri gizlətmir.

Sintetik test yenə production-un surəti deyil. Real istifadəçi retry edir, botlar fərqli davranır, payment provider gecikə bilər, cache hit nisbəti dəyişir. Buna görə testdən çıxan ən qiymətli məlumat rekord throughput yox, sistemin əyilməyə başladığı nöqtədir: hansı queue böyüyür, p95 latency nə vaxt sıçrayır, error budget harada sürətlə xərclənir və overload zamanı hansı funksiya əvvəl məhdudlaşdırılmalıdır.

Flash sale üçün dayanıqlı dizayn bir “sehrli” komponentdən yaranmır. Shopify nümunəsində əsas fikir qatların birlikdə işləməsidir: routing request-i doğru pod-a bağlayır, pod nasazlıq və yük sərhədi yaradır, cache bahalı oxumaları azaldır, checkout correctness qaydalarını qoruyur, performans testləri isə bütün bu fərziyyələri trafik gəlməzdən əvvəl sıxır.

Tez-tez verilən suallar

Flash sale adi yüksək trafikdən nə ilə fərqlənir?

Trafik qısa müddətdə kəskin artır, çoxlu alıcı eyni mağazaya, məhsula və checkout axınına yönəlir. Bu, orta yükü deyil, konkret resurslardakı sıxlığı kritik edir.

Shopify pod arxitekturasından niyə istifadə edir?

Pod mağazaların bir hissəsini ayrıca datastore dəsti daxilində saxlayır. Beləliklə, yük və nasazlıq bütün platformaya nəzarətsiz yayılmır.

Flash sale üçün yalnız load test kifayətdirmi?

Xeyr. Load test məlum hədəfi yoxlayır, stress test isə sistemin yuxarı həddini və dağılma formasını göstərir. Real trafik forması və bahalı endpoint-lər də sınaqda təkrarlanmalıdır.

Mənbələr

Bu yazı süni intellekt köməyi ilə yazılıb, faktları və mənbələri yoxlanılıb.

Açıq cloud API vendor lock-in problemini həll edirmi?

Jamal Ali — Sat, 29 Aug 2026 22:39:57 +0000

Cloud provayderinin API-ni açması ilk baxışda çox cəlbedici vəd verir: infrastrukturu kodla idarə et, istənilən alətdən qoşul, lazım gələndə də başqa yerə keç. İlk iki hissə doğrudur. Üçüncüsü isə bu qədər rahat deyil.

Açıq cloud API xidmətlə danışığın qaydasını görünən edir. Hansı request göndərilir, hansı sahələr tələb olunur, cavab və xəta necə görünür, bunları bilmək üçün provayderin daxili koduna ehtiyac qalmır. OpenAPI Specification də HTTP API-ləri proqramlaşdırma dilindən asılı olmayan təsvirlə insan və proqram üçün anlaşılan etməyə xidmət edir. Bu, client generatoru, test, sənədləşmə və üçüncü tərəf alətləri üçün möhkəm başlanğıcdır.

Amma açıq olmaqla eyni olmaq ayrı şeylərdir. İki provayder API sənədini hamıya göstərə bilər, hər ikisi virtual maşın yaratmağa imkan verər, yenə də image formatı, şəbəkə modeli, disk snapshot-ı, rol sistemi və xəta davranışı bir-birinə uyğun gəlməz. Müqaviləni oxumaq mümkündür, müqavilələr isə fərqlidir.

Açıq API əslində nəyi açır?

API müqaviləsi dörd əsas sualı cavablandırır: hansı əməliyyat mövcuddur, giriş məlumatı nədir, uğurlu cavab necə görünür və xəta hansı formada qaytarılır. Maşın tərəfindən oxunan təsvir bu müqaviləni alətlər üçün də işlək edir. İş bununla bitmir. OpenAPI HTTP endpoint-lərini, parametrləri, request və response strukturunu ifadə edir; spesifikasiya mənbə koduna və şəbəkə trafikini əl ilə araşdırmağa ehtiyac olmadan servisin imkanlarını anlamağı hədəfləyir.

Bu səviyyədə açıqlıq real fayda verir. Provayderin öz SDK-sı yeganə giriş qapısı olmur. Komanda öz client-ini yarada, müqavilə testləri qura, dəyişiklikləri diff edə və idarəetməni mövcud automation alətlərinə bağlaya bilər. API versiyası və deprecation qaydası aydın yazılıbsa, upgrade zamanı sürpriz də azalır.

Lakin API təsviri servisin davranışını tam standartlaşdırmır. Eyni adlı createServer əməliyyatı bir sistemdə saniyələr içində hazır resurs qaytara, digərində isə sonradan izlənməli asinxron job yarada bilər. Rate limit, eventual consistency, retry təhlükəsizliyi və kvota modeli sxemdə qismən görünür, bəzən heç görünmür. Burada məsələ qəlizləşir: sintaksis uyğun olsa da semantika fərqli qala bilər.

Portativlik bir neçə qatın birlikdə işləməsidir

Tətbiqi daşımaq üçün təkcə API çağırışlarını dəyişmək kifayət etsəydi, migration layihələri xeyli darıxdırıcı olardı. Əsl yük aşağı qatlarda üzə çıxır. Tətbiqin topologiyası, komponentlər arasındakı əlaqələr, deployment artifact-ları və lifecycle əməliyyatları da təsvir olunmalıdır. TOSCA 2.0 məhz komponentləri, onların əlaqələrini və yaradılma ilə dəyişdirilmə prosedurlarını service topology və orchestration vasitəsilə ifadə edir.

Aşağıdakı sxemdə açıq API yalnız üst qapıdır. Request adapterdən keçib provayderin resurs modelinə çevrilir; workload həmin resurslarda işləyir, data isə ayrıca köçürülür. Identity və observability bütün bu axına toxunur. Buna görə hər yolun ortaq portability testindən keçməsi lazımdır.

Diaqram — orijinal məqalədə

Provayder adapteri ortaq daxili model ilə konkret cloud API-si arasındakı tərcümə qatıdır. Compute, şəbəkə və storage modeli resursların nə demək olduğunu müəyyən edir. Workload və lifecycle hissəsi deploy, scale, patch və shutdown kimi əməliyyatları əhatə edir. Data ixracı və idxalı vəziyyətin yeni mühitə aparılmasıdır; identity rol və icazələrin, observability isə log, metric və tracing axınının yenidən qurulmasını tələb edir. Portability testi bunları birlikdə sınamırsa, kağız üzərindəki uyğunluq production keçidini sübut etmir.

TOSCA-nın model-driven yanaşması da bu boşluğu hədəfləyir: modeldəki dependency, connection və composition məlumatı avtomatlaşdırılmış prosesləri idarə edə bilir. Üstəlik CSAR adlı arxiv formatı service template ilə deployment və implementation artifact-larını eyni konteynerdə daşımağa imkan verir. Bu, hər cloud-un eyni davranacağı demək deyil. Standart təsvir olunan hissəni portativ edir; tətbiqin içindəki provayderə məxsus komponent ayrıca həll tələb edir.

Vendor lock-in harada qalır?

Ən görünən bağlılıq xüsusi API əməliyyatıdır. Məsələn, tətbiq yalnız bir provayderdə olan managed database funksiyasına söykənirsə, adapter yazmaq həmin funksiyanın alternativini yaratmır. Daha sakit bağlılıqlar da var: böyük həcmdə datanın çıxarılma vaxtı və qiyməti, IAM siyasətlərinin fərqli semantikası, region topologiyası, secret idarəetməsi, metric adları və incident zamanı komandanın istifadə etdiyi runbook-lar.

Lock-in həmişə pis qərar deyil. Provayderə məxsus servis daha az əməliyyat yükü, daha yaxşı latency və sürətli məhsul inkişafı verə bilər. Bağlılığı görməmək səhvdir. Həm də bahalı. Komanda qazancı ölçüb çıxış planının xərcini qəbul edirsə, bu şüurlu trade-off-dur; yalnız API açıqdır deyə çıxışın pulsuz olduğunu düşünürsə, hesab yarımçıqdır.

API-nin lisenziyası da ayrıca məsələdir. Spesifikasiyanı oxumaq və client yaratmaq hüququ vacibdir, amma uyğun alternativ implementasiyanın bazarda mövcud olacağına zəmanət vermir. Kağız üzərində tam açıq interfeys ola bilər, onu eyni semantika ilə təqdim edən ikinci servis isə olmaya bilər. Bu halda hüquqi və texniki açıqlıq var, praktik çıxış yolu yoxdur.

Fərq məhz budur.

Ortaq abstraction qatının da qiyməti var. Bütün cloud-ları ən kiçik ortaq məxrəcə salanda fərqləndirici imkanlar itir. Həddindən artıq ümumi model isə xüsusi hallarla dolur və bir müddət sonra öz kiçik cloud platformanıza çevrilir. Adətən daha sağlam sərhəd tətbiqin istifadə etdiyi dar imkan dəstini abstraktlaşdırmaq, provayderə məxsus optimizasiyaları isə açıq şəkildə adapterin arxasında saxlamaqdır.

Portativliyi necə sınaqdan keçirmək olar?

Yaxşı ölçü “ikinci provayder üçün kodumuz var” deyil. Eyni workload təmiz mühitdə qurula, lazımi data bərpa oluna, identity siyasətləri tətbiq edilə və observability siqnalları görünə bilirmi? Failover və rollback işləyirmi? Bunlar müntəzəm sınaqdan keçmirsə, alternativ deployment çox vaxt köhnəlmiş YAML və nikbin wiki səhifəsindən ibarət qalır.

API contract testləri request və response uyğunluğunu yoxlayır. Integration testləri adapterin real provayder davranışını tutmalıdır. Sonra data restore testi, icazə testi və əməliyyat ssenariləri gəlir. TOSCA service lifecycle idarəetməsini yaradılma ilə məhdudlaşdırmır; model deploy-dan sonrakı dəyişiklikləri də ifadə edir. Portativlik də yalnız ilk deployment anı deyil, scale, patch, monitor və dayandırma kimi bütün ömür dövründə qorunmalıdır.

Belə sınağın tezliyi biznesin həssaslığından asılıdır. İldə bir dəfə masa arxasında sənədə baxmaqla canlı migration məşqi eyni sübut deyil. Kritik sistemdə müvəqqəti ikinci mühit qurmaq baha görünə bilər, amma DNS keçidi, sertifikatlar, queue-da qalan mesajlar və write zamanı yaranan data fərqi yalnız real axında üzə çıxır. Daha az kritik workload üçün isə periodik restore və smoke test kifayət edə bilər. Məqsəd multi-cloud nişanı toplamaq yox, qəbul edilmiş bərpa müddətinin texniki olaraq mümkün olduğunu görməkdir.

Açıq cloud API buna görə son həll yox, yoxlanıla bilən sərhəddir. O, qapını və qapının dilini göstərir. Qapıdan keçəndən sonra resurs semantikası, data, identity və əməliyyat vərdişləri hələ də sizinlə gəlməlidir.

Tez-tez verilən suallar

Açıq API istifadə etmək vendor lock-in-i aradan qaldırır?

Xeyr. Açıq müqavilə inteqrasiyanı və alternativ client yazmağı asanlaşdırır, lakin resurs semantikası, data köçürməsi, identifikasiya və əməliyyat davranışı yenə provayderə bağlı qala bilər.

OpenAPI ilə cloud API eyni şeydir?

Xeyr. Cloud API xidməti idarə edən interfeysdir, OpenAPI isə HTTP API-nin əməliyyatlarını və strukturunu maşın tərəfindən oxuna bilən formada təsvir edən standartdır.

Multi-cloud üçün bütün provayderləri ortaq interfeys arxasında gizlətmək lazımdır?

Yalnız tətbiqin həqiqətən istifadə etdiyi sabit imkanlar üçün. Ən kiçik ortaq məxrəc yanaşması provayderlərin faydalı fərqli imkanlarını gizlədə və mürəkkəbliyi adapter qatına daşıya bilər.

Mənbələr

Bu yazı süni intellekt köməyi ilə yazılıb, faktları və mənbələri yoxlanılıb.

HTTP cache header-larını düzgün qurmaq

Jamal Ali — Sat, 29 Aug 2026 12:47:48 +0000

HTTP keşini “sürət düyməsi” kimi təsəvvür etmək rahatdır: max-age əlavə et, server yükü azalsın, səhifə də sürətlənsin. Problem ondadır ki, keş yanlış cavabı çox səmərəli şəkildə çoxalda da bilir. Bir istifadəçinin məlumatı başqasına görünəndə və ya köhnə HTML yeni JavaScript bundle-a işarə etməyəndə qazandığımız bir neçə millisaniyə artıq təsəlli vermir.

Fərq vacibdir.

Düzgün siyasət header adlarını əzbərləməklə qurulmur. Əvvəl hər resurs üçün üç suala cavab lazımdır: cavab nə qədər müddət dəyişmədən qala bilər, onu kimlər paylaşa bilər və köhnələndə origin serverlə yoxlanmalıdırmı? Üç sual. Qalan seçimlər onların cavabından çıxır.

Keşin iki ayrı işi var

HTTP cache cavabı saxlaya və sonrakı uyğun request-də yenidən istifadə edə bilər. Browser cache adətən bir istifadəçiyə xidmət edən private cache-dir. CDN və reverse proxy isə bir cavabı çox istifadəçiyə verən shared cache rolundadır. Eyni Cache-Control sətri hər ikisinə təsir edə bilər, amma onların riskləri eyni deyil.

Burada iki anlayış tez-tez qarışır: freshness və validation. Fresh cavabın müəyyən edilmiş ömrü hələ bitməyib, ona görə cache origin-ə getmədən onu işlədə bilər. Stale cavabın ömrü bitib. Bu, cavabın mütləq yararsız olması demək deyil; validator varsa cache kiçik conditional request göndərib nüsxəsinin hələ aktual olub-olmadığını soruşa bilər. RFC 9111 HTTP cache davranışını məhz saxlama, freshness və validation qaydaları üzərindən müəyyənləşdirir.

max-age=300 cavabın yaradıldığı və ya son uğurlu validation edildiyi andan beş dəqiqə sonra stale sayılacağını bildirir. Beş dəqiqə ərzində cache hit origin-ə request göndərməyə bilər. Bu müddəti yalnız trafikə baxıb seçmək yarımçıq yanaşmadır, çünki əsas ölçü biznesin həmin cavabın köhnəlməsinə nə qədər dözə bilməsi və yanlış məlumatın hansı əməliyyata təsir göstərməsidir.

Cache-Control: public, max-age=300

public cavabı açıq şəkildə cacheable edir və shared cache üçün də istifadəyə imkan yaradır. Hər public resursa bu direktivi əlavə etmək məcburi deyil, çünki bəzi cavablar onsuz da cacheable olur; API və CDN konfiqurasiyasında niyyəti aydın göstərmək isə yenə faydalıdır.

no-cache, no-store və private eyni şey deyil

Adına görə ən çox çaşdıran direktiv no-cache-dir. Cavabı saxlamağı qadağan etmir. Cache saxlanmış cavabı yenidən verməzdən əvvəl origin serverdə uğurla validate etməlidir. Bu, tez-tez dəyişən HTML üçün yaxşı seçim ola bilər: browser nüsxəni saxlayır, ETag ilə soruşur, məzmun dəyişməyibsə server body əvəzinə 304 Not Modified qaytarır.

Cache-Control: no-cache
ETag: "page-v42"

ETag cavab variantının identifikatorudur. Növbəti request If-None-Match header-ı ilə gedir. Serverdə təqdimat eynidirsə bütün body yenidən daşınmır, amma network gediş-gəlişi qalır; deməli validation bandwidth-i azalda bilər, latency-ni sıfırlamır.

no-store daha sərtdir: cache request və response-u saxlamamalı, həmin response-u başqa request-i cavablandırmaq üçün istifadə etməməlidir. Bank çıxarışı, birdəfəlik token və həssas şəxsi məlumat kimi cavablarda məntiqlidir. Bununla belə, no-store şifrələmə və access control əvəzi deyil, komprometasiya edilmiş cache və ya şəbəkədə dinləmə riskini bu header təkbaşına həll etmir.

private başqa sərhəd çəkir. Shared cache cavabı saxlamır, istifadəçinin private cache-i isə digər şərtlər imkan verirsə saxlaya bilər. Login olmuş istifadəçinin profil səhifəsi dəyişməz deyil, amma hər naviqasiyada bütün body-ni yenidən daşımaq da lazım olmaya bilər:

Cache-Control: private, no-cache
ETag: "profile-8d91"

Bu kombinasiya browser-ə cavabı saxlamağa, hər istifadədən əvvəl isə yoxlamağa imkan verir. Təkcə Set-Cookie görüb response-un cache edilməyəcəyini düşünmək təhlükəlidir, çünki Set-Cookie özü caching-i dayandırmır və siyasət Cache-Control ilə açıq yazılmalıdır.

Browser və CDN üçün ayrı ömür

Bəzən browser-in cavabı qısa müddət saxlaması, CDN-in isə daha uzun saxlaması məqsədəuyğundur. s-maxage yalnız shared cache üçün maksimum yaşı müəyyən edir və həmin cache-də max-age və Expires dəyərini üstələyir.

Cache-Control: public, max-age=60, s-maxage=600

Bu nümunədə browser bir dəqiqəlik freshness görür, CDN isə cavabı on dəqiqə fresh saya bilər. Risk də böyüyür. Daha uzun CDN ömrü bütün istifadəçilərə köhnə məlumat yayır, buna görə endpoint-in cavabı regiona, dilə və ya başqa request header-ına görə dəyişirsə cache key həmin fərqi mütləq bilməlidir.

Vary: Accept-Encoding cache-ə sıxılma variantlarını ayırmağı deyir. Vary: Accept-Language dilə görə ayrıca variant yaradır. Vary-də göstərilən request header-ları uyğun gəlmirsə saxlanmış cavab yoxlanmadan istifadə edilə bilməz. Hər şeyi Vary-yə əlavə etmək çıxış yolu deyil, variantların sayı artdıqca hit ratio düşür, cache-in faydası əriyir və xüsusən Vary: User-Agent çox geniş kombinasiya yarada bilər.

İstifadəçiyə görə dəyişən cavabı shared cache-də saxlamaq istəyərkən məsələ daha qəlizdir. Cache key həqiqətən istifadəçini ayırmırsa, public və uzun s-maxage təhlükəli seçimdir. Belə cavabı private saxlamaq və ya public hissə ilə fərdi hissəni ayrı endpoint-lərə bölmək daha aydın sərhəd yaradır.

Statik asset və HTML fərqli ömür istəyir

Content hash daşıyan app.a81f3c.js faylının məzmunu dəyişəndə adı da dəyişir. Bu tip immutable asset üçün uzun freshness uyğundur:

Cache-Control: public, max-age=31536000, immutable

Köhnə faylı zorla invalidasiya etməyə ehtiyac qalmır. Yeni deploy yeni URL yaradır, HTML də həmin URL-ə işarə edir. Amma hash daşımayan /app.js üçün eyni birillik siyasət deploy-dan sonra köhnə kodun uzun müddət qalmasına səbəb ola bilər; cache busting query parametrindən istifadə edilirsə parametr hər məzmun dəyişikliyində sabit qayda ilə dəyişməlidir.

HTML isə adətən qısa freshness və ya validation istəyir, çünki yeni asset ünvanlarını o daşıyır. HTML uzun müddət köhnə qalsa, serverdə artıq silinmiş bundle-a request gedə bilər. Release prosesi köhnə asset-ləri bir müddət saxlamaqla bu keçidi yumşalda bilər, lakin əsas siyasət yenə resursların dəyişmə modelinə uyğun olmalıdır.

Expires eyni məqsəd üçün tarix verir, amma max-age olduqda recipient Expires-ı nəzərə almır. Müasir konfiqurasiyada nisbi saniyə dəyəri deploy və saat fərqləri baxımından daha rahatdır. Header ümumiyyətlə verilməyəndə bəzi cache-lər heuristic freshness hesablaya bilər; davranışı infrastruktura buraxmaqdansa niyyəti açıq yazmaq daha proqnozlaşdırılandır.

Siyasəti production-da görmək

Konfiqurasiya faylında düzgün görünən header yolun sonunda dəyişə bilər. CDN qaydası origin header-ını əvəz edir, framework middleware-i yalnız bəzi status kodlarına işləyir, reverse proxy isə Vary sahəsini itirir. Ona görə yoxlama browser devtools ilə bitmir. Origin və CDN cavabları ayrıca izlənir, Age, Cache-Control, ETag, Vary və status kodu birlikdə oxunur.

Age shared cache-də cavabın təxmini yaşını saniyə ilə göstərir. Ardıcıl request-lərdə artması cavabın origin-dən yox, aradakı cache-dən gəldiyinə işarə edə bilər. Validation baş verəndə 304, fresh hit zamanı isə çox vaxt normal status və cache vendor-una aid əlavə hit header-ı görünür.

Keş siyasəti endpoint növünə görə sənədləşdiriləndə dəyişikliklər də təhlükəsiz olur: hashed asset uzunömürlüdür, HTML validate edilir, public kataloq cavabı qısa müddət shared cache-də qalır, şəxsi məlumat isə shared cache-dən uzaq tutulur. Eyni universal header daha az konfiqurasiya kimi görünür. Sonradan açdığı başağrısı isə xeyli universaldır.

Tez-tez verilən suallar

no-cache cavabın saxlanmasını qadağan edirmi?

Xeyr. no-cache cavabın sonrakı request üçün istifadə edilməzdən əvvəl origin serverdə uğurla yoxlanmasını tələb edir.

no-store ilə private arasında fərq nədir?

no-store cavabın cache-də saxlanmasını qadağan edir. private isə shared cache-i kənarda saxlayır, amma istifadəçinin browser cache-inə saxlamağa icazə verə bilər.

Dəyişməz statik fayllara uzun max-age vermək təhlükəlidirmi?

Faylın URL-i content hash və ya versiya daşıyırsa təhlükə xeyli azalır, çünki məzmun dəyişəndə URL də dəyişir. Eyni URL altında məzmun dəyişəcəksə uzun ömür uyğun deyil.

Mənbələr

Bu yazı süni intellekt köməyi ilə yazılıb, faktları və mənbələri yoxlanılıb.

Cisco ACE load balancer-i idarə edərkən nəyə baxmaq lazımdır?

Jamal Ali — Sat, 29 Aug 2026 09:34:53 +0000

Cisco ACE ilə işləyən administratorun qarşısında qəribə vəziyyət dayanır: cihaz zəngin funksiyalara malikdir, trafik yolunun tam ortasındadır, amma özü artıq keçmiş nəsil platformadır. Buna görə konfiqurasiyaya yalnız “request hansı serverə getsin?” sualı ilə baxmaq kifayət etmir. Tətbiqin sağlamlığı, session davranışı, SSL sərhədi və cihaz sıradan çıxanda baş verəcək hadisələr eyni xəritədə görünməlidir.

Problem də budur.

ACE 4710 ayrıca appliance kimi, ACE modulları isə şəbəkə avadanlığının daxilində application delivery funksiyası verirdi. Cisco bu iki məhsulu data center üçün load balancing və application delivery həlli kimi təsvir edir. Bu sinif cihaz client ilə backend arasında reverse proxy və ya Layer 4 load balancer rolunda dayanır; client virtual IP-yə qoşulur, ACE uyğun server farm-ı tapır, işlək real server seçir və bağlantını ora ötürür. Kağız üzərində sadədir. Production-da isə hər oxun öz state-i və nasazlıq ssenarisi var.

Trafik ACE-dən necə keçir?

Konfiqurasiyanı oxumağın rahat yolu ayrı-ayrı komandaları əzbərləmək deyil, obyektlər arasındakı yolu izləməkdir. Virtual IP xidmətin xarici ünvanıdır. Class map trafiki tanıyır, policy map həmin trafikə load balancing davranışı bağlayır, server farm backend hovuzunu saxlayır, real server isə konkret tətbiq instansiyasıdır. Health probe real serverin rotasiyada qalıb-qalmayacağına qərar verir.

Diaqram — orijinal məqalədə

Bu axında class map və policy map giriş trafikinin hansı xidmətə aid olduğunu müəyyən edir. Server farm seçildikdən sonra predictor işlək real serverlər arasından birini seçir. Cavab client-ə ACE üzərindən qayıdırsa, cihaz connection state-i saxlayır; asimmetrik routing yaranarsa paketlərin bir hissəsi bu state-dən yan keçə və bağlantı qırıla bilər. Deməli, routing dizaynı load balancer konfiqurasiyasından ayrı məsələ deyil.

Predictor serverin həqiqi yükünü həmişə bilmir

ACE-də round-robin və least connections davranışları fərqli məqsədlərə xidmət edir. Weighted round-robin standart predictor-dur. Weight böyükdürsə, server daha çox yeni bağlantı alır; eyni gücdə və oxşar workload daşıyan backend-lər üçün bu, proqnozlaşdırılması asan seçimdir.

Least connections açıq bağlantısı daha az olan serverə üstünlük verir. Uzunömürlü bağlantılar və qeyri-bərabər request müddətləri olan sistemdə bu, faydalı görünür, amma connection sayı CPU, yaddaş və ya queue dərinliyi deyil. On min yüngül keep-alive bağlantısı bəzən yüz ağır hesablama request-indən ucuz başa gəlir. Siqnal natamamdır.

Yeni serveri bir anda tam trafikə salmaq da yaxşı fikir deyil. ACE-nin least-connections predictor-u üçün slow start mexanizmi yeni real serverə əvvəlcə az bağlantı göndərir, sonra yükü tədricən artırır. Bu, cache-i soyuq olan və ya connection pool-u yenicə qurulan instansiyanın ilk saniyələrdə boğulmasının qarşısını ala bilər.

Hash əsaslı seçim başqa ehtiyacı həll edir. ACE ünvan, cookie, HTTP header və URL əsasında server seçə bilir. Müəyyən açar eyni backend-ə düşür. Açarlar bərabər paylanmırsa isə serverlərdən biri həddindən artıq yüklənə bilər, buna görə qərarı alqoritmin adı yox, tətbiqin real trafik forması müəyyən edir.

Health probe port yoxlamasından artıq olmalıdır

Probe-un işi backend-in trafik qəbul edib-etmədiyini müəyyənləşdirməkdir. ACE ICMP, TCP, HTTP, HTTPS, DNS və başqa yoxlama növləri ilə konfiqurasiya oluna bilir. TCP probe portun bağlantı qəbul etdiyini göstərir, daha artığını yox. Tətbiq database-ə çata bilmirsə və bütün request-lərə xəta qaytarırsa, açıq portun çox təsəllisi yoxdur.

HTTP probe üçün ayrıca, ucuz health endpoint seçmək daha düzgün siqnal verir. Endpoint tətbiqin trafik qəbul edə bildiyini yoxlamalıdır, amma hər probe-da bütün asılılıqlara ağır sorğu göndərməməlidir. Interval həddən artıq qısa, uğursuzluq həddi isə çox sərt seçiləndə qısa şəbəkə titrəyişi serverləri növbə ilə rotasiyadan çıxara bilər. Bu dəfə load balancer problemi azaltmır, özü trafik dalğası yaradır.

Server probe-dan keçməyəndə mövcud bağlantıların taleyi əvvəlcədən məlum olmalıdır. Yeni bağlantıları dayandırmaqla aktiv connection-ları dərhal sıfırlamaq eyni davranış deyil. Fərq böyükdür. Uzun download, WebSocket və ya stateful transaction daşıyan sistemdə istifadəçi bunu dərhal görür; nasazlıq testi buna görə backend-i söndürüb bir yeni request yoxlamaqla bitməməli, aktiv bağlantını, bərpanı və serverin yenidən rotasiyaya qoşulmasını da əhatə etməlidir.

Stickiness rahatlıq verir, sonra hesabını istəyir

ACE eyni client-in sonrakı bağlantılarını eyni real serverə bağlamaq üçün source IP, cookie, HTTP header və SSL session ID kimi stickiness üsullarını dəstəkləyir. Lokal yaddaşda session saxlayan köhnə tətbiq üçün bu, zəruri ola bilər; backend dəyişəndə istifadəçi login vəziyyətini itirmir.

Amma source IP stickiness NAT arxasındakı minlərlə istifadəçini bir serverə yığa bilər. Cookie əsaslı üsul daha dəqiqdir, bunun müqabilində cookie-nin müddəti, adı və təhlükəsizlik atributları idarə olunmalıdır. Server rotasiyadan çıxanda sticky qeydin hara yönələcəyi də ayrıca failover qərarıdır. Stateless tətbiq və ortaq session store mümkündürsə, load balancer-də yığılan bu gizli state-dən qurtulmaq sistemi xeyli sadələşdirir.

SSL termination tətbiq serverlərindən kriptoqrafik işi götürür və HTTP səviyyəli routing imkanı açır. RFC 7098 SSL reverse proxy-nin session boyu SSL, TCP və bəzən HTTP state-i saxladığını qeyd edir. State artır. Bunun əvəzində sertifikatın yenilənməsi, private key-in qorunması, cipher siyasəti və ACE-dən backend-ə gedən trafikin şifrələnib-şifrələnməməsi cihazın məsuliyyətinə çevrilir; load balancer trafik paylayan qutu olmaqdan çıxıb təhlükəsizlik sərhədinə çevrilir.

Əsas risk artıq cihazın yaşıdır

Cisco ACE üçün köhnəlmə nəzəri risk deyil. ACE ailəsi artıq retired və dəstəksiz platformadır. Üstəlik, CVE-2016-6399 qeydində ACE30 və ACE 4700 cihazlarında xüsusi SSL və ya TLS paketləri ilə uzaqdan denial-of-service yaradıb cihazı reload etməyin mümkün olduğu göstərilir. Bu ciddi fərqdir. İşlək cihaz dəstəklənən cihaz demək deyil.

Legacy ACE saxlanılırsa, inventarda yalnız model və IP ünvanı olmamalıdır. Software versiyası, konfiqurasiya backup-ı, lisenziyalar, sertifikatlar, ehtiyat cihaz, failover nəticəsi və cihazı əvəz edə biləcək platformaya keçid planı birlikdə sənədləşdirilməlidir. Xüsusilə SSL termination aktivdirsə, dəstəklənməyən proqram təminatını internet trafikinin qarşısında saxlamaq təhlükəsizlik riskini böyüdür.

Miqrasiyada ən asan hissə virtual IP yaratmaqdır. Çətin hissə illər ərzində yığılmış sticky qaydalarını, probe davranışını, timeout-ları, NAT siyasətini, SSL sertifikatlarını və qeyri-adi routing asılılıqlarını tapmaqdır. Mövcud konfiqurasiya obyekt-obyekt deyil, xidmət-xidmət xəritələnəndə boşluqlar daha tez görünür: hansı client gəlir, hansı qayda işə düşür, hansı backend seçilir, cavab hansı yolla qayıdır və nasazlıq zamanı aktiv bağlantı necə bağlanır.

Cisco ACE-ni idarə etmək bu gün daha çox legacy sistem mühəndisliyidir. Cihazın predictor və probe imkanları hələ də load balancing məntiqini öyrətmək üçün yaxşı modeldir, amma production qərarında əsas ölçü funksiyaların sayı yox, təhlükəsiz yenilənmə və bərpa imkanının qalıb-qalmamasıdır.

Tez-tez verilən suallar

Cisco ACE hələ production mühitində istifadə oluna bilərmi?

Texniki olaraq işlək cihaz mövcud trafiki daşıya bilər, lakin platforma rəsmi dəstəkdən çıxıb. Təhlükəsizlik yeniləmələri, ehtiyat hissə, vendor dəstəyi və bərpa müddəti nəzərə alınmadan onu production-da saxlamaq ciddi əməliyyat riskidir.

Round-robin ilə least connections arasında fərq nədir?

Round-robin yeni bağlantıları serverlər arasında növbə ilə paylayır. Least connections isə mövcud açıq bağlantı sayını nəzərə alaraq daha az bağlantısı olan serverə üstünlük verir.

Stickiness nə vaxt lazımdır?

Tətbiq session vəziyyətini yalnız lokal yaddaşda saxlayırsa, eyni istifadəçinin ardıcıl bağlantılarını eyni backend-ə yönəltmək lazım gələ bilər. Stateless tətbiqdə isə stickiness çox vaxt yükün qeyri-bərabər paylanmasına səbəb olur.

Mənbələr

Bu yazı süni intellekt köməyi ilə yazılıb, faktları və mənbələri yoxlanılıb.