Backend mühəndisləri üçün bulud arxitekturasının əsasları

Problem: serveri buluda köçürüb onun düzgün davranmasını gözləmək

Komanda Spring Boot servisini icarəyə götürülmüş tək serverdən bulud hesabına köçürür. O, bir virtual maşında işləyir, yüklənmiş faylları lokal diskdə saxlayır, session-ları yaddaşda tutur və eyni maşında quraşdırılmış bazaya qoşulur. Bir aydan sonra provayder maşını texniki xidmət üçün restart edir, session-lar yox olur, fayllar itir, hesabda isə heç kimin başa düşmədiyi maddələr görünür. Bulud vəd etdiyini etdi: resurslar icarəyədir, istənilən vaxt dəyişdirilə bilər və istifadəyə görə ödənilir. Arxitektura isə uyğunlaşmadı.

Bu məqalə servisin istənilən böyük provayderdə düzgün işləməsini təmin edən terminologiya və dizayn vərdişlərini verir. AWS, Azure və Google Cloud-da adlar fərqlənir, kateqoriyalar isə eynidir.

Region və availability zone-lar

Region bir neçə müstəqil data mərkəzi qrupu olan coğrafi ərazidir. Availability zone region daxilində öz enerji və şəbəkəsi olan belə izolyasiya olunmuş qruplardan biridir. Bir regiondakı zonalar aşağı gecikməli xətlərlə birləşdirilir.

• Instance-ları ən azı iki zonada işlətmək bir zonanın çökməsindən qoruyur. Bütün regionu əhatə edən problemdən və ya öz səhv deploy-unuzdan qorumur.
• Regionu istifadəçilərinizin yerinə, data residency və hüquqi tələblərə, lazım olan servislərə görə seçin. Regionlar arasında gecikmə zonalararasından nəzərəçarpacaq dərəcədə yüksəkdir və datanın onlar arasında daşınması adətən ödənişlidir.
• Multi-region dizaynlar data replikasiyası, konflikt idarəsi və əməliyyat mürəkkəbliyi əlavə edir. Multi-zone ilə başlayın, multi-region-a yalnız tələb (əlçatanlıq hədəfi və ya qanun) əsaslandırdıqda keçin.

Stateless servislər

Stateless servis sorğular arasında sorğu ilə bağlı datanı öz prosesində və ya diskində saxlamır. Sağ qalmalı olan hər şey paylaşılan yerə yazılır.

          ┌──────────────┐
 users -> │ load balancer│
          └──────┬───────┘
        ┌────────┼────────┐
     [app]    [app]    [app]     <- replaceable, in several zones
        └────┬───────┬────┘
         [database] [object storage] [cache]

İstənilən app instance-ı heç nə itirmədən öldürülüb əvəz oluna bilirsə, horizontal miqyaslaya, rolling update ilə deploy edə və node uğursuzluqlarına dözə bilərsiniz. Praktik nəticələr: session və ya token-lər paylaşılan yerdə (və ya stateless token), yüklənmiş fayllar object storage-də, konfiqurasiya mühitdən, planlaşdırılmış job-lar iki instance-ın eyni job-u eyni anda işlətməyəcəyi şəkildə, log-lar isə diskdə qalmaq əvəzinə instance-dan kənara göndərilir.

Managed və self-hosted servislər

Hər tikinti blokunu (baza, keş, message broker, axtarış) ya virtual maşın və ya container üzərində özünüz işlədirsiniz, ya da provayderin managed təklifindən istifadə edirsiniz.

Managed servislər adətən kiçik və orta komandalar üçün qalib gəlir, çünki bazanı işlətməyin çətin hissəsi onu quraşdırmaq deyil, uğursuzluqlar və yenilənmələr boyunca idarə etməkdir. Self-hosting xüsusi versiya və ya extension, sərt nəzarət lazım olanda və ya managed təklif uyğun gəlmədikdə məntiqlidir. Mümkün olan yerdə interfeysi standart saxlayın (PostgreSQL protokolu, Kafka protokolu, S3 tipli object API), belə ki, provayderi dəyişmək yenidən yazma yox, layihə olsun.

Baza seçimi

Moda ilə yox, giriş nümunələri ilə başlayın.

• Relational baza tranzaksiyalı biznes datası üçün standart seçimdir: constraint-lər, join-lər və transaction-lar dəyərlidir. Managed PostgreSQL çox geniş ehtiyac spektrini örtür.
• Key-value və ya document store açarla əldə olunan, forması çevik, yazı yükü çox yüksək data üçün uyğundur, qeydlər arasında uyğunluğun zəif olması bahasına.
• Keş (yaddaş saxlayıcısı) oxumanı sürətləndirir, amma həqiqət mənbəyi deyil.
• Object storage fayllar və böyük blob-lar üçündür; ucuz və davamlıdır, amma sürətli təsadüfi yeniləməsi olan fayl sistemi deyil.
• Axtarış mühərriki full-text və faceted sorğular üçündür, adətən əsas bazadan qidalanır.

