Örnek Yenileme ve Yaşam Döngüsü Kancaları

Bir Launch Template'i (yeni AMI, yeni kullanıcı verileri veya yeni bulut sunucusu türüyle) güncellediğinizde, ASG'de çalışmakta olan mevcut bulut sunucuları otomatik olarak değiştirilmez; eski yapılandırmayla çalışmaya devam ederler. Değişiklikleri yaymak için bulut sunucularını değiştirmeniz gerekir. Bulut sunucularını manuel olarak sonlandırıp yeniden başlatmak risklidir ve hataya açıktır. Instance Refresh, yapılandırılabilir güvenlik denetimleriyle bu süreci otomatikleştirir.

Instance Refresh, ASG bulut sunucularını dönen gruplar hâlinde değiştirir. Her adımda eski bulut sunucularından bir grubu sonlandırır, yeni bulut sunucularının durum denetimlerini geçmesini bekler ve ardından sonraki gruba geçer. Hızı, yenileme sırasında kapasitenin sağlıklı kalması gereken minimum yüzdeyi belirleyen MinHealthyPercentage ve isteğe bağlı bir InstanceWarmup süresiyle denetlersiniz.

MinHealthyPercentage, yenileme sırasında sağlıklı kapasitenin alt sınırını tanımlar. Bu değeri %90 olarak ayarlarsanız filonun aynı anda yalnızca %10'u değiştirilir; süreç daha yavaştır ancak daha güvenlidir. %50 değeri, filonun yarısını aynı anda değiştirir; süreç daha hızlıdır ancak yedeklilik daha azdır. ASG, grup boyutlarını bu yüzdeye ve mevcut istenen kapasitenize göre otomatik olarak hesaplar. Kullanılabilirliği korumak için üretim iş yüklerinde daha yüksek bir yüzde seçin.

Kontrol noktaları, Instance Refresh işlemini önceden belirlenmiş yüzde aşamalarında duraklatmanıza olanak tanır. Örneğin bulut sunucularının %20'sini yenileyip duman testlerini çalıştırmak için 10 dakika duraklatabilir, ardından devam edebilirsiniz. Herhangi bir kontrol noktasında sorun tespit ederseniz yenilemeyi iptal edebilirsiniz; ASG ek bulut sunucularını değiştirmeyi durdurur ancak daha önce değiştirilen bulut sunucularını çalışır durumda bırakır (bunlar zaten yeni şablonu kullanmaktadır). Bu, EC2 için etkili bir canary dağıtımı modelidir.

Devam eden bir Instance Refresh işlemini istediğiniz zaman iptal edebilirsiniz; bu işlem yeni değişiklikleri durdurur ancak tamamlananları geri almaz. Durumu, ilerleme yüzdesini ve başlatılamayan bulut sunucularını kontrol etmek için describe-instance-refreshes kullanın. Yeni bir AMI'yi Launch Template'e gönderdikten sonra yenilemeyi otomatik olarak tetiklemek için Instance Refresh'i CI/CD işlem hattınıza entegre ederek tamamen otomatik, blue/green tarzı bir dağıtım gerçekleştirebilirsiniz.

Lifecycle Hooks, özel mantık çalıştırabilmeniz için ASG bulut sunucusu geçişlerini önemli anlarda duraklatır. İki kanca noktası vardır: EC2_INSTANCE_LAUNCHING (başlatmadan sonra, bulut sunucusu InService durumuna alınmadan önce) ve EC2_INSTANCE_TERMINATING (sonlandırma kararından sonra, bulut sunucusu gerçekten sonlandırılmadan önce). Bir kanca sırasında bulut sunucusu Pending:Wait veya Terminating:Wait durumundadır.

Başlatma kancası, bir bulut sunucusu trafiğe hizmet vermeden önce tamamlanması gereken görevler için idealdir: ek yazılım yüklemek, Parameter Store'dan yapılandırma çekmek, bir hizmet keşfi kayıt sistemine kaydolmak veya tümleştirme testleri çalıştırmak. Kanca tamamlanana (veya zaman aşımına uğrayana) kadar ASG bulut sunucusunu yük dengeleyicinin hedef grubuna eklemez. Bu, trafiğin yapılandırması tamamlanmamış bir bulut sunucusuna ulaşmasını önler.

Sonlandırma kancası, bir bulut sunucusu gerçekten sonlandırılmadan önce çalışır. Kullanım alanları arasında uygulama düzeyindeki bir kuyruktan devam eden istekleri boşaltmak, önbelleğe alınan verileri kalıcı bir depoya yazmak, hizmet kayıt sistemindeki kaydı kaldırmak veya günlük dosyalarını S3'e kopyalamak bulunur. Sonlandırma kancası olmadan sonlandırılan bir bulut sunucusundaki devam eden işler kaybolabilir. Kanca, düzgün kapatma görevlerini tamamlamanız için size (kalp atışı zaman aşımı olarak) 2 saate kadar süre tanır.

Bulut sunucusunda çalışan (veya bulut sunucusu tarafından tetiklenen) özel mantık, işi tamamladığında kancaya sinyal göndermelidir. complete-lifecycle-action komutunu CONTINUE (normal şekilde devam et) veya ABANDON (başlatma kancasında bulut sunucusunu sonlandır; sonlandırma kancasında sonucu yok sayıp devam et) ile kullanın. Ayrıca maksimum süreye kadar her aralıkta bir kalp atışı göndererek kancanın zaman aşımını uzatabilirsiniz. Kancanın zaman aşımına uğraması durumunda DefaultResult uygulanır.

Yaşam döngüsü kancalarına yanıt vermenin en temiz yolu Amazon EventBridge kullanmaktır. Bir yaşam döngüsü kancası tetiklendiğinde ASG, EventBridge'e bir olay gönderir. Bir EventBridge kuralı bu olayı gerekli işi gerçekleştiren ve ardından complete-lifecycle-action çağrısı yapan bir Lambda işlevine yönlendirir. Bu mimari tamamen sunucusuzdur, yoklama gerektirmez ve otomatik olarak ölçeklenir. SQS ve SNS bildirimleri daha eski seçeneklerdir; ancak yeni tasarımlar için EventBridge tercih edilir.

Instance Refresh bir bulut sunucusunu değiştirdiğinde her iki yaşam döngüsü kancası da çalışmaya devam eder: eski bulut sunucusunda sonlandırma kancası, yenisinde ise başlatma kancası. Bu, düzgün kapatma ve başlatma mantığınızın yalnızca normal ölçeklendirme olaylarında değil, dönen bir güncelleme sırasında da otomatik olarak çalıştığı anlamına gelir. Doğru davranışı doğrulamak için üretim dağıtımından önce yaşam döngüsü kancası mantığınızı aşamalı bir Instance Refresh sırasında mutlaka test edin.

Bu derste ele alınan AWS Solutions Architect (SAA-C03) kavramlarını anlayıp anlamadığınızı test edin.

Bu derste şunları öğrendiniz: Instance Refresh, MinHealthyPercentage ve canary tarzı doğrulama için isteğe bağlı kontrol noktalarıyla denetlenen dönen gruplar hâlinde ASG bulut sunucularını değiştirir; Lifecycle Hooks, özel başlatma veya düzgün kapatma mantığını çalıştırmak için başlatma ya da sonlandırma sırasında bulut sunucusu geçişlerini duraklatır; EventBridge + Lambda ise yoklama yapmadan yaşam döngüsü kancası olaylarına yanıt vermek için önerilen modeldir. Sırada AWS Lambda işlevlerini, çalışma zamanlarını, tetikleyicilerini ve işleyicilerini inceleyeceğiz.