Bulutlar sihirli bir kutu gibidir; neye ihtiyacınız olduğunu sorarsınız ve kaynaklar birdenbire ortaya çıkar. Sanal makineler, veritabanları, ağ – bunların hepsi yalnızca size aittir. Başka bulut kiracıları da var, ancak Evreninizde tek yönetici sizsiniz. Her zaman gerekli kaynakları alacağınızdan eminsiniz, kimseyi hesaba katmıyorsunuz ve ağın nasıl olacağına bağımsız olarak siz karar veriyorsunuz. Bulutun kaynakları esnek bir şekilde tahsis etmesini ve kiracıları birbirinden tamamen izole etmesini sağlayan bu sihir nasıl çalışıyor?
AWS bulutu, 2006'dan bu yana evrimsel olarak gelişen mega süper karmaşık bir sistemdir. Bu gelişmenin bir kısmı gerçekleşti Vasili Pantyukhin - Amazon Web Hizmetleri Mimarı. Bir mimar olarak yalnızca nihai sonuca değil, aynı zamanda AWS'nin üstesinden geldiği zorluklara da içeriden bakıyor. Sistemin nasıl çalıştığı daha iyi anlaşıldıkça güven de artar. Bu nedenle Vasily, AWS bulut hizmetlerinin sırlarını paylaşacak. Aşağıda fiziksel AWS sunucularının tasarımı, elastik veritabanı ölçeklenebilirliği, özel bir Amazon veritabanı ve sanal makinelerin performansını artırırken aynı zamanda fiyatlarını düşürmeye yönelik yöntemler yer almaktadır. Amazon'un mimari yaklaşımları hakkında bilgi sahibi olmak, AWS hizmetlerini daha etkili bir şekilde kullanmanıza yardımcı olacak ve kendi çözümlerinizi oluşturmanız için size yeni fikirler sunabilir.
Konuşmacı hakkında: Vasily Pantyukhin () .ru şirketlerinde Unix yöneticisi olarak işe başladı, 6 yıl boyunca büyük Sun Microsystem donanımı üzerinde çalıştı ve 11 yıl boyunca EMC'de veri merkezli bir dünyanın vaazını verdi. Doğal olarak özel bulutlara dönüştü ve 2017'de halka açık bulutlara geçti. Artık AWS bulutunda yaşamanıza ve gelişmenize yardımcı olacak teknik tavsiyeler sağlıyor.
Yasal Uyarı: Aşağıdaki her şey Vasily'nin kişisel görüşüdür ve Amazon Web Services'in konumuyla örtüşmeyebilir. Makalenin dayandığı rapor YouTube kanalımızda mevcuttur.
Neden Amazon cihazından bahsediyorum?
İlk arabam manuel şanzımanlıydı. Arabayı kullanabileceğimi ve onun üzerinde tam kontrole sahip olabileceğimi hissettiğim için harikaydı. Ayrıca en azından çalışma prensibini kabaca anlamış olmam da hoşuma gitti. Doğal olarak kutunun yapısının oldukça ilkel olduğunu hayal ettim - bisikletteki vites kutusu gibi bir şey.
Bir şey dışında her şey harikaydı - trafik sıkışıklığı sıkışmış. Görünüşe göre oturuyor ve hiçbir şey yapmıyorsunuz, ama sürekli vites değiştiriyorsunuz, debriyaj, gaz, fren tuşuna basıyorsunuz - sizi gerçekten yoruyor. Aile otomatik bir araba aldığında trafik sıkışıklığı sorunu kısmen çözüldü. Sürüş sırasında bir şey düşünmek ve bir sesli kitap dinlemek için zamanım vardı.
Hayatımda başka bir gizem daha ortaya çıktı çünkü arabamın nasıl çalıştığını anlamayı tamamen bıraktım. Modern bir araba karmaşık bir cihazdır. Araç onlarca farklı parametreye aynı anda uyum sağlıyor: Gaza basma, frenleme, sürüş tarzı, yol kalitesi. Artık nasıl çalıştığını anlamıyorum.
Amazon bulutu üzerinde çalışmaya başladığımda, bu benim için de bir gizemdi. Sadece bu gizem daha büyük bir büyüklük sırasıdır, çünkü arabada bir sürücü vardır ve AWS'de milyonlarca kişi vardır. Tüm kullanıcılar aynı anda yönlendirir, gaz ve frene basın. İstedikleri yere gitmeleri şaşırtıcı - bu benim için bir mucize! Sistem, her kullanıcıya otomatik olarak adapte olur, ölçeklendirir ve elastik bir şekilde ayarlanır, böylece ona bu evrende yalnız göründüğü görülür.
Daha sonra Amazon'da mimar olarak çalışmaya başladığımda sihir biraz etkisini yitirdi. Hangi sorunlarla karşılaştığımızı, bunları nasıl çözdüğümüzü, hizmetleri nasıl geliştirdiğimizi gördüm. Sistemin nasıl çalıştığının anlaşılması arttıkça hizmete olan güven de artıyor. Bu yüzden AWS bulutunun altında ne olduğuna dair bir resim paylaşmak istiyorum.
Ne hakkında konuşmalıyız
Çeşitlendirilmiş bir yaklaşım seçtim - hakkında konuşmaya değer 4 ilginç hizmet seçtim.
Sunucu optimizasyonu. Fiziksel bir yapıya sahip geçici bulutlar: Mırıldanan, ısınan ve ışıklarla yanıp sönen fiziksel sunucuların bulunduğu fiziksel veri merkezleri.
Sunucusuz işlevler (Lambda) muhtemelen buluttaki en ölçeklenebilir hizmettir.
Veritabanı ölçeklendirme. Size kendi ölçeklenebilir veritabanlarımızı nasıl oluşturduğumuzu anlatacağım.
Ağ ölçeklendirme. Ağımızın cihazını açacağım son bölüm. Bu harika bir şey; her bulut kullanıcısı bulutta yalnız olduğuna ve diğer kiracıları hiç görmediğine inanır.
Not. Bu makalede sunucu optimizasyonu ve veritabanı ölçeklendirmesi tartışılacaktır. Bir sonraki makalede ağ ölçeklendirmeyi ele alacağız. Sunucusuz işlevler nerede? Bunlarla ilgili ayrı bir transkript yayınlandı”" Birkaç farklı ölçeklendirme yönteminden bahsediyor ve bir sanal makine ile konteynerlerin en iyi özelliklerinin birleşimi olan Firecracker çözümünü ayrıntılı olarak tartışıyor.
Sunucular
Bulut geçicidir. Ancak bu geçiciliğin hala fiziksel bir düzenlemesi var: sunucular. Başlangıçta mimarileri klasikti. Standart x86 yonga seti, ağ kartları, Linux, sanal makinelerin çalıştırıldığı Xen hipervizörü.
2012 yılında bu mimari görevleriyle oldukça iyi başa çıktı. Xen harika bir hipervizördür ancak büyük bir dezavantajı vardır. O yeterince var cihaz emülasyonu için yüksek ek yük. Yeni, daha hızlı ağ kartları veya SSD sürücüleri piyasaya çıktıkça bu yük çok yüksek hale gelir. Bu sorunla nasıl başa çıkılır? Aynı anda iki cephede çalışmaya karar verdik. hem donanımı hem de hipervizörü optimize edin. Görev çok ciddi.
Donanımı ve hipervizörü optimize etme
Her şeyi aynı anda ve iyi yapmak işe yaramayacaktır. Başlangıçta neyin “iyi” olduğu da belirsizdi.
Evrimsel bir yaklaşım benimsemeye karar verdik; mimarinin önemli bir unsurunu değiştirip onu üretime alıyoruz.
Her tırmığa basıyoruz, şikayet ve önerileri dinliyoruz. Daha sonra başka bir bileşeni değiştiriyoruz. Böylece, kullanıcılardan ve destekten gelen geri bildirimlere dayanarak tüm mimariyi küçük artışlarla kökten değiştiriyoruz.
Dönüşüm 2013 yılında en karmaşık şey olan ağla başladı. İÇİNDE С3 Örneklerde standart ağ kartına özel bir Ağ Hızlandırıcı kartı eklendi. Kelimenin tam anlamıyla ön paneldeki kısa bir geridöngü kablosuyla bağlandı. Hoş değil ama bulutta görünmüyor. Ancak donanımla doğrudan etkileşim temel olarak titreşimi ve ağ verimini artırdı.
Daha sonra, blok veri depolamaya (EBS - Elastik Blok Depolama) erişimi iyileştirmeye karar verdik. Ağ ve depolamanın birleşimidir. Buradaki zorluk, Network Accelerator kartları piyasada mevcutken, yalnızca Storage Accelerator donanımını satın alma seçeneğinin olmamasıydı. Bu yüzden bir startup'a döndük Annapurna LaboratuvarlarıBizim için özel ASIC çipleri geliştiren kişi. Uzak EBS birimlerinin NVMe cihazları olarak bağlanmasına izin verdiler.
Bazı durumlarda C4 iki sorunu çözdük. Birincisi, gelecek vaat eden ancak o zamanlar yeni olan NVMe teknolojisinin temelini hayata geçirdik. İkinci olarak, EBS'ye gelen taleplerin işlenmesini yeni bir karta aktararak merkezi işlemcinin yükünü önemli ölçüde hafiflettik. Her şey yolunda gitti ve artık Annapurna Labs Amazon'un bir parçası oldu.
Kasım 2017 itibarıyla hipervizörün kendisini değiştirme zamanının geldiğini fark ettik.
Yeni hipervizör, değiştirilmiş KVM çekirdek modüllerine dayanarak geliştirildi.
Cihaz emülasyonunun yükünü temel olarak azaltmayı ve yeni ASIC'lerle doğrudan çalışmayı mümkün kıldı. Örnekler С5 kaputun altında çalışan yeni bir hiper yöneticiye sahip ilk sanal makinelerdi. Ona adını verdik Nitro.
Zaman çizelgesindeki örneklerin gelişimi.
Kasım 2017'den bu yana ortaya çıkan tüm yeni sanal makine türleri bu hipervizörde çalışıyor. Bare Metal örneklerinin hipervizörü yokturancak özel Nitro kartları kullandıkları için Nitro olarak da adlandırılırlar.
Önümüzdeki iki yıl boyunca Nitro bulut sunucusu türlerinin sayısı birkaç düzineyi aştı: A1, C5, M5, T3 ve diğerleri.
Örnek türleri.
Modern Nitro makineleri nasıl çalışır?
Üç ana bileşeni vardır: Nitro hipervizörü (yukarıda tartışılmıştır), güvenlik çipi ve Nitro kartları.
Güvenlik çipi doğrudan anakarta entegre edilmiştir. Ana bilgisayar işletim sisteminin yüklenmesini kontrol etmek gibi birçok önemli işlevi kontrol eder.
Nitro kartları - Dört türü vardır. Hepsi Annapurna Labs tarafından geliştirildi ve ortak ASIC'leri temel alıyor. Firmware'lerinden bazıları da yaygındır.
Dört tür Nitro kartı.
Kartlardan biri çalışmak üzere tasarlandı ağVPC. Sanal makinelerde ağ kartı olarak görünen şey budur ENA - Elastik Ağ Adaptörü. Aynı zamanda fiziksel bir ağ üzerinden iletirken trafiği de kapsüller (bundan makalenin ikinci bölümünde bahsedeceğiz), Güvenlik Grupları güvenlik duvarını kontrol eder ve yönlendirme ve diğer ağ işlerinden sorumludur.
Belirli kartlar blok depolamayla çalışır EBS ve sunucuya yerleşik diskler. Konuk sanal makineye şu şekilde görünürler: NVMe adaptörleri. Ayrıca veri şifreleme ve disk izlemeden de sorumludurlar.
Nitro kartlar, hipervizör ve güvenlik çipinden oluşan sistem bir SDN ağına entegre edilmiştir veya Yazılım Tanımlı Ağ. Bu ağı yönetmekten sorumludur (Kontrol Düzlemi) denetleyici kartı.
Elbette yeni ASIC'ler geliştirmeye devam ediyoruz. Örneğin 2018'in sonunda makine öğrenimi görevleriyle daha verimli çalışmanıza olanak tanıyan Inferentia çipini piyasaya sürdüler.
Interentia Makine Öğrenme İşlemci Çipi.
Ölçeklenebilir Veritabanı
Geleneksel bir veritabanı katmanlı bir yapıya sahiptir. Büyük ölçüde basitleştirmek için aşağıdaki seviyeler ayırt edilir.
- SQL — istemci ve istek göndericileri bunun üzerinde çalışır.
- Hükümler işlemler - burada her şey açık, ASİT falan.
- Önbelleğe almaktampon havuzları tarafından sağlanır.
- Kerestecilik — yineleme günlükleriyle çalışma sağlar. MySQL'de bunlara Bin Günlükleri, PosgreSQL'de - İleri Yaz Günlükleri (WAL) adı verilir.
- Depolama – diske doğrudan kayıt.
Katmanlı veritabanı yapısı.
Veritabanlarını ölçeklendirmenin farklı yolları vardır: parçalama, Paylaşılan Hiçbir Şey mimarisi, paylaşılan diskler.
Ancak tüm bu yöntemler aynı yekpare veritabanı yapısını korur. Bu, ölçeklendirmeyi önemli ölçüde sınırlar. Bu sorunu çözmek için kendi veritabanımızı geliştirdik – Amazon Aurora'sı. MySQL ve PostgreSQL ile uyumludur.
Amazon Aurora'sı
Ana mimari fikir, depolama ve günlük seviyelerini ana veritabanından ayırmaktır.
İleriye baktığımızda önbellekleme seviyesini de bağımsız hale getirdiğimizi söyleyeceğim. Mimari yekpare olmaktan çıkıyor ve bireysel blokları ölçeklendirmede ek özgürlük dereceleri kazanıyoruz.
Günlük kaydı ve depolama düzeyleri veritabanından ayrıdır.
Geleneksel bir DBMS, verileri bir depolama sistemine bloklar halinde yazar. Amazon Aurora'da dil konuşabilen akıllı depolama alanı oluşturduk günlükleri yeniden yap. İçerideki depolama, günlükleri veri bloklarına dönüştürür, bütünlüklerini izler ve otomatik olarak yedekler.
Bu yaklaşım, aşağıdaki gibi ilginç şeyleri uygulamanıza olanak tanır: klonlama. Tüm verilerin tam bir kopyasının oluşturulmasını gerektirmediği için temelde daha hızlı ve daha ekonomik çalışır.
Depolama katmanı dağıtılmış bir sistem olarak uygulanır. Çok sayıda fiziksel sunucudan oluşur. Her yineleme günlüğü aynı anda işlenir ve kaydedilir altı deniz mili. Bu, veri korumasını ve yük dengelemeyi sağlar.
Okuma ölçeklendirmesi uygun kopyalar kullanılarak gerçekleştirilebilir. Dağıtılmış depolama, üzerinden veri yazdığımız ana veritabanı örneği ile geri kalan kopyalar arasındaki senkronizasyon ihtiyacını ortadan kaldırır. Güncel verilerin tüm replikalarda mevcut olması garanti edilir.
Tek sorun eski verileri okuma kopyalarında önbelleğe almaktır. Ama bu sorun çözülüyor tüm yineleme günlüklerinin aktarımı Dahili ağ üzerinden kopyalara. Günlük önbellekte ise, yanlış ve üzerine yazılmış olarak işaretlenir. Önbellekte değilse, sadece atılır.
Depolamayı hallettik.
DBMS katmanları nasıl ölçeklendirilir?
Burada yatay ölçeklendirme çok daha zordur. Öyleyse hadi alışılmış yoldan gidelim klasik dikey ölçeklendirme.
Bir ana düğüm aracılığıyla DBMS ile iletişim kuran bir uygulamamız olduğunu varsayalım.
Dikey ölçeklendirme yaparken daha fazla işlemciye ve belleğe sahip olacak yeni bir düğüm tahsis ediyoruz.
Daha sonra uygulamayı eski ana düğümden yenisine geçiriyoruz. Sorunlar ortaya çıkıyor.
- Bu, önemli bir uygulama kesintisi gerektirecektir.
- Yeni ana düğümün soğuk önbelleği olacaktır. Veritabanı performansı ancak önbellek ısındıktan sonra maksimum olacaktır.
Durum nasıl geliştirilir? Uygulama ile ana düğüm arasında bir proxy ayarlayın.
Bu bize ne verecek? Artık tüm uygulamaların yeni düğüme manuel olarak yönlendirilmesine gerek yok. Geçiş bir proxy altında yapılabilir ve temelde daha hızlıdır.
Sorun çözülmüş gibi görünüyor. Ama hayır, hala önbelleği ısıtma ihtiyacından dolayı acı çekiyoruz. Ayrıca yeni bir sorun ortaya çıktı; artık proxy potansiyel bir başarısızlık noktasıdır.
Amazon Aurora sunucusuz ile nihai çözüm
Bu sorunları nasıl çözdük?
Bir vekil bıraktı. Bu ayrı bir örnek değil, uygulamaların veritabanına bağlandığı dağıtılmış bir proxy filosudur. Arıza durumunda düğümlerden herhangi biri neredeyse anında değiştirilebilir.
Çeşitli boyutlarda sıcak düğümlerden oluşan bir havuz eklendi. Bu nedenle, daha büyük veya daha küçük boyutta yeni bir düğüm tahsis edilmesi gerekiyorsa, hemen kullanılabilir. Yüklenmesini beklemeye gerek yok.
Tüm ölçeklendirme süreci özel bir izleme sistemi tarafından kontrol edilir. İzleme, mevcut ana düğümün durumunu sürekli olarak izler. Örneğin, işlemci yükünün kritik bir değere ulaştığını tespit ederse, sıcak örnekler havuzuna yeni bir düğüm tahsis edilmesi gerektiği konusunda bildirimde bulunur.
Dağıtılmış proxy'ler, sıcak örnekler ve izleme.
Gerekli güce sahip bir düğüm mevcuttur. Tampon havuzları buna kopyalanır ve sistem geçiş yapmak için güvenli bir anı beklemeye başlar.
Genellikle geçiş anı oldukça çabuk gelir. Daha sonra proxy ile eski ana düğüm arasındaki iletişim askıya alınır ve tüm oturumlar yeni düğüme geçirilir.
Veritabanıyla çalışmaya devam edilir.
Grafik, süspansiyonun gerçekten çok kısa olduğunu gösteriyor. Mavi grafik yükü, kırmızı adımlar ise ölçeklendirme momentlerini gösterir. Mavi grafikteki kısa vadeli düşüşler tam olarak bu kısa gecikmedir.
Bu arada, Amazon Aurora, örneğin hafta sonları kullanılmadığında tamamen paradan tasarruf etmenize ve veritabanını kapatmanıza olanak tanır. Yük durdurulduktan sonra DB yavaş yavaş gücünü azaltır ve bir süreliğine kapanır. Yük geri döndüğünde tekrar sorunsuz bir şekilde yükselecektir.
Amazon cihazıyla ilgili hikayenin bir sonraki bölümünde ağ ölçeklendirmesinden bahsedeceğiz. Abone Ve makaleyi kaçırmamak için bizi izlemeye devam edin.
Üzerinde Vasily Pantyukhin bir rapor verecek “" Amazon geliştiricileri tarafından dağıtılmış sistemler için hangi tasarım modelleri kullanılıyor, hizmet arızalarının nedenleri nelerdir, Hücre tabanlı mimari nedir, Sürekli Çalışma, Karışık Parçalama - ilginç olacaktır. Konferansa bir aydan az bir süre kaldı - . 24 Ekim nihai fiyat artışı.
Kaynak: habr.com