Bir neçə data saxlayıcı əlavə etmək əməliyyat yükünü və aralarındakı uyğunluq problemlərini artırır. Bunu ölçülmüş ehtiyac olanda edin.

Xərc amilləri

Qiymətlər dəyişir və provayderə görə fərqlənir, ona görə onları əzbərləməyin; hesabı nəyin formalaşdırdığını öyrənin.

• İşləyən instance-ların hesablama vaxtı, o cümlədən boş və artıq böyük olanlar.
• Saxlama həcmi və tipi, xüsusilə heç vaxt silinməyən snapshot-lar və log-lar.
• Data transferi, xüsusən provayderdən çıxan trafik və zonalar və ya regionlar arasındakı trafik.
• Managed servis səviyyələri, o cümlədən sorğular, əməliyyatlar və ya ayrılmış tutum.
• Observability datası: limitsiz qəbul edilərsə, log və metriklər böyük maddəyə çevrilə bilər.
• Unudulmuş resurslar: test mühitləri, qoşulmamış disklər, köhnə image-lər.

Praktik nəzarət vasitələri: hər resursu komanda və mühit tag-ı ilə işarələyin, büdcə və alert-lər qurun, qeyri-production mühitləri iş saatlarından kənarda söndürün, log və snapshot üçün saxlama müddəti təyin edin, hesabı dizayn qərarlarını verən insanlarla müntəzəm nəzərdən keçirin. Autoscaling kömək edir, amma səhvi də böyük hesaba qədər miqyaslaya bilər, ona görə yuxarı hədd qoyun.

Shared-responsibility modeli

Provayder buludun özünün təhlükəsizliyinə cavabdehdir: fiziki obyektlər, avadanlıq və virtualizasiya qatı. Siz buludun içindəki təhlükəsizliyə cavabdehsiniz: identity və access management, şəbəkə qaydaları, data təsnifatı və şifrələmə seçimləri, işlətdiyiniz hər şeyin patch-i və tətbiq kodunuz. Bölgü servis tipinə görə dəyişir: virtual maşınlarda əməliyyat sistemini siz yeniləyirsiniz; managed bazada mühərriki provayder yeniləyir, amma istifadəçilər, icazələr, şəbəkə açıqlığı və backup siyasəti yenə sizindir.

İnsidentlərdə ən çox rast gəlinən səhvlər müştəri tərəfindədir: ictimai edilmiş storage bucket, həddindən artıq səlahiyyətli rol, internetdən əlçatan baza, sızmış access key. Hər servis üçün minimum səlahiyyətli identity istifadə edin, bazaları private şəbəkədə saxlayın, sirləri xüsusi secret store-da idarə edin.

Tez-tez edilən səhvlər

• Bulud VM-ə əl ilə dəyişikliklər edilən "ev heyvanı" server kimi yanaşmaq. Mühitlərin yenidən yaradıla bilməsi üçün infrastrukturu kod kimi təsvir edin.
• Hər şey üçün bir nəhəng ortaq hesab və ya subscription. Mühitləri və sahiblik sərhədlərini ayırın.
• Hər yerdə ən yüksək əlçatanlıq quraşdırmasından istifadə. Dizaynı real tələbə uyğunlaşdırın.
• Çox danışan servis dizaynlarında egress və zonalararası trafik xərcini nəzərə almamaq.
• Test olunmuş backup bərpası yoxdur. Heç vaxt bərpa etmədiyiniz backup ümiddir.
• Çıxış xərcini bilmədən provayderə xas imkanlara görə dizayn etmək.

Güzəştlər

Managed servislər əziyyəti azaldır, amma bir vendordan asılılığı artırır. Multi-cloud lock-in-dən qaçır, amma lazım olan bacarıq və alətləri ikiqat artırır; əksər komandalar standart interfeyslərlə bir provayderdə təmiz dizayndan daha çox qazanır. Serverless funksiyalar server idarəsini aradan qaldırır və sıfıra qədər miqyaslanır, amma cold start, icra limitləri və fərqli debug-ı var; onlar uzunmüddətli stateful yüklərdən çox event-driven və sıçrayışlı yüklərə uyğundur. Kubernetes portativ platforma verir, onu öyrənmək və işlətmək bahasına.

Yoxlama siyahısı

• Əlçatan qalmalı hər şey üçün ən azı iki zona.
• Stateless tətbiq instance-ları; fayllar object storage-də.
• Self-host etmək üçün səbəbiniz yoxdursa, managed servislər.
• Bazalar private şəbəkədə, test olunmuş backup-larla.
• Minimum səlahiyyətli identity-lər və sirlər secret store-da.
• Tag-lar, büdcələr və saxlama siyasətləri təyin olunub.

Növbəti addım

• Servisi istənilən platforma üçün Java servisləri üçün Docker ilə paketləyin.
• Bulud səbəb olacaq uğursuzluqlara Distributed sistemlərdə uğursuzluğun idarəsi ilə hazırlaşın.
• Bu seçimlər üzərində mühakimə yürütməyi solution architect roadmap ilə məşq edin.