Amazon SAA-C03: Uygulama Entegrasyonu, Mesajlaşma ve Akış — Çalışma kılavuzu

By Laurynas Brazys · 19 July 2026 · #amazon #saa-c03 #certification #exam-prep #study-guide

Şunun bir parçası: AWS SAA-C03 — Eksiksiz ç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.

Amazon SQS: Ayrıştırma, Sıralama ve Teslimat Semantiği

Amazon SQS, temel mimari rolü üreticileri (producer) tüketicilerden (consumer) ayrıştırmak olan, tamamen yönetilen, çekme (pull) tabanlı bir mesaj kuyruğudur. Senkron bir çağrı zinciri, üreticinin gecikmesini ve kullanılabilirliğini her bir alt akış bağımlılığına bağlar; araya bir SQS kuyruğu eklemek, bunu asenkron bir devir teslim işlemine dönüştürür. Üreticiler, trafik hangi hızda gelirse gelsin mesajları kuyruğa ekler ve tüketiciler, güvenli bir şekilde işleyebilecekleri hızda kuyruktan çeker. Bu, aksi takdirde bir RDS örneğini bunaltacak olan anlık yazma yoğunlukları (write burst) için standart bir çözümdür — kuyruk bu yoğunluğu emer ve sınırlı sayıdaki bir tüketici filosu, kontrollü bir eşzamanlılıkla kuyruğu boşaltarak veritabanı bağlantı sayısını kontrol altında tutar.

İki kuyruk türü mevcuttur ve yapılan seçim hem iş hacmini (throughput) hem de teslimat garantilerini belirler.

Standart kuyruklar, yalnızca en iyi çaba (best-effort) sıralamasıyla en az bir kez teslimat yapar. Bir tüketici, görünürlük zaman aşımı (visibility timeout) süresi dolmadan bir mesajı silemediğinde veya dağıtık arka uç (backend) bir mesajı shard’lar arasında yeniden oynattığında yinelenen mesajlar ortaya çıkabilir. Test sırasında hiç yinelenen bir mesaj görmeseniz bile, hizmet mimari olarak, özellikle de broker’ların yük devretmesi (failover) sırasında yeniden teslimat yapma iznine sahiptir. Standart kuyrukların “genellikle” bir kez teslimat yapacağını varsaymak bir operasyonel risk değil, bir tasarım kusurudur — büyük ölçekte yinelenen mesajların eninde sonunda ortaya çıkacağı garantidir. Bu nedenle, tüketici mantığı idempotent olmalıdır: DynamoDB’de koşullu bir yazma (conditional write) ile bir MessageId veya iş anahtarını (business key) takip edin, alt akış API çağrılarında bir idempotency anahtarı kullanın veya upsert semantiğine güvenin.

FIFO kuyruklar, bir MessageGroupId içinde katı sıralama ve 5 dakikalık bir pencere boyunca yinelenen mesajları engelleyen bir MessageDeduplicationId (açıkça belirtilen veya mesaj gövdesinin SHA-256 özeti) aracılığıyla tam olarak bir kez işleme (exactly-once processing) sağlar. MessageGroupId en önemli kavramdır: aynı grup kimliğini paylaşan tüm mesajlar, her seferinde tek bir tüketiciye katı bir sırayla teslim edilirken, farklı grup kimlikleri paralel olarak işlenebilir. Her müşterinin olaylarının sıralı olması gereken ancak farklı müşterilerin birbirinden bağımsız olduğu bir sipariş işleme sistemi için MessageGroupId = customerId kullanın. Her şey için tek bir grup kimliği kullanmak, tüm iş yükünü serileştirir ve iş hacmini yok eder. Tekilleştirme kimlikleri (Deduplication ID), bir kullanıcı takılıp kalmış bir ödeme işlemini yeniden gönderdiğinde yinelenen sipariş oluşturulmasını önlemek için doğru temel mekanizmadır: istemci deterministik bir idempotency token’ı (ödeme oturumuna bağlı bir UUID) oluşturur ve SQS, pencere içinde gelen tüm yinelenen gönderimleri atar.

PaymentsQueue:
  Type: AWS::SQS::Queue
  Properties:
    QueueName: payments.fifo
    FifoQueue: true
    ContentBasedDeduplication: true
    DeduplicationScope: messageGroup
    FifoThroughputLimit: perMessageGroupId
    VisibilityTimeout: 60
    RedrivePolicy:
      deadLetterTargetArn: !GetAtt PaymentsDLQ.Arn
      maxReceiveCount: 5

Gereksinim “sıralama” veya “yinelenen mesaj olmasın” dediğinde standart kuyruk seçmek klasik bir hatadır. Hiçbir uygulama mantığı, kuyruğun korumadığı bir sıralamayı geri getiremez, çünkü farklı arka uç (backend) sunucularından gelen mesajlar iç içe geçmiş bir şekilde ulaşır. İş yükü sıralama (işlem kayıtları, durum makinesi geçişleri) veya tam olarak bir kez semantiği (ödeme alma, envanter düşürme) gerektirdiğinde FIFO seçin.

Görünürlük Zaman Aşımı, Zehirli Mesajlar ve Veri Yükü Sınırları

Bir tüketici bir mesaj aldığında, SQS bu mesajı görünürlük zaman aşımı (varsayılan 30 saniye, maksimum 12 saat) süresince diğer tüketiciler için görünmez hale getirir. Tüketici, zaman aşımı süresi dolmadan mesajı silerse, mesaj kalıcı olarak silinir; silmezse — çünkü tüketici çöktü veya işleme süresi çok uzadı — mesaj yeniden görünür hale gelir ve tekrar teslim edilir. Görünürlük zaman aşımını gerçek işleme süresinden daha kısa ayarlamak, yinelenen işlemelerin önde gelen nedenlerinden biridir: varsayılan 30 saniyelik zaman aşımına sahip bir kuyrukta 45 saniye süren bir Lambda, her mesajı en az iki kez yeniden işleyecektir. Zaman aşımını en az p99 işleme süresine ayarlayın (Lambda tabanlı kuyruklar için AWS’nin tavsiyesi, fonksiyon zaman aşımının en az 6 katıdır) ve süresi öngörülemeyen işler için zaman aşımını dinamik olarak uzatın:

sqs.change_message_visibility(
    QueueUrl=queue_url,
    ReceiptHandle=handle,
    VisibilityTimeout=300  # extend by 5 minutes
)

Dead-letter queue’lar (DLQ’lar), zehirli hap (poison-pill) mesajları yakalar. Kaynak kuyruktaki bir RedrivePolicy, bir maxReceiveCount (genellikle 3-5) belirtir; bu sayı aşıldığında, SQS mesajı çevrimdışı inceleme için DLQ’ya taşır. DLQ, kaynak kuyruğun türüyle eşleşmelidir (FIFO ↔ FIFO). Bir DLQ olmadan, bozuk biçimli mesajlar süresiz olarak döngüye girer ve bu durum FIFO’da özellikle zararlıdır — sıralama, sorunlu mesaj halledilene kadar aynı gruptaki sonraki mesajların teslim edilmesini engeller, bu nedenle tek bir kötü mesaj bütün bir grubu durdurur.

SQS mesajları 256 KB ile sınırlıdır. Daha büyük veri yükleri için — örneğin, render edilmiş bir belge taşıyan bir iş — veri yükünü S3’e yazan ve kuyruğa yalnızca bir bucket/key referansı ekleyen SQS Extended Client Library‘yi kullanın. Tüketici kütüphanesi, mesajı alırken bu veriyi şeffaf bir şekilde çeker. Veri yüklerini birden fazla mesaja bölmeyin (atomikliği ve sıralamayı kaybedersiniz) ve 2 MB’lık bir blob’u sığacağını umarak base64 ile kodlamayın.

Kuyruk Tabanlı Otomatik Ölçeklendirme

Bir SQS kuyruğunun arkasındaki EC2 veya ECS üzerindeki bir tüketici filosu için doğru ölçeklendirme sinyali CPU değil, kuyruk birikimidir (backlog). CPU, geliş hızının gerisinde kalır ve doymuş (saturated) bir tüketiciyi “meşgul ama başa çıkıyor” olarak yanlış yorumlar. Standart ölçeklendirme metriği ApproximateNumberOfMessagesVisible‘dır, ancak doğrudan ham kuyruk derinliğine göre ölçeklendirme yapmak kaba bir yaklaşımdır. Önerilen yaklaşım, örnek başına birikim (backlog-per-instance) özel metriğidir:

backlogPerInstance = ApproximateNumberOfMessagesVisible / RunningInstances

Bunu CloudWatch’a yayınlayın ve bir Auto Scaling grubunda veya ECS hizmetinde bir hedef izleme (target-tracking) ilkesini yönlendirin, böylece her bir çalışan (worker) sınırlı bir birikim (örneğin, 10 mesaj) tutar. Bu, anlık yoğunluklar sırasında sorunsuz bir şekilde dışa doğru ölçeklendirme (scale-out) sağlar ve kuyruk derinliği küçükken ancak tüketiciler zaten doymuş durumdayken yaşanan dalgalanmaları (oscillation) önler. İçe doğru ölçeklendirme (scale-in) için, eski mesajlar beklerken kapasiteyi sonlandırmaktan kaçınmak amacıyla bunu ApproximateAgeOfOldestMessage ile birlikte kullanın.

Amazon SNS: Fan-Out, Filtreleme ve Hesaplar Arası Teslimat

SNS, itme tabanlı (push-based) bir yayınla/abone ol (publish/subscribe) hizmetidir. Yayıncılar bir topic’e yazar; SNS her aboneliğe mesajı iter: SQS kuyrukları, Lambda fonksiyonları, HTTP(S) uç noktaları, e-posta, SMS, Kinesis Data Firehose veya mobil anlık bildirimler. Baskın dayanıklılık deseni SNS → SQS fan-out’tur: birden fazla SQS kuyruğunun abone olduğu tek bir topic sayesinde, her alt akış hizmeti kendi dayanıklı arabelleğine, yeniden deneme politikasına ve DLQ’suna sahip olurken, yayıncı yalnızca topic’i bilir. Eğer bir tüketici hizmet saatlerce devre dışı kalırsa, kuyruğu mesajları biriktirir ve hizmet kurtarıldığında bu mesajları işlemeye başlar — tek başına SNS bu arabellek özelliğine sahip değildir ve yeniden deneme politikasını tüketir.

Producer ──▶ SNS topic ──┬──▶ SQS Queue A ──▶ Service A
                         ├──▶ SQS Queue B ──▶ Service B
                         └──▶ SQS Queue C ──▶ Service C

Mesaj filtreleme, her aboneliğin bir JSON filtre politikası bildirmesine olanak tanır, böylece SNS yalnızca eşleşen mesajları teslim eder. Bu, her tüketicinin her mesajı alıp istemci tarafında filtrelediği anti-desenden kaçınmayı sağlar:

{
  "eventType": ["order_placed", "order_cancelled"],
  "region": ["us-east-1", "us-west-2"]
}

İki davranışsal özellik önemlidir. Birincisi, standart SNS topic’leri mesajlar arasında sıralamayı garanti etmez — abone başına yeniden deneme zamanlayıcıları ve bağımsız ağ yolları yeniden sıralamayı rutin hale getirir. Sıralama önemliyse, SQS FIFO kuyruklarına abone olan bir SNS FIFO topic kullanın; mesaj grubu ID’si uçtan uca yayılır. Aksi takdirde, abonelerin idempotent olması ve yeniden sıralamaya tolerans göstermesi gerekir. İkincisi, HTTP(S) abonelikleri bir teslimat politikasına göre yeniden dener (varsayılan: üç anında yeniden deneme, ardından bir saate kadar üstel geri çekilme, sonra mesajı atma). Aboneler 15 saniye içinde 2xx yanıtı vermeli, x-amz-sns-message-type imzasını doğrulamalı ve — güvenilir olmayan uç noktalar için — teslim edilemeyen mesajların sessizce atılması yerine yakalanması için her zaman bir SNS DLQ’suna (SQS’e yeniden yönlendirilen) sahip olmalıdır.

Hesaplar arası çağırma sık karşılaşılan bir tuzaktır. Hesap A, Hesap B’deki bir Lambda’ya fan-out yapan bir topic’e yayın yaptığında iki politika gerekir: SNS topic politikası (veya abonelik yönü) aboneliğe izin vermeli ve Lambda’nın kaynak tabanlı politikası, topic ile eşleşen bir SourceArn koşuluyla sns.amazonaws.com‘dan lambda:InvokeFunction izni vermelidir. Lambda kaynak politikasının eksik olması en yaygın hata modudur — abonelik sağlıklı görünür, ancak çağırmalar 403 ile reddedilir. Eğer topic müşteri tarafından yönetilen bir KMS anahtarı ile şifrelenmişse, anahtar politikası ayrıca yayıncı principal’a ve sns.amazonaws.com‘a kms:Decrypt ve kms:GenerateDataKey izinlerini de vermelidir.

{
  "Effect": "Allow",
  "Principal": {"Service": "sns.amazonaws.com"},
  "Action": "lambda:InvokeFunction",
  "Resource": "arn:aws:lambda:us-east-1:222222222222:function:ProcessOrder",
  "Condition": {"ArnLike": {"AWS:SourceArn": "arn:aws:sns:us-east-1:111111111111:orders"}}
}

Amazon EventBridge: Yönlendirilmiş Olay Yolları (Event Buses)

EventBridge (eski adıyla CloudWatch Events), pub/sub modelini içerik tabanlı yönlendirme, şema keşfi, SaaS iş ortağı olay kaynakları ve arşivleme/yeniden oynatma ile genişletir. Olaylar olay yolları (event bus) (varsayılan, özel veya iş ortağı) üzerinden akar ve olay desenleri JSON yapısına göre filtreleme yapan kurallarla eşleşir. Kurallar, giriş yolları ve giriş şablonları aracılığıyla yükleri (payload) dönüştürebilir, teslim edilemeyen mesaj hedefleri (dead-letter targets) ekleyebilir ve Lambda, Step Functions, ECS görevleri, SQS, SNS, Kinesis ve API hedefleri dahil 20’den fazla yerel hedefe teslimat yapabilir.

{
  "source": ["com.acme.orders"],
  "detail-type": ["OrderPlaced"],
  "detail": {"amount": [{"numeric": [">", 500]}]}
}

SNS’ten farkı mimariseldir. SNS, basit öznitelik filtrelemesi ve daha düşük gecikme süresi ile homojen abonelere yüksek verimli yayın yapmak için optimize edilmiştir. EventBridge, heterojen olay güdümlü mimariler için optimize edilmiştir: birçok üretici farklı olay şemaları yayar ve tüketiciler topic yerine desene göre abone olur. Mikroservislere ayrıştırılan bir monolit için — özellikle üreticiler arasında olayları yerel olarak yayan SaaS iş ortakları veya AWS hizmetleri (Config, GuardDuty, CodePipeline, CloudTrail) varsa — EventBridge genellikle doğru seçimdir. Çok yüksek hacimli, düşük gecikmeli ve özdeş abonelere fan-out yapmak için SNS hala daha üstündür, çünkü EventBridge’in olay başına gecikmesi biraz daha yüksektir ve varsayılan verim tavanı daha düşüktür.

Amazon MQ: Mevcut Protokoller için Aracılı Mesajlaşma

Amazon MQ, ActiveMQ veya RabbitMQ çalıştıran yönetilen bir aracıdır (broker). Uygulamayı yeniden yazmadan AMQP 0-9-1, AMQP 1.0, MQTT, STOMP, OpenWire veya JMS’e bağımlı olan şirket içi (on-premises) iş yüklerini taşımak için mevcuttur. Eğer bir ödeme sistemi, işlemsel tam olarak bir kez (transactional exactly-once) semantiğine sahip üçüncü taraf bir JMS aracısı kullanıyorsa, bunu Amazon MQ’ya taşımak, altyapı yönetimini ortadan kaldırırken iletişim protokolünü (wire protocol) ve teslimat garantilerini korur. Sıfırdan geliştirilen AWS’e özgü (native) tasarımlar için SQS/SNS/EventBridge’i seçin; Amazon MQ’yu yalnızca protokol uyumluluğu bir kısıt olduğunda seçin.

Kinesis Data Streams

Kinesis Data Streams (KDS), yüksek verimli akış halinde veri alımı (streaming ingest) — tıklama akışları, IoT telemetrisi, log toplama — için dayanıklı, sıralı, bölümlenmiş bir günlüktür. Kayıtlar PartitionKey‘e göre shard’lara yerleştirilir; sıralama akış genelinde değil, bir shard içinde garanti edilir. Her shard, 1 MB/s veya 1.000 kayıt/s yazma ve 2 MB/s okuma (veya Enhanced Fan-Out ile daha yüksek) hızını destekler. Kayıtlar varsayılan olarak 24 saat saklanır ve bu süre 365 güne kadar uzatılabilir, böylece birden fazla bağımsız tüketici aynı geçmişi yeniden oynatabilir — SQS bunu yapamaz çünkü SQS onay (ack) üzerine siler.

İsteğe bağlı mod (On-demand mode), akış başına 200 MiB/s yazma hızına kadar otomatik olarak ölçeklenerek shard matematiğini ortadan kaldırır ve öngörülemeyen trafik için idealdir. Sağlanan mod (Provisioned mode), kapasitenin bilindiği kararlı durumlarda daha ucuzdur.

İş yükü, FIFO’nun karşılayamayacağı verimlerde (KDS’in saniyede milyonlarca kaydı işleyebilmesinin çok altında) sıralı, yeniden oynatılabilir veri alımı gerektirdiğinde, birden fazla bağımsız tüketicinin aynı akışı okuması gerektiğinde veya “işleme boyunca orijinal sırayı koru” ifadesi yüksek hacimle birleştiğinde SQS FIFO yerine KDS’yi seçin.

Kinesis Data Firehose

Kinesis Data Firehose, tam olarak yönetilen bir teslimat hizmetidir. Bir Kinesis akışından veya doğrudan PUT ile okuma yapar, boyuta (1–128 MB) veya zamana (60–900 saniye, hangisi önce dolarsa) göre arabelleğe alır, isteğe bağlı olarak kayıt bazında dönüşüm (PII temizleme, format normalleştirme) için bir Lambda’yı çağırır, bir Glue şeması kullanarak anında JSON’u Parquet veya ORC‘ye dönüştürebilir, KMS ile şifreler ve S3, Redshift, OpenSearch veya Splunk’a teslim eder. Shard’ları yoktur, çalıştırılacak consumer’ları yoktur ve GB başına ödeme fiyatlandırmasına sahiptir.

Bir veri gölüne ölçeklenebilir veri alımı için kanonik model, dayanıklı arabellek olarak Data Streams’i (on-demand) S3’e teslimat için Firehose ile eşleştirir:

Producers → Kinesis Data Streams (on-demand) → Firehose (60s buffer, Parquet) → S3 → Athena/Glue

Milyonlarca mobil olayı almak, şifrelemek ve S3’e Parquet olarak kaydetmek için doğru cevap, Parquet dönüşümü ve bir KMS anahtarı ile Firehose’dur — KDS artı özel bir consumer artı elle yazılmış bir Parquet yazıcısı değildir, ki bu çok daha fazla kod ve altyapı demektir. Firehose neredeyse gerçek zamanlıdır ve consumer tarafında yeniden oynatmayı (replay) desteklemez; yeniden oynatma gerektiğinde, KDS’i yolda tutun.

Kinesis Data Analytics (şimdiki adıyla Managed Service for Apache Flink), pencereli agregasyonlar için bir akış üzerinde SQL veya Flink işleri çalıştırır.

Lambda Entegrasyonu ve Yeniden Deneme Semantiği

Lambda, bu hizmetlerle önemli ölçüde farklı yeniden deneme davranışlarıyla entegre olur:

SQS için, Lambda fonksiyonu zaman aşımını ≤ kuyruk görünürlük zaman aşımı olarak tutun ve görünürlük zaman aşımını fonksiyon zaman aşımının en az 6 katına ayarlayın. Kinesis için, BisectBatchOnFunctionError özelliğini etkinleştirin ve tek bir zehirli kaydın (poison record) tüm shard’ı süresiz olarak durdurmaması için bir OnFailure hedefi (SQS veya SNS) yapılandırın.

Seçim Karar Tablosu

← Analitik · Tüm alanlar · Güvenlik →

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

Amazon'a göz atın →