DEV Community: Jamal Ali

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.