AWS'de uygulama mimarisi desenleri

AWS'de Uygulama Dağıtımı

Dunieski Otano

Amazon Web Services Solutions Architect

Eğitmeninle tanış

Yaklaşık on yıllık bulut deneyimi olan AWS Solutions Architect ve kurs eğitmeni Dunieski Otano

Doğru mimari neden önemlidir

Açık temalı karar diyagramı: tek bir mimari seçim düğümü üç faktöre ayrılıyor: bağlaşım, durum ve iletişim; alt kısımda ödün dengesi için küçük bir terazi simgesi

Mimari tek doğru değil, ödünler bütünüdür
- Her seçimi şu üç soru şekillendirir:
  - Bileşenler ne kadar sıkı bağlı?
  - Durum nerede tutuluyor?
  - İletişim eşzamanlı mı eşzamansız mı?
- Deseni iş yüküne uydur, trende değil

Cuma gecesi zincirleme etki

Yavaş bir ödeme API'si tüm ödeme akışını dondurur
Her servis ona eşzamanlı bekler
Çözüm daha hızlı API değil, mimaridir

Sıkı bağlı hizmetlerin kilitlenmesi ile bir mesaj kuyruğuyla ayrıştırılan hizmetlerin yan yana karşılaştırması

Mimari seçimler dağıtımı neden belirler

Kırılgan, sıkı bağlı bir mimaride tek bir hatalı hizmetin tüm hizmetlere yayılması ile bir kuyruğun tampon olduğu ve arızayı yalıtıp diğerlerinin hizmet vermeyi sürdürdüğü dayanıklı tasarımın diyagram karşılaştırması

Seçtiğin desen, uygulamanın nasıl ölçekleneceğini ve hataya düşeceğini belirler
- Sıkı bağlı tasarım yük altında dağılır
Doğru desen dağıtımı öngörülebilir kılar
- Aynı kod, prod'da çok farklı davranış

Temel mimari desenler

Monolitik: tek dağıtılabilir birim, başlaması kolay
Mikro servisler: bağımsız servisler, ayrı dağıtılır
Olay güdümlü: bileşenler doğrudan çağrı yerine olaylara tepki verir
- Fanout olay güdümlünün alt deseni: tek olay pek çok tüketiciye ulaşır

Yan yana üç uygulama mimarisi deseni: tek yığılmış blok olarak monolitik, bağımsız dağıtılabilir servisler olarak mikro servisler ve olay veri yolu olan olay güdümlü; panel içinde bir olayı birçok tüketiciye yayımlayan fanout alt deseni etiketli

Durumlu vs durumsuz

Durumsuz: istekler arasında istemci verisi tutulmaz
- Her örnek her isteği işleyebilir
Durumlu: örnek önceki etkileşimleri hatırlar
Yatay ölçekleme durumsuzlukla mümkün olur
- Paylaşılan durumu DynamoDB veya ElastiCache'e taşı

Solda her isteğin ulaşabildiği durumsuz işlev örneği, sağda tek istemci oturumuna bağlı durumlu örnek

Sıkı vs gevşek bağlaşım

Yavaş çağrılanı beklerken engellenen sıkı bağlaşım ile üretici ve tüketici arasına tampon olan bir SQS kuyruğuyla gevşek bağlaşım

Sıkı bağlaşım: arayan, yanıt için çağrılanı bekler
Yavaş bir servis tüm zinciri durdurur
Gevşek bağlaşım: servisler arasına bir Amazon SQS kuyruğu konur
Tüketici kapalı olsa da üretici çalışmayı sürdürür

Eşzamanlı vs eşzamansız

Eşzamanlı: arayan bloklanır ve sonucu bekler
Arayanın cevabı hemen gerektiğinde kullan
Eşzamansız: işi devredip hemen döner
Yavaş, patlamalı ya da acil olmayan işler için kullan

Solda yanıt gelene kadar bloklanan eşzamanlı çağrı, sağda arka planda işleyen ve hemen dönen eşzamansız devir

Üçüncü taraf çağrıları için dayanıklılık desenleri

Üstel geri çekilmeli yeniden dene: denemeler arası bekleme uzar
Devre kesici: arızalı servisi bir süre çağırmayı durdur
Dead-letter queue: sürekli başarısız iletileri park et
Birleştir; körlemesine yeniden denemeler kesintileri büyütür

Üç dayanıklılık deseni: üstel geri çekilme deneme eğrisi, arızalı servise çağrıları durduran devre kesici ve yeniden denemeleri tüketen iletileri yakalayan dead-letter queue

Hadi pratik yapalım!

AWS'de Uygulama Dağıtımı