Bulut bilişim açıklandı: Bilmeniz gereken 11 mimari konsept (4K Masterclass).

Bu video neleri kapsar

• - Mimari Duvar & Ana Plan
• - 01. Dikey vs. Yatay Ölçeklendirme
• - 02. Yük Dengeleme Mimarisi (L4 vs. L7 & Sağlık Kontrolleri)
• - 03. Otomatik Ölçeklendirme & Esneklik
• - 04. Sunucusuz (FaaS & Firecracker MikroVM'ler)

Çevrilmiş deşifre

Orijinal İngilizce anlatımdan çevrilmiştir. Mevcut ses ve altyazılar YouTube tarafından kontrol edilir.

- Mimari Duvar & Ana Plan

0:00 Her yazılım mühendisi eninde sonunda bulut mimarisi duvarıyla karşılaşır. Uygulamanızı dizüstü bilgisayarınızda oluşturursunuz, üretime aktarırsınız, ve gerçek kullanıcılar geldiği anda sunucular çöker, veritabanı bağlantıları tükenir ve AWS faturanız bir telefon numarası gibi görünür. Çoğu geliştirici bulut mühendisliğini ezberleyerek çözmeye çalışır. üç yüz farklı AWS ürün kısaltması. Ancak gerçek bulut bilişim, satıcı kataloglarını ezberlemekle ilgili değildir: on bir temel mimari ilkel üzerine inşa edilmiştir.

0:34 Bu ana sınıfta, tüm kurumsal planı adım adım inceleyeceğiz: ölçeklendirme ve yük dengelemeden sunucusuz, olay odaklı ayrıştırma, depolama hiyerarşileri ve bulut ağ iletişimi. depolama hiyerarşileri ve bulut ağ iletişimi. Bu on bir konseptte ustalaşın ve AWS, GCP veya Azure'da herhangi bir arka ucu tasarlayabilirsiniz. GCP veya Azure. Bu, The Daily Diff, perde arkasından.

- 01. Dikey vs. Yatay Ölçeklendirme

0:57 Birinci konsept: Ölçeklendirme. Uygulamanız trafik artışı yaşadığında, yükü idare etmek için temelde iki farklı yolunuz vardır: dikey ölçeklendirme veya yatay ölçeklendirme. Dikey ölçeklendirme veya ölçek büyütme, mevcut makinenizi alıp daha fazla kaynak eklemek anlamına gelir: dört CPU çekirdeğinden otuz ikiye yükseltme veya otuz iki gigabayt RAM'i yüz otuz iki gigabayt RAM'i yüz yirmi sekizle değiştirme. yüz yirmi sekizle değiştirme. Dikey ölçeklendirme sıfır mimari değişiklik gerektirir: kodunuz

1:28 ve veritabanı tam olarak aynı kalır. Ama acımasız bir donanım tavanına çarpar. Dünyada on bin CPU çekirdeği olan tek bir makine yoktur, ve üst düzey örnekler katlanarak artan bir fiyat primi taşır. Yatay ölçeklendirme veya ölçek genişletme, sunucularınızı küçük ve ticari fiyatlı tutmak, ancak bir yönlendiricinin arkasında birden çok örneği paralel olarak çalıştırmak anlamına gelir. Bir örnek çökerse, kalan düğümler trafiği sıfır kesintiyle emer. Yatay ölçeklendirmenin altın kuralı durumsuzluktur: uygulama sunucularınız kullanıcı oturumlarını,

2:01 yüklenen dosyaları veya durumu yerel disklerinde saklayamaz. yüklenen dosyaları veya durumu yerel disklerinde saklayamaz. Durum harici bir veritabanında veya önbellekte yaşamalıdır, herhangi bir düğümün herhangi bir kullanıcı isteğini işlemesine izin verir.

- 02. Yük Dengeleme Mimarisi (L4 vs. L7 & Sağlık Kontrolleri)

2:17 İkinci konsept: Yük Dengeleme. Yatay ölçeklendirme kağıt üzerinde harika görünür, ancak hemen bir sorun ortaya çıkarır: on bin kullanıcı alan adınıza geldiğinde, trafiklerini hangi özel sunucu alır? Bir yük dengeleyici, genel internet ile özel arka uç kümeniz arasında oturan bir ters proxy görevi görür. ve özel arka uç kümeniz. Gelen TCP veya HTTP bağlantılarını kabul eder ve istekleri sağlıklı örnekleriniz arasında dağıtır.

2:47 Yük dengeleyiciler iki ana ağ katmanında çalışır. Katman 4 Ağ Yük Dengeleyiciler taşıma katmanında çalışır, ham TCP ve UDP paketlerini IP adresine ve porta göre yönlendirir. mikrosaniye gecikme ve saniyede milyonlarca istekle. Katman 7 Uygulama Yük Dengeleyiciler HTTP protokolünü inceler: URL yollarını, istek başlıklarını, çerezleri ve HTTP yöntemlerini okur. Bu, yol tabanlı yönlendirmeyi etkinleştirir: slash-api isteklerini arka uç kümenize ve slash-static isteklerini bir

3:25 nesne deposuna gönderir. Kritik olarak, yük dengeleyiciler aktif sağlık kontrolü yapar. Birkaç saniyede bir, dengeleyici her örnekteki bir sağlık uç noktasına ping atar. Bir örnek art arda üç beş yüz hatası verirse veya yanıt veremezse, havuzdan otomatik olarak çıkarılır ve sıfır düşen istek olur. Sıfır düşen istekle havuzdan otomatik olarak çıkarılır.

- 03. Otomatik Ölçeklendirme & Esneklik

3:45 Üçüncü konsept: Otomatik Ölçeklendirme. Web uygulamanızın sabah üçte iki sunucuya ihtiyacı varsa, ancak öğle yemeği lansmanı sırasında yirmi sunucuya ihtiyacı varsa, bulut konsolundaki düğmelere manuel olarak tıklamak, kesintiye ve iflasa giden garantili bir yoldur. bulut konsolundaki düğmelere manuel olarak tıklamak, kesintiye ve iflasa giden garantili bir yoldur. Otomatik ölçeklendirme, yatay sunucu havuzlarına dinamik esneklik getirir. Otomatik Ölçeklendirme Grubu, ortalama CPU kullanımı, ağ G/Ç veya kuyruk arkalığı derinliği gibi performans metriklerini izler. Ortalama CPU tanımlanmış bir eşiği aştığında – örneğin, üç dakika boyunca yüzde yetmiş – otomatik ölçekleyici otomatik olarak

4:19 yüzde yetmiş — otomatik ölçekleyici otomatik olarak yeni sanal makineler başlatır, bunları yük dengeleyicinize kaydeder ve trafiği yönlendirmeye başlar. yeni sanal makineler başlatır, bunları yük dengeleyicinize kaydeder ve trafiği yönlendirmeye başlar. yeni sanal makineler başlatır, bunları yük dengeleyicinize kaydeder ve trafiği yönlendirmeye başlar. Aynı derecede önemli olan ölçeklendirmedir: trafik dalgası azaldığında, otomatik ölçekleyici fazla örnekleri sonlandırır, böylece boşta duran bilgi işlem için ödeme yapmayı bırakırsınız. Kanatlanmayı önlemek için — sunucuların sonsuz bir karmaşa döngüsünde hızla oluşturulup yok edildiği durum — bulut mimarları soğuma süreleri yapılandırır. Dördüncü konsept: Sunucusuz. soğuma süreleri yapılandırır. Dördüncü konsept: Sunucusuz.

- 04. Sunucusuz (FaaS & Firecracker MikroVM'ler)

4:53 Yıllardır pazarlama ekipleri sunucusuzu gökyüzünde çalışan sihirli kod olarak tanıttı. gökyüzünde çalışan sihirli kod olarak tanıttı. Gerçekte, sunucusuz hala sunucular kullanır — ancak kod çalışmadığında onlara sahip olmaz, yamalamaz veya onlar için ödeme yapmazsınız. AWS Lambda veya Google Cloud Functions gibi Hizmet Olarak Fonksiyon ile, bağımsız bir işleyici fonksiyon yazarsınız. Bir HTTP isteği, S3 dosya yüklemesi veya veritabanı değişikliği meydana geldiğinde, bulut çalışma zamanı Firecracker gibi geçici bir

5:23 mikro-sanal makineyi beş milisaniyenin altında başlatır. Kodunuz yürütülür, bir yanıt döndürür ve kapanır. Üç ay boyunca hiç kimse web sitenizi ziyaret etmezse, bilgi işlem faturanız tam olarak sıfır dolar ve sıfır senttir. Bir milyon kullanıcı aynı anda vurursa, sağlayıcı bir milyon eşzamanlı microVM başlatır. Mühendislik değiş tokuşları gerçektir: yeni çalışma zamanlarını başlatırken soğuk başlatma gecikmesi, Lambda'da katı on beş dakikalık yürütme sınırı ve katı durumsuzluk. gecikmesi, Lambda'da katı on beş dakikalık yürütme sınırı ve katı durumsuzluk.

5:55 Sunucusuz, olay işlem hatları ve sporadik API'ler için rakipsizdir, ancak kalıcı WebSockets veya çok saatlik eğitim çalışmaları için zayıftır.

- 05. Olay Odaklı Mimari (EDA & Ayrıştırma)

6:05 Beşinci konsept: Olay Odaklı Mimari veya EDA. Geleneksel mimarilerde hizmetler senkronize olarak iletişim kurar. Ödeme hizmetiniz ödemeyi arar, ödeme envanteri arar, envanter dolandırıcılığı arar ve dolandırıcılık e-postayı arar. Bu, senkronize bir kıyamet şelalesi yaratır. Üçüncü taraf e-posta sağlayıcısı bir ağ aksaklığı yaşar ve yanıt vermesi on saniye sürerse, müşterinizin tüm ödeme isteği bir hatayla zaman aşımına uğrar. Olay odaklı bir mimaride, hizmetler tamamen ayrıştırılmıştır.

6:37 Bir müşteri satın al'a tıkladığında, ödeme hizmeti alt hizmetleri çağırmaz. Sadece merkezi bir Olay Veri Yolu'na Amazon EventBridge veya bir SNS konusuna OrderPlaced adlı bir olay yayınlar. Olay Veri Yolu'na Amazon EventBridge veya bir SNS konusuna OrderPlaced adlı bir olay yayınlar. Ödeme elli milisaniyede tamamlanır. Ödeme, envanter düşüşü ve e-posta makbuzları için alt çalışanlar mesajları kendi özel SQS kuyruklarından bağımsız olarak çeker. E-posta hizmeti bir saatliğine çökerse, mesajlar güvenli bir şekilde kuyrukta tamponlanır ve tek bir sipariş bile düşmez.

- 06. Konteyner Düzenlemesi (Docker & Kubernetes)

7:13 Altıncı konsept: Konteyner Düzenlemesi. Docker paketlemeyi çözdü: uygulama kodunuzu, sistem kütüphanelerini, yapılandırmayı ve çalışma zamanını değişmez bir görüntüye sarar MacBook'unuzda ve bulutta aynı şekilde çalışır. Ama bir konteyneri paketlemek kolaydır. Elli fiziksel sanal makinede beş yüz konteyner çalıştırmak ise mühendisliğin çözüldüğü yerdir. mühendisliğin çöktüğü yerdir. Bu yüzden Kubernetes ve AWS ECS gibi konteyner düzenleyicileri

7:41 mevcuttur. Bir düzenleyici bir kontrol düzlemi sağlar: bir API sunucusu, bir etcd durum deposu ve akıllı bir zamanlayıcı. İstenilen durumunuzu beyan edersiniz: kimlik doğrulama hizmetimin her biri iki gigabayt RAM'e sahip on kopyasını istiyorum. kimlik doğrulama hizmetimin her biri iki gigabayt RAM'e sahip on kopyasını istiyorum. Zamanlayıcı kümeyi denetler, boş belleğe sahip düğümlere podları yerleştirir, dahili ağı yapılandırır ve sürekli olarak gerçeği uzlaştırır. Bir düğüm donanım hatası yaşarsa, Kubernetes kaybı algılar ve tüm yerinden edilmiş podları anında sağlıklı düğümlere yeniden planlar.

- 07. 4 Bulut Depolama Sütunu (S3, EBS, Veritabanları & Redis)

8:16 sağlıklı düğümlere yeniden planlar. Yedinci konsept: Bulut Depolama Hiyerarşisi. Yeni başlayanlar genellikle bulut depolamayı dosyaları attığınız tek bir kova olarak görürler. Üretim mimarisinde, depolama erişim desenlerine ve gecikmeye göre dört farklı sütuna ayrılır. Birincisi Amazon S3 veya Google Cloud Storage gibi Nesne Depolama'dır. Dosyalara HTTP REST API'leri üzerinden basit PUT ve GET çağrıları kullanarak erişirsiniz. Ayda gigabayt başına iki sent karşılığında sonsuz yatay kapasite sunar,

8:49 bu da onu video, kullanıcı yüklemeleri, günlükler ve yedeklemeler için ideal kılar. İkincisi Amazon EBS gibi Blok Depolama'dır. Bunlar, yüksek hızlı ara bağlantılar üzerinden doğrudan belirli bir sanal makineye bağlı sanal sabit disklerdir. yüksek hızlı ara bağlantılar üzerinden. ext4 gibi standart dosya sistemlerine formatlanırlar, veritabanı motorlarının gerektirdiği hızlı rastgele okuma ve yazma erişimini destekler. Üçüncüsü Yönetilen Veritabanlarıdır: RDS'deki PostgreSQL gibi ACID işlemleri ve karmaşık birleşimler sağlayan ilişkisel motorlar, RDS'de PostgreSQL gibi ACID işlemleri ve karmaşık birleşimler sağlayan ilişkisel motorlar,

9:21 ve DynamoDB gibi NoSQL motorları büyük ölçekte tek haneli milisaniye gecikme süresi sağlar. Ve dördüncüsü Redis gibi Bellek İçi Önbelleklerdir. RAM'den veri okumak milisaniyeler yerine mikrosaniyeler sürer. Önbellekler veritabanınızın önünde durur, onu tekrarlanan okuma trafiğinden korur ve geçici kullanıcı oturum belirteçlerini yönetir. Önbellekler veritabanınızın önünde durur, onu tekrarlanan okuma trafiğinden korur ve geçici kullanıcı oturum belirteçlerini yönetir.

- 08. Yüksek Erişilebilirlik & Dokuzlar (Çoklu-AZ Yük Devretme)

9:44 Sekizinci konsept: Yüksek Erişilebilirlik veya HA. Erişilebilirlik bir soruyu yanıtlar: uygulamanızın ne kadarı çalışır durumda ve kullanıcılar tarafından erişilebilir? uygulamanızın ne kadarı çalışır durumda ve kullanıcılar tarafından erişilebilir? Kurumsal sözleşmelerde, erişilebilirlik dokuzlarla ölçülür. İki dokuz, veya yüzde doksan dokuz erişilebilirlik, her yıl üç buçuk günden fazla kesinti süresine izin verir. Dört dokuz izin verilen kesinti süresini elli iki dakikaya düşürür, ve beş dokuz, yılda toplam beş dakikadan az kesintiye izin verir.

10:15 Yüksek erişilebilirlik elde etmek için, hata etki alanları arasında tek hata noktalarını ortadan kaldırmalısınız. Bulutta bu, birden çok Erişilebilirlik Bölgesi'ne dağıtım yapmak anlamına gelir. Bir Erişilebilirlik Bölgesi tek bir raf değildir: bağımsız güç ve soğutmaya sahip millerce uzakta bir veya daha fazla farklı fiziksel veri merkezidir. Bölge A ve Bölge B'de eşzamanlı veritabanı replikasyonu ile aktif örnekler çalıştırarak, tüm fiziksel tesisi etkileyen bir yıldırım çarpması veya fiber kesintisi otomatik yük devretmeyle sonuçlanır.

10:50 otuz saniye içinde sıfır insan müdahalesiyle.

- 09. Dayanıklılık vs. Erişilebilirlik (Neden 11 Dokuz Çalışma Süresi Değil)

10:53 Dokuz numaralı kavram: Dayanıklılık ve Erişilebilirlik. Bu, bulut mimarisi mülakatlarındaki en yaygın kavramsal tuzaktır. Mühendisler sıklıkla bu kelimeleri birbirinin yerine kullanır, ancak bunlar tamamen farklı özellikleri ölçer. Erişilebilirlik çalışma süresini ölçer: Şu anda verilerimi okumak veya yazmak için bir API çağrısı yapabilir miyim? Durabilirlik korumayı ölçer: verilerim on yıl boyunca kalıcı bit çürümesi, bozulma veya yok olma olmadan hayatta kalacak mı? Durabilirlik korumayı ölçer: verilerim on yıl boyunca kalıcı bit çürümesi, bozulma veya yok olma olmadan hayatta kalacak mı? bit çürümesi, bozulma veya on yıl boyunca yok olma olmadan hayatta kalacak mı?

11:24 Amazon S3 Standard'a bakın. Hizmet Seviyesi Anlaşması yüzde doksan doksan dokuz nokta dokuz erişilebilirlik sunar, bu da her ay yaklaşık kırk üç dakikalık kesinti süresine izin verir bir API isteğinin beş yüz hatası döndürebileceği durumlarda. Ancak S3, on bir dokuzlu dayanıklılık vaat ediyor: yüzde doksan dokuz nokta doksan dokuz doksan dokuz doksan dokuz doksan dokuz doksan dokuz doksan dokuz doksan dokuz yüzde. S3'te on milyon dosya depolarsanız, istatistiksel olarak her on bin yılda ortalama bir dosya kaybetmeyi bekleyebilirsiniz.

11:56 ortalama on bin yılda bir dosya kaybetmeyi bekleyebilirsiniz. S3 bunu, nesneleri silme koduyla kodlayarak ve en az üç coğrafi olarak ayrı veri tesisinde parçaları çoğaltarak başarır. en az üç coğrafi olarak ayrılmış veri tesisinde. Büyük bir bölgesel ağ kesintisi sırasında S3 geçici olarak kullanılamaz olabilir, ancak verileriniz asla yok olmaz.

- 10. Kod Olarak Altyapı (Terraform vs. Konsol Kayması)

12:14 On numaralı kavram: Kod Olarak Altyapı veya IaC. Bulut bilişimin ilk günlerinde, mühendisler AWS web yönetim konsoluna giriş yapıp sanal makineler oluşturmak, alt ağları yapılandırmak ve güvenlik grupları eklemek için manuel olarak tıklarlardı. web yönetim konsoluna giriş yaptı ve sanal oluşturmak için manuel olarak tıkladı makineler, alt ağları yapılandırmak ve güvenlik gruplarını eklemek. Endüstri buna ClickOps diyor ve üretimde bu mutlak bir felaket. Manuel konsol değişikliklerinin denetim izi yoktur, geri alma mekanizması yoktur ve kaçınılmaz olarak hazırlık ve üretim ortamları arasında yapılandırma kaymasına neden olur. üretim ortamları. Terraform gibi Kod Olarak Altyapı

12:48 olarak Kod araçlarıyla, OpenTofu, Pulumi veya AWS CDK gibi araçlarla, tüm bulut mimarinizi Git'te depolanan bildirimsel yapılandırma dosyalarında tanımlarsınız. tüm bulut mimarinizi Git'te depolanan bildirimsel yapılandırma dosyalarında tanımlarsınız. Açık bir bağlantı noktası veya veritabanı çoğaltmasına yapılan her değişiklik bir çekme isteği ve eş incelemesinden geçer. çekme isteği ve eş incelemesinden geçer. terraform planını çalıştırmak, bir şeye dokunulmadan önce tam API farkını önizler ve üretim yığınınızın aynı bir kopyasını oluşturmak dört hafta yerine dört dakika sürer. bir şeye dokunulmadan önce ve üretim yığınınızın özdeş bir kopyasını oluşturmak yığın dört hafta yerine dört dakika sürer.

- 11. Bulut Ağ İletişimi (VPC, Alt Ağlar, NAT & Güvenlik Grupları)

13:20 On bir numaralı kavram: Bulut Ağları ve Sanal Özel Bulutlar. Sunucuları buluta dağıttığınızda, ham genel internete maruz kalmazlar. Bir VPC adı verilen yazılım tanımlı izole bir sınır içinde yaşarlar. VPC adı verilen bir VPC'nin içinde. VPC'nizin içinde, on-nokta-sıfır-nokta-sıfır-nokta-sıfır bölü on altı gibi özel bir IP adresi alanı ayırırsınız ve bunu genel ve özel alt ağlara bölersiniz. on-nokta-sıfır-nokta-sıfır-nokta-sıfır bölü on altı gibi ve onu genel ve özel alt ağlara böler. Genel bir alt ağın doğrudan bir İnternet Ağ Geçidi'ne rotası vardır.

13:51 Uygulama Yük Dengeleyicileriniz ve NAT Ağ Geçitleriniz gibi genel kullanıma açık varlıkları barındırır. Ağınızın yalnızca genel IP adreslerine sahip olan kısmıdır. Uygulama sunucularınız ve üretim veritabanlarınız kesinlikle özel IP'leri olmayan ve internetten sıfır gelen rotaları olan özel alt ağlarda yaşar. özel alt ağlarda genel IP'ler ve sıfır gelen rotaları olmadan internet. Arka uç sunucularınızın güvenlik güncellemelerini indirmesi gerektiğinde, giden trafikleri genel alt ağdaki NAT Ağ Geçidi üzerinden yönlendirilir. Her örneği çevreleyen Güvenlik Grupları vardır: en az ayrıcalık ilkesini uygulayan durum bilgili sanal güvenlik duvarları. sanal güvenlik duvarları, en az ayrıcalık ilkesini uygular.

- 12. Tam Kurumsal Plan & Karar

14:28 Veritabanı güvenlik grubunuz yalnızca 5432 numaralı bağlantı noktasındaki bağlantıları yalnızca uygulama sunucularınızın güvenlik grubundan kabul eder, dışarıdan sızmayı matematiksel olarak imkansız hale getirir. 5432 kesinlikle uygulama sunucularınızın güvenlik grubundan, dışarıdan sızmayı matematiksel olarak imkansız hale getiriyor. Uzaklaştığınızda, bu on bir temel öğe tek bir uyumlu sisteme bağlanır. DNS'niz genel bir alt ağdaki Yük Dengeleyiciye yönlendirilir, otomatik ölçekleme grupları birden fazla Erişilebilirlik Bölgesi'ndeki trafik artışlarını yönetir, olay veri yolları arka uç çalışanlarını birbirinden ayırır ve tüm yığınlarınız Kod Olarak Altyapı kullanılarak Git'ten dağıtılır.

15:02 Bugünkü masterclass kararı: SHIP IT. Yüzlerce bulut pazarlama kısaltmasını ezberlemeyi bırakın. Bu on bir mimari kalıbına hakim olun, durumunuzu birbirinden ayırın, ve başarısız olamayacak sistemler kurun. İlk başladığınızda size en çok baş ağrısı veren bulut kavramını yorumlarda belirtin. yorumlarda bina. Ve eksiksiz mimari kopya kağıdını almak için, The Daily Diff.dev adresindeki bültene abone olun.

15:28 aşağıdaki bağlantı. Ve bugünkü fark bu kadar. Ben Axrisi'den Niko. Sorumlu bir şekilde birleştirin.

Kaynaklar

1. AWS Well-Architected Framework (Reliability & Performance Pillars)aws.amazon.com
2. Kubernetes Architecture & Control Plane Conceptskubernetes.io
3. Martin Fowler: What is Event-Driven Architecture?martinfowler.com
4. Amazon S3 Data Durability & Availability Technical Whitepaperaws.amazon.com
5. HashiCorp: Declarative Infrastructure as Code with Terraformwww.terraform.io