Hizmetleri koordine etme ve durumu yönetme

AWS üzerinde Uygulama Geliştirme

Ricardo Sueiras

Principal Technologist

Hizmet Koordinasyonu

 

• Bir iş akışını tamamlamak için birden çok hizmet birlikte çalışır.
• Bir koordinasyon stratejisine ihtiyaç duyarlar.
• İki yaklaşım: orkestrasyon ve koreografi.

Orkestrasyon

 

• Merkezi bir orkestratör iş akışını koordine eder.
• Orkestratör sıralamayı kontrol eder ve sıradaki hizmete karar verir.
• Yeniden denemeler, koşullu mantık ve hata yönetimi için kullanışlıdır.
• AWS'de: Step Functions ile Lambda, ECS, DynamoDB üzerinde uygulanır.

Orkestrasyon

 

• İş akışı mantığı tek yerde olduğundan hata ayıklama ve izleme daha kolaydır.
• Bedeli: merkezi bir bağımlılık getirir.

Koreografi

• Merkezi bir denetleyici yok.
• Hizmetler olaylara bağımsız tepki verir.
• Her hizmet ilgili olayları dinler ve işini yapar.
• Hiçbir hizmet tüm iş akışını bilmek zorunda değildir.
• Gevşek bağlılık ve ölçeklenebilirliği artırır.

 

Koreografi

• AWS'de: EventBridge, SNS, SQS.
• Yüksek ölçekte ölçeklenebilir.
• Bedeli: iş akışları büyüdükçe anlamak ve hata ayıklamak zorlaşır.

 

Olay güdümlü mimari

• Hizmetler olay üreterek ve tüketerek iletişim kurar.
• Hizmetler arasında gevşek bağlılığı teşvik eder.
• Yüksek ölçeklenebilirliği teşvik eder.
• Olayların paralel işlenmesini sağlar.
• Mevcut hizmetleri değiştirmeden yeni hizmetler abone olabilir.

 

Olay güdümlü mimari

 

• EDA uygularken ödünleşimler:
• Sonunda tutarlılık için tasarla.
• İdempotentlik uygula.
• Hata yönetimi daha karmaşıktır.

İdempotentlik

 

• Aynı işlemi birden çok kez çalıştırmak aynı sonucu üretir.
• Asenkron ve olay güdümlü sistemlerde kritik bir tasarım ilkesidir.
• Dağıtık sistemler yinelenen olaylar teslim edebilir (yeniden denemeler, ağ hataları, yeniden işleme).
• Sistem doğruluğunu ve güvenilirliğini korur.

Dead letter queues

 

• Asenkron iletişimdeki hataları yönetir.
• Sorunlu "zehirli" iletileri izole eder.
• Tekrarlı yeniden denemeler de başarısız olunca ileti DLQ'ya taşınır.
• Ana işleme akışı çalışmaya devam eder.

Dead letter queues

• İleti sırası kritik değilse kullan.
• Ara sıra veri kaybının kabul edilebilir olduğu kritik olmayan sistemlerde atla.
• İleti sırasının korunması gerekiyorsa kaçın.

 

Durumu yönetme

• Durumu yönetmek bulut-yerel uygulamalar için temeldir.
• Durum, etkileşimler arasında korunan her tür veridir.
• Durumu sunucuda yerel saklamak ölçeklenebilirliği ve dayanıklılığı sınırlar.

 

Durumu yönetme

• Durum yönetimi, ne inşa ettiğine bağlı ödünleşimler içerir.
• Harici durum, ölçeklenebilirliği ve dayanıklılığı artırır.
• Maliyetler: ek gecikme ve karmaşıklık.
• Düşünülmesi gerekenler: tutarlılık, önbellekleme ve veri erişim kalıpları.

 

Durumlu (Stateful)

 

• Oturum verisi sunucuda tutulur.
• İstekler aynı örneğe yönlendirilmelidir (yapışkan oturumlar).
• Ölçekleme esnekliğini sınırlar.
• Örnek başarısız olursa oturum kaybolur.

Durumsuz (Stateless)

 

• Her istek bağımsız ele alınır.
• Sunucuda durum saklanmaz.
• Durum harici sistemlerde yaşar.
• Bulut-yerel uygulamalar için tercih edilen yaklaşımdır.
• Her örnek herhangi bir isteği karşılayabilir; yatay ölçekleme basittir.

Hadi pratik yapalım!

AWS üzerinde Uygulama Geliştirme