+994512060920
Böyük kampaniya başlayır. Reklam işləyir, sosial şəbəkələrdə paylaşımlar gedir, trafik qəfil artır. İlk yarım saat hər şey əla görünür, sonra səhifələr yavaşlayır, ardınca sayt tamam açılmır. Komanda serveri yenidən başladır, bir az işləyir, sonra yenə çökür. Kampaniya büdcəsi isə xərclənməkdə davam edir.
Bu ssenari çox tanışdır. Səbəb çox vaxt kodda yox, bütün sorğuların tək serverə yönəlməsindədir. Load balancer bu problemi həll edən əsas alətlərdən biridir. Bu yazıda onun nə olduğunu, necə işlədiyini və kiçik biznesin də bunu necə sadə şəkildə tətbiq edə biləcəyini izah edəcəyik.
Load Balancer Nədir?
Load balancer gələn sorğuları bir neçə serverin arasında bölüşdürən sistemdir. İstifadəçi saytınıza daxil olanda sorğu birbaşa serverə getmir, əvvəlcə load balancer-ə çatır. O isə sorğunu o anda ən uyğun serverə yönləndirir.
Bunu supermarketdəki kassa növbəsi ilə müqayisə etmək olar. Əgər yalnız bir kassa işləyirsə, hamı onun qarşısında növbəyə dayanır və növbə uzanır. Əgər beş kassa işləyirsə və giriş qapısında bir nəfər müştəriləri boş kassaya yönləndirirsə, növbə qısa qalır. Həmin nəfər load balancer-dir.
Sayt Trafik Artanda Niyə Çökür?
Tək server sistemində hər şey bir maşının üzərinə düşür. Bunun bir neçə nəticəsi var:
- Resurs həddi: Server eyni anda yalnız müəyyən sayda sorğunu emal edə bilir. Limit aşıldıqda yeni sorğular gözləməyə başlayır, sonra rədd edilir.
- Tək nöqtə riski: Server hər hansı səbəbdən dayanarsa, sayt tamamilə əlçatmaz olur. Ehtiyat yoxdur.
- Zəncirvari effekt: Yavaşlayan server sorğuları daha da uzun saxlayır, bu da növbəni artırır və vəziyyəti pisləşdirir.
- Yenilənmə problemi: Tək serveri yenidən başlatmaq və ya yeniləmək üçün saytı dayandırmaq lazım gəlir.
Yəni problem sadəcə "güc çatmır" deyil. Sistem bir nöqtəyə bağlıdır və bu nöqtə yüklənməni də, nasazlığı da tək başına daşımalıdır.
Load Balancer Necə İşləyir?
- İstifadəçi saytın ünvanına daxil olur.
- Sorğu load balancer-ə çatır.
- Load balancer işləyən serverlərin siyahısına baxır.
- Müəyyən qaydaya görə ən uyğun serveri seçir.
- Sorğunu həmin serverə ötürür.
- Server cavabı hazırlayır, istifadəçiyə qayıdır.
Bundan əlavə load balancer serverlərin sağlamlığını müntəzəm yoxlayır (health check). Server cavab vermirsə, onu siyahıdan müvəqqəti çıxarır və sorğuları yalnız sağlam serverlərə göndərir. İstifadəçi bunu hiss etmir.
Trafik Bölgüsü Üsulları
Load balancer sorğunu hansı serverə göndərəcəyini bir neçə qaydaya görə seçə bilər:
| Üsul | Necə işləyir | Nə vaxt uyğundur |
|---|---|---|
| Round Robin | Sorğular növbə ilə serverlərə göndərilir: birinci, ikinci, üçüncü, yenidən birinci | Serverlər eyni gücdədir və sorğular təxminən eyni ağırlıqdadır |
| Least Connections | Sorğu o anda ən az aktiv bağlantısı olan serverə göndərilir | Sorğuların uzunluğu fərqlidir |
| Weighted | Güclü serverə daha çox, zəif serverə daha az sorğu verilir | Serverlərin gücü eyni deyil |
| IP Hash | İstifadəçinin IP ünvanına görə həmişə eyni serverə yönləndirilir | İstifadəçinin eyni serverə bağlı qalması lazımdır |
Başlanğıc üçün Round Robin və ya Least Connections çox vaxt kifayət edir. Daha mürəkkəb qaydalar sistem böyüdükcə lazım olur.
Load Balancer-in Əsas Üstünlükləri
- Yük bölünür: Heç bir server tək başına ağırlığı daşımır.
- Davamlılıq artır: Bir server dayansa, digərləri işləməyə davam edir.
- Genişlənmək asanlaşır: Trafik artanda yeni server əlavə etmək kifayətdir, sayt dayandırılmır.
- Dayanmadan yeniləmə: Serverləri növbə ilə yeniləmək olar, istifadəçi fərq etmir.
- Təhlükəsizlik üçün əlavə qat: Load balancer serverləri birbaşa internetə açmaqdan qoruyur, bəzi növləri isə şübhəli trafiki süzə bilir.
Layer 4 və Layer 7 Load Balancer
Load balancer iki səviyyədə işləyə bilər.
Layer 4 yalnız şəbəkə məlumatına baxır: IP ünvanı və port. Sorğunun içində nə olduğunu bilmir, amma çox sürətlidir və sadədir.
Layer 7 sorğunun məzmununa baxır: ünvan, başlıqlar, cookie. Buna görə daha ağıllı qərarlar verə bilər. Məsələn, /api ilə başlayan sorğuları bir qrup serverə, /images ilə başlayanları digərinə yönləndirə bilər. Mikroservis arxitekturasında bu imkan çox faydalıdır, çünki hər servis öz serverlər qrupuna yönləndirilir.
Sessiya Problemi: İstifadəçi Başqa Serverə Düşəndə
Load balancer istifadəçinin sorğularını fərqli serverlərə göndərə bilər. Əgər sessiya məlumatı (məsələn, daxil olmuş vəziyyət və ya səbət) yalnız bir serverin yaddaşındadırsa, istifadəçi növbəti sorğuda başqa serverə düşəndə sistemdən "çıxmış" olur. Bunun iki əsas həlli var:
- Sticky session: Load balancer eyni istifadəçini həmişə eyni serverə yönləndirir. Sadədir, amma həmin server dayananda sessiya itir və yük bərabər bölünməyə bilər.
- Paylaşılan sessiya saxlama: Sessiya məlumatı serverlərin yaddaşında yox, ortaq yerdə saxlanır. Bu məqsəd üçün çox vaxt Redis istifadə olunur. Bu, daha etibarlı yoldur, çünki istənilən server istənilən istifadəçiyə xidmət edə bilir.
Load Balancer-in Özü Tək Nöqtəyə Çevrilə Bilərmi?
Bəli, bu vacib bir nüansdır. Əgər bütün trafik tək load balancer-dən keçirsə və o dayanırsa, serverlər sağlam olsa belə sayt əlçatmaz olur. Buna görə ciddi sistemlərdə load balancer-in özü də ehtiyatlı qurulur: iki və ya daha çox load balancer birlikdə işləyir, biri dayananda digəri onun yerini tutur. Bulud provayderlərinin hazır load balancer xidmətləri adətən bunu özü təmin edir.
Hansı Variantlardan İstifadə Etmək Olar?
| Variant | Xüsusiyyəti |
|---|---|
| Nginx | Geniş yayılmış açıq mənbəli həll, həm veb server, həm load balancer kimi işləyir |
| HAProxy | Yüksək performans və böyük trafik üçün populyar, yalnız bu işə fokuslanıb |
| Bulud load balancer-ləri | AWS, Azure və Google Cloud-un hazır xidmətləri, ehtiyatlılıq və genişlənmə daxilidir |
| Kubernetes Ingress və Service | Konteyner mühitində trafiki Pod-lara bölüşdürür |
| Cloudflare və oxşar xidmətlər | Trafiki kənardan qəbul edir, bölüşdürür və qoruyur |
Konteyner əsaslı sistemlərdə trafik bölgüsü artıq platformanın tərkib hissəsidir. Bu mövzuda Kubernetes yazımızı oxuya bilərsiniz.
Load Balancer Hər Şeyi Həll Edirmi?
Xeyr. Load balancer serverlər arasında yükü bölür, amma əsas problem başqa yerdədirsə, onu aradan qaldırmaz. Məsələn:
- Verilənlər bazası darboğazı: Əgər bütün serverlər eyni zəif verilənlər bazasına bağlıdırsa, serveri artırmaq kömək etmir. Bu halda cache və sorğu optimallaşdırması lazımdır.
- Yavaş kod: Hər sorğu özlüyündə yavaşdırsa, serveri çoxaltmaq xərci artırır, problemi həll etmir.
- Paylaşılan resurs: Fayl sistemi və ya xarici servis də darboğaz ola bilər.
Buna görə genişlənmə strategiyası tam şəkildə düşünülməlidir: load balancer, cache, verilənlər bazası və monitoring birlikdə baxılmalıdır.
Monitoring Olmadan Load Balancer Kifayət Etmir
Serverlərin sayı artdıqca hansının yüklü, hansının problemli olduğunu görmək çətinləşir. Load balancer-in özünün göstəricilərini (sorğu sayı, səhv nisbəti, serverlərin sağlamlığı) izləmək vacibdir. Bunun üçün monitoring və logging yazımızdakı addımlar yaxşı başlanğıcdır. Daha irəli getmək istəyənlər üçün proactive monitoring trafik artımını əvvəlcədən görməyə kömək edir.
Yük Testi: Çökməzdən Əvvəl Yoxlayın
Ən təhlükəli yanaşma sistemin yükü daşıyıb-daşımadığını real kampaniyada öyrənməkdir. Əvvəlcədən yük testi (load testing) aparmaq daha ağıllıdır: süni şəkildə çoxlu istifadəçi simulyasiya edib sistemin nə vaxt yavaşladığını və nə vaxt çökdüyünü görürsünüz. Beləliklə kampaniya başlamazdan əvvəl zəif nöqtələri tapıb düzəldə bilərsiniz.
Ən Çox Edilən Səhvlər
- Trafik artımını gözləmədən hazırlıqsız qalmaq: Kampaniya, endirim günü və ya xəbər effekti əvvəlcədən planlaşdırılmalıdır.
- Load balancer qurub health check-i unutmaq: Problemli serverə sorğu göndərilməyə davam edir.
- Sessiyanı serverin yaddaşında saxlamaq: İstifadəçilər təsadüfi çıxış edir.
- Load balancer-i tək nöqtə kimi qoymaq: Onun özü dayananda bütün sistem dayanır.
- Yalnız server sayını artırmaq: Darboğaz verilənlər bazasındadırsa, nəticə olmur.
- Test etməmək: Real yükdə ilk dəfə sınaqdan keçirmək ən bahalı üsuldur.
- Deployment zamanı trafiki nəzərə almamaq: Yeni versiya yayımlanarkən serverlər bir-bir yenilənməli və load balancer onları vaxtında sıradan çıxarıb geri qaytarmalıdır. Bu proses CI/CD pipeline ilə avtomatlaşdırılanda daha etibarlı olur.
Necə Başlamaq Olar?
- Hazırkı vəziyyəti ölçün: pik saatlarda server nə qədər yüklənir?
- Darboğazı tapın: problem serverdədir, yoxsa verilənlər bazasında?
- Sessiyanı serverdən ayırın (məsələn, paylaşılan saxlama ilə).
- İki serverlə başlayın və qarşılarına load balancer qoyun.
- Health check-i düzgün tənzimləyin.
- Yük testi ilə sistemin həddini öyrənin.
- Trafik artdıqca server əlavə edin, monitoring ilə izləyin.
Layihə böyükdürsə və ya trafikin kəskin artması gözlənilirsə, bu qərarların arxitektura mərhələsində verilməsi sonradan düzəltməkdən xeyli sərfəlidir. Belə işlər adətən fərdi proqram təminatı layihələrinin ilkin planlamasının tərkib hissəsi olur.
Tez-tez Verilən Suallar
Kiçik sayt üçün load balancer lazımdır?
Çox vaxt yox. Trafik azdırsa, tək server və düzgün cache kifayət edir. Load balancer trafik artanda və ya davamlılıq kritik olanda məna kəsb edir.
Load balancer ilə CDN eyni şeydirmi?
Xeyr. CDN statik faylları istifadəçiyə yaxın serverdən verir. Load balancer isə sorğuları öz serverləriniz arasında bölüşdürür. Bunlar çox vaxt birlikdə istifadə olunur.
Load balancer saytı sürətləndirirmi?
Dolayı yolla bəli. Yük bölündüyü üçün serverlər daha az yorulur və cavab müddəti stabil qalır. Amma kod yavaşdırsa, load balancer onu sürətləndirməz.
Bir server dayananda istifadəçi bunu hiss edirmi?
Düzgün qurulubsa, yox. Load balancer problemli serveri siyahıdan çıxarır və sorğuları sağlam serverlərə göndərir. Yalnız həmin serverlə bağlı ani sorğular səhv ola bilər.
Bulud xidməti ilə öz load balancer-imi qurmaq arasında hansını seçməli?
Kiçik və orta layihələr üçün hazır bulud xidməti adətən daha sadə və etibarlıdır. Xüsusi tələblər və ya xərc optimallaşdırması olduqda Nginx və ya HAProxy ilə öz həllinizi qurmaq düşünülə bilər.
Nəticə
Sayt trafik artanda çökürsə, səbəb çox vaxt serverin zəifliyi deyil, bütün yükün bir nöqtəyə düşməsidir. Load balancer sorğuları bir neçə server arasında bölüşdürür, nasaz serveri sıradan çıxarır və genişlənməni asanlaşdırır. Amma o, tək başına sehrli həll deyil. Cache, verilənlər bazası, sessiya idarəsi, monitoring və yük testi ilə birlikdə düşünüldükdə real nəticə verir.
Saytınızın və ya sisteminizin böyük trafikə hazır olub-olmadığını yoxlamaq istəyirsinizsə, Crocusoft komandası ilə əlaqə saxlayın. Əvvəlcə darboğazın harada olduğunu tapaq, sonra uyğun arxitekturanı birlikdə müəyyən edək.
