Amazon DOP-C02: Konteynerler ve Sunucusuz Operasyonlar — Çalışma kılavuzu
Şunun bir parçası: AWS DevOps Engineer Professional DOP-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.
Genel Bakış
Konteynerler ve sunucusuz (serverless) mimari, AWS üzerinde uygulamaları işletme, ölçeklendirme ve yayınlama şeklinizi değiştirir. Bu bölüm, Amazon ECS, AWS Fargate, Amazon EKS, Amazon ECR, AWS Lambda ve Amazon API Gateway genelindeki operasyonel temel bileşenleri birbirine bağlar; böylece güvenli dağıtımlar tasarlayabilir, imaj yönetişimini (image governance) uygulayabilir, eş zamanlılığı (concurrency) ayarlayabilir ve EC2 ile Fargate tabanlı kapasite arasında tutarlı seçimler yapabilirsiniz. Bölüm; görev (task) ve pod zamanlama modellerine, sağlık kontrolleri ve dağıtım denetimlerine, trafik yönlendirmeye, hesaplar arası imaj dağıtımına ve API önbellekleme (caching) ile Lambda provisioned concurrency gibi performans özelliklerine odaklanır.
Amazon ECS ve AWS Fargate
ECS görev tanımları (task definitions), bir veya daha fazla konteyneri ve zamanlayıcının (scheduler) ihtiyaç duyduğu tüm çalışma zamanı yapılandırmasını beyan eder. Temel unsurlar arasında CPU/bellek rezervasyonları ve limitleri, portMappings, ortam değişkenleri ve gizli bilgiler (AWS Secrets Manager veya Systems Manager Parameter Store’dan), Linux parametreleri ve ulimit’ler, logConfiguration (awslogs, firelens, vb.), ephemeralStorage boyutu (Fargate için 20–200 GB) ve volümler (EFS dahil) bulunur. İmaj çekme (pull) ve log sürücüleri için görev yürütme rolünü (task execution role); uygulama AWS API erişimi için ise görev rolünü (task role) kullanın. Konteyner healthCheck; komut, aralık (interval), zaman aşımı (timeout), yeniden deneme (retries) ve startPeriod’u tanımlar. dependsOn (condition=HEALTHY) ile birleştirildiğinde, sağlık kontrolleri sidecar’lar için başlatma sıralamasını zorunlu kılar.
ECS servisleri, istenen görev sayısını (desired task count) korur ve isteğe bağlı olarak görevleri bir ALB/NLB’ye kaydeder. Servis deploymentConfiguration, minimumHealthyPercent ve maximumPercent ile rolling update’leri kontrol eder. Dağıtım devre kesicisi (deployment circuit breaker) (enabled/rollback), görevler sağlık kontrollerinde başarısız olduğunda, başarısız olan dağıtımları otomatik olarak geri alabilir. Servis otomatik ölçeklendirme (autoscaling), CPU/bellek tabanlı hedef takibi (target tracking) veya ALB RequestCountPerTarget için Application Auto Scaling ile entegre olur. Servis keşfi (Service discovery) (AWS Cloud Map) ve ECS Service Connect, servisler arası trafiği basitleştirir.
Küme türleri ve kapasite:
- EC2 launch type, görevleri kendi yönettiğiniz EC2 bulut sunucularında çalıştırır. Auto Scaling gruplarını, yerleştirme kısıtlamalarını/stratejilerini (placement constraints/strategies) ve herhangi bir networkMode’u (bridge/host/awsvpc) kullanın. Daemon görevleri ve özelleştirilmiş AMI’ler (örneğin, Bottlerocket) desteklenir.
- Fargate launch type, konteynerler için sunucusuz bir işlem (compute) platformudur. Yalnızca awsvpc ağ modunu kullanır ve her göreve kendi ENI’sini ve güvenlik grubunu verir. Daemon görevleri yoktur; sidecar’lara veya servis yerel entegrasyonlarına (örneğin, FireLens) güvenirsiniz. Platform sürümleri özellikleri belirler (EFS, ephemeral storage ve exec desteği için sürüm notlarını kontrol edin). Fargate Spot, kesintiye uğrayabilecek görevler için maliyeti düşürür. CPU/belleği desteklenen çiftler halinde seçin (örneğin, 0.25 vCPU/0.5–2 GB’den 16 vCPU/120 GB’ye kadar). Özel alt ağlarda (private subnets) çalışırken, imajları çekmek ve logları NAT olmadan göndermek için ECR (api ve dkr), CloudWatch Logs için VPC arayüz uç noktaları (interface endpoints) ve S3 için ağ geçidi uç noktası (gateway endpoint) ekleyin.
Fargate ve EFS: görev tanımında bir EFS volümü tanımlayın ve TLS ile bağlayın (mount); en az ayrıcalık (least-privilege) ve kimlik zorlaması için EFS erişim noktalarını (access points) tercih edin. Bu, paylaşılan yapılandırmalar, model ağırlıkları veya ara dosyalar gibi durum bilgisi gerektiren (stateful) ihtiyaçları, bunları imajların içine dahil etmeden destekler.
Konteyner sağlık kontrolleri, rolling update’ler ve blue/green:
- Sağlık kontrolleri birden çok katmanda gerçekleşir: konteyner (CMD tabanlı), ECS görevi (toplu konteyner durumları) ve yük dengeleyici hedef sağlığı (HTTP/TCP). Aralıkları ve eşikleri, ECS’nin sağlıksız görevleri ALB hedefleri kayıttan çıkarmadan önce düzgün bir şekilde değiştirebilmesi için hizalayın.
- Rolling update’ler ECS’nin varsayılanıdır. Anlık artışı (surge) ve kapasite güvenliğini kontrol etmek için minHealthy/maxPercent ayarlarını yapın.
- Blue/green, ECS ile CodeDeploy kullanır (deploymentController türü CODE_DEPLOY). CodeDeploy, ALB’nin arkasındaki iki hedef grubunu (target group) yönetir, test trafiğini yeşil kümeye (green set) kaydırır (AfterAllowTestTraffic), otomatik kontrolleri çalıştırır (örneğin Lambda aracılığıyla) ve ardından üretim trafiğini kaydırır. 5XX ani artışları, gecikme veya özel metrikler durumunda geri alma (rollback) işlemi için CloudWatch alarmlarını bağlayın. Bu desen, arızaları izole eder ve sıfıra yakın kesinti süresiyle hızlı geri dönüşler sağlar.
ECR ile imaj yönetişimi:
- Tarama: scan-on-push’u etkinleştirin ve sürekli CVE kapsamı ve SBOM’lar için Amazon Inspector gelişmiş taramasını (enhanced scanning) benimseyin. Pipeline kontrollerini kullanarak dağıtımları güvenlik açığı önem derecesine göre denetleyin.
- Yaşam döngüsü politikaları (Lifecycle policies), eski imaj etiketlerini sayıya/yaşa ve etiket önekine göre sonlandırır. Yanlışlıkla üzerine yazmaları engellemek için etiket değişmezliği (tag immutability) ile birleştirin.
- Şifreleme: ECR tarafından yönetilen şifrelemeyi veya uygun anahtar politikasına sahip müşteri tarafından yönetilen bir KMS anahtarını kullanın.
- Hesaplar arası (Cross-account): Diğer hesaplardan veya CI rollerinden çekme/itme (pull/push) izni vermek için depo kaynak politikalarını (repository resource policies) ekleyin. Yerellik (locality) ve etki alanını (blast-radius) azaltmak için imajları Bölgeler/hesaplar arasında kopyalamak için ECR çoğaltma kurallarını (replication rules) kullanın. PrivateLink (VPC uç noktaları), internet olmadan imaj çekmeye olanak tanır.
Amazon EKS Bilişim Modelleri
EKS, yönetilen kontrol düzlemini (control plane) veri düzlemi (data plane) seçeneklerinizden ayırır:
Yönetilen düğüm grupları (MNG’ler), EC2 çalışan düğümlerini (worker nodes) tedarik eder ve yaşam döngülerini yönetir. AMI seçimi (Amazon Linux 2, Bottlerocket), EC2 örnek tipleri ve bootstrap parametreleri için launch template’ler ile entegre olurlar. MNG’ler, kesintiyi en aza indirmek için surge kapasitesi ile sıralı güncellemeleri (rolling updates) ve otomatik cordon/drain işlemlerini yönetir. Belirli iş yüklerini yönlendirmek için node taint’lerini ve toleration’larını kullanın. Bekleyen pod’lara (pending pods) göre düğüm kapasitesini doğru boyutlandırmak (rightsize) için Cluster Autoscaler (veya Karpenter) ile birlikte kullanın.
Kendi kendine yönetilen düğümler (self-managed nodes), bootstrap ve işletim sistemi üzerinde tam kontrol sağlar ancak operasyonel yük getirir; genellikle özel kernel’lar veya niş donanımlar için kullanılırlar.
EKS on Fargate, düğümleri yönetmeye gerek kalmadan pod’ları çalıştırır. Fargate profilleri, namespace’leri/label’ları Fargate’e eşler. Her pod kendi ENI’sini (awsvpc) alır, bu da ağ izolasyonunu basitleştirir. Kısıtlamaları arasında DaemonSet’lerin, host ağının/volümlerinin olmaması ve ayrıcalıklı (privileged) iş yükleri üzerindeki kısıtlamalar yer alır. Gözlemlenebilirlik (observability) ajanları (ör. Fluent Bit), sidecar olarak çalışmalı veya yönetilen log toplama hizmetlerini kullanmalıdır. Bu model, ani yükselen (spiky), az yer kaplayan (small-footprint) veya pod başına izolasyon ve pod başına ödeme ekonomisinden yararlanan çok kiracılı (multi-tenant) iş yükleri için idealdir.
Operasyonel eklentiler:
- VPC CNI, CoreDNS ve kube-proxy yönetilen eklentilerdir (managed add-ons); küme sürümüyle uyumlu sürümleri sabitleyin (pin) ve yükseltmeleri bilinçli olarak yapın.
- IAM Roles for Service Accounts (IRSA), pod başına en az ayrıcalık (least-privilege) ilkesiyle AWS erişimini zorunlu kılar ve düğüm rolü (node-role) kimlik bilgisi paylaşımının yerini alır.
- AWS Load Balancer Controller aracılığıyla yük dengeleme, Service’ler ve Ingress’ler için ALB/NLB’yi destekler; özellikle MNG ve Fargate’i bir arada kullanırken uygun IAM ve güvenlik grubu kurallarını sağladığınızdan emin olun.
- CSI sürücüleri aracılığıyla kalıcı depolama (EBS pod başına blok depolama için, EFS paylaşılan POSIX için). Fargate için, paylaşılan durum (shared state) için genellikle EFS tercih edilir.
AWS Lambda Operasyonları ve Eş Zamanlılık
Paketleme ve yapılandırma:
- Dağıtım paketleri ZIP arşivleri (dil çalışma zamanı ile birlikte) veya 10 GB’a kadar container imajları olabilir. ZIP, küçük kodlar için daha hafiftir; imajlar ise container tabanlı derlemelerle araçları birleştirir.
- Layer’lar, fonksiyonlar arasında paylaşılan kütüphaneleri kapsüller; bunları minimal ve versiyonlu tutun. Bir fonksiyon en fazla beş layer içerebilir.
- Versiyonlar değişmez anlık görüntülerdir (immutable snapshots); alias’lar ise versiyonlara yönelik kararlı işaretçilerdir ve trafik yönlendirme için ağırlıklar taşıyabilirler.
- Geçici depolama (ephemeral storage) varsayılan olarak 512 MB’tır ve derlemeler, geçici dosyalar veya ML çıkarım önbellekleri için 10.240 MB’a kadar yükseltilebilir. Maliyet/performans dengesi için x86_64 veya arm64 mimarisini seçin. Yapılandırma için ortam değişkenlerini (environment variables) kullanın ve Secrets Manager veya Parameter Store ile entegre edin.
Trafik yönlendirme ve güvenlik:
- CloudWatch alarmlarına (ör. 5XX, gecikme veya özel uygulama metrikleri) dayalı otomatik geri alma (rollback) özellikli canary/linear geçişler için CodeDeploy kullanın. Alternatif olarak, basit A/B yönlendirmesi için alias ağırlıklarını doğrudan ayarlayın.
- CloudWatch Logs’a yapılandırılmış loglama (structured logging) yapın ve metrik enstrümantasyonunu değiştirmeden operasyon/versiyon/kod boyutlu metrikler türetmek için metrik filtreleri oluşturun. Uçtan uca gecikme takibi (latency tracing) için X-Ray’i etkinleştirin.
Eş zamanlılık (concurrency) kontrolleri:
- Ayrılmamış eş zamanlılık (unreserved concurrency), hesabın bölgesel havuzundan kullanılır. Ani trafik artışları diğer fonksiyonların kaynaklarını tüketebilir (starve).
- Ayrılmış eş zamanlılık (reserved concurrency), bir fonksiyonun maksimum eş zamanlılığını sınırlar ve bölgesel havuzdan pay ayırarak bu fonksiyon için kapasiteyi garanti eder; bu, gürültülü komşulardan (noisy neighbors) izolasyon sağlar.
- Sağlanan eş zamanlılık (provisioned concurrency), bir versiyon/alias için çalıştırma ortamlarını (execution environments) başlatılmış halde tutar, bu da cold start’ları neredeyse ortadan kaldırır ve gecikmeyi stabilize eder. Sağlanan eş zamanlılığı, Application Auto Scaling ile günün saatine veya metriklere göre ölçeklendirin.
- Bir fonksiyon eş zamanlılık sınırına ulaştığında kısıtlama (throttling) meydana gelir; senkron çağrılar 429 hatası alır, asenkron çağrılar ise üssel geri çekilme (exponential backoff) ile yeniden denenir ve yapılandırılan deneme sayısından sonra dead-letter kuyruğuna gönderilebilir. SQS gibi yoklama tabanlı (poll-based) kaynaklar için Lambda, kuyruk derinliğiyle (queue depth) birlikte eş zamanlılığı artırır; birikmeyi (backlog) önlemek için ayrılmış/sağlanan eş zamanlılığın ve aşağı akış (downstream) kapasitesinin maksimum anlık mesaj (inflight messages) sayısıyla eşleştiğinden emin olun.
API Gateway Tasarımı ve ECR Hesaplar Arası Erişim
API Gateway REST API’leri ve HTTP API’leri karşılaştırması:
- REST API’leri en zengin özellik setini sunar: istek/yanıt eşlemesi (VTL), kullanım planları ve API anahtarları, yetkilendiriciler, WAF ve aşama seviyesinde önbelleğe alma. Gelişmiş dönüşümlere, kotalı API anahtarlarına veya olgun ekosistem entegrasyonlarına ihtiyacınız olduğunda REST API’lerini seçin.
- HTTP API’leri, Lambda ve HTTP arka uçlarına (ALB/NLB/özel entegrasyonlar dahil) daha basit yönlendirme ile daha düşük gecikme süresi ve maliyet sunar. JWT yetkilendiricilerini ve IAM’i desteklerler ancak aşama seviyesinde önbelleğe alma ve VTL dönüşümleri dahil olmak üzere birçok REST özelliğinden yoksundurlar. Minimum ek yük ile doğrudan proxy’leme için HTTP API’lerini seçin.
Aşamalar (Stages) ve kısıtlama (throttling):
- Aşamalar, belirli bir dağıtımı bir URL yoluna bağlar. Aşama değişkenlerini, günlük kaydını ve kısıtlamayı aşama seviyesinde yapılandırın. API anahtarı başına kısıtlamaları ve kotaları uygulamak için kullanım planlarını (REST) uygulayın. Kısıtlama ayarları oran (rate) ve patlama (burst) içerir; bunlar hesap seviyesindeki limitlerle birleşir, bu nedenle toplam trafiğin bölgesel kotaları aşmadığından emin olun. Yapılandırılmış JSON ile erişim günlük kaydını etkinleştirin ve kötü niyetli istekleri denetlemek ve engellemek için WAF’ı entegre edin.
Önbelleğe alma (Yalnızca REST API’leri):
- Aşama seviyesinde önbellek, arka uç yükünü ve gecikme süresini azaltır; yöntem başına TTL’ler ayarlayın, şifrelemeyi etkinleştirin ve doğruluk için önbellek anahtarı parametrelerini/başlıklarını göz önünde bulundurun. Yanıt şekillerini veya davranışını değiştiren dağıtımlardan sonra önbellekleri geçersiz kılın.
Özel bağlantı:
- Uç nokta türünü seçin: edge-optimized (REST, CloudFront üzerinden global), bölgesel veya özel (VPC uç noktaları). VPC Link ile özel entegrasyonlar, VPC’lerdeki NLB/ALB arka uçlarına genele açık olmadan bağlanır.
ECR hesaplar arası erişim:
- Diğer hesaplardaki principal’lara (CI/CD veya çalışma zamanı rolleri) pull/push izni vermek için depo kaynak politikalarını kullanın. Müşteri tarafından yönetilen bir KMS anahtarı kullanıyorsanız, anahtar politikasını buna göre genişletin. Çoklu hesap dağıtımı için, hedef hesapları/Bölgeleri hedeflemek üzere ECR replikasyon kuralları tanımlayın ve dağıtımlarda etiket değişmezliği (tag immutability) ve özet (digest) sabitleme ile imaj bütünlüğünü doğrulayın.
Pratik Problem Senaryosu
Spotify, en yoğun lansmanlar sırasında gecikme süresi değişkenliğini azaltmak ve birden çok AWS hesabındaki imaj tedarik zincirini sıkılaştırmak için bir çalma listesi mikroservis yığınını modernize ediyor.
- İmaj oluşturma ve yönetişimini standartlaştırın
- Push işleminde tarama (scan-on-push) ve Amazon Inspector gelişmiş tarama özellikli ECR depoları uygulayın. Dal (branch) başına en son N sürümü korumak ve sürüklenmeyi (drift) temizlemek için etiket değişmezliği (tag immutability) ve yaşam döngüsü politikaları ekleyin. Derleme (build) hesabından üretim (prod) ve hazırlık (staging) hesaplarına Bölgeler/hesaplar arası replikasyonu yapılandırın. Neden: Inspector sürekli CVE kapsamı sağlar, değişmezlik etiket ele geçirmeyi (tag hijacking) önler ve replikasyon, dağıtım gecikmesini ve patlama yarıçapını (blast radius) azaltmak için pull işlemlerini yerelleştirir.
- Durumsuz (stateless) API’leri Fargate ile ECS üzerinde sunun
- Yapılandırılmış günlükler ve metrikler için awslogs ve FireLens ile ECS görev tanımlarını (task definitions) tanımlayın. Konteyner healthCheck’ini etkinleştirin ve ALB hedef grup (target group) sağlık kontrolleriyle hizalayın. Bir erişim noktası (access point) aracılığıyla paylaşılan salt okunur yapılandırma için bir EFS birimi bağlayın. Maliyet verimliliği için Fargate ve Fargate Spot’u karıştıran bir kapasite sağlayıcı (capacity provider) stratejisiyle hizmetleri Fargate üzerinde çalıştırın. Neden: Fargate, düğüm (node) yönetimini ortadan kaldırır ve görevleri ENI başına izole eder; EFS, yapılandırmaları imajların içine gömmekten kaçınır ve yapılandırmanın atomik geri alımlarını (rollback) destekler.
- Blue/green ve otomatik testlerle güvenli dağıtımlar
- ECS hizmetlerini bir CodeDeploy dağıtım denetleyicisine (deployment controller) geçirin. ALB üzerinde iki hedef grup (target group) yapılandırın. 5 dakika içinde kritik uç noktaları çalıştıran bir Lambda test çalıştırıcısını çağırmak için AfterAllowTestTraffic ile bir kanarya (canary) geçişi kullanın. Geri almayı (rollback) tetiklemek için 5XX ve p90 gecikme süresi üzerine CloudWatch alarmları ekleyin. Neden: CodeDeploy blue/green riski izole eder, test kancası (hook) tam geçişten önce yeşil ortamı doğrular ve alarmlar otomatik, nesnel geri alma sağlar.
- Soğuk başlatmaları (cold start) stabilize edilmiş Lambda üzerinde gecikmeye duyarlı operasyonlar
- Bir tokenizasyon yardımcı API’si için, işlevi yalın bağımlılıklara sahip bir ZIP olarak paketleyin. Bir sürüm/alias oluşturun ve en yoğun zamana göre boyutlandırılmış sağlanmış eşzamanlılığı (provisioned concurrency) etkinleştirin. Sağlanmış eşzamanlılığı, lansman pencerelerini izleyen günlük bir programla Application Auto Scaling aracılığıyla yönetin. CloudWatch alarmlarına bağlı alias tabanlı trafik kaydırma için CodeDeploy kanarya (10%/15 dakika) kullanın. Neden: Sağlanmış eşzamanlılık, ani artışlar sırasında soğuk başlatmaları (cold start) ortadan kaldırır; alias kanaryaları, hızlı geri alma ile kademeli maruz bırakmayı sağlar.
- Harici API’leri API Gateway üzerinden sunun ve özel arka uçları (backend) güvence altına alın
- Lambda ve ECS ALB’yi API Gateway ile ön yüzeylendirin. Maliyet/gecikmeyi en aza indirmek için Lambda proxy’si için HTTP API’lerini kullanın. İstek/yanıt eşlemesi ve yoğun okuma yapılan uç noktalar için aşama önbelleğe alması gereken ECS ALB yolu için REST API kullanın. WAF web ACL’lerini ve aşama kısıtlamasını uygulayın; yapılandırılmış erişim günlüklerini etkinleştirin. Neden: API türlerini ihtiyaçlarla eşleştirmek maliyeti ve yetenekleri optimize eder; önbelleğe alma yükü azaltır; WAF ve kısıtlama, olay (event) ani artışları altında koruma ekler.
- İnternet olmadan hesaplar arası çalışma zamanı (runtime) pull işlemleri
- Çalışma zamanı VPC’lerinde, ECR (api, dkr) ve CloudWatch Logs için arayüz uç noktaları (interface endpoints) ve bir S3 ağ geçidi uç noktası (gateway endpoint) ekleyin. Üretim hesabının görev yürütme rollerinin (task execution roles) pull yapmasına izin vermek için ECR depo kaynak politikalarını ekleyin. Bekleme durumundaki (at rest) imaj şifrelemesi için hesaplar arası anahtar politikasına sahip, müşteri tarafından yönetilen bir KMS anahtarı kullanın. Neden: Özel imaj pull işlemleri, NAT maliyetlerinden ve dışarı veri çıkışı (egress) risklerinden kaçınır; açık kaynak/anahtar politikaları, en az ayrıcalıkla (least-privilege) hesaplar arası erişimi zorunlu kılar.
Bu tasarım, operasyonel angaryayı azaltır (yönetilecek düğüm yok), sağlanmış eşzamanlılık ve sağlık durumuyla uyumlu dağıtımlar (rollout) aracılığıyla deterministik gecikme süresi sağlar ve ECR taraması, replikasyonu ve değişmezliği ile uçtan uca imaj kökenini (provenance) zorunlu kılar.
← Güvenlik · Tüm alanlar · Yüksek Erişilebilirlik →
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 →