Salam, mənim adım Evgeniydir. Yandex.Market axtarış infrastrukturunda işləyirəm. Mən Habr icmasına Marketin daxili mətbəxi haqqında danışmaq istəyirəm - və deməli çox şeyim var. İlk növbədə, Bazar axtarışının necə işlədiyi, prosesləri və arxitekturası. Fövqəladə hallarla necə məşğul oluruq: bir server sıradan çıxsa nə baş verir? 100 belə server varsa nə olacaq?
Siz həmçinin bir anda bir neçə serverdə yeni funksiyaları necə tətbiq etdiyimizi öyrənəcəksiniz. Və biz istifadəçilərə heç bir narahatlıq yaratmadan mürəkkəb xidmətləri birbaşa istehsalda necə sınaqdan keçiririk. Ümumiyyətlə, Market axtarışı necə işləyir ki, hər kəs yaxşı vaxt keçirsin.
Haqqımızda bir az: hansı problemi həll edirik
Mətn daxil etdikdə, məhsulu parametrlər üzrə axtardıqda və ya müxtəlif mağazalardakı qiymətləri müqayisə etdikdə bütün sorğular axtarış xidmətinə göndərilir. Axtarış bazarda ən böyük xidmətdir.
Biz bütün axtarış sorğularını emal edirik: market.yandex.ru, beru.ru saytlarından, Supercheck xidməti, Yandex.Advisor, mobil proqramlar. Biz yandex.ru-da axtarış nəticələrinə məhsul təkliflərini də daxil edirik.
Axtarış xidməti dedikdə mən təkcə axtarışın özünü deyil, həm də bazarda bütün təklifləri özündə əks etdirən verilənlər bazasını nəzərdə tuturam. Ölçü belədir: gündə bir milyarddan çox axtarış sorğusu emal olunur. Və hər şey tez, fasiləsiz işləməli və həmişə istədiyiniz nəticəni verməlidir.
Nədir: Bazar memarlığı
Bazarın hazırkı arxitekturasını qısaca təsvir edəcəyəm. Aşağıdakı diaqramla təxminən təsvir edilə bilər:
Tutaq ki, bizə partnyor mağaza gəlir. Deyir ki, mən oyuncaq satmaq istəyirəm: bu pis pişik cığırtılı. Və başqa bir qəzəbli pişik cırtdansız. Və sadəcə bir pişik. Sonra mağaza Marketin axtardığı təkliflər hazırlamalıdır. Mağaza təkliflərlə xüsusi xml yaradır və filial interfeysi vasitəsilə bu xml-ə gedən yolu ötürür. Daha sonra indeksləşdirici vaxtaşırı bu xml-ni yükləyir, səhvləri yoxlayır və bütün məlumatları böyük verilənlər bazasında saxlayır.
Belə saxlanan xml-lər çoxdur. Bu verilənlər bazasından axtarış indeksi yaradılır. İndeks daxili formatda saxlanılır. İndeksi yaratdıqdan sonra Layout xidməti onu axtarış serverlərinə yükləyir.
Nəticədə, verilənlər bazasında çığırtılı qəzəbli pişik, serverdə isə pişiyin indeksi görünür.
Axtarış memarlığı ilə bağlı hissədə pişiyi necə axtardığımızı sizə izah edəcəyəm.
Bazar axtarış arxitekturası
Biz mikroservislər dünyasında yaşayırıq: hər gələn sorğu çoxlu alt sorğulara səbəb olur və onların işlənməsində onlarla xidmət iştirak edir. Diaqram yalnız bir neçəsini göstərir:
Sadələşdirilmiş sorğu emalı sxemi
Hər bir xidmətin gözəl bir xüsusiyyəti var - unikal adı olan öz balanslaşdırıcısı:
Balanslaşdırıcı bizə xidməti idarə etməkdə daha çox çeviklik verir: siz, məsələn, yeniləmələr üçün tez-tez tələb olunan serverləri söndürə bilərsiniz. Balanslaşdırıcı serverin əlçatmaz olduğunu görür və sorğuları avtomatik olaraq digər serverlərə və ya məlumat mərkəzlərinə yönləndirir. Serveri əlavə edərkən və ya çıxararkən yük avtomatik olaraq serverlər arasında yenidən bölüşdürülür.
Balanslaşdırıcının unikal adı məlumat mərkəzindən asılı deyil. A xidməti B-yə sorğu göndərdikdə, defolt olaraq balanslaşdırıcı B sorğunu cari məlumat mərkəzinə yönləndirir. Əgər xidmət mövcud deyilsə və ya cari məlumat mərkəzində mövcud deyilsə, sorğu digər məlumat mərkəzlərinə yönləndirilir.
Bütün məlumat mərkəzləri üçün vahid FQDN A xidmətinə yerlərdən tamamilə mücərrəd olmağa imkan verir. Onun B xidmətinə müraciəti həmişə icra olunacaq. İstisna, xidmətin bütün məlumat mərkəzlərində yerləşdiyi haldır.
Ancaq bu balanslaşdırıcı ilə hər şey o qədər də çəhrayı deyil: əlavə bir ara komponentimiz var. Balanslaşdırıcı qeyri-sabit ola bilər və bu problem lazımsız serverlər tərəfindən həll edilir. A və B xidmətləri arasında əlavə gecikmə də var. Amma praktikada bu 1 ms-dən azdır və əksər xidmətlər üçün bu kritik deyil.
Gözlənilməzlərlə Mübarizə: Axtarış Xidmətinin balanslaşdırılması və dayanıqlılığı
Təsəvvür edin ki, çökmə var: cırtdanlı bir pişik tapmaq lazımdır, lakin server çökür. Və ya 100 server. Necə çıxmaq olar? Həqiqətənmi istifadəçini pişiksiz qoyacağıq?
Vəziyyət qorxuludur, amma biz buna hazırıq. Mən sizə sıra ilə deyəcəm.
Axtarış infrastrukturu bir neçə məlumat mərkəzlərində yerləşir:
Dizayn edərkən biz bir məlumat mərkəzini bağlamaq imkanını daxil edirik. Həyat sürprizlərlə doludur - məsələn, bir ekskavator yeraltı kabeli kəsə bilər (bəli, belə oldu). Qalan məlumat mərkəzlərindəki tutum pik yükə tab gətirmək üçün kifayət olmalıdır.
Gəlin vahid məlumat mərkəzini nəzərdən keçirək. Hər bir məlumat mərkəzi eyni balanslaşdırıcı əməliyyat sxeminə malikdir:
Bir balanslaşdırıcı ən azı üç fiziki serverdir. Bu ehtiyat etibarlılıq üçün edilir. Balanslaşdırıcılar HAProx üzərində işləyir.
Biz HAProx-u yüksək performansa, aşağı resurs tələblərinə və geniş funksionallığına görə seçdik. Axtarış proqramımız hər bir server daxilində işləyir.
Bir serverin sıradan çıxma ehtimalı azdır. Ancaq bir çox serveriniz varsa, ən azı birinin aşağı düşmə ehtimalı artır.
Reallıqda belə olur: serverlər çökür. Buna görə də bütün serverlərin vəziyyətinə daim nəzarət etmək lazımdır. Server cavab verməyi dayandırarsa, o, avtomatik olaraq trafikdən ayrılır. Bu məqsədlə HAProxy-də daxili sağlamlıq yoxlaması var. O, bütün serverlərə saniyədə bir dəfə “/ping” HTTP sorğusu ilə gedir.
HAProxy-nin başqa bir xüsusiyyəti: agent-check bütün serverləri bərabər şəkildə yükləməyə imkan verir. Bunun üçün HAProxy bütün serverlərə qoşulur və onlar cari yükdən asılı olaraq çəkilərini 1-dən 100-ə qədər qaytarırlar.Çəki emal üçün növbədə olan sorğuların sayına və prosessorun yüklənməsinə əsasən hesablanır.
İndi pişiyi tapmaq haqqında. Axtarış nəticəsində belə sorğular var: /axtarış?text=qəzəbli+pişik. Axtarışın sürətli olması üçün bütün pişik indeksi RAM-a uyğun olmalıdır. Hətta SSD-dən oxumaq kifayət qədər sürətli deyil.
Bir vaxtlar təklif bazası kiçik idi və bir serverin operativ yaddaşı bunun üçün kifayət idi. Təklif bazası böyüdükcə, hər şey artıq bu RAM-a sığmadı və məlumatlar iki hissəyə bölündü: shard 1 və shard 2.
Ancaq bu həmişə olur: istənilən həll, hətta yaxşı bir həll başqa problemlərə səbəb olur.
Balanslaşdırıcı hələ də istənilən serverə getdi. Ancaq sorğunun gəldiyi maşında indeksin yalnız yarısı var idi. Qalanları başqa serverlərdə idi. Buna görə də server hansısa qonşu maşına getməli oldu. Hər iki serverdən məlumat alındıqdan sonra nəticələr birləşdirilib və yenidən sıralanıb.
Balanslaşdırıcı sorğuları bərabər payladığından, bütün serverlər yalnız məlumat göndərməklə deyil, yenidən sıralama ilə məşğul olurdular.
Problem qonşu server əlçatmaz olduqda baş verdi. Həll yolu müxtəlif prioritetləri olan bir neçə serveri “qonşu” server kimi təyin etmək idi. Birincisi, sorğu cari rafdakı serverlərə göndərildi. Cavab olmadıqda, sorğu bu məlumat mərkəzindəki bütün serverlərə göndərildi. Və nəhayət, sorğu digər məlumat mərkəzlərinə getdi.
Təkliflərin sayı artdıqca məlumatlar dörd hissəyə bölündü. Amma bu hədd deyildi.
Hazırda səkkiz parçadan ibarət konfiqurasiya istifadə olunur. Bundan əlavə, daha çox yaddaş saxlamaq üçün indeks axtarış hissəsinə (axtarış üçün istifadə olunur) və fraqment hissəsinə (axtarışda iştirak etməyən) bölündü.
Bir server yalnız bir parça üçün məlumat ehtiva edir. Buna görə də, tam indeksi axtarmaq üçün müxtəlif fraqmentləri olan səkkiz serverdə axtarış etməlisiniz.
Serverlər qruplara bölünür. Hər klasterdə səkkiz axtarış motoru və bir parça server var.
Snippet serveri statik məlumatlarla əsas dəyər verilənlər bazasını idarə edir. Onlar sənədləri vermək üçün lazımdır, məsələn, bir pişik ilə bir pişik təsviri. Məlumat axtarış serverlərinin yaddaşını yükləməmək üçün xüsusi olaraq ayrıca serverə ötürülür.
Sənəd identifikatorları yalnız bir indeks daxilində unikal olduğundan, fraqmentlərdə heç bir sənədin olmadığı vəziyyət yarana bilər. Yaxşı, ya da bir şəxsiyyət üçün fərqli məzmun olacaq. Buna görə də, axtarışın işləməsi və nəticələrin geri qaytarılması üçün bütün klasterdə ardıcıllığa ehtiyac var idi. Ardıcıllığı necə izlədiyimizi sizə aşağıda söyləyəcəyəm.
Axtarışın özü belə qurulmuşdur: axtarış sorğusu səkkiz serverdən hər hansı birinə gələ bilər. Deyək ki, o, 1-ci serverə gəldi. Bu server bütün arqumentləri emal edir və nəyi və necə axtarmaq lazım olduğunu anlayır. Daxil olan sorğudan asılı olaraq server lazımi məlumat üçün xarici xidmətlərə əlavə sorğular edə bilər. Bir sorğu xarici xidmətlərə on sorğu ilə müşayiət oluna bilər.
Lazımi məlumatları topladıqdan sonra təklif bazasında axtarış başlayır. Bunun üçün klasterdəki bütün səkkiz serverə alt sorğular edilir.
Cavablar alındıqdan sonra nəticələr birləşdirilir. Nəhayət, nəticələr yaratmaq üçün fraqment serverinə daha bir neçə alt sorğu tələb oluna bilər.
Klaster daxilində axtarış sorğuları belə görünür: /shard1?text=qəzəbli+pişik. Bundan əlavə, formanın alt sorğuları klasterdəki bütün serverlər arasında saniyədə bir dəfə edilir: /status.
İstək /status serverin mövcud olmadığı vəziyyəti aşkar edir.
O, həmçinin axtarış motoru versiyasının və indeks versiyasının bütün serverlərdə eyni olmasına nəzarət edir, əks halda klaster daxilində uyğunsuz məlumatlar olacaq.
Bir snippet serverinin səkkiz axtarış motorundan gələn sorğuları emal etməsinə baxmayaraq, onun prosessoru çox yüngül yüklənir. Buna görə də, biz indi fraqment məlumatlarını ayrı bir xidmətə köçürürük.
Məlumatların ötürülməsi üçün biz sənədlər üçün universal açarları təqdim etdik. İndi başqa bir sənəddəki məzmunun bir açardan istifadə edərək qaytarıldığı bir vəziyyət mümkün deyil.
Amma başqa arxitekturaya keçid hələ tamamlanmayıb. İndi biz xüsusi fraqment serverindən xilas olmaq istəyirik. Və sonra klaster strukturundan tamamilə uzaqlaşın. Bu, bizə asanlıqla miqyas almağa davam etməyə imkan verəcək. Əlavə bir bonus dəmirə əhəmiyyətli qənaətdir.
İndi isə xoşbəxt sonluqla bitən qorxulu hekayələrə keçək. Serverin əlçatmazlığının bir neçə halını nəzərdən keçirək.
Dəhşətli bir şey baş verdi: bir server əlçatan deyil
Deyək ki, bir server əlçatmazdır. Sonra klasterdə qalan serverlər cavab verməyə davam edə bilər, lakin axtarış nəticələri natamam olacaq.
Vəziyyət yoxlaması vasitəsilə /status qonşu serverlər birinin əlçatmaz olduğunu başa düşür. Buna görə də, tamlığı qorumaq üçün, klasterdəki bütün serverlər sorğu başına /ping onlar balanslaşdırıcıya cavab verməyə başlayırlar ki, onlar da əlçatmazdırlar. Məlum oldu ki, klasterdəki bütün serverlər ölüb (bu doğru deyil). Bu, bizim klaster sxemimizin əsas çatışmazlığıdır - buna görə də biz ondan uzaqlaşmaq istəyirik.
Səhvlə uğursuz olan sorğular balanslaşdırıcı tərəfindən digər serverlərə göndərilir.
Balanslaşdırıcı həmçinin istifadəçi trafikini ölü serverlərə göndərməyi dayandırır, lakin onların statusunu yoxlamağa davam edir.
Server əlçatan olduqda, cavab verməyə başlayır /ping. Ölü serverlərdən pinglərə normal cavablar gəlməyə başlayan kimi balanslaşdırıcılar istifadəçi trafikini ora göndərməyə başlayırlar. Klaster əməliyyatı bərpa olundu, hurray.
Daha da pisi: bir çox server əlçatan deyil
Məlumat mərkəzindəki serverlərin əhəmiyyətli bir hissəsi kəsilib. Nə etməli, hara qaçmalı? Balansçı yenidən köməyə gəlir. Hər balanslaşdırıcı daim yaddaşda canlı serverlərin cari sayını saxlayır. O, cari məlumat mərkəzinin emal edə biləcəyi maksimum trafik miqdarını daim hesablayır.
Məlumat mərkəzindəki bir çox serverlər sıradan çıxdıqda, balanslaşdırıcı bu məlumat mərkəzinin bütün trafiki emal edə bilməyəcəyini başa düşür.
Sonra artıq trafik təsadüfi olaraq digər məlumat mərkəzlərinə paylanmağa başlayır. Hər şey işləyir, hamı xoşbəxtdir.
Bunu necə edirik: buraxılışların nəşri
İndi xidmətə edilən dəyişiklikləri necə dərc etdiyimizdən danışaq. Burada biz proseslərin sadələşdirilməsi yolunu tutduq: yeni buraxılışın yayılması demək olar ki, tamamilə avtomatlaşdırılıb.
Layihədə müəyyən sayda dəyişikliklər toplandıqda, avtomatik olaraq yeni buraxılış yaradılır və onun qurulmasına başlanır.
Sonra xidmət sınağa çıxarılır, burada əməliyyatın sabitliyi yoxlanılır.
Eyni zamanda, avtomatik performans testi işə salınır. Bu xüsusi xidmət tərəfindən idarə olunur. İndi bu barədə danışmayacağam - onun təsviri ayrı bir məqaləyə layiqdir.
Sınaqda dərc uğurlu olarsa, buraxılışın əvvəlcədən stabil rejimdə dərci avtomatik olaraq başlayır. Prestable, normal istifadəçi trafikinin yönləndirildiyi xüsusi klasterdir. Səhv qaytararsa, balanslaşdırıcı istehsala yenidən müraciət edir.
Prestabil rejimdə cavab müddətləri ölçülür və istehsalda əvvəlki buraxılışla müqayisə edilir. Hər şey qaydasındadırsa, o zaman insan qoşulur: qrafikləri və yük testinin nəticələrini yoxlayır və sonra istehsala yayılmağa başlayır.
Ən yaxşısı istifadəçiyə düşür: A/B testi
Xidmətə edilən dəyişikliklərin real fayda gətirəcəyi həmişə aydın olmur. Dəyişikliklərin faydalılığını ölçmək üçün insanlar A/B testi ilə çıxış etdilər. Bunun Yandex.Market axtarışında necə işlədiyini sizə bir az danışacağam.
Hər şey yeni funksiyaları təmin edən yeni CGI parametrinin əlavə edilməsi ilə başlayır. Parametrimiz belə olsun: bazar_yeni_funksionallıq=1. Sonra kodda bayraq varsa, bu funksiyanı işə salırıq:
If (cgi.experiments.market_new_functionality) {
// enable new functionality
}Yeni funksionallıq istehsala təqdim olunur.
A/B testini avtomatlaşdırmaq üçün ətraflı məlumat verən xüsusi xidmət var . Xidmətdə təcrübə yaradılır. Trafik payı, məsələn, 15% müəyyən edilir. Faizlər sorğular üçün deyil, istifadəçilər üçün müəyyən edilir. Təcrübənin müddəti də, məsələn, bir həftə göstərilir.
Eyni vaxtda bir neçə təcrübə həyata keçirilə bilər. Parametrlərdə siz digər eksperimentlərlə kəsişmənin mümkün olub olmadığını təyin edə bilərsiniz.
Nəticədə xidmət avtomatik olaraq arqument əlavə edir bazar_yeni_funksionallıq=1 istifadəçilərin 15%-nə qədər. O, həmçinin seçilmiş ölçüləri avtomatik hesablayır. Təcrübə başa çatdıqdan sonra analitiklər nəticələrə baxır və nəticə çıxarırlar. Tapıntılara əsasən, istehsala və ya təkmilləşdirməyə keçmək qərarı verilir.
Bazarın bacarıqlı əli: istehsalda sınaq
Tez-tez olur ki, istehsalda yeni bir funksionallığın işini yoxlamaq lazımdır, lakin onun ağır yük altında "döyüş" şəraitində necə davranacağına əmin deyilsiniz.
Bir həll yolu var: CGI parametrlərindəki bayraqlar yalnız A/B testi üçün deyil, həm də yeni funksionallığı yoxlamaq üçün istifadə edilə bilər.
Xidməti risklərə məruz qoymadan minlərlə serverdə konfiqurasiyanı dərhal dəyişməyə imkan verən alət hazırladıq. Buna Stop Tap deyilir. Orijinal ideya bəzi funksionallığı layout olmadan tez söndürə bilmək idi. Sonra alət genişləndi və daha mürəkkəb oldu.
Xidmət axını diaqramı aşağıda təqdim olunur:
Bayraq dəyərləri API vasitəsilə təyin olunur. İdarəetmə xidməti bu dəyərləri verilənlər bazasında saxlayır. Bütün serverlər hər on saniyədə bir dəfə verilənlər bazasına daxil olur, bayraq dəyərlərini çıxarır və bu dəyərləri hər sorğuya tətbiq edir.
Stop kranında siz iki növ dəyər təyin edə bilərsiniz:
1) Şərti ifadələr. Dəyərlərdən biri doğru olduqda tətbiq edin. Misal üçün:
{
"condition":"IS_DC1",
"value":"3",
},
{
"condition": "CLUSTER==2 and IS_BERU",
"value": "4!"
}Sorğu DC3 yerində emal edildikdə "1" dəyəri tətbiq olunacaq. Sorğu beru.ru saytı üçün ikinci klasterdə işləndikdə dəyər "4" olur.
2) Şərtsiz qiymətlər. Şərtlərdən heç biri yerinə yetirilmədikdə, standart olaraq müraciət edin. Misal üçün:
dəyər, dəyər!
Əgər dəyər nida işarəsi ilə bitirsə, ona daha yüksək üstünlük verilir.
CGI parametr analizatoru URL-i təhlil edir. Sonra Stop Tap-dan olan dəyərləri tətbiq edir.
Aşağıdakı prioritetləri olan dəyərlər tətbiq olunur:
- Stop Tap-dan artan prioritetlə (nida işarəsi).
- Sorğudan gələn dəyər.
- Stop kranından defolt dəyər.
- Kodda defolt dəyər.
Şərti dəyərlərdə göstərilən bir çox bayraq var - bunlar bizə məlum olan bütün ssenarilər üçün kifayətdir:
- Məlumat mərkəzi.
- Ətraf mühit: istehsal, sınaq, kölgə.
- Məkan: market, beru.
- Klaster nömrəsi.
Bu alətlə siz müəyyən serverlər qrupunda (məsələn, yalnız bir məlumat mərkəzində) yeni funksionallığı aktivləşdirə və bütün xidmət üçün heç bir risk olmadan bu funksionallığın işini sınaqdan keçirə bilərsiniz. Bir yerdə ciddi səhv etsəniz belə, hər şey düşməyə başladı və bütün məlumat mərkəzi sıradan çıxdı, balanslaşdırıcılar sorğuları digər məlumat mərkəzlərinə yönləndirəcəklər. Son istifadəçilər heç nə görməyəcəklər.
Problem görsəniz, dərhal bayrağı əvvəlki dəyərinə qaytara bilərsiniz və dəyişikliklər geri qaytarılacaq.
Bu xidmətin mənfi cəhətləri də var: tərtibatçılar onu çox sevirlər və tez-tez bütün dəyişiklikləri Stop Tap-a itələməyə çalışırlar. Biz sui-istifadə ilə mübarizə aparmağa çalışırıq.
Stop Tap yanaşması, artıq istehsala yayılmağa hazır stabil kodunuz olduqda yaxşı işləyir. Eyni zamanda, hələ də şübhələriniz var və kodu "döyüş" şəraitində yoxlamaq istəyirsiniz.
Bununla belə, Stop Tap inkişaf zamanı sınaq üçün uyğun deyil. Tərtibatçılar üçün “kölgə klasteri” adlanan ayrıca klaster var.
Gizli sınaq: Kölgə çoxluğu
Klasterlərdən birinin sorğuları kölgə klasterinə təkrarlanır. Lakin balanslaşdırıcı bu klasterdən gələn cavablara tamamilə məhəl qoymur. Onun işinin diaqramı aşağıda təqdim olunur.
Həqiqi "döyüş" şəraitində olan bir test klasteri alırıq. Normal istifadəçi trafiki ora gedir. Hər iki klasterdəki aparat eynidir, buna görə də performans və səhvlər müqayisə edilə bilər.
Balanslaşdırıcı cavablara tamamilə məhəl qoymadığından, son istifadəçilər kölgə klasterindən gələn cavabları görməyəcəklər. Ona görə də səhv etmək qorxulu deyil.
Tapıntılar
Beləliklə, bazar axtarışını necə qurduq?
Hər şeyin rəvan getməsi üçün biz funksionallığı ayrı xidmətlərə ayırırıq. Bu yolla biz yalnız bizə lazım olan komponentləri miqyaslandıra və komponentləri sadələşdirə bilərik. Başqa bir komandaya ayrıca bir komponent təyin etmək və onun üzərində işləmək üçün məsuliyyətləri bölüşmək asandır. Və bu yanaşma ilə dəmirdə əhəmiyyətli qənaət açıq bir artıdır.
Kölgə klasteri də bizə kömək edir: biz xidmətləri inkişaf etdirə, onları prosesdə sınaqdan keçirə və istifadəçini narahat etməyərək.
Təbii ki, istehsalda sınaqdan keçirilir. Minlərlə serverdə konfiqurasiyanı dəyişmək lazımdır? Asan, Stop Tap-dan istifadə edin. Beləliklə, siz dərhal hazır kompleks həlli təqdim edə və problem yaranarsa, stabil versiyaya qayıda bilərsiniz.
Ümid edirəm ki, getdikcə artan təkliflər bazası ilə bazarı necə sürətli və sabit etdiyimizi göstərə bildim. Server problemlərini necə həll edirik, çoxlu sayda sorğu ilə məşğul oluruq, xidmətin çevikliyini yaxşılaşdırırıq və bunu iş proseslərini dayandırmadan edirik.
Mənbə: www.habr.com