Yayda həm alış aktivliyi, həm də veb layihələrin infrastrukturunda dəyişikliklərin intensivliyi ənənəvi olaraq azalır, Kapitan Obvious bizə deyir. Sadəcə ona görə ki, hətta İT mütəxəssisləri də bəzən məzuniyyətə çıxırlar. Və CTO da. Vəzifədə qalanlar üçün hər şey daha çətindir, amma indi vacib deyil: bəlkə də buna görə yay mövcud rezervasiya sxemi haqqında yavaş-yavaş düşünmək və onu təkmilləşdirmək üçün plan hazırlamaq üçün ən yaxşı dövrdür. Və Yeqor Andreevin təcrübəsi , bu barədə konfransda danışıb .
Ehtiyat saytlar qurarkən düşə biləcəyiniz bir neçə tələ var. Və onlara tutulmaq tamamilə mümkün deyil. Bütün bunlarda da bizi məhv edən, bir çox başqa şeylərdə olduğu kimi, mükəmməllik və... tənbəllikdir. Biz hər şeyi, hər şeyi, hər şeyi mükəmməl etməyə çalışırıq, amma bunu mükəmməl etməyə ehtiyac yoxdur! Sadəcə müəyyən işləri görmək lazımdır, lakin onları düzgün etmək, düzgün işləməsi üçün tamamlamaq lazımdır.
Failover bir növ əyləncəli, əyləncəli bir şey deyil; bu, tam olaraq bir şeyi etməli olan bir şeydir - dayanma müddətini azaldın ki, xidmət, şirkət daha az pul itirsin. Və bütün rezervasiya üsullarında aşağıdakı kontekstdə düşünməyi təklif edirəm: pul haradadır?
İlk tələ: böyük, etibarlı sistemlər qurduqda və ehtiyatla məşğul olduqda, qəzaların sayını azaldırıq. Bu dəhşətli yanlış fikirdir. Biz ixtisarla məşğul olduğumuz zaman qəzaların sayını artıra bilərik. Və hər şeyi düzgün etsək, kollektiv olaraq dayanma müddətini azaldacağıq. Daha çox qəzalar olacaq, lakin daha az xərclə baş verəcəklər. Rezervasiya nədir? - bu sistemin mürəkkəbliyidir. Hər hansı bir fəsad pisdir: bizdə daha çox dişli, daha çox dişli, bir sözlə, daha çox element var - və buna görə də, daha yüksək sıradan çıxma şansı. Və həqiqətən qırılacaqlar. Və daha tez-tez qırılacaqlar. Sadə bir misal: tutaq ki, bizim PHP və MySQL ilə veb saytımız var. Və təcili olaraq rezerv edilməlidir.
Shtosh (c) Biz ikinci saytı götürürük, eyni sistem qururuq... Mürəkkəblik iki dəfə böyük olur - bizdə iki varlıq var. Biz həmçinin məlumatların bir saytdan digərinə ötürülməsi üçün müəyyən bir məntiq tətbiq edirik - yəni məlumatların təkrarlanması, statik məlumatların surətinin çıxarılması və s. Deməli, təkrarlama məntiqi adətən çox mürəkkəbdir və buna görə də sistemin ümumi mürəkkəbliyi 2 yox, 3, 5, 10 dəfə çox ola bilər.
İkinci tələ: həqiqətən böyük mürəkkəb sistemlər qurarkən, sonda nə əldə etmək istədiyimizi xəyal edirik. Voila: biz heç bir fasiləsiz işləyən, yarım saniyəyə (yaxud daha yaxşısı, dərhal) dəyişən super etibarlı sistem əldə etmək istəyirik və biz xəyalları gerçəkləşdirməyə başlayırıq. Ancaq burada bir nüans da var: istədiyiniz keçid vaxtı nə qədər qısa olarsa, sistemin məntiqi bir o qədər mürəkkəbləşir. Bu məntiqi nə qədər mürəkkəb etməliyiksə, sistem bir o qədər tez-tez sıradan çıxacaq. Və sonda çox xoşagəlməz bir vəziyyətə düşə bilərsiniz: biz bütün gücümüzlə dayanma müddətini azaltmağa çalışırıq, amma əslində biz hər şeyi daha da mürəkkəbləşdiririk və bir şey səhv olanda, dayanma müddəti daha uzun olacaq. Burada tez-tez fikirləşirsən: yaxşı... rezervasiya etməsən yaxşı olardı. Tək və başa düşülən fasilələrlə işləsəydi, daha yaxşı olardı.
Bununla necə mübarizə apara bilərsiniz? Biz özümüzə yalan danışmağı dayandırmalıyıq, indi burada bir kosmik gəmi inşa edəcəyik deyə özümüzə yaltaqlanmağı dayandırmalıyıq, amma layihənin nə qədər yalan danışa biləcəyini adekvat şəkildə başa düşməliyik. Və bu maksimum müddət ərzində sistemimizin etibarlılığını artırmaq üçün əslində hansı üsullardan istifadə edəcəyimizi seçəcəyik.
Əlbəttə ki, “w-dən hekayələr”in vaxtıdır... həyatdan.
Bir nömrəli nümunə
N şəhərindəki 1 nömrəli boru prokat zavodunun vizit kartı saytını təsəvvür edin. Orada nəhəng hərflərlə yazılır - 1 nömrəli BORU PROKƏMİ ZAVOVASI. Bir az aşağıda şüar var: “Bizim borularımız N-də ən dairəvi borulardır”. Və aşağıda CEO-nun telefon nömrəsi və adı var. Biz anlayırıq ki, rezervasiya etməlisiniz - bu çox vacib bir şeydir! Onun nədən ibarət olduğunu anlamağa başlayaq. Html-statika - yəni baş menecerin, əslində, tərəfdaşı ilə hamamdakı masada bir növ növbəti sövdələşməni müzakirə etdiyi bir neçə şəkil. Biz fasilələr haqqında düşünməyə başlayırıq. Ağlıma gəlir: orada beş dəqiqə yatmaq lazımdır, daha çox deyil. Və sonra sual yaranır: ümumiyyətlə bizim bu saytdan nə qədər satış olub? Nə qədər - nə qədər? "Sıfır" nə deməkdir? Bu da o deməkdir ki, general keçən il dörd əməliyyatın hamısını eyni masada, hamama getdikləri və masa arxasında oturduqları eyni adamlarla etdi. Və başa düşürük ki, sayt bir gün otursa belə, dəhşətli bir şey olmayacaq.
Giriş məlumatlarına əsasən, bu hekayəni qaldırmaq üçün bir gün var. İşdən çıxarılma sxemi haqqında düşünməyə başlayaq. Və biz bu misal üçün ən ideal artıqlıq sxemini seçirik: biz artıqlıqdan istifadə etmirik. Bütün bunları tüstü fasilələri ilə yarım saat ərzində istənilən admin qaldıra bilər. Veb server quraşdırın, fayllar əlavə edin - budur. Bu işləyəcək. Heç bir şeyə diqqət yetirmək lazım deyil, heç bir şeyə xüsusi diqqət yetirmək lazım deyil. Yəni, bir nömrəli misaldan gələn nəticə olduqca açıqdır: rezervasiyaya ehtiyacı olmayan xidmətlərin rezervasiyasına ehtiyac yoxdur.
İkinci nömrəli misal
Şirkət bloqu: orada xüsusi təlim keçmiş insanlar xəbər yazır, filan sərgidə iştirak etdik, amma daha bir yeni məhsul buraxdıq və s. Deyək ki, bu, WordPress ilə standart PHP, kiçik verilənlər bazası və bir az statikdir. Əlbətdə ki, bir daha ağlınıza gəlir ki, heç bir halda uzanmamalısınız - "beş dəqiqədən çox deyil!" Hamısı budur. Ancaq daha çox düşünək. Bu blog nə edir? İnsanlar oraya Yandex-dən, Google-dan bəzi sorğular əsasında üzvi şəkildə gəlirlər. Əla. Satışın bununla əlaqəsi varmı? Epiphany: həqiqətən yox. Reklam trafiki başqa bir maşında olan əsas sayta gedir. Bir rezervasiya sxemi haqqında düşünməyə başlayaq. Yaxşı mənada, bir-iki saata qaldırılmalıdır və buna hazırlaşmaq yaxşı olardı. Başqa bir məlumat mərkəzindən maşın götürüb ətraf mühiti, yəni veb serveri, PHP, WordPress, MySQL-i onun üzərinə sürüb orada buraxmaq məqsədəuyğun olardı. Hər şeyin pozulduğunu anladığımız anda, iki şey etməliyik - mysql zibilini 50 metrə yaymaq, bir dəqiqədən sonra orada uçacaq və oradakı ehtiyat nüsxədən müəyyən sayda şəkilləri yaymaq. Bu da yoxdur, Allah bilir nə qədərdir. Beləliklə, yarım saat ərzində hər şey yüksəlir. Replikasiya yoxdur və ya Allah məni bağışlasın, avtomatik uğursuzluq. Nəticə: ehtiyat nüsxədən tez çıxara biləcəyimiz şeylərin ehtiyat nüsxəsini çıxarmaq lazım deyil.
Üçüncü nümunə, daha mürəkkəbdir
Online mağaza. Açıq ürəkli PhP bir az dəyişdirilmişdir, möhkəm baza ilə mysql. Olduqca statik (hər şeydən sonra onlayn mağazada gözəl HD şəkillər və bütün bunlar var), sessiya üçün Redis və axtarış üçün Elasticsearch. Biz fasilələr haqqında düşünməyə başlayırıq. Və burada, əlbəttə ki, bir onlayn mağazanın bir gün ərzində ağrısız uzana bilməyəcəyi açıqdır. Axı, yalan nə qədər uzun olsa, bir o qədər çox pul itiririk. Sürətləndirməyə dəyər. Nə qədər? Məncə, bir saat uzansaq, heç kim dəli olmaz. Bəli, nəyisə itirəcəyik, amma çox işləməyə başlasaq, daha da pisləşəcək. Biz saatda icazə verilən fasilələrin sxemini müəyyən edirik.
Bütün bunları necə rezerv etmək olar? İstənilən halda avtomobilə ehtiyacınız var: bir saat vaxt olduqca azdır. Mysql: burada bizə artıq replikasiya, canlı replikasiya lazımdır, çünki bir saatdan sonra 100 GB çox güman ki, zibilliyə əlavə edilməyəcək. Statika, şəkillər: yenə bir saat sonra 500 GB əlavə etməyə vaxt olmaya bilər. Buna görə də, şəkilləri dərhal köçürmək daha yaxşıdır. Redis: işlərin maraqlı olduğu yer budur. Redis-də seanslar saxlanılır - biz sadəcə onu götürüb basdıra bilmərik. Çünki bu çox yaxşı olmayacaq: bütün istifadəçilər sistemdən çıxacaq, səbətləri boşalacaq və s. İnsanlar istifadəçi adlarını və şifrələrini yenidən daxil etməyə məcbur olacaqlar və bir çox insanlar ayrılıb satınalmanı tamamlamaya bilər. Yenə də dönüşümlər azalacaq. Digər tərəfdən, Redis birbaşa yenilənir, son daxil olan istifadəçilər də yəqin ki, lazım deyil. Yaxşı bir kompromis Redis-i götürüb dünənki ehtiyat nüsxədən bərpa etməkdir və ya bunu hər saat edirsinizsə, bir saat əvvəldən. Xoşbəxtlikdən, onu ehtiyat nüsxədən bərpa etmək bir faylı kopyalamaq deməkdir. Ən maraqlı hekayə isə Elasticsearch-dir. Kim heç MySQL replikasiyasını götürüb? Elasticsearch replikasiyasını kim götürüb? Və kimlər üçün normal işlədikdən sonra? Demək istədiyim odur ki, sistemimizdə müəyyən bir varlıq görürük. Faydalı görünür - lakin mürəkkəbdir.
Mühəndis yoldaşlarımızın onunla işləmək təcrübəsi olmadığı mənasında mürəkkəbdir. Və ya mənfi təcrübə var. Yaxud başa düşürük ki, bu hələ nüansları və ya xamlığı olan kifayət qədər yeni texnologiyadır. Düşünürük ki... Lənət olsun, elastiklik də sağlamdır, onu ehtiyat nüsxədən bərpa etmək də çox vaxt aparır, nə etməliyəm? Başa düşürük ki, bizim vəziyyətimizdə elastik axtarış üçün istifadə olunur. Onlayn mağazamız necə satılır? Marketoloqlara gedib insanların haradan gəldiyini soruşuruq. Cavab verirlər: "Yandex Marketdən 90% birbaşa məhsul kartına gəlir." Və ya alırlar, ya da almırlar. Buna görə də istifadəçilərin 10%-i axtarışa ehtiyac duyur. Xüsusilə müxtəlif zonalardakı müxtəlif məlumat mərkəzləri arasında elastik replikasiyanın qorunması, həqiqətən də çoxlu nüanslar var. Hansı çıxış? Biz qorunan saytdan elastiki götürürük və onunla heç nə etmirik. Əgər məsələ uzanarsa, yəqin ki, nə vaxtsa onu qaldıracağıq, amma bu dəqiq deyil. Əslində, nəticə eynidir, müsbət və ya mənfi: biz yenə də pula təsir etməyən xidmətləri rezerv etmirik. Diaqramı daha sadə saxlamaq üçün.
Dördüncü nümunə, daha da çətin
İnteqrator: çiçək satmaq, taksi çağırmaq, mal satmaq, ümumiyyətlə, hər hansı bir şey. Çox sayda istifadəçi üçün 24/7 işləyən ciddi bir şey. Maraqlı əsasların, həllərin, yüksək yükün və ən əsası, 5 dəqiqədən çox uzanmaq üçün ağrılı olduğu tam hüquqlu maraqlı yığınla. Nəinki və o qədər də çox deyil, çünki insanlar almayacaqlar, həm də insanlar bu şeyin işləmədiyini görəcəklər, əsəbiləşəcəklər və ümumiyyətlə geri qayıtmaya bilərlər.
TAMAM. Beş dəqiqə. Bununla bağlı nə edəcəyik? Bu halda, biz, böyüklər kimi, hər şeyin təkrarlanması ilə real ehtiyat sayt yaratmaq üçün bütün pullardan istifadə edirik və bəlkə də bu sayta keçidi mümkün qədər avtomatlaşdırırıq. Bundan əlavə, bir vacib şeyi etməyi unutmamalısınız: əslində, keçid qaydalarını yazın. Hər şey avtomatlaşdırılmış olsa belə, qaydalar çox sadə ola bilər. "Belə və belə bir əsaslı skript işlədin", "53 nömrəli marşrutda filan və belə bir onay qutusunu vurun" və s. - lakin bu, bir növ hərəkətlərin dəqiq siyahısı olmalıdır.
Və hər şey aydın görünür. Replikasiyanın dəyişdirilməsi mənasız bir işdir, yoxsa o, özü dəyişəcək. DNS-də domen adının yenidən yazılması eyni seriyadandır. Problem ondadır ki, belə bir layihə uğursuz olduqda panika başlayır və hətta ən güclü, saqqallı adminlər belə buna həssas ola bilər. “Terminalını aç, bura gəl, serverimizin ünvanı hələ belədir” kimi aydın göstərişlər olmadan reanimasiya üçün ayrılmış 5 dəqiqəlik müddətə çatmaq çətindir. Yaxşı, üstəlik, biz bu reqlamentlərdən istifadə etdikdə, məsələn, infrastrukturda bəzi dəyişiklikləri qeyd etmək və qaydalara uyğun olaraq dəyişdirmək asandır.
Yaxşı, əgər rezervasiya sistemi çox mürəkkəbdirsə və bir anda səhv etmişiksə, o zaman ehtiyat saytımızı məhv edə bilərik və əlavə olaraq məlumatları hər iki saytda balqabaq halına gətirə bilərik - bu tamamilə kədərli olacaq.
Beşinci misal, tam hardcore
Dünyada yüz milyonlarla istifadəçisi olan beynəlxalq xidmət. Bütün vaxt zonaları var, maksimum sürətlə yüksək yük, ümumiyyətlə uzana bilməzsiniz. Bir dəqiqə - və kədərli olacaq. Nə etməli? Yenə tam proqrama uyğun olaraq ehtiyat edin. Əvvəlki nümunədə danışdığım hər şeyi etdik və bir az daha çox. İdeal bir dünya və infrastrukturumuz IaaC devops-un bütün konsepsiyalarına uyğundur. Yəni hər şey git-dədir və siz sadəcə düyməni sıxırsınız.
Nə çatışmır? Biri - məşqlər. Onlarsız mümkün deyil. Deyəsən bizdə hər şey mükəmməldir, ümumiyyətlə hər şey nəzarət altındadır. Düyməni basırıq, hər şey olur. Bu belə olsa belə - və bunun belə baş vermədiyini başa düşürük - sistemimiz bəzi digər sistemlərlə qarşılıqlı əlaqədə olur. Məsələn, bu, 53 marşrutundan dns, s3 saxlama, bəzi api ilə inteqrasiyadır. Bu spekulyativ təcrübədə hər şeyi qabaqcadan görə bilməyəcəyik. Və həqiqətən keçidi çəkənə qədər onun işləyəcəyini bilməyəcəyik.
Yəqin ki, hamısı budur. Tənbəl olmayın və ya həddindən artıq çox etməyin. Və iş vaxtı sizinlə olsun!
Mənbə: www.habr.com