Artem Denisov ( , )
Badoo dünyanın ən böyük tanışlıq saytıdır. Hazırda dünyada təxminən 330 milyon qeydiyyatdan keçmiş istifadəçimiz var. Ancaq bugünkü söhbətimiz kontekstində daha vacib olan odur ki, biz təxminən 3 petabayt istifadəçi fotoşəkilini saxlayırıq. Hər gün istifadəçilərimiz təxminən 3,5 milyon yeni fotoşəkil yükləyir və oxuma yükü təxminəndir Saniyədə 80 min sorğu. Bu, bizim backendimiz üçün olduqca çoxdur və bəzən bununla bağlı çətinliklər yaranır.
Mən ümumiyyətlə fotoşəkilləri saxlayan və göndərən bu sistemin dizaynı haqqında danışacağam və ona bir tərtibatçının nöqteyi-nəzərindən baxacağam. Onun necə inkişaf etdiyinə dair qısa bir retrospektiv olacaq, burada əsas mərhələləri qeyd edəcəyəm, lakin mən yalnız hazırda istifadə etdiyimiz həllər haqqında daha ətraflı danışacağam.
İndi başlayaq.
Dediyim kimi, bu retrospektiv olacaq və onu haradansa başlamaq üçün ən çox yayılmış nümunəni götürək.
Bizim ümumi vəzifəmiz var, istifadəçi şəkillərini qəbul etməli, saxlamalı və göndərməliyik. Bu formada tapşırıq ümumidir, hər şeydən istifadə edə bilərik:
- müasir bulud saxlama,
- qutulu bir həll, indi də çoxları var;
- Məlumat mərkəzimizdə bir neçə maşın qura və onlara böyük sərt disklər qoya və orada fotoşəkillər saxlaya bilərik.
Badoo tarixən - həm indi, həm də sonra (yenicə körpəlikdə olduğu dövrdə) - öz serverlərində, öz DC-lərimizdə yaşayır. Ona görə də bu variant bizim üçün optimal idi.
Biz sadəcə bir neçə maşın götürdük, onları “şəkillər” adlandırdıq və fotoşəkilləri saxlayan bir çoxluq əldə etdik. Amma deyəsən nəsə çatışmır. Bütün bunların işləməsi üçün hansı fotoları hansı maşında saxlayacağımızı müəyyən etməliyik. Və burada da Amerikanın açılmasına ehtiyac yoxdur.
İstifadəçilər haqqında məlumatla yaddaşımıza bəzi sahələr əlavə edirik. Bu parçalanma açarı olacaq. Bizim vəziyyətimizdə biz onu place_id adlandırdıq və bu yer id-si istifadəçi şəkillərinin saxlandığı yerə işarə edir. Xəritələr düzəldirik.
Birinci mərhələdə bu, hətta əl ilə edilə bilər - biz deyirik ki, bu istifadəçinin belə bir yeri olan bir fotoşəkili belə bir serverə düşəcək. Bu xəritə sayəsində biz hər zaman istifadəçinin şəklini nə vaxt yüklədiyini, onu harada saxlayacağını və haradan verəcəyini bilirik.
Bu, tamamilə mənasız bir sxemdir, lakin olduqca əhəmiyyətli üstünlüklərə malikdir. Birincisi, dediyim kimi sadədir, ikincisi isə budur ki, bu yanaşma ilə biz sadəcə olaraq yeni avtomobilləri çatdırıb xəritəyə əlavə etməklə üfüqi olaraq asanlıqla miqyaslaya bilərik. Başqa bir şey etmək lazım deyil.
Bir müddət bizim üçün belə idi.
Bu, təxminən 2009-cu il idi. Maşın gətirdilər, çatdırdılar...
Və bir anda bu sxemin müəyyən çatışmazlıqları olduğunu görməyə başladıq. Mənfi cəhətləri nələrdir?
Əvvəla, məhdud imkanlar var. İstədiyimiz qədər sabit diski bir fiziki serverə yığa bilmərik. Və bu, zamanla və verilənlər bazasının böyüməsi ilə müəyyən bir problemə çevrildi.
Və ikinci. Bu, maşınların atipik konfiqurasiyasıdır, çünki bu cür maşınları bəzi digər qruplarda təkrar istifadə etmək çətindir; onlar olduqca spesifikdir, yəni. onlar performans baxımından zəif olmalıdır, lakin eyni zamanda böyük bir sabit disk ilə.
Bütün bunlar 2009-cu il üçün idi, lakin prinsipcə, bu tələblər bu gün də aktualdır. Bizim retrospektivimiz var, ona görə də 2009-cu ildə bununla bağlı hər şey tamamilə pis idi.
Və son nöqtə qiymətdir.
O vaxt qiymət çox baha idi və biz bəzi alternativlər axtarmalı idik. Bunlar. həm məlumat mərkəzlərindəki yerdən, həm də bütün bunların yerləşdiyi fiziki serverlərdən hansısa şəkildə daha yaxşı istifadə etməmiz lazım idi. Sistem mühəndislərimiz bir çox müxtəlif variantları nəzərdən keçirdikləri böyük bir araşdırmaya başladılar. Onlar həmçinin PolyCeph və Luster kimi klaster fayl sistemlərinə baxdılar. Performans problemləri və olduqca çətin əməliyyat var idi. Onlar imtina etdilər. Birtəhər genişləndirmək üçün bütün məlumat dəstini NFS vasitəsilə hər bir avtomobilə quraşdırmağa çalışdıq. Oxumaq da pis keçdi, biz müxtəlif satıcılardan fərqli həllər sınadıq.
Və sonda biz Storage Area Network adlanan şəbəkədən istifadə etməyə qərar verdik.
Bunlar böyük miqdarda məlumatların saxlanması üçün xüsusi olaraq hazırlanmış böyük SHD-lərdir. Onlar son optik çıxış maşınlarına quraşdırılmış diskləri olan rəflərdir. Bu. bir növ maşın hovuzumuz var, kifayət qədər kiçikdir və bu SHD-lər göndərmə məntiqimizə şəffafdır, yəni. bizim nginx və ya başqasının bu fotoşəkillər üçün sorğulara xidmət etməsi üçün.
Bu qərarın aşkar üstünlükləri var idi. Bu SHD. Fotoşəkilləri saxlamaq məqsədi daşıyır. Bu, sadəcə maşınları sabit disklərlə təchiz etməkdən daha ucuz başa gəlir.
İkinci artı.
Bu, tutumun daha böyük olmasıdır, yəni. biz daha kiçik həcmdə daha çox yaddaş yerləşdirə bilərik.
Ancaq kifayət qədər tez ortaya çıxan çatışmazlıqlar da var idi. İstifadəçilərin sayı və bu sistemə yüklənmə artdıqca, performans problemləri yaranmağa başladı. Və burada problem olduqca açıqdır - bir çox fotoşəkilləri kiçik həcmdə saxlamaq üçün nəzərdə tutulmuş hər hansı bir SHD, bir qayda olaraq, intensiv oxumaqdan əziyyət çəkir. Bu, əslində hər hansı bulud saxlama və ya başqa bir şey üçün doğrudur. İndi sonsuz genişlənə bilən ideal bir yaddaşımız yoxdur, ona hər şeyi doldura bilərsiniz və oxunuşlara çox yaxşı dözür. Xüsusilə təsadüfi oxunuşlar.
Fotoşəkillərimizdə olduğu kimi, çünki fotoşəkillər ardıcıl olaraq tələb olunmur və bu, onların performansına çox təsir edəcək.
Hətta bugünkü rəqəmlərə görə, yaddaşın qoşulduğu bir maşında fotoşəkillər üçün 500-dən çox RPS əldə etsək, problemlər artıq başlayır. Və bu, bizim üçün kifayət qədər pis oldu, çünki istifadəçilərin sayı artır, işlər daha da pisləşəcək. Bunu bir şəkildə optimallaşdırmaq lazımdır.
Optimallaşdırmaq üçün biz o zaman qərara gəldik ki, yük profilinə baxaq - ümumiyyətlə nə baş verir, nəyi optimallaşdırmaq lazımdır.
Və burada hər şey bizim əlimizdə oynayır.
Artıq birinci slaydda dedim: gündə cəmi 80 milyon yükləmə ilə saniyədə 3,5 min oxuma sorğumuz var. Yəni bu, üç dərəcəli fərqdir. Aydındır ki, oxumağı optimallaşdırmaq lazımdır və necə olacağı praktiki olaraq aydındır.
Daha bir kiçik məqam var. Xidmətin xüsusiyyətləri ondan ibarətdir ki, bir şəxs qeydiyyatdan keçir, şəkil yükləyir, sonra digər insanlara aktiv şəkildə baxmağa başlayır, onları bəyənir və digər insanlara aktiv şəkildə göstərilir. Sonra həyat yoldaşı tapır və ya həyat yoldaşı tapmır, bu, necə olacağından asılıdır və bir müddət xidmətdən istifadəni dayandırır. Bu anda ondan istifadə edəndə onun fotoları çox isti olur - onlara tələbat var, çox adam onlara baxır. O, bunu etməyi dayandıran kimi, əvvəlki kimi digər insanlarla ünsiyyətdən çox tez çıxır və onun fotoşəkilləri demək olar ki, heç vaxt tələb olunmur.
Bunlar. Çox kiçik qaynar məlumat dəstimiz var. Amma eyni zamanda ona müraciətlər də az deyil. Və burada tamamilə açıq bir həll bir önbellek əlavə etməkdir.
LRU ilə bir önbellek bütün problemlərimizi həll edəcək. Biz nə edirik?
Fotokeşlər adlanan saxlama ilə böyük klasterimizin qarşısına daha bir nisbətən kiçik əlavə edirik. Bu, mahiyyətcə sadəcə bir keşləmə proksisidir.
İçəridən necə işləyir? Budur istifadəçimiz, budur yaddaş. Hər şey əvvəlki kimidir. Arasına nə əlavə edirik?
Bu, sadəcə olaraq sürətli fiziki lokal diski olan maşındır. Bu, məsələn, SSD ilə. Və bu diskdə bir növ yerli keş saxlanılır.
Nə kimi görünür? İstifadəçi fotoşəkil üçün sorğu göndərir. NGINX onu ilk növbədə yerli keşdə axtarır. Yoxdursa, sadəcə olaraq yaddaşımıza proxy_pass edin, şəkli oradan endirin və istifadəçiyə verin.
Amma bu çox bayağıdır və içəridə nə baş verdiyi bəlli deyil. Bu kimi bir şey işləyir.
Keş məntiqi olaraq üç təbəqəyə bölünür. Mən “üç qat” deyəndə bu o demək deyil ki, bir növ mürəkkəb sistem var. Xeyr, bunlar fayl sistemində şərti olaraq yalnız üç qovluqdur:
- Bu, proksidən yenicə endirilmiş şəkillərin getdiyi buferdir.
- Bu, hazırda aktiv şəkildə tələb olunan fotoşəkilləri saxlayan isti yaddaşdır.
- Və daha az sorğu gələndə fotoşəkillərin tədricən isti keşdən çıxarıldığı soyuq bir keş.
Bunun işləməsi üçün bu önbelleği birtəhər idarə etməliyik, içindəki fotoşəkilləri yenidən təşkil etməliyik və s. Bu da çox primitiv bir prosesdir.
Nginx sadəcə olaraq hər sorğu üçün RAMDisk access.log-a yazır, orada hazırda xidmət göstərdiyi fotoya gedən yolu (əlbəttə ki, nisbi yol) və hansı bölməyə xidmət göstərildiyini göstərir. Bunlar. o, “şəkil 1” və sonra ya bufer, ya isti keş, ya da soyuq keş və ya proxy deyə bilər.
Bundan asılı olaraq, bir şəkildə fotoşəkillə nə edəcəyimizə qərar verməliyik.
Bizim hər bir maşında bu jurnalı daim oxuyan və yaddaşında müəyyən fotoşəkillərin istifadəsinə dair statistik məlumatları saxlayan kiçik bir demonumuz var.
O, sadəcə orada yığır, sayğacları saxlayır və vaxtaşırı aşağıdakıları edir. O, çoxlu sorğuların olduğu, aktiv şəkildə tələb olunan fotoşəkilləri harada olursa olsun, isti yaddaşa köçürür.
Nadir hallarda tələb olunan və daha az tələb olunan fotoşəkillər tədricən isti keşdən soyuq fotoya atılır.
Keş yaddaşda yerimiz bitdikdə, sadəcə olaraq soyuq keşdən hər şeyi fərq etmədən silməyə başlayırıq. Və yeri gəlmişkən, bu yaxşı işləyir.
Şəklin buferə proksiləşdirilərkən dərhal saxlanması üçün biz proxy_store direktivindən istifadə edirik və bufer də RAMDiskdir, yəni. istifadəçi üçün çox tez işləyir. Bu, keşləmə serverinin daxili hissələrinə aiddir.
Qalan sual sorğuları bu serverlər arasında necə yaymaqdır.
Deyək ki, iyirmi saxlama maşını və üç keş serverdən ibarət bir çoxluq var (bu belə oldu).
Hansı fotoşəkillər üçün hansı sorğuların olduğunu və onları hara endirə biləcəyimizi bir şəkildə müəyyən etməliyik.
Ən çox yayılmış seçim Round Robindir. Yoxsa təsadüfən edirsiniz?
Bunun açıq-aydın bir sıra mənfi cəhətləri var, çünki belə bir vəziyyətdə önbelleği çox səmərəsiz istifadə etmiş olarıq. Sorğular bəzi təsadüfi maşınlara düşəcək: burada o, yaddaşda saxlanıb, növbətisində isə artıq yoxdur. Bütün bunlar işləsə, çox pis olacaq. Klasterdə az sayda maşın olsa belə.
Hansı serverin hansı sorğuya endirilməsini birmənalı şəkildə müəyyən etməliyik.
Banal bir yol var. Biz URL-dən hash və ya URL-də olan sharding açarımızdan hash götürürük və onu serverlərin sayına bölürük. İşləyəcək? iradə.
Bunlar. Bizim 2% sorğumuz var, məsələn, bəzi “example_url” üçün o, həmişə “XNUMX” indeksli serverə düşəcək və keş daim mümkün qədər yaxşı şəkildə silinəcək.
Ancaq belə bir sxemdə yenidən parçalanma ilə bağlı problem var. Yenidən paylaşma - mən serverlərin sayının dəyişdirilməsini nəzərdə tuturam.
Tutaq ki, keşləmə klasterimiz artıq öhdəsindən gələ bilmir və biz başqa maşın əlavə etmək qərarına gəlirik.
əlavə edək.
İndi hər şey üçə yox, dördə bölünür. Beləliklə, bizdə olan demək olar ki, bütün açarlar, demək olar ki, bütün URL-lər indi digər serverlərdə yaşayır. Bütün keş sadəcə bir anlıq etibarsız sayıldı. Bütün sorğular saxlama klasterimizə düşdü, o, pisləşdi, xidmət çatışmazlığı və narazı istifadəçilər. Mən bunu etmək istəmirəm.
Bu seçim də bizə uyğun deyil.
Bu. biz nə etməliyik? Biz bir şəkildə keşdən səmərəli istifadə etməli, eyni sorğunu eyni serverə təkrar-təkrar göndərməli, lakin yenidən bölüşdürülməyə davamlı olmalıyıq. Və belə bir həll var, o qədər də mürəkkəb deyil. Buna ardıcıl hashing deyilir.
Necə görünür?
Sharding açarından bəzi funksiyaları götürürük və onun bütün dəyərlərini dairəyə yayırıq. Bunlar. 0 nöqtəsində onun minimum və maksimum dəyərləri yaxınlaşır. Sonra, bütün serverlərimizi təxminən bu şəkildə eyni dairəyə yerləşdiririk:
Hər bir server bir nöqtə ilə müəyyən edilir və ona saat əqrəbi istiqamətində gedən sektora müvafiq olaraq bu host xidmət göstərir. Sorğular bizə gələndə dərhal görürük ki, məsələn, A sorğusu - onun orada hash var - və ona 2-ci server tərəfindən xidmət edilir. Sorğu B - server 3. Və s.
Yenidən parçalanma zamanı bu vəziyyətdə nə baş verir?
Əvvəlki kimi bütün keşi etibarsız hesab etmirik və bütün düymələri dəyişdirmirik, lakin hər sektoru qısa bir məsafəyə köçürürük ki, nisbətən desək, əlavə etmək istədiyimiz altıncı serverimiz boş yerə uyğunlaşsın və ora əlavə edirik.
Təbii ki, belə bir vəziyyətdə açarlar da yerindən tərpənir. Amma əvvəlkindən xeyli zəif hərəkət edirlər. Və görürük ki, ilk iki açarımız öz serverlərində qaldı və keş serveri yalnız sonuncu açar üçün dəyişdi. Bu olduqca səmərəli işləyir və tədricən yeni hostlar əlavə etsəniz, burada böyük problem yoxdur. Siz bir az əlavə edib əlavə edirsiniz, cache yenidən dolana qədər gözləyin və hər şey yaxşı işləyir.
Yeganə sual imtinalarla qalır. Tutaq ki, hansısa avtomobil sıradan çıxıb.
Və biz, məsələn, maşın yenidən işə salınıbsa və birtəhər xidmət sorğularına ehtiyacımız olsa, bu anda bu xəritəni yenidən yaratmaq, keşin bir hissəsini etibarsız etmək və sair istəməzdik. Biz sadəcə olaraq hər saytda bir ehtiyat nüsxə foto keşini saxlayırıq ki, bu da hazırda işlək vəziyyətdə olan hər hansı bir maşının əvəzi kimi çıxış edir. Və birdən serverlərimizdən biri əlçatmaz olarsa, trafik ora gedir. Təbii ki, orada heç bir önbelleğimiz yoxdur, yəni. soyuqdur, lakin ən azı istifadəçi sorğuları işlənir. Əgər bu qısa bir intervaldırsa, o zaman biz bunu tamamilə sakit yaşayırıq. Yaddaşda daha çox yük var. Əgər bu interval uzundursa, onda biz artıq qərar verə bilərik - bu serveri xəritədən silmək və ya etməmək və ya bəlkə də başqası ilə əvəz etmək.
Bu, keşləmə sisteminə aiddir. Gəlin nəticələrə baxaq.
Görünür, burada mürəkkəb bir şey yoxdur. Ancaq önbelleği idarə etməyin bu üsulu bizə təxminən 98% hiylə nisbəti verdi. Bunlar. saniyədə bu 80 min sorğudan yalnız 1600-ü anbara çatır və bu tamamilə normal yükdür, buna sakitcə dözürlər, həmişə ehtiyatımız var.
Biz bu serverləri üç DC-də yerləşdirdik və üç mövcudluq nöqtəsi aldıq - Praqa, Mayami və Honq Konq.
Bu. onlar bizim hədəf bazarlarımızın hər birində az-çox yerli olaraq yerləşirlər.
Gözəl bir bonus olaraq, CPU-nun əslində boş olduğu bu keşləmə proksisini əldə etdik, çünki məzmuna xidmət etmək üçün o qədər də lazım deyil. Və orada NGINX+ Lua-dan istifadə edərək bir çox utilitar məntiq tətbiq etdik.
Məsələn, biz webp və ya mütərəqqi jpeg ilə sınaqdan keçirə bilərik (bunlar effektiv müasir formatlardır), onun trafikə necə təsir etdiyini görmək, bəzi qərarlar qəbul etmək, müəyyən ölkələr üçün onu aktivləşdirmək və s.; dinamik ölçüsünü dəyişdirin və ya fotoşəkilləri tez kəsin.
Bu, məsələn, fotoşəkilləri göstərən mobil proqramınız olduqda və mobil proqram müştərinin CPU-nu böyük bir fotoşəkil tələb etmək və sonra onu itələmək üçün müəyyən bir ölçüyə dəyişdirmək üçün sərf etmək istəmədikdə yaxşı istifadə olunur. baxış. Biz sadəcə olaraq UPort şərti URL-də bəzi parametrləri dinamik olaraq təyin edə bilərik və foto önbelleği şəklin özünün ölçüsünü dəyişəcək. Bir qayda olaraq, o, fiziki olaraq diskdə olan ölçüsünü tələb olunana mümkün qədər yaxın seçəcək və onu müəyyən koordinatlarda aşağı salacaq.
Yeri gəlmişkən, biz yüksək yüklü sistemlərin tərtibatçıları konfransının son beş ilinin video çəkilişlərini ictimaiyyətə açıqladıq. . Baxın, öyrənin, paylaşın və abunə olun .
Biz oraya çoxlu məhsul məntiqi də əlavə edə bilərik. Məsələn, URL parametrlərindən istifadə edərək müxtəlif su nişanları əlavə edə bilərik, fotoşəkilləri bulandıra, bulanıqlaşdıra və ya pikselləşdirə bilərik. Bu, bir insanın şəklini göstərmək istədiyimiz zamandır, lakin onun üzünü göstərmək istəmirik, bu yaxşı işləyir, hamısı burada həyata keçirilir.
Nə əldə etdik? Üç mövcudluq nöqtəsi, yaxşı bir hiylə nisbətimiz var və eyni zamanda bu maşınlarda boş CPU yoxdur. İndi o, əlbəttə ki, əvvəlkindən daha vacib oldu. Özümüzə daha güclü avtomobillər verməliyik, amma buna dəyər.
Bu, fotoşəkillərin qaytarılmasına aiddir. Burada hər şey olduqca aydın və aydındır. Düşünürəm ki, mən Amerikanı kəşf etməmişəm, demək olar ki, hər hansı bir CDN bu şəkildə işləyir.
Və çox güman ki, mükəmməl bir dinləyicinin sualı ola bilər: niyə hər şeyi CDN-ə dəyişdirməyək? Təxminən eyni olardı; bütün müasir CDN-lər bunu edə bilər. Və bir sıra səbəblər var.
Birincisi fotoşəkillərdir.
Bu, bizim infrastrukturumuzun əsas məqamlarından biridir və bizə mümkün qədər çox nəzarət lazımdır. Bu, üçüncü tərəf satıcısının bir növ həllidirsə və bunun üzərində heç bir səlahiyyətiniz yoxdursa, böyük bir məlumat dəstiniz olduqda və çox böyük bir axınınız olduqda onunla yaşamaq sizin üçün olduqca çətin olacaq. istifadəçi sorğuları.
Sizə bir misal deyim. İndi öz infrastrukturumuzla, məsələn, hansısa problem və ya yeraltı döymələr zamanı, nisbətən desək, maşına gedib orada qarışa bilərik. Biz yalnız bizə lazım olan bəzi metriklərin toplusunu əlavə edə bilərik, bir şəkildə təcrübə edə bilərik, bunun qrafiklərə necə təsir etdiyini görə bilərik və s. İndi bu keşləmə klasterində çoxlu statistika toplanır. Və biz vaxtaşırı ona baxırıq və bəzi anomaliyaları araşdırmağa uzun müddət sərf edirik. CDN tərəfində olsaydı, nəzarət etmək daha çətin olardı. Yaxud, məsələn, hansısa qəza baş verərsə, biz nə baş verdiyini bilirik, onunla necə yaşayacağımızı və ondan necə çıxacağımızı bilirik. Bu, birinci nəticədir.
İkinci nəticə də kifayət qədər tarixidir, çünki sistem uzun müddətdir inkişaf edir və müxtəlif mərhələlərdə çoxlu müxtəlif biznes tələbləri var idi və onlar həmişə CDN konsepsiyasına uyğun gəlmir.
Və əvvəlkindən irəli gələn məqam budur
Bunun səbəbi, fotoşəkil önbelleğimizdə çoxlu xüsusi məntiqə sahib olmamızdır, onları həmişə tələb əsasında əlavə etmək mümkün deyil. Hər hansı bir CDN-nin sizin istəyinizlə sizə bəzi xüsusi şeylər əlavə etməsi ehtimalı azdır. Məsələn, müştərinin nəyisə dəyişdirə bilməsini istəmirsinizsə, URL-lərin şifrələnməsi. Serverdəki URL-i dəyişmək və onu şifrələmək və sonra bəzi dinamik parametrləri buraya göndərmək istəyirsiniz.
Bu hansı nəticəni təklif edir? Bizim vəziyyətimizdə CDN çox yaxşı alternativ deyil.
Və sizin vəziyyətinizdə, hər hansı bir xüsusi iş tələbləriniz varsa, o zaman sizə göstərdiklərimi özünüz həyata keçirə bilərsiniz. Və bu, oxşar yük profili ilə mükəmməl işləyəcək.
Ancaq bir növ ümumi həlliniz varsa və tapşırıq çox spesifik deyilsə, tamamilə təhlükəsiz bir CDN ala bilərsiniz. Və ya vaxt və resurslar sizin üçün nəzarətdən daha vacibdirsə.
Müasir CDN-lərdə indi sizə söylədiyim demək olar ki, hər şey var. Artı və ya mənfi bəzi xüsusiyyətlər istisna olmaqla.
Bu, fotoşəkilləri təqdim etməkdir.
İndi retrospektivimizdə bir az irəli gedək və saxlama haqqında danışaq.
2013-cü il keçdi.
Keşləmə serverləri əlavə edildi, performans problemləri aradan qaldırıldı. Hər şey yaxşıdır. Dataset böyüyür. 2013-cü ilə qədər yaddaşa qoşulmuş təxminən 80 serverimiz və hər DC-də təxminən 40 keşləmə serverimiz var idi. Bu, hər DC-də 560 terabayt məlumatdır, yəni. cəmi bir petabayt.
Məlumat dəstinin böyüməsi ilə əməliyyat xərcləri əhəmiyyətli dərəcədə artmağa başladı. Bu nə deməkdi?
Çəkilən bu diaqramda - SAN ilə, ona qoşulmuş maşınlar və önbelleklərlə - çoxlu uğursuzluq nöqtələri var. Əgər əvvəllər serverlərin keşləşdirilməsinin uğursuzluğu ilə məşğul olsaydıq, hər şey az və ya çox proqnozlaşdırıla bilən və başa düşülən idi, lakin saxlama tərəfində hər şey daha pis idi.
Birincisi, uğursuz ola bilən Storage Area Network (SAN) özü.
İkincisi, optika vasitəsilə son maşınlara qoşulur. Optik kartlarda və bujilərdə problemlər ola bilər.
Əlbəttə ki, SAN-ın özündə olduğu qədər çox deyil, amma buna baxmayaraq, bunlar da uğursuzluq nöqtələridir.
Sonrakı, anbara qoşulmuş maşının özüdür. Bu da uğursuz ola bilər.
Ümumilikdə üç uğursuz nöqtəmiz var.
Bundan əlavə, nasazlıq nöqtələrinə əlavə olaraq, anbarın özünə də ciddi texniki qulluq göstərilir.
Bu mürəkkəb çoxkomponentli sistemdir və sistem mühəndisləri onunla işləməkdə çətinlik çəkə bilərlər.
Və son, ən vacib məqam. Bu üç nöqtədən hər hansı birində nasazlıq baş verərsə, istifadəçi məlumatlarını itirmək şansımız sıfıra bərabərdir, çünki fayl sistemi çökə bilər.
Deyək ki, fayl sistemimiz xarabdır. Birincisi, onun bərpası uzun müddət tələb edir - böyük miqdarda məlumatla bir həftə çəkə bilər. İkincisi, nəhayət, çox güman ki, istifadəçi fotoşəkillərinə bir şəkildə birləşdirilməli olan bir dəstə anlaşılmaz faylla başa çatacağıq. Və məlumatları itirmək riskimiz var. Risk olduqca yüksəkdir. Və belə hallar nə qədər tez-tez baş verirsə və bütün bu zəncirdə nə qədər çox problem yaranarsa, bu risk bir o qədər yüksəkdir.
Bununla bağlı nəsə etmək lazım idi. Və qərara gəldik ki, sadəcə məlumatların ehtiyat nüsxəsini çıxarmalıyıq. Bu, əslində açıq bir həlldir və yaxşı bir həlldir. Biz nə etmişik?
Serverimiz əvvəllər yaddaşa qoşulduqda belə görünürdü. Bu, bir əsas bölmədir, sadəcə optika vasitəsilə uzaqdan saxlama üçün montajı təmsil edən bir blok cihazıdır.
Sadəcə ikinci bölmə əlavə etdik.
Yanına ikinci bir yaddaş yerləşdirdik (xoşbəxtlikdən, pul baxımından o qədər də baha deyil) və onu ehtiyat bölmə adlandırdıq. O, həmçinin optika vasitəsilə birləşdirilir və eyni maşında yerləşir. Amma biz hansısa şəkildə onların arasında məlumatları sinxronlaşdırmalıyıq.
Burada sadəcə yaxınlıqda asinxron növbə yaradırıq.
O, çox məşğul deyil. Biz bilirik ki, kifayət qədər qeydlərimiz yoxdur. Növbə sadəcə MySQL-də “bu şəklin ehtiyat nüsxəsini çıxartmalısınız” kimi sətirlərin yazıldığı cədvəldir. İstənilən dəyişiklik və ya yükləmə ilə biz asinxron və ya sadəcə bir növ fon işçisindən istifadə edərək əsas bölmədən ehtiyat nüsxəyə köçürüürük.
Beləliklə, bizdə həmişə iki ardıcıl bölmə var. Bu sistemin bir hissəsi uğursuz olsa belə, biz həmişə ehtiyat nüsxə ilə əsas bölməni dəyişə bilərik və hər şey işləməyə davam edəcək.
Ancaq buna görə oxu yükü çox artır, çünki... əsas bölmədən oxuyan müştərilərə əlavə olaraq, onlar əvvəlcə oradakı fotoşəkilə baxdıqları üçün (orada daha yenidir), sonra onu tapmayıblarsa, ehtiyat nüsxədə axtarırlar (lakin NGINX sadəcə bunu edir), sistemimiz də artıq əsas bölmədən oxunan bir artı ehtiyatdır. Bunun bir darboğaz olduğu deyildi, amma mən yükü artırmaq istəmədim, mahiyyətcə, eynilə.
Biz kiçik bir SSD olan üçüncü diski əlavə etdik və onu bufer adlandırdıq.
İndi necə işləyir.
İstifadəçi fotonu buferə yükləyir, sonra onun iki hissəyə kopyalanması lazım olduğunu bildirən hadisə növbəyə atılır. Kopyalanır və foto bir müddət (məsələn, bir gün) buferdə yaşayır və yalnız bundan sonra oradan təmizlənir. Bu, istifadəçi təcrübəsini çox yaxşılaşdırır, çünki istifadəçi bir şəkil yükləyir, bir qayda olaraq, sorğular dərhal izlənməyə başlayır və ya özü səhifəni yenilədi və təzələdi. Ancaq hamısı yükləməni edən proqramdan asılıdır.
Və ya, məsələn, özünü göstərməyə başladığı digər insanlar bu fotoşəkildən sonra dərhal sorğu göndərirlər. Hələ keşdə deyil, ilk sorğu çox tez baş verir. Əsasən fotoşəkil önbelleğindeki ilə eynidir. Yavaş saxlama bunda ümumiyyətlə iştirak etmir. Və bir gün sonra təmizləndikdə, o, artıq ya keşləmə qatımızda yaddaşda saxlanılır, ya da çox güman ki, artıq heç kimə lazım deyil. Bunlar. Buradakı istifadəçi təcrübəsi belə sadə manipulyasiyalar sayəsində çox yaxşı inkişaf etmişdir.
Yaxşı və ən əsası: məlumatları itirməyi dayandırdıq.
Deyək ki, dayandıq potensial olaraq məlumatları itirdik, çünki biz onu həqiqətən itirməmişik. Amma təhlükə var idi. Görürük ki, bu həll əlbəttə ki, yaxşıdır, lakin bu, bir az problemi tamamilə həll etmək əvəzinə, əlamətlərini hamarlaşdırmağa bənzəyir. Və burada bəzi problemlər qalmaqdadır.
Birincisi, bu, bütün bu mexanizmlərin işlədiyi fiziki hostun özü şəklində uğursuzluq nöqtəsidir; o, getməmişdir.
İkincisi, hələ də SAN-larla bağlı problemlər, onların ağır texniki xidməti və s. qalır. Bu, kritik bir amil deyildi, amma mən onsuz yaşamağa çalışmaq istədim.
Biz isə üçüncü versiyanı (əslində ikincisini) - rezervasiya versiyasını hazırladıq. Nə kimi görünürdü?
Bu belə idi -
Bizim əsas problemimiz bunun fiziki ev sahibi olması ilə bağlıdır.
Birincisi, biz SAN-ları silirik, çünki sınaqdan keçirmək istəyirik, sadəcə yerli sabit diskləri sınamaq istəyirik.
Bu, artıq 2014-2015-ci illərdir və o zaman bir hostda disklər və onların tutumu ilə bağlı vəziyyət xeyli yaxşılaşdı. Niyə cəhd etməməyə qərar verdik.
Və sonra biz sadəcə ehtiyat bölməmizi götürürük və fiziki olaraq ayrı bir maşına köçürürük.
Beləliklə, bu diaqramı əldə edirik. Eyni məlumat dəstlərini saxlayan iki avtomobilimiz var. Onlar bir-birinin ehtiyat nüsxəsini tamamilə çıxarır və eyni MySQL-də asinxron növbə vasitəsilə məlumatları şəbəkə üzərindən sinxronlaşdırırlar.
Bunun yaxşı işləməsinin səbəbi bizdə bir neçə qeydin olmasıdır. Bunlar. yazı oxumaqla müqayisə oluna bilsəydi, bəlkə də bir növ şəbəkə yükümüz və problemlərimiz olardı. Yazı azdır, çox oxuyur - bu üsul yaxşı işləyir, yəni. Biz nadir hallarda bu iki server arasında fotoşəkilləri kopyalayırıq.
Bu necə işləyir, bir az daha ətraflı baxsanız.
Yükləmək. Balanslaşdırıcı sadəcə bir cüt ilə təsadüfi hostları seçir və ona yükləyir. Eyni zamanda o, təbii olaraq sağlamlığını yoxlayır və maşının yıxılmamasını təmin edir. Bunlar. o, fotoşəkilləri yalnız canlı serverə yükləyir və sonra asinxron növbə vasitəsilə hamısı qonşusuna kopyalanır. Yükləmə ilə hər şey çox sadədir.
Tapşırıq bir az daha çətindir.
Lua burada bizə kömək etdi, çünki vanil NGINX-də belə bir məntiq yaratmaq çətin ola bilər. Əvvəlcə birinci serverə sorğu göndəririk, fotonun orada olub-olmadığını görürük, çünki potensial olaraq, məsələn, qonşuya yüklənə bilər, lakin hələ buraya gəlməyib. Şəkil oradadırsa, yaxşıdır. Biz onu dərhal müştəriyə veririk və ola bilsin ki, onu keşləyirik.
Əgər orada deyilsə, biz sadəcə qonşumuza müraciət edirik və onu oradan alacağımıza zəmanət verilir.
Bu. yenə deyə bilərik: performansla bağlı problemlər ola bilər, çünki daimi gediş-gəliş var - şəkil yüklənib, burada deyil, bir əvəzinə iki sorğu edirik, bu yavaş işləməlidir.
Bizim vəziyyətimizdə bu, yavaş işləmir.
Bu sistemdə bir dəstə metrik toplayırıq və belə bir mexanizmin şərti smart dərəcəsi təxminən 95% -dir. Bunlar. Bu ehtiyat nüsxəsinin gecikməsi kiçikdir və buna görə demək olar ki, zəmanət verilir, şəkil yükləndikdən sonra onu ilk dəfə çəkəcəyik və iki dəfə heç yerə getməməliyik.
Beləliklə, həqiqətən gözəl olan başqa nəyimiz var?
Əvvəllər əsas ehtiyat bölməmiz var idi və biz onlardan ardıcıl olaraq oxuduq. Bunlar. Biz həmişə əvvəlcə əsası, sonra ehtiyat nüsxəsini axtarırdıq. Bu bir hərəkət idi.
İndi biz eyni anda iki maşından oxumaqdan istifadə edirik. Biz Round Robin istifadə edərək sorğuları yayırıq. Çox az hallarda biz iki sorğu veririk. Amma ümumilikdə, indi əvvəlkindən iki dəfə çox oxu ehtiyatımız var. Həm göndərən maşınlarda, həm də birbaşa saxlama maşınlarında yük çox azaldı, o zaman bizdə də vardı.
Səhv tolerantlığına gəldikdə. Əslində, biz əsas mübarizə apardıq. Səhv tolerantlığı ilə burada hər şey əla oldu.
Bir maşın xarab olur.
Problem deyil! Sistem mühəndisi gecələr oyanmaya da bilər, səhərə qədər gözləyəcək, pis bir şey olmayacaq.
Əgər bu maşın sıradan çıxsa belə, növbə sıradan çıxıb, heç bir problem də yoxdur, sadəcə olaraq log əvvəlcə canlı maşında yığılacaq, sonra növbəyə, sonra isə həmin maşına əlavə olunacaq. bir müddət sonra işə salın.
Baxımla eyni şey. Biz sadəcə maşınlardan birini söndürürük, onu bütün hovuzlardan əl ilə çıxarırıq, o, trafiki qəbul etməyi dayandırır, bir növ texniki xidmət göstəririk, nəyisə redaktə edirik, sonra onu xidmətə qaytarırıq və bu ehtiyat nüsxəni kifayət qədər tez tutur. Bunlar. gündə bir avtomobilin dayanma müddəti bir neçə dəqiqəyə çatır. Bu, həqiqətən çox azdır. Səhvlərə dözümlülüklə, yenə deyirəm, burada hər şey sərindir.
Bu ixtisar sxemindən hansı nəticələr çıxarmaq olar?
Səhv tolerantlığımız var.
İstifadəsi asandır. Maşınların yerli sərt diskləri olduğundan, bu, onunla işləyən mühəndislər üçün əməliyyat baxımından daha əlverişlidir.
Biz ikiqat oxu haqqı aldıq.
Bu, səhvlərə dözümlülükdən əlavə çox yaxşı bir bonusdur.
Amma problemlər də var. İndi bununla bağlı bəzi xüsusiyyətlərin daha mürəkkəb inkişafı var, çünki sistem nəticədə 100% ardıcıl oldu.
Deyək ki, hansısa fon işində daim düşünməliyik: “Hazırda hansı serverdə işləyirik?”, “Həqiqətən burada cari bir şəkil varmı?” və s. Bu, əlbəttə ki, hər şey yekunlaşdırılıb və biznes məntiqini yazan proqramçı üçün şəffafdır. Ancaq buna baxmayaraq, bu böyük mürəkkəb təbəqə meydana çıxdı. Amma biz ondan aldığımız nemətlər müqabilində buna dözməyə hazırıq.
Və burada yenə bəzi münaqişələr yaranır.
Başda dedim ki, hər şeyi yerli sərt disklərdə saxlamaq pisdir. İndi də deyirəm ki, xoşumuza gəldi.
Bəli, həqiqətən, zaman keçdikcə vəziyyət çox dəyişdi və indi bu yanaşmanın bir çox üstünlükləri var. Birincisi, biz daha sadə əməliyyat əldə edirik.
İkincisi, bu, daha məhsuldardır, çünki bizdə bu avtomatik kontrollerlər və ya disk rəfləri ilə əlaqə yoxdur.
Orada çoxlu sayda maşın var və bunlar maşında basqın halında yığılmış bir neçə diskdir.
Ancaq mənfi cəhətləri də var.
Bu, hətta indiki qiymətlərlə SAN-ların istifadəsindən təxminən 1,5 dəfə bahadır. Buna görə də, bütün böyük klasterimizi cəsarətlə yerli sabit diskləri olan avtomobillərə çevirməmək qərarına gəldik və hibrid bir həll buraxmağa qərar verdik.
Maşınlarımızın yarısı sərt disklərlə işləyir (yaxşı, yarısı deyil - yəqin ki, 30 faiz). Qalanları isə əvvəllər ilk rezervasiya sxeminə malik olan köhnə avtomobillərdir. Biz onları sadəcə olaraq yenidən quraşdırdıq, çünki yeni məlumatlara və ya başqa bir şeyə ehtiyacımız olmadığı üçün montajları bir fiziki hostdan ikiyə köçürdük.
İndi bizim böyük oxu ehtiyatımız var və biz onu genişləndirdik. Əvvəllər bir anbarı bir maşına quraşdırırdıqsa, indi dördü, məsələn, bir cütə quraşdırırıq. Və yaxşı işləyir.
Nəyə nail olduğumuzu, nə üçün mübarizə apardığımızı və uğur qazanıb-bağlamadığımızı qısaca xülasə edək.
Nəticələri
İstifadəçilərimiz var - 33 milyona qədər.
Bizim üç mövcud nöqtəmiz var - Praqa, Mayami, Honq Konq.
Onların tərkibində NGINX-dən sadə mexanizmlər, onun access.log və Python demonları işləyən, bütün bunları emal edən və keşi idarə edən sürətli lokal disklərə (SSD) malik avtomobillərdən ibarət keşləmə qatı daxildir.
İstəyirsinizsə, siz layihənizdəsiniz, əgər fotoşəkillər sizin üçün bizim üçün olduğu qədər kritik deyilsə və ya inkişaf sürəti və resurs xərclərinə qarşı nəzarət sizin üçün başqa istiqamətdədirsə, onu təhlükəsiz şəkildə əvəz edə bilərsiniz. CDN ilə müasir CDN-lər yaxşı işləyirlər.
Sonra bir-birinin ehtiyat nüsxəsini çıxaran maşın cütlərinin çoxluq etdiyi yaddaş təbəqəsi gəlir, fayllar hər dəfə dəyişdirildikdə asinxron olaraq birindən digərinə kopyalanır.
Üstəlik, bu maşınların bəziləri yerli sabit disklərlə işləyir.
Bu maşınların bəziləri SAN-lara qoşulur.
Və, bir tərəfdən, istifadəsi daha rahat və bir az daha məhsuldardır, digər tərəfdən, yerləşdirmə sıxlığı və gigabayt üçün qiymət baxımından əlverişlidir.
Bu, əldə etdiklərimizin arxitekturasına və hamısının necə inkişaf etdiyinə dair qısa bir xülasədir.
Kapitandan daha bir neçə məsləhət, çox sadə olanlar.
Birincisi, birdən foto infrastrukturunuzdakı hər şeyi təcili olaraq təkmilləşdirməli olduğunuza qərar versəniz, əvvəlcə ölçün, çünki bəlkə də heç nəyi yaxşılaşdırmaq lazım deyil.
Sizə bir misal deyim. Çatlarda əlavələrdən fotoşəkillər göndərən bir çox maşın var və sxem 2009-cu ildən orada işləyir və heç kim bundan əziyyət çəkmir. Hamı yaxşıdır, hamı hər şeyi bəyənir.
Ölçmək üçün əvvəlcə bir sıra ölçüləri asın, onlara baxın və sonra nədən narazı olduğunuzu və nəyin təkmilləşdirilməsi lazım olduğuna qərar verin. Bunu ölçmək üçün Pinba adlı sərin alətimiz var.
O, NGINX-dən hər sorğu və cavab kodları, vaxt bölgüsü - istədiyiniz hər şey üçün çox ətraflı statistika toplamağa imkan verir. Onun hər cür müxtəlif analitik sistemlərə bağlanması var və sonra siz hamısına gözəl baxa bilərsiniz.
Əvvəlcə ölçdük, sonra təkmilləşdirdik.
Daha. Biz önbellek ilə oxumağı, sharding ilə yazmağı optimallaşdırırıq, lakin bu açıq bir məqamdır.
Daha. Əgər siz indi sisteminizi qurmağa başlayırsınızsa, o zaman fotoşəkilləri dəyişməz fayllar kimi etmək daha yaxşıdır. Çünki siz dərhal keşin etibarsızlığı, məntiqin fotoşəkilin düzgün versiyasını necə tapması və s. ilə bağlı bütün problemləri itirirsiniz.
Tutaq ki, yüz yüklədiniz, sonra onu çevirdiniz, fiziki olaraq fərqli bir fayl olsun. Bunlar. düşünməyə ehtiyac yoxdur: indi bir az yer saxlayacağam, eyni fayla yazacam, versiyanı dəyişəcəyəm. Bu həmişə yaxşı işləmir və sonradan çoxlu baş ağrısına səbəb olur.
Növbəti nöqtə. Tez ölçüsünü dəyişmək haqqında.
Əvvəllər, istifadəçilər bir fotoşəkil yüklədikdə, biz dərhal bütün hallar üçün, müxtəlif müştərilər üçün bütün ölçüləri kəsdik və hamısı diskdə idi. İndi biz bundan imtina etmişik.
Biz yalnız üç əsas ölçü buraxdıq: kiçik, orta və böyük. Biz sadəcə olaraq Uport-da bizə tələb olunan ölçüdən geridə qalan hər şeyi azaldırıq, sadəcə olaraq kiçildirik və istifadəçiyə veririk.
Buradakı keşləmə qatının CPU-su hər anbarda bu ölçüləri daim bərpa etdiyimizdən daha ucuz olur. Tutaq ki, biz yenisini əlavə etmək istəyirik, bu, bir ay çəkəcək - klasteri məhv etmədən bütün bunları səliqəli şəkildə yerinə yetirəcək bir skript işlədin. Bunlar. İndi seçmək imkanınız varsa, mümkün qədər az fiziki ölçülər etmək daha yaxşıdır, lakin ən azı bir paylama, deyək ki, üç olsun. Qalan hər şey hazır modullardan istifadə edərək tez bir zamanda ölçüsünü dəyişdirilə bilər. İndi hər şey çox asandır və əlçatandır.
Və artımlı asinxron ehtiyat yaxşıdır.
Təcrübəmiz göstərdiyi kimi, bu sxem dəyişdirilmiş faylların gecikmiş surətinin çıxarılması ilə əla işləyir.
Sonuncu məqam da göz qabağındadır. Əgər indi sizin infrastrukturunuzda belə problemlər yoxdursa, amma qırıla biləcək bir şey varsa, bir az daha çox olanda mütləq qırılacaq. Buna görə də, bu barədə əvvəlcədən düşünmək və bununla bağlı problem yaşamamaq daha yaxşıdır. Bütün demək istədiyim bu idi.
əlaqə
»
»
Bu hesabat yüksək yüklü sistemlərin tərtibatçılarının konfransında ən yaxşı çıxışlardan birinin stenoqramıdır . HighLoad++ 2017 konfransına bir aydan az vaxt qalıb.
Bizdə artıq hazırdır , qrafik hazırda fəal şəkildə formalaşdırılır.
Bu il biz memarlıq və miqyaslama mövzusunu araşdırmağa davam edirik:
- / İqor Vasilyev
- / Dmitri Eqorov
- / Anatoli Plaskovski
- / Roman Şexovtsov, Aleksey Qromatçikov
- / Filip Delqado
Biz bu materiallardan bəzilərini yüksək yüklü sistemlərin inkişafı üzrə onlayn təlim kursumuzda da istifadə edirik xüsusi seçilmiş məktublar, məqalələr, materiallar, videolar silsiləsi. Dərsliyimizdə artıq 30-dan çox unikal material var. Qoşulun!
Mənbə: www.habr.com