Serverless günlük rapor, askıya alınmış AWS Auto Scaling süreçlerini ortaya çıkarıyor

Scaling'i bozan unutulmuş bir bayrak

Amazon EC2 Auto Scaling Group'lar, mühendislere tek tek scaling süreçlerini askıya alma imkânı verir — Launch, Terminate, HealthCheck ve AZRebalance bunlardan bazılarıdır. dev.to'da yayımlanan bir yazıya göre bu esneklik olaylar (incident) sırasında değerlidir: bir dağıtım için kapasiteyi dondurmak, hata ayıklarken instance değişimini durdurmak veya bir geçiş sırasında grubu sabit tutmak. Tehlike, daha sonra kimse askıya alınan süreçleri hatırlamadığında ortaya çıkar.

Launch askıya alınmış bir grup, trafik arttığında kapasite eklemez; HealthCheck askıya alınmış olan ise sağlıksız instance'ları değiştirmez. Yazar, bu durumu varsayılan olarak kapsayan hiçbir alarm olmadığını belirtiyor; dolayısıyla ekipler artık kullanılmayan askıya almayı, tam da scaling'in çalışmasını gerektirdiği bir olayın ortasında keşfediyor.

Üç parçalı serverless hattı

dev.to'da anlatılan çözüm, günlük çalışan ve neredeyse hiç maliyeti olmayan bir zincir:

• Amazon EventBridge cron tarzı bir tetikleyici sağlar.
• Python ve boto3 ile yazılmış bir AWS Lambda fonksiyonu, yapılandırılmış bölgelerdeki tüm Auto Scaling Group'ları listeler ve yalnızca askıya alınmış süreci olanları tutar.
• Amazon SES bulguları biçimlendirilmiş bir HTML e-posta olarak iletir.

Sayfalama ve raporun kendisi

Tarama, describe_auto_scaling_groups üzerinde bir paginator kullanıyor; yazar bunu zorunlu olarak işaretliyor: çok sayıda gruba sahip hesaplarda yanıtlar sayfalanır, bu yüzden tek bir sayfalanmamış çağrı bazı grupları sessizce atlar.

E-posta, etkilenen her grubu bölgesi, adı, askıya alınmış süreç adları ve min, desired ve max kapasite değerleriyle listeliyor; böylece okuyucu etkiyi ham JSON'u incelemek yerine bir bakışta değerlendirebiliyor. NOTIFY_WHEN_EMPTY ayarı, yalnızca uyarı modu ile günlük "her şey yolunda" mesajı arasında geçiş yapıyor.

Framework olmadan dağıtım

Dağıtım hiçbir bağımlılık gerektirmiyor: bir bash script'i AWS CLI'yi çağırıyor, handler.py dosyasını zip'liyor ve Lambda'yı Python 3.12 üzerinde 120 saniyelik timeout ile oluşturuyor (örnekte ap-south-1). EventBridge kuralı ve IAM rolü de ya aynı şekilde ya da bir kez elle oluşturuluyor. Framework yok, agent yok, ayakta tutulacak sunucu yok.

Öğrenilmeye değer iki hata

Yazı ayrıca hattın çalışmadan önce düzeltilmesi gereken iki hatayı da kaydediyor.

İlk çağrı Runtime.ImportModuleError ile sonlandı: fonksiyon hâlâ konsol varsayılanı olan lambda_function.lambda_handler'ı gösteriyordu, oysa kod aslında handler.py içinde handler adında bir fonksiyondu. Handler ifadesi önce dosya sonra fonksiyon şeklinde olmalı; bu yüzden handler.handler değerini ayarlayan tek bir update-function-configuration çağrısı sorunu çözdü.

İkinci çalışma daha ileri gitti ve describe_auto_scaling_groups üzerinde AccessDenied hatasıyla başarısız oldu: execution rolünde bir trust policy vardı ama kodun ihtiyaç duyduğu izinlerin hiçbiri yoktu. Çözüm, autoscaling:DescribeAutoScalingGroups iznini veren minimal bir inline policy oldu — yazar, bu iznin kaynak düzeyinde kısıtlama desteklemediğini, bu yüzden wildcard kaynak gerektirdiğini belirtiyor — ayrıca daha sıkı least privilege için doğrulanmış bir SES kimliğiyle sınırlandırılabilecek olan ses:SendEmail ve ses:SendRawEmail izinleri eklendi.

Yazarın çıkarılan daha genel ders şu: least-privilege IAM AccessDenied hataları üretecektir ve bu bir özelliktir; her hata, genel wildcard'lara yönlendirmek yerine, verilmesi gereken tek bir eylemi tek tek adlandırır. Hata türünü okumak da doğrudan çözüme işaret eder — import hataları yapılandırma sorunlarıdır, erişim hataları IAM sorunlarıdır.

Neden önemli

Askıya alınmış scaling süreçleri, olaylar sırasında bunlara başvuran her ekip için sessiz ama gerçek bir risktir ve varsayılan AWS araçlarında artıkları raporlayan hiçbir şey yoktur. Bu örüntü, bu boşluğu günlük bir Lambda çağrısının maliyetiyle kapatır.

Ayrıca geniş ölçüde yeniden kullanılabilir: boto3 çağrısını değiştirin, aynı EventBridge-Lambda-SES iskeleti şifrelenmemiş volume'ları, public snapshot'ları, boşta bekleyen load balancer'ları ya da CloudWatch alarmlarının doğal olarak kapsamadığı herhangi bir yavaş gelişen drift'i raporlayabilir. Yazının da savunduğu gibi, bu tür küçük periyodik otomasyonlar birkaç satırlık Python ile ciddi üretim arızalarını önleyebilir.