Bir şirket, basit bir ölçeklendirme politikası kullanan bir Auto Scaling grubundaki üç EC2 örneğinde çalışan bir worker uygulamasıyla mesajları işler. Worker'lar Amazon SQS kuyruğundan mesajları yoklar. Mesajlardaki düzensiz artışlar işleme performansını düşürüyor ve SysOps yöneticisinin daha yüksek kuyruk hacmini yönetmek için Auto Scaling grubunu ölçeklendirmesi gerekiyor. Bu gereksinimi en iyi hangi yaklaşım karşılar?

Doğru cevap, SQS kuyruğu için örnek başına yaklaşık görünür mesaj sayısını hesaplamak üzere CloudWatch metric math kullanmak ve bu ifadeye dayalı bir hedef izleme ölçeklendirme politikası oluşturmaktır. Bu yaklaşım, iş yükü arttığında (yani kuyruktaki mesaj sayısı arttığında) Auto Scaling grubunun otomatik olarak ölçeklenmesini sağlar. Hedef izleme politikaları, belirli bir metriği belirli bir hedef değerde tutmaya çalışarak dinamik ve verimli ölçeklendirme sağlar. Diğer seçenekler neden yanlış: SQS kuyruğundaki en eski mesajın yaşını tahmin etmek için CloudWatch metric math kullanmak, doğrudan iş yükünü yansıtmadığı için optimal bir ölçeklendirme metriği değildir. Mesaj yaşı, mesaj sayısıyla her zaman doğru orantılı olmayabilir. Application Load Balancer (ALB) oluşturmak ve ALBRequestCountPerTarget metriğini kullanmak, worker uygulamaları için uygun değildir çünkü worker'lar genellikle doğrudan SQS'ten mesaj çeker ve dışarıdan gelen HTTP/HTTPS isteklerini işlemezler. ALB oluşturmak ve zamanlanmış bir ölçeklendirme politikası yapılandırmak, ani ve düzensiz mesaj artışlarını yönetmek için yeterince dinamik değildir. Zamanlanmış politikalar, öngörülebilir iş yükleri için daha uygundur.