Bir "lift-and-shift" geçişi sonucunda, her bir EC2 instance'ının web, veritabanı ve Redis önbellek bileşenlerini çalıştırdığı tek bir Auto Scaling grubu kaldı. Bu durum değişken yanıt sürelerine ve aşırı yüklenmiş instance'lara neden oldu. Şirket, kullanılabilirliği ve performansı artırmak için bileşenleri ayırmak istiyor. Bu gereksinimi hangi mimari değişikliği karşılar?

Doğru cevap, web uygulaması için bir Application Load Balancer (ALB) ve bir Auto Scaling grubu oluşturulmasını, veritabanının Multi-AZ özellikli bir Amazon Aurora veritabanına taşınmasını ve önbellek için bir Amazon ElastiCache (Redis OSS) kümesi oluşturulmasını önerir. Bu yaklaşım, her bir bileşeni ayrı katmanlara ayırarak ölçeklenebilirlik, kullanılabilirlik ve performans sorunlarını çözer. ALB, HTTP/S trafiğini yönetmek ve web katmanını ölçeklendirmek için idealdir. Multi-AZ Aurora, veritabanı için yüksek kullanılabilirlik ve dayanıklılık sağlarken, ElastiCache Redis önbelleği, düşük gecikmeli veri erişimi ve ayrı ölçeklenebilirlik sunar. Diğer seçenekler hatalıdır çünkü: İlk seçenek, Redis önbelleği için bir ALB ve Auto Scaling grubu önermektedir ki bu Redis için uygun değildir. Ayrıca, Aurora Serverless her zaman Multi-AZ Aurora kadar performanslı veya uygun maliyetli olmayabilir. İkinci seçenek, Redis önbelleği için tek bir Availability Zone'da bir Network Load Balancer (NLB) ve Auto Scaling grubu önermektedir ki bu, Redis için uygun olmayan bir mimaridir ve tek bir AZ'de olması yüksek kullanılabilirliği engeller. Üçüncü seçenek, web uygulaması için bir NLB önermektedir ki bu, HTTP/S trafiği için ALB'nin gelişmiş özelliklerini sunmaz. Ayrıca, ElastiCache için hedef grubu oluşturmak yerine doğrudan ElastiCache kümesi kullanılır.