Amazon SAP-C02: Migrasyon ve Modernizasyon — Çalışma kılavuzu
Şunun bir parçası: AWS Solutions Architect Professional SAP-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.
Geçiş stratejisi ve planlama
Etkili bir geçiş; disiplinli bir keşif, bağımlılık haritalaması ve risk tabanlı önceliklendirme ile başlar. Sunucuları envanterlemek, performans metriklerini toplamak ve uygulama bağımlılıklarını görselleştirmek için AWS Application Discovery Service ve AWS Migration Hub’ı kullanın; gizli durum bilgisi tutan (stateful) bağlantıları bulmak için bunu aracısız (agentless) ağ akışı analizi ve yapılandırma yönetimi verileriyle tamamlayın. Keşif sonuçlarını landing zone (iniş bölgesi) kararlarına dönüştürün: AWS Control Tower ve Organizations ile hesap stratejisini seçin, Transit Gateway ile ağ topolojisini tanımlayın ve Compute Optimizer ile doğru boyutlandırma yönergelerini kullanarak hedef işlem (compute) kaynaklarını boyutlandırın. Geçiş (cutover) stratejisi her uygulama için ayrı seçilmelidir: küçük, düşük riskli sistemler için big-bang; iş açısından kritik paketler için aşamalı (phased) veya dalga tabanlı (wave-based); kullanıcı etkisini en aza indirmek için müşteriye yönelik hizmetler için blue/green veya canary. Geçişi planlarken veri senkronizasyon pencerelerini, DNS TTL’lerini, bant genişliği kısıtlamalarını ve mevzuata ilişkin kısıtlamaları göz önünde bulundurun. Yaygın tuzaklar arasında veri aktarım süresini ve maliyetlerini hafife almak, lift-and-shift’i (olduğu gibi taşımayı) nihai durum olarak görmek, lisans taşınabilirliğini ihmal etmek ve geri alma (rollback) için plan yapmamak yer alır. Karar kriterleri genellikle maliyet ile operasyonel çaba ve esneklik arasında bir denge kurar: yönetilen hizmetler (RDS/Aurora, DocumentDB) OPEX (işletme giderleri) öngörülebilirliğini ve esnekliği artırır ancak şema değişiklikleri gerektirebilir; yönetilen hizmetlere yeniden platformlama (replatforming), geçiş karmaşıklığı pahasına operasyonel yükü azaltır.
Lift-and-shift ve veri taşıma araçları
Hızlı bir yeniden barındırma (rehosting) için AWS Application Migration Service (MGN), VMware, Hyper-V ve fiziksel sunuculardan EC2’ye blok seviyesinde replikasyonu otomatikleştirerek geçiş (cutover) süresini en aza indirir ve işletim sistemi seviyesindeki yapılandırmaları korur. Büyük hacimli veya çevrimdışı veri taşıma, dosyalar ve POSIX/NFS iş yükleri için AWS Snow Family veya DataSync gerektirebilirken, Amazon S3 Transfer Acceleration ve Direct Connect nesne ve toplu aktarımı hızlandırır. Veritabanı geçişi, homojen veya heterojen geçişler için AWS Database Migration Service’e (DMS) dayanır ve yapısal değişiklikler gerektiğinde Schema Conversion Tool (SCT) ile birlikte kullanılır. DMS’in sınırlamalarına dikkat edin: MongoDB kaynak/hedef davranışının sürüm ve özellik kısıtlamaları, büyük LOB’ların (Large Objects) işlenmesi ve CDC (Değişiklik Veri Yakalama) sırasında potansiyel replikasyon gecikmesi. Veri bütünlüğü için mimari oluşturun: sağlama toplamları (checksums) ile doğrulayın, minimum kesinti için tam yükleme artı CDC çalıştırın ve geçişi düşük trafikli zaman pencerelerinde aşamalandırın. Tasarım ödünleşimleri, hız ve aslına uygunluk karşılaştırması etrafında döner: MGN veya yeniden barındırma, uygulama değişikliğini en aza indirir ancak eski operasyonel modelleri sürdürür; yeniden platformlama (replatforming) uzun vadeli operasyonları azaltır ancak yeniden düzenleme (refactor) ve test gerektirir. Yaygın tuzaklar arasında uç nokta güvenliğini ihmal etmek, geçiş öncesi yetersiz doğrulama yapmak ve bulut depolamadaki IOPS/aktarım hızının (throughput) aynı olduğunu varsaymak yer alır.
Modernizasyon: konteynerler, sunucusuz mimari ve yeniden yapılandırma (refactoring) için desenler
Modernizasyon seçenekleri, konteyner orkestrasyonuna yeniden platformlamadan (replatforming) sunucusuz mimariye tam yeniden yapılandırmaya (refactoring) kadar uzanır. Minimum altyapı yönetimi ile hızlı konteynerize edilmiş dağıtımlar için Amazon ECS on Fargate’i veya taşınabilirlik ve karmaşık orkestrasyon gerektiren Kubernetes-native iş yükleri için Amazon EKS’yi seçin. Olay güdümlü mikroservisler için, operasyonel ek yükü azaltmak ve istek başına ölçeklenmek amacıyla AWS Lambda’yı API Gateway, EventBridge ve Step Functions ile birleştirin. Veri hizmetleri yönetilen arka uçlara (backends) yönelmelidir: ilişkisel veritabanları için Amazon RDS/Aurora, NoSQL/doküman depoları için Amazon DynamoDB veya Amazon DocumentDB ve düşük gecikmeli önbellekleme için ElastiCache. Ödünleşimler, operasyonel karmaşıklık ile maliyet ve performans öngörülebilirliği arasındaki dengeye dayanır: EKS, daha yüksek operasyonel maliyetle kontrol ve taşınabilirlik sunar; Fargate operasyonları basitleştirir ancak büyük ölçekte daha pahalı olabilir. Sunucusuz mimari, düzensiz (spiky) iş yükleri için maliyet verimliliği sunar ancak soğuk başlatma (cold start), eşzamanlılık limitleri ve gözlemlenebilirlik zorlukları ortaya çıkarır. Yaygın mimari tuzakları arasında, durum bilgisi tutan (stateful) bileşenleri ayrıştırmadan monolitleri konteynerlere taşımak, dağıtımları yönetmek için yetersiz CI/CD ve IaC (CloudFormation, CDK, Terraform) kullanmak ve görev rolleri (task roles) ile Lambda yürütme rolleri (execution roles) için IAM en az ayrıcalık ilkesini göz ardı etmek yer alır.
← Veritabanları ve Analitik · Tüm alanlar · Dayanıklılık →
Bu soruları çözün → · ExamRoll.io’da süreli pratik →
Pass the whole exam — not just this question
You found this answer. Get every verified question and explanation in one place, and save hours of prep. Free to start.
Sınavınızı geçin →