Amazon SOA-C02: Bilişim ve Otomatik Ölçeklendirme — Çalışma kılavuzu

By Laurynas Brazys · 2 August 2026 · #amazon #soa-c02 #certification #exam-prep #study-guide

Şunun bir parçası: AWS SysOps Administrator Associate SOA-C02 — Çalışma kılavuzu. Doğrulanmış cevaplarla şurada pratik yapın: Amazon sınav merkezi, veya şurada süreli deneme sınavları çözün: ExamRoll.io.

Bu alan, güvenilir ve uygun maliyetli işlem (compute) kapasitesi sunmak amacıyla EC2 bulut sunucularını ve Auto Scaling’i yönetmeyi kapsar. Bulut sunucusu yaşam döngüsü operasyonları, ölçeklendirme stratejileri, yük dengeleyici entegrasyonu, performans ve dayanıklılık için yerleşim ve erişilebilirliği ile durumu (state) etkileyen bakım/sonlandırma davranışlarına odaklanır. Operasyonel uzmanlık, maliyetleri kontrol altında tutarken SLA’ları karşılamak için doğru bulut sunucusu tiplerini, başlatma yapılandırma desenlerini, ölçeklendirme politikalarını ve sağlık kontrolü entegrasyonunu seçmek anlamına gelir.

EC2 bulut sunucusu yaşam döngüsü ve yönetimi

EC2 yaşam döngüsü yönetimi, başlatma yapılandırması noktasında başlar: AMI, bulut sunucusu tipi, IAM bulut sunucusu profili, kullanıcı verisi (user-data), ağ arayüzleri, EBS eşlemesi ve meta veri seçeneklerini tanımlamak için Launch Templates (

undefined

/ konsol) kullanın; şablonlar, değişmez (immutable) dağıtımları basitleştiren sürümlemeyi destekler. Değişmez dağıtımlar, yeni bir başlatma şablonu sürümü (veya yeni bir başlatma şablonu) kullanır ve bulut sunucularını değiştirmek için ya yeni bir Auto Scaling grubu oluşturur ya da ASG bulut sunucusu yenileme (instance refresh) özelliğini kullanır; değişiklikler başlangıç (boot) zamanı davranışını veya AMI seviyesindeki yamaları etkilediğinde, çalışan bulut sunucularının yerinde (in-place) yükseltilmesinden kaçının.

Operasyonel CLI/konsol desenleri, tek seferlik başlatmalar için

undefined

ve ASG tarafından yönlendirilen başlatmalar için

undefined

komutlarını içerir. Başlangıç zamanına (boot time) göre AMI hazırlama (baking) (Packer/CodeBuild) ile kullanıcı verisi (user-data) başlangıç betikleri arasında karar verin: başlangıç süresini azaltmak için ağır bağımlılıkları AMI’ların içine gömün (bake); ortama özgü bağlantılar (wiring) için kullanıcı verisini kullanın. Geçici depolama için, instance-store birimlerinin sonlandırmada kaybolduğunu unutmayın; bulut sunucusu sonlandırıldıktan sonra EBS’nin kalıcılığına ihtiyacınız varsa kök ve veri birimlerini

undefined

ile yapılandırın.

Auto Scaling grupları, politikaları ve yaşam döngüsü kancaları

Auto Scaling Grupları (ASG’ler), bir başlatma şablonu (launch template) veya başlatma yapılandırması (launch configuration) ile yapılandırılır ve Erişilebilirlik Alanları (Availability Zones) genelinde istenen/minimum/maksimum kapasiteyi kontrol eder. On-Demand ve Spot’u bir bulut sunucusu tipi listesiyle harmanlayan maliyet optimizasyonlu filolar için başlatma şablonu + MixedInstancesPolicy seçin; öngörülebilir kapasite için bulut sunucusu ağırlıklandırma (instance weighting) ve kapasite optimizasyonlu tahsis stratejilerini (capacity-optimized allocation strategies) kullanın. Dağıtımlar için değişmez (immutable) desenleri tercih edin: mevcut bulut sunucularını yeniden yapılandırmak yerine yeni bir başlatma şablonu sürümü oluşturun ve bir ASG bulut sunucusu yenileme (instance refresh) veya mavi/yeşil (blue/green) geçişi gerçekleştirin.

Ölçeklendirme politikaları şu şekilde ifade edilir:

Hedef izleme (

undefined

): ALB RequestCountPerTarget veya ASG ortalama CPU gibi önceden tanımlanmış bir metrik ve bir hedef değer belirleyin; ASG ayarlamaları otomatik olarak yapar.

Adım ölçeklendirme (

undefined

): ihlal ciddiyetine göre belirli ayarlama adımlarını (ör. +2, +4) tetikleyen CloudWatch alarmları tanımlayın; anlık (bursty) iş yükleri için kullanışlıdır.

Basit ölçeklendirme (eski): bekleme süreli (cooldown) tek adımlı ayarlamalar; genellikle yerini hedef izleme veya adım ölçeklendirmeye bırakmıştır.

Bulut sunucusu sonlandırmasını/başlatılmasını duraklatmak için yaşam döngüsü kancalarını (

undefined

) kullanın. Yaşam döngüsü kancaları, işlem tamamlanmadan önce bağlantıları boşaltmanıza (drain), durumu (state) çoğaltmanıza (S3/RDS’e) veya SNS/SQS/Lambda aracılığıyla orkestrasyon sistemlerini bilgilendirmenize olanak tanır; takılı kalmış durumlardan (stuck states) kaçınmak için her zaman HeartbeatTimeout ve varsayılan bir eylem belirleyin.

Elastic Load Balancing tipleri ve sağlık kontrolleri

Trafik desenine göre yük dengeleyici tipini seçin: içerik tabanlı yönlendirme ve ana bilgisayar/yol (host/path) kuralları ile HTTP/HTTPS için Application Load Balancer (ALB); olağanüstü performans ve TCP/UDP için statik IP’ler için Network Load Balancer (NLB); yalnızca eski (legacy) yığınlar için Classic Load Balancer (CLB).

undefined

komutlarıyla ALB’ler ve hedef grupları oluşturun; otomatik yaşam döngüsü sağlık entegrasyonu için ASG’nin hedef grup ilişkilendirmesini kullanarak ASG hedeflerini kaydedin.

Sağlık kontrolü entegrasyonu, ASG ve ELB sağlık kontrollerini hizalamayı gerektirir: ASG HealthCheckType’ı ELB olarak ayarlayın (

undefined

), böylece bir bulut sunucusu yalnızca yük dengeleyici hedefini sağlıklı olarak işaretledikten sonra sağlıklı kabul edilir. Sağlık kontrolü tipleri ve etkileri:

ALB/NLB hedef grubu sağlık kontrolü: HTTP/HTTPS/TCP’yi destekler ve uygulama seviyesindeki hazır olma durumunu ölçer; web uygulamaları için önerilir.
Yalnızca ASG sağlık kontrolleri: basit ana makine seviyesi kontroller (ör. EC2 durum kontrolleri) için kullanın.
HealthCheckGracePeriod: yeni bulut sunucularına başlatılması, kullanıcı verisini (user-data) çalıştırması ve uygulama seviyesi kontrolleri geçmesi için zaman tanıyın.

Yapışkanlık (Stickiness) etkileri: ALB hedef grubu yapışkanlığı, oturum yakınlığını (session affinity) iyileştirebilen ancak eşit dağılımı azaltan ve sıralı güncellemeleri (rolling updates) karmaşıklaştıran, uygulama çerezi tabanlı (süre tabanlı) bir yakınlık (affinity) kullanır. NLB, istemci IP yakınlığını (client IP affinity) destekler; yapışkanlığı yalnızca oturum durumu (session state) dışarıya taşınamadığında kullanın.

Instance yerleşimi, kapasite planlaması ve ölçeklendirme metrikleri

Yerleşim kararları gecikmeyi ve hata etki alanlarını (failure domains) etkiler: yerleşim grupları (placement groups) cluster (düşük gecikmeli ağ), spread (kritik instance’lar için her rack’e bir instance) ve partition (hatadan yalıtılmış bölümler) stratejileri sunar. ASG’ler varsayılan olarak instance’ları AZ’ler arasında dengeler; tek bir AZ’de yoğunluk (hotspot) oluşmasını önlemek için AZ’ye duyarlı kapasite planlamasını tercih edin. CLI için: aws ec2 create-placement-group –strategy cluster|spread|partition.

Kapasite planlaması, instance tiplerini, satın alma seçeneklerini ve metrikleri dikkate alır:

Instance tipleri: iş yüküne göre CPU/bellek/ağ için optimize edilmiş aileleri (M/C/R/T/D/I) seçin; temsili yük testleri ile ölçüm yapın.
Satın alma: öngörülebilirlik için On-Demand, sürekli durumdaki maliyetleri düşürmek için Reserved veya Savings Plans, geçici işler için maliyet verimliliği sağlayan Spot; tipleri ve satın alma seçeneklerini birleştirmek için MixedInstancesPolicy kullanın.
Ölçeklendirme metrikleri: varsayılan ASG metrikleri grup genelindeki ortalama CPU’yu kullanır; hedef takibi (target tracking) için ALB RequestCountPerTarget gibi uygulama seviyesi metrikleri veya özel CloudWatch metriklerini (ör. kuyruk derinliği) tercih edin. Yaygın desenler:
Instance başına sabit sayıda istek gerektiğinde, ALB/request-count-per-target ile hedef takibini (target tracking) kullanın.
Tanımlanmış toparlanma adımları ile ani ve büyük artışlar için adım ölçeklendirmeyi (step scaling) kullanın.
Günlük döngüsel iş yükleri için Predictive Scaling’i (Tahmine Dayalı Ölçeklendirme) değerlendirin.

Instance kurtarma, sonlandırma davranışı ve bakım

Donanım sorunları için otomatik kurtarmayı (EC2 Recover eylemi ile CloudWatch alarmı) etkinleştirerek ve zamanlanmış olayları (describe-instance-status) yöneterek instance arızaları ve bakımlar için plan yapın. Volume yaşam döngüsünü kontrol etmek için instance-initiated-shutdown-behavior ve EBS DeleteOnTermination bayraklarını yapılandırın; ayarlamak için aws ec2 modify-instance-attribute –instance-id i-xxx –block-device-mappings kullanın.

ASG’lerde sonlandırma davranışı: ASG sonlandırma politikaları (termination policies) hangi instance’ın önce sonlandırılacağına karar verir (Default: en eski launch configuration veya instance sağlığı ve AZ dengeleme sezgisel yöntemleri). Önemli operasyonel detaylar:

Yerel durum geçicidir: instance-store birimleri ve bellek içi önbellekler (in-memory caches) sonlandırma sırasında kaybolur. Değiştirilen instance’ın yerel durumu koruyacağını varsaymayın; kritik verileri EBS (uygun snapshot/yedekleme ile), S3 veya harici bir önbelleğe (ElastiCache) kalıcı olarak yazın.
Sonlandırmadan önce trafiği boşaltmak (drain) ve durumu dışarı aktarmak (offload) için yaşam döngüsü kancalarını (lifecycle hooks) kullanın.
Bakım sırasında instance’ları güvenli bir şekilde değiştirmek için instance refresh veya blue/green yöntemlerini kullanın; aws autoscaling start-instance-refresh –auto-scaling-group-name my-asg –preferences file://prefs.json.

Sık Yapılan Hatalar ve Karar Kriterleri

Varsayılan bekleme sürelerine (cooldowns) ve yalnızca CPU metriklerine güvenmek: uygulama davranışıyla uyumlu metrikler seçin (ALB RequestCountPerTarget, kuyruk derinliği); dalgalanmayı (oscillation) önlemek için bekleme sürelerini başlangıç zamanını karşılayacak şekilde ve HealthCheckGracePeriod’u ayarlayın.
Düzgün sonlandırma (graceful termination) için yaşam döngüsü kancalarını (lifecycle hooks) kullanmamak: kancalar olmadan, işlemdeki istekler (in-flight requests) ve yerel önbellekler kaybolur; durumu boşaltmak ve kalıcı hale getirmek için SNS/SQS/Lambda ile kancaları uygulayın.
Instance değişiminin yerel durumu koruduğunu varsaymak: yerel instance-store ve bellek içi önbellekler geçicidir; durumsuz (stateless) instance’lar için tasarım yapın veya durumu dayanıklı depolama alanlarına çoğaltın.
Yapışkan oturumları (stickiness) aşırı kullanmak: yapışkanlık, dengesiz yük dağılımını artırır ve ölçeklendirme ile güncellemeleri karmaşıklaştırır; yatay ölçeklendirme (scale-out) için harici oturum depolarını (ElastiCache, DynamoDB) tercih edin.
AZ dengelemesini ve yerleşim gruplarını (placement groups) göz ardı etmek: tek bir AZ’ye veya cluster grubuna çok fazla instance yerleştirmek, tekil hata noktaları (single points of failure) yaratabilir; ASG’nin çoklu AZ dağıtımını ve uygun yerleşim grubu stratejilerini kullanın.
Sağlık kontrolü (health-check) entegrasyonunu yanlış yapılandırmak: ASG health-check-type, ELB/hedef grup sağlık kontrolleriyle eşleşmeli ve HealthCheckGracePeriod, uygulamanın başlatılması için yeterince uzun olmalıdır, aksi takdirde sağlıklı instance’lar sonlandırılır.

Pratik Problem: Kullanım Senaryosu

StreamingCo, günlük trafik artışları yaşayan bir video küçük resmi (thumbnail) API’si işletmektedir ve EC2 instance’larında yerel disk önbellekleri kullanmaktadır; son zamanlarda, ölçeklenme yavaşlamış ve sonlandırılan instance’ların önbelleği kaybetmesi kötü yanıt sürelerine yol açmıştır.

Launch configuration’ı bir Launch Template’e taşıyın ve çalışma zamanı bağımlılıklarını içeren hafif bir AMI oluşturun (bake); değişmez (immutable) dağıtımlar için aws ec2 create-launch-template ve sürüm kontrolünü kullanın.
Maliyet ve kapasiteyi dengelemek için birkaç instance tipini ve Spot + On-Demand tahsisini listeleyen bir MixedInstancesPolicy ile bir ASG yapılandırın.
Bir ALB bağlayın ve uygulamanın başlangıç (bootstrap) süresine ayarlanmış bir HealthCheckGracePeriod ile ALB RequestCountPerTarget metriği üzerinde TargetTrackingScaling kullanın.
Bağlantıları boşaltmak (drain) ve sonlandırmadan önce gerekli önbellek anahtarlarını ElastiCache veya S3’e kalıcı olarak yazmak için bir Lambda/SNS akışı çalıştırmak üzere ASG sonlandırmalarında yaşam döngüsü kancaları (lifecycle hooks) uygulayın.
Oturum ve önbellek durumunu ElastiCache veya S3’e dışsallaştırın ve gecikme ile hata etki alanı (fault-domain) gereksinimlerini karşılamak için yerleşim gruplarını/AZ dağıtımını kullanın.

Gerekçe: Launch template’ler ve değişmez (immutable) dağıtımlar kullanmak, başlangıçtaki değişkenliği azaltır; ALB hedefli target tracking, ölçeklendirmeyi CPU yerine istek yüküne bağlar; yaşam döngüsü kancaları (lifecycle hooks) sonlandırma sırasında veri kaybını önler; önbelleği dışsallaştırmak, geçici yerel duruma olan bağımlılığı ortadan kaldırır ve karma instance/satın alma stratejileri aracılığıyla hızlı, güvenli ölçeklendirme ve daha düşük maliyet sağlar.

← Depolama ve Veri Yönetimi · Tüm alanlar · Veritabanları ve Önbelleğe Alma →

Bu soruları çözün → · ExamRoll.io’da süreli pratik →