Buludlar sehrli qutuya bənzəyir - siz nəyə ehtiyacınız olduğunu soruşursunuz və resurslar heç bir yerdən görünmür. Virtual maşınlar, verilənlər bazası, şəbəkə - bütün bunlar yalnız sizə məxsusdur. Başqa bulud kirayəçiləri var, lakin Kainatınızda yeganə hökmdar sizsiniz. Siz həmişə tələb olunan resursları alacağınıza əminsiniz, heç kimi nəzərə almırsınız və şəbəkənin necə olacağını müstəqil şəkildə müəyyənləşdirirsiniz. Buludu elastik şəkildə resursları bölüşdürən və kirayəçiləri bir-birindən tamamilə təcrid edən bu sehr necə işləyir?
AWS bulud 2006-cı ildən bəri təkamül yolu ilə inkişaf edən meqa-super mürəkkəb sistemdir. Bu inkişafın bir hissəsi baş verdi Vasili Pantyuxin - Amazon Web Services Architect. Bir memar olaraq, o, yalnız son nəticəyə deyil, həm də AWS-nin dəf etdiyi çətinliklərə daxili baxış əldə edir. Sistemin necə işlədiyini başa düşmək nə qədər çox olarsa, etibar da bir o qədər çox olar. Buna görə də Vasili AWS bulud xidmətlərinin sirlərini bölüşəcək. Aşağıda fiziki AWS serverlərinin dizaynı, elastik verilənlər bazası miqyası, xüsusi Amazon verilənlər bazası və virtual maşınların işini artırmaq və eyni zamanda onların qiymətini azaltmaq üsulları verilmişdir. Amazon-un memarlıq yanaşmaları haqqında bilik AWS xidmətlərindən daha səmərəli istifadə etməyə kömək edəcək və öz həllərinizi yaratmaq üçün sizə yeni ideyalar verə bilər.
Natiq haqqında: Vasili Pantyuxin () .ru şirkətlərində Unix admin kimi başlamış, 6 il böyük Sun Microsystem aparatları üzərində çalışmış və 11 il ərzində EMC-də məlumat mərkəzli dünyanı təbliğ etmişdir. O, təbii olaraq özəl buludlara çevrildi və 2017-ci ildə ictimai buludlara keçdi. İndi o, AWS buludunda yaşamağa və inkişaf etməyə kömək etmək üçün texniki məsləhətlər verir.
İmtina: aşağıda göstərilən hər şey Vasilinin şəxsi fikridir və Amazon Veb Xidmətlərinin mövqeyi ilə üst-üstə düşməyə bilər. Məqalənin əsaslandığı reportaj YouTube kanalımızda mövcuddur.
Niyə mən Amazon cihazı haqqında danışıram?
İlk avtomobilim mexaniki transmissiyaya malik idi. Maşını idarə edə biləcəyimi və ona tam nəzarət edə biləcəyimi hiss etdiyim üçün əla idi. Onun iş prinsipini ən azı kobud şəkildə başa düşməyim də xoşuma gəldi. Təbii ki, qutunun strukturunu kifayət qədər primitiv təsəvvür etdim - velosipeddə sürət qutusu kimi bir şey.
Hər şey əla idi, bir şey istisna olmaqla - tıxaclarda ilişib. Deyəsən oturursan və heç nə etmirsən, amma siz daim dişliləri dəyişirsiniz, muftaya, qaza, əyləcə basırsınız - bu sizi həqiqətən yorur. Ailə avtomatik maşın aldıqdan sonra tıxac problemi qismən həll olundu. Avtomobil sürərkən nəsə düşünməyə və audiokitab dinləməyə vaxtım oldu.
Həyatımda başqa bir sirr ortaya çıxdı, çünki avtomobilimin necə işlədiyini başa düşməyi tamamilə dayandırdım. Müasir avtomobil mürəkkəb bir cihazdır. Avtomobil eyni vaxtda onlarla müxtəlif parametrlərə uyğunlaşır: qaza basmaq, əyləc, sürmə tərzi, yol keyfiyyəti. Artıq necə işlədiyini başa düşmürəm.
Amazon buludunda işləməyə başlayanda bu, mənim üçün də sirr idi. Yalnız bu sirr daha böyük bir sifarişdir, çünki avtomobildə bir sürücü var və AWS-də milyonlarla var. Bütün istifadəçilər eyni vaxtda sükanı idarə edir, qazı sıxır və əyləci basır. Onların istədikləri yerə getmələri heyrətamizdir - bu mənim üçün möcüzədir! Sistem avtomatik olaraq hər bir istifadəçiyə uyğunlaşır, ölçülür və elastik şəkildə uyğunlaşır ki, ona bu Kainatda tək olduğu görünür.
Daha sonra Amazonda memar kimi işləməyə gələndə sehr bir az söndü. Hansı problemlərlə üzləşdiyimizi, onları necə həll etdiyimizi və xidmətləri necə inkişaf etdirdiyimizi gördüm. Sistemin necə işlədiyinə dair artan anlayışla xidmətə daha çox inam yaranır. Beləliklə, AWS buludunun başlığı altında olanların şəklini paylaşmaq istəyirəm.
Nə danışaq
Mən çoxşaxəli bir yanaşma seçdim - danışmağa dəyər 4 maraqlı xidmət seçdim.
Server optimallaşdırılması. Fiziki təcəssümü olan efemer buludlar: zümzümə edən, qızdıran və işıqlarla yanıb-sönən fiziki serverlərin olduğu fiziki məlumat mərkəzləri.
Serversiz funksiyalar (Lambda) yəqin ki, buludda ən genişlənən xidmətdir.
Verilənlər bazasının miqyası. Mən sizə öz genişlənə bilən verilənlər bazalarımızı necə qurduğumuzu izah edəcəyəm.
Şəbəkə miqyası. Şəbəkəmizin cihazını açacağım son hissə. Bu gözəl bir şeydir - hər bir bulud istifadəçisi buludda tək olduğuna inanır və digər kirayəçiləri ümumiyyətlə görmür.
Qeyd. Bu məqalə serverin optimallaşdırılması və verilənlər bazası miqyasını müzakirə edəcək. Növbəti məqalədə şəbəkə miqyasını nəzərdən keçirəcəyik. Serversiz funksiyalar haradadır? Onlar haqqında ayrıca stenoqram dərc olunub”" Bu, bir neçə müxtəlif miqyaslama metodundan bəhs edir və Firecracker həllini - virtual maşının və konteynerlərin ən yaxşı keyfiyyətlərinin simbiozunu ətraflı müzakirə edir.
Serverlər
Bulud efemerdir. Lakin bu efemerliyin hələ də fiziki təcəssümü var - serverlər. Əvvəlcə onların memarlığı klassik idi. Standart x86 çipset, şəbəkə kartları, Linux, virtual maşınların işlədildiyi Xen hipervizoru.
2012-ci ildə bu memarlıq öz vəzifələrinin öhdəsindən kifayət qədər yaxşı gəldi. Xen əla hipervizordur, lakin onun bir böyük çatışmazlığı var. Onun kifayət qədər var cihazın emulyasiyası üçün yüksək yük. Yeni, daha sürətli şəbəkə kartları və ya SSD diskləri əlçatan olduqda, bu yük çox yüksək olur. Bu problemlə necə məşğul olmaq olar? Bir anda iki cəbhədə işləmək qərarına gəldik - həm hardware, həm də hipervizoru optimallaşdırın. Vəzifə çox ciddidir.
Aparat və hipervizorun optimallaşdırılması
Hər şeyi bir anda etmək və yaxşı etmək nəticə verməyəcək. “Yaxşı”nın nə olduğu da əvvəlcə bəlli deyildi.
Biz təkamül yolu ilə yanaşmaq qərarına gəldik - memarlığın bir mühüm elementini dəyişdirərək istehsalata atırıq.
Hər dırmıqda addımlayır, şikayət və təklifləri dinləyirik. Sonra başqa bir komponenti dəyişdiririk. Beləliklə, kiçik artımlarla istifadəçilərin rəyi və dəstəyi əsasında bütün arxitekturanı kökündən dəyişdiririk.
Transformasiya 2013-cü ildə ən mürəkkəb şeylə - şəbəkə ilə başladı. IN C3 hallarda, standart şəbəkə kartına xüsusi Şəbəkə Sürətləndirici kartı əlavə edilmişdir. Ön paneldə qısa bir geri dönmə kabeli ilə sözün həqiqi mənasında birləşdirildi. Gözəl deyil, amma buludda görünmür. Lakin avadanlıqla birbaşa qarşılıqlı əlaqə titrəmə və şəbəkə ötürmə qabiliyyətini əsaslı şəkildə yaxşılaşdırdı.
Sonra EBS - Elastik Block Storage məlumat saxlama blokuna girişi yaxşılaşdırmaq qərarına gəldik. Şəbəkə və yaddaşın birləşməsidir. Çətinlik ondadır ki, Şəbəkə Sürətləndirici kartları bazarda mövcud olsa da, sadəcə Storage Accelerator aparatını almaq imkanı yox idi. Beləliklə, biz startapa müraciət etdik Annapurna Laboratoriyaları, bizim üçün xüsusi ASIC çipləri hazırlayan. Onlar uzaq EBS həcmlərinin NVMe cihazları kimi quraşdırılmasına icazə verdilər.
Nümunələrdə C4 iki problemi həll etdik. Birincisi, biz perspektivli, lakin o dövrdə yeni olan NVMe texnologiyasının gələcəyi üçün təməl yaratdıq. İkincisi, EBS-ə sorğuların işlənməsini yeni karta köçürməklə mərkəzi prosessoru əhəmiyyətli dərəcədə boşaltdıq. Yaxşı çıxdı, buna görə də indi Annapurna Labs Amazonun bir hissəsidir.
2017-ci ilin noyabrına qədər hipervizorun özünü dəyişdirməyin vaxtı olduğunu başa düşdük.
Yeni hipervizor dəyişdirilmiş KVM nüvə modulları əsasında hazırlanmışdır.
Bu, cihazın emulyasiyasını əsaslı şəkildə azaltmağa və yeni ASIC-lərlə birbaşa işləməyə imkan verdi. Nümunələr C5 başlıq altında çalışan yeni hipervizoru olan ilk virtual maşınlar idi. Adını qoyduq Nitro.
Zaman qrafikində nümunələrin təkamülü.
2017-ci ilin noyabr ayından bəri ortaya çıxan bütün yeni virtual maşın növləri bu hipervizorda işləyir. Bare Metal nümunələrində hipervizor yoxdur, lakin onlar Nitro da adlanır, çünki onlar xüsusi Nitro kartlarından istifadə edirlər.
Növbəti iki il ərzində Nitro nümunələrinin növlərinin sayı bir neçə ondan çox oldu: A1, C5, M5, T3 və başqaları.
Nümunə növləri.
Müasir Nitro maşınları necə işləyir
Onların üç əsas komponenti var: Nitro hipervizoru (yuxarıda müzakirə olunub), təhlükəsizlik çipi və Nitro kartları.
Təhlükəsizlik çipi birbaşa ana plataya inteqrasiya olunur. O, host OS-nin yüklənməsinə nəzarət kimi bir çox vacib funksiyaları idarə edir.
Nitro kartları - Onların dörd növü var. Onların hamısı Annapurna Labs tərəfindən hazırlanmışdır və ümumi ASIC-lərə əsaslanır. Onların bəzi proqram təminatı da ümumidir.
Dörd növ Nitro kartları.
Kartlardan biri işləmək üçün nəzərdə tutulub şəbəkəVPC. Virtual maşınlarda şəbəkə kartı kimi görünən budur ENA - Elastik Şəbəkə Adapteri. O, həmçinin fiziki şəbəkə vasitəsilə ötürülən trafiki əhatə edir (bu barədə məqalənin ikinci hissəsində danışacağıq), Təhlükəsizlik Qruplarının təhlükəsizlik duvarına nəzarət edir, marşrutlaşdırma və digər şəbəkə işlərinə cavabdehdir.
Seçilmiş kartlar blok yaddaşı ilə işləyir EBS və serverə quraşdırılmış disklər. Onlar qonağa virtual maşın kimi görünürlər NVMe adapterləri. Onlar həmçinin məlumatların şifrələnməsi və disk monitorinqi üçün məsuliyyət daşıyırlar.
Nitro kartları, hipervizor və təhlükəsizlik çipi sistemi SDN şəbəkəsinə inteqrasiya olunub və ya Proqram təminatı ilə müəyyən edilmiş şəbəkə. Bu şəbəkənin idarə edilməsinə cavabdehdir (İdarəetmə Planı) nəzarətçi kartı.
Əlbəttə ki, biz yeni ASIC-ləri inkişaf etdirməyə davam edirik. Məsələn, 2018-ci ilin sonunda onlar maşın öyrənmə tapşırıqları ilə daha səmərəli işləməyə imkan verən Inferentia çipini buraxdılar.
Inferentia Machine Learning Processor çipi.
Ölçülənə bilən verilənlər bazası
Ənənəvi verilənlər bazası laylı struktura malikdir. Böyük dərəcədə sadələşdirmək üçün aşağıdakı səviyyələr fərqləndirilir.
- SQL — müştəri və sorğu dispetçerləri bunun üzərində işləyirlər.
- Müddəalar əməliyyatlar - burada hər şey aydındır, ACID və bütün bunlar.
- önbelleğe alma, bufer hovuzları tərəfindən təmin edilir.
- Giriş — redo logs ilə işi təmin edir. MySQL-də onlar Bin Logs, PosgreSQL-də isə - Write Ahead Logs (WAL) adlanır.
- saxlama - diskə birbaşa qeyd.
Laylı verilənlər bazası strukturu.
Verilənlər bazasını miqyaslandırmağın müxtəlif yolları var: sharding, Shared Nothing arxitekturası, paylaşılan disklər.
Bununla belə, bütün bu üsullar eyni monolit verilənlər bazası strukturunu saxlayır. Bu, miqyasını əhəmiyyətli dərəcədə məhdudlaşdırır. Bu problemi həll etmək üçün biz öz verilənlər bazamızı inkişaf etdirdik - Amazon Aurora. MySQL və PostgreSQL ilə uyğun gəlir.
Amazon Aurora
Əsas memarlıq ideyası saxlama və giriş səviyyələrini əsas verilənlər bazasından ayırmaqdır.
İrəliyə baxaraq deyəcəm ki, keşləmə səviyyəsini də müstəqil etdik. Memarlıq monolit olmaqdan çıxır və biz ayrı-ayrı blokların miqyasında əlavə sərbəstlik dərəcələri əldə edirik.
Giriş və saxlama səviyyələri verilənlər bazasından ayrıdır.
Ənənəvi DBMS məlumatları bloklar şəklində saxlama sisteminə yazır. Amazon Aurora-da biz dildə danışa bilən ağıllı yaddaş yaratdıq redo-logs. İçəridə saxlama qeydləri məlumat bloklarına çevirir, onların bütövlüyünə nəzarət edir və avtomatik olaraq ehtiyat nüsxəsini çıxarır.
Bu yanaşma kimi maraqlı şeyləri həyata keçirməyə imkan verir klonlama. Bütün məlumatların tam surətinin yaradılmasını tələb etmədiyinə görə, prinsipcə daha sürətli və daha qənaətcil işləyir.
Saxlama təbəqəsi paylanmış sistem kimi həyata keçirilir. Çox sayda fiziki serverdən ibarətdir. Hər bir redo log eyni vaxtda işlənir və saxlanılır altı düyün. Bu, məlumatların qorunmasını və yük balansını təmin edir.
Oxu miqyasına uyğun replikalardan istifadə etməklə nail olmaq olar. Paylanmış yaddaş məlumat yazdığımız əsas verilənlər bazası nümunəsi ilə qalan replikalar arasında sinxronizasiya ehtiyacını aradan qaldırır. Ən son məlumatların bütün replikalara əlçatan olmasına zəmanət verilir.
Yeganə problem oxunan replikalarda köhnə məlumatların keşləşdirilməsidir. Amma bu problem həll olunur bütün redo loglarının ötürülməsi daxili şəbəkə üzərindən replikalara. Günlük keş yaddaşdadırsa, o, səhv olaraq qeyd olunur və üzərinə yazılır. Önbellekdə deyilsə, sadəcə atılır.
Anbarı sıraladıq.
DBMS səviyyələrini necə ölçmək olar
Burada üfüqi miqyas daha çətindir. Beləliklə, döyülən yolla gedək klassik şaquli miqyaslama.
Fərz edək ki, bizim DBMS ilə master node vasitəsilə əlaqə saxlayan proqramımız var.
Şaquli miqyaslandırarkən, daha çox prosessor və yaddaşa sahib olacaq yeni bir node ayırırıq.
Sonra, proqramı köhnə master nodedan yenisinə keçirik. Problemlər yaranır.
- Bu, tətbiqin əhəmiyyətli dayanma müddətini tələb edəcəkdir.
- Yeni master node soyuq önbelleğe malik olacaq. Verilənlər bazasının performansı yalnız önbellek istiləndikdən sonra maksimum olacaq.
Vəziyyəti necə yaxşılaşdırmaq olar? Tətbiq və master node arasında bir proxy qurun.
Bu bizə nə verəcək? İndi bütün tətbiqləri yeni node-a əl ilə yönləndirmək lazım deyil. Keçid bir proxy altında edilə bilər və əsasən daha sürətlidir.
Deyəsən problem həll olunub. Ancaq yox, biz hələ də önbelleği istiləşdirmək ehtiyacından əziyyət çəkirik. Bundan əlavə, yeni bir problem ortaya çıxdı - indi proxy potensial uğursuzluq nöqtəsidir.
Amazon Aurora ilə serversiz son həll
Bu problemləri necə həll etdik?
Proksi tərk etdi. Bu ayrı bir nümunə deyil, proqramların verilənlər bazasına qoşulduğu proksilərin tam paylanmış donanmasıdır. Uğursuzluq halında, qovşaqlardan hər hansı biri demək olar ki, dərhal dəyişdirilə bilər.
Müxtəlif ölçülü isti qovşaqlar hovuzu əlavə edildi. Buna görə, daha böyük və ya daha kiçik ölçülü yeni bir node ayırmaq lazımdırsa, dərhal mövcuddur. Yüklənməsini gözləməyə ehtiyac yoxdur.
Bütün miqyaslama prosesi xüsusi monitorinq sistemi tərəfindən idarə olunur. Monitorinq cari master node-un vəziyyətini daim izləyir. Məsələn, prosessor yükünün kritik dəyərə çatdığını aşkar edərsə, o, yeni bir node ayırmaq zərurəti barədə isti nümunələr hovuzunu xəbərdar edir.
Paylanmış proksilər, isti nümunələr və monitorinq.
Lazımi gücə malik bir node mövcuddur. Bufer hovuzları ona kopyalanır və sistem keçid üçün təhlükəsiz anı gözləməyə başlayır.
Adətən keçid anı olduqca tez gəlir. Sonra proksi ilə köhnə master node arasında əlaqə dayandırılır, bütün seanslar yeni node-a keçir.
Verilənlər bazası ilə işləmək davam edir.
Qrafik göstərir ki, dayandırma həqiqətən çox qısadır. Mavi qrafik yükü, qırmızı addımlar isə ölçmə anlarını göstərir. Mavi qrafikdə qısamüddətli enişlər məhz bu qısa gecikmədir.
Yeri gəlmişkən, Amazon Aurora sizə pula tamamilə qənaət etməyə və verilənlər bazası istifadə edilmədikdə, məsələn, həftə sonları onu söndürməyə imkan verir. Yükü dayandırdıqdan sonra DB tədricən gücünü azaldır və bir müddət sönür. Yük geri qayıtdıqda, yenidən rəvan yüksələcək.
Amazon cihazı haqqında hekayənin növbəti hissəsində şəbəkə miqyası haqqında danışacağıq. Abunə ol və məqaləni qaçırmamaq üçün bizi izləyin.
Haqqında Vasili Pantyuxin məruzə edəcək "" Amazon tərtibatçıları tərəfindən paylanmış sistemlər üçün hansı dizayn nümunələri istifadə olunur, xidmət uğursuzluqlarının səbəbləri nələrdir, Hüceyrə əsaslı arxitektura nədir, Daimi İş, Qarışıq Parçalanma - bu maraqlı olacaq. Konfransa bir aydan az vaxt qalıb - . 24 oktyabr son qiymət artımı.
Mənbə: www.habr.com