Amazon DVA-C02: Mesajlaşma, Akış ve Olay Güdümlü Mimariler (SNS, SQS, Kinesis, EventBridge, Step Functions) — Çalışma kılavuzu

By Laurynas Brazys · 27 July 2026 · #amazon #dva-c02 #certification #exam-prep #study-guide

Şunun bir parçası: AWS Developer Associate DVA-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.

Doğru mesajlaşma ve akış temel bileşenini seçme

SNS, SQS (standart ve FIFO), Kinesis, EventBridge ve Step Functions arasında seçim yapmak, iletişim modeline dayanır: pub/sub, noktadan noktaya, sıralı akış, olay veri yolu yönlendirmesi veya iş akışı düzenlemesi. SNS, bir fan-out (dağıtımlı) pub/sub yayıncısıdır; Publish (SDK çağrısı: Publish/PublishBatch) kullanın ve SQS uç noktalarını, Lambda’yı, HTTP/S’i veya mobil uç noktaları abone yapın. SQS, ReceiveMessage/DeleteMessage semantiğine sahip, dayanıklı bir noktadan noktaya arabellektir; CreateQueue ile kuyruklar oluşturun ve VisibilityTimeout, ReceiveMessageWaitTimeSeconds (uzun yoklama), MessageRetentionPeriod gibi nitelikleri ve bir DLQ’ya bağlanan yeniden deneme politikalarını (redrive policies) yapılandırın. FIFO kuyrukları FifoQueue=true gerektirir ve sıralama ve tekilleştirme (dedupe) için MessageGroupId ile birlikte MessageDeduplicationId (veya ContentBasedDeduplication) kullanır. Kinesis Data Streams, sıralı, shard tabanlı bir akış hizmetidir; üreticiler PutRecord/PutRecords çağrısı yapar ve tüketiciler GetShardIterator (TRIM_HORIZON, LATEST, AT_SEQUENCE_NUMBER) ve ardından GetRecords kullanır. Kinesis Firehose, S3/Redshift/OpenSearch’e teslimatı yönetir ve BufferingHints (SizeInMBs, IntervalInSeconds) ile Lambda dönüşümleri sunar. EventBridge, PutEvents ve kural tabanlı filtreleme ile olayları yönlendirir, şema kaydını (schema registry) ve hesaplar arası veri yollarını (cross-account buses) destekler. Step Functions karmaşık akışları düzenler; senkron Express desenleri için StartExecution (Standard) veya StartSyncExecution kullanılır ve

undefined

gibi Görev (Task) entegrasyonları bulunur. Verim (throughput), sıralama, teslimat garantileri, saklama (retention) ve düzenleme (orchestration) ihtiyaçları çakıştığında bu ödünleşimleri (tradeoffs) göz önünde bulundurun.

• SNS: yüksek verimli fan-out, sıralama yok, Publish/Subscribe, yönlendirme için MessageAttributes kullanın.
• SQS Standard: en az bir kez teslimat (at-least-once), en iyi çaba sıralaması (best-effort ordering), uzun yoklama (long polling), ayrıştırma (decoupling) için daha ucuz.
• SQS FIFO: MessageGroupId içinde tam olarak bir kez sıralama (exactly-once ordering), katı sıralama ve tekilleştirme (dedupe) için kullanın.
• Kinesis Data Streams: shard başına sıralı, yüksek verimli akış, PutRecord/PutRecords, shard ölçeklendirmesi gerekli.
• Kinesis Firehose: yönetilen teslimat ve arabelleğe alma, sunucu tarafı şifrelemeyi ve Lambda dönüşümlerini destekler.
• EventBridge: yönlendirme kurallarına sahip olay veri yolu (event bus), şema kaydı, arşivleme ve yeniden oynatma (archive & replay), PutEvents API.
• Step Functions: durum bilgili düzenleme (stateful orchestration), yeniden denemeler/Catch, dayanıklılık ve verim için Standard ve Express arasındaki ödünleşimler.

SQS ve SNS desenleri, tekilleştirme ve tüketici ölçeklendirmesi

Dayanıklı bir ayrıştırma (durable decoupling) gerektiğinde, SQS en iyi seçenektir; üreticiler için SendMessage/SendMessageBatch uygulayın ve uzun yoklamayı (long polling) etkinleştirip boş alımları azaltmak için ReceiveMessage’ı WaitTimeSeconds ile kullanın. Katı sıralama ve tekilleştirme için, CreateQueue (FifoQueue=true) ile bir FIFO kuyruğu oluşturun ve sıralı bölümler için MessageGroupId ayarlayın; tekilleştirme penceresi içindeki aynı içeriğe sahip mesajların (payload) bastırılması için MessageDeduplicationId kullanın veya ContentBasedDeduplication’ı etkinleştirin. Standart kuyruklar yinelenen mesajlar teslim edebilir — bu nedenle, veritabanına koşullu yazmalar (ConditionExpression attribute_not_exists(pk) ile DynamoDB PutItem) veya RDS’teki benzersiz kısıtlamalar (unique constraints) ve işlemler (transactions) içindeki upsert’ler aracılığıyla tüketicileri bir kez etkili (idempotent) hale getirin. Başarısız olan mesajları maxReceiveCount’tan sonra bir DLQ’ya yönlendirmek için yeniden deneme politikalarını (redrive policies) yapılandırın; GetQueueAttributes aracılığıyla ApproximateNumberOfMessages ve ApproximateNumberOfMessagesNotVisible’ı izleyin. Lambda entegrasyonları SQS için CreateEventSourceMapping kullanır: BatchSize, MaximumBatchingWindowInSeconds ayarlayın ve kısmi toplu iş yanıtı (partial-batch-response) semantiğini kullanmak ve başarılı kayıtların yeniden işlenmesini önlemek için FunctionResponseTypes = [“ReportBatchItemFailures”] seçeneğini etkinleştirin. FIFO Lambda semantiğine dikkat edin: mesaj grubu sıralaması, MessageGroupId başına tek iş parçacıklı (single-threaded) işlemeyi zorunlu kılarak grup başına eşzamanlılığı sınırlar; çok sayıda grup kimliğine bölerek veya birden çok kuyruğa yönlendiren SNS ile paralel tüketiciler kullanarak ölçeklendirin. Ayrıca görünürlük zaman aşımına (visibility timeout) dikkat edin: işlem daha uzun sürdüğünde veya yinelenen işleme riskiyle karşılaştığınızda ChangeMessageVisibility’yi ayarlayın.

Kinesis Data Streams ve Firehose: sıralama, saklama ve geri basınç yönetimi

Kinesis Data Streams, akış (streaming) kullanım senaryoları için shard başına sıralama ve dayanıklı saklama (durable retention) sağlar. Üreticiler, bir shard’a eşlenen bir PartitionKey ile PutRecord veya PutRecords (toplu) çağrısı yapar; tüketiciler GetShardIterator ve GetRecords çağrısı yapar, ardından KCL (Kinesis Client Library) veya özel bir DynamoDB kontrol noktası (checkpoint) tablosu kullanarak ofsetleri işaretler. Varsayılan saklama süresi 24 saattir (akış yapılandırmasına göre daha uzun sürelere ayarlanabilir ve mevcut olduğunda genişletilmiş saklama özellikleri kullanılabilir); yazma verimini (write throughput) ve okuyucu paralelliğini eşleştirmek için shard sayılarını UpdateShardCount ile planlayın. Tüketici ölçeklendirmesi kısıtlıdır: tek bir Lambda olay kaynağı eşlemesi, bir shard’ı bir Lambda eşzamanlılığına eşler, bu nedenle tüketici eşzamanlılığını artırmak için shard’ları artırın veya her tüketiciye kendi 2 MB/sn’lik hattını ve SubscribeToShard API’sini (tüketici kaydı) kullanarak bağımsız ölçeklendirme sağlamak için gelişmiş fan-out’u (enhanced fan-out) etkinleştirin. Verimli toplu işleme için PutRecords kullanın; tüketiciler geri kaldığında geri basınç (back-pressure) oluşur (GetRecords.IteratorAgeMilliseconds’ı izleyin). Ani artışları (spikes) yönetmek için Kinesis üzerinde arabelleğe alın veya önüne SQS koyun, üstel geri çekilme (exponential backoff) ile Üretici yeniden denemelerini kullanın ve kişisel olarak tanımlanabilir bilgiler (PII) için KMS ile akış düzeyinde şifreleme kullanın. Kinesis Data Firehose teslimatı basitleştirir: BufferingHints (SizeInMBs, IntervalInSeconds), CompressionFormat ve bir Lambda veri dönüşümünü yapılandırın. Firehose, hedeflere yeniden deneme/geri çekilme (retry/backoff) işlemlerini yönetir ve başarısız kayıtları yedek bir S3 bucket’ına yazabilir. Yaygın bir tuzak, shard’ları yetersiz sağlamaktır (under-provisioning): tüketiciler yetersiz kalır (starve) ve gecikme (latency) aniden yükselir; proaktif olarak ölçüm yapın ve ölçeklendirin.

Yönlendirme ve orkestrasyon için EventBridge ve Step Functions

EventBridge, olayları enjekte etmek için PutEvents ve SQS, Lambda, Kinesis, Step Functions veya HTTP uç noktalarına yönlendirmek için PutRule/PutTargets kullanarak şema tabanlı olay yönlendirme ve hesaplar arası/olay ortağı entegrasyonlarında mükemmeldir. EventBridge, filtreleme için olay desenleri (event patterns) kullanır ve durumu yeniden oluşturmak için arşivlemeyi ve yeniden oynatmayı (replay) destekler. Kurallar için ‘dead-letter queue’ler (SqsParameters veya DeadLetterConfig ile Target) kullanın ve EventBridge’in hata durumunda üstel geri çekilme (exponential backoff) ile yeniden denemeler ve ardından DLQ sağladığını unutmayın. Orkestrasyon için Step Functions’ı seçin: Yürütme geçmişi ve yerleşik yeniden denemeler/Catch ile uzun süren dayanıklı iş akışları için Standart durum makineleri (Standard state machines) ve daha düşük maliyetli ve ‘best-effort’ yürütme ile yüksek verimli, kısa ömürlü iş akışları için Express. Asenkron harici onayları uygulamak için hizmet entegrasyonları (arn:aws:states:::lambda:invoke veya arn:aws:states:::aws-sdk:apigateway:invoke) ile Görev (Task) entegrasyonlarını ve “waitForTaskToken” kullanan geri arama (callback) desenlerini kullanın. Üstel geri çekilme ile yeniden denemeleri ve Catch’i uygulayın ve uzun görevler için HeartbeatSeconds kullanın. Büyük koleksiyonları paralelleştirmek için Map durumunu (Map state) kullanın, ancak eşzamanlılık (concurrency) ve alt sistemlerdeki kısıtlamalara (downstream throttles) dikkat edin. Yaygın bir tuzak, tam olarak bir kez (exactly-once) ve dayanıklı geçmiş gerektiren iş akışları için Express’i yanlış seçmektir — denetlenebilirlik (auditability) için Standart’ı seçin. Ayrıca, bir ‘idempotency token’ geçirerek ve hedef servislerin yazma anında benzersizliği zorunlu kılmasını sağlayarak Step Functions tarafından çağrılan görevlerde ‘idempotency’yi (tekrarlanabilirlik) sağlayın.

Pratik Problem: Kullanım Senaryosu

Senaryo: StreamlyGames, çoklu hesaplı bir AWS ortamında küresel bir oyun arka ucu işletmektedir. Oyuncular S3’e 10 MB’lık oyun klipleri yükler; bir işleme hattının (processing pipeline) videoları dönüştürmesi (transcode), ML analizi çalıştırması ve sonuçları sıralı, tekilleştirilmiş işleme ve ölçeklenebilir tüketicilerle Aurora Serverless’a yazması gerekir.

Zorluk: Her yüklenen dosyanın oyuncu başına sırayla tam olarak bir kez (exactly-once) işlemeyi tetiklemesini sağlayın, olayları kaybetmeden ani yoğunlukları (spike) yönetin ve yinelenen veritabanı yazmalarını önlerken ML çıkarımı (inference) için tüketicileri ölçeklendirin.

Önerilen Yaklaşım:

1. Nesne oluşturma olaylarını bir EventBridge özel veri yoluna (custom bus) (PutEvents) ve ayrıca PlayerID’nin MessageGroupId olarak anahtarlandığı ve S3 ETag’ine dayalı MessageDeduplicationId kullanan bir SQS FIFO kuyruğuna (CreateQueue ile FifoQueue=true) yayınlamak için bir S3 olay bildirimi oluşturun.
2. BatchSize=1, FunctionResponseTypes=[“ReportBatchItemFailures”] kullanarak bir SQS olay kaynağı eşlemesi (CreateEventSourceMapping) ile bir Lambda tüketicisi yapılandırın ve VisibilityTimeout’u maksimum işlem süresinden daha büyük bir değere ayarlayın; üçüncü taraf ML API’lerini çağırırken ChangeMessageVisibility kullanın.
3. Lambda, deterministik bir ‘idempotency’ anahtarı (INSERT … ON CONFLICT DO NOTHING veya benzersiz kısıtlama) kullanarak Aurora’ya ‘idempotent’ veritabanı yazmaları gerçekleştirir ve ilerlemeyi kontrol noktalarıyla (checkpoint) işaretler; uzun ML çağrıları için görev jetonları (task tokens) ile asenkron Step Functions (arn:aws:states:::lambda:invoke.waitForTaskToken) veya yüksek verim için Step Functions Express kullanın.
4. Çıkarımı (inference) ölçeklendirmek için, yüksek verimli tüketiciler için bölge başına parça (shard) başına ara olayları Kinesis Data Streams’e yazın ve adanmış ML işçi filoları için geliştirilmiş fan-out tüketicileri (enhanced fan-out consumers) (SubscribeToShard) etkinleştirin; ölçeklendirmek için IteratorAgeMilliseconds’i izleyin ve UpdateShardCount kullanın.

Gerekçe: Oyuncu başına sıralamayı ve alım sırasında tekilleştirmeyi (deduplication) garanti etmek için SQS FIFO, ’tam olarak bir kez’ (exactly-once) semantiğini zorunlu kılmak için ‘idempotent’ veritabanı yazmaları ve tüketicileri birbirinden bağımsız ve ölçeklenebilir tutarken ani ve yüksek verimli ML işlemeyi yönetmek için Kinesis artı geliştirilmiş fan-out veya Step Functions kullanın.

← Veritabanları ve Önbellekleme (RDS · Tüm alanlar

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

Amazon'a göz atın →