Amazon SAP-C02: Veritabanları ve Analitik — Çalışma kılavuzu

By Laurynas Brazys · 1 August 2026 · #amazon #sap-c02 #certification #exam-prep #study-guide

Ş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.

İşlemsel Veritabanları, Ölçeklendirme Desenleri ve Önbelleğe Alma

Amazon RDS (MySQL/PostgreSQL/Oracle/SQL Server), Amazon Aurora ve Amazon DynamoDB arasında seçim yapmak iş yükü profiliyle başlar: katı ilişkisel şema ve karmaşık işlemler RDS/Aurora’yı; devasa ölçek, tek haneli milisaniyelik sorgular ve esnek şema ise DynamoDB’yi öne çıkarır. Aurora, dağıtık depolama, replika otomatik ölçeklendirme, hızlı yük devretme, bölgeler arası okumalar için Global Database ve daha düşük gecikmeli felaket kurtarma özellikleriyle yüksek verim sunar. RDS Multi-AZ, yüksek erişilebilirlik için senkron replikasyon sağlar ancak okuma ölçeklendirme sunmaz; okuma replikaları (RDS/Aurora) okuma ağırlıklı iş yüklerini yönetir. Anahtar-değer önbelleğe alma ve mikrosaniye düzeyinde gecikme için ElastiCache (Redis veya Memcached) veritabanı yükünü azaltır; MemoryDB for Redis ise verinin yüksek erişilebilirliğe sahip ve kurtarılabilir olması gereken durumlarda dayanıklılık ve Redis uyumlu kalıcılık ekler. Sık karşılaşılan tuzaklar arasında bağlantı limitlerini hafife almak (MySQL max connections), bağlantı havuzu (connection pooling) kullanmamak (Lambda/konteynerlerin çok sayıda bağlantı oluşturması), kötü anahtar tasarımı nedeniyle DynamoDB’de sıcak bölümler (hot partition) oluşması ve önbellek temizleme/tasarımını ihmal ederek verinin bayatlamasına yol açmak yer alır. Karar verirken yapılan ödünleşimler genellikle maliyet ile performans ve dayanıklılık arasındadır: sağlanmış (provisioned) Aurora/büyük RDS örnekleri daha maliyetlidir ancak gecikmeyi azaltır ve işlemleri basitleştirir; isteğe bağlı (on-demand) veya otomatik ölçeklendirmeli DynamoDB ise operasyonel yükü azaltabilir ancak dikkatli şema ve kapasite planlaması gerektirir. Şifreleme, otomatik yedeklemeler, PITR (belirli bir zamana kurtarma) ve bölgeler arası replikasyon desenleri RPO/RTO’ya göre seçilmelidir.

Veri Gölü, ETL ve Analitik Sorgu Motorları

S3, kanonik dayanıklı veri gölüdür; maliyet etkin sorgular yürütmek için bölümleme (partitioning), sütun bazlı formatlar (Parquet/ORC), sıkıştırma ve birleştirme (compaction) etrafında tasarım yapın. AWS Glue ve AWS Glue Data Catalog sunucusuz ETL, şema keşfi ve kataloglama sağlar; Lake Formation ise yönetişimli göller için merkezi erişim kontrolü, ayrıntılı izinler ve hesaplar arası paylaşım ekler. Etkileşimli analizler için Amazon Athena, S3 verilerini doğrudan sorgular (sunucusuz, sorgu başına ödeme), Amazon Redshift (RA3/Iceberg desteği) ise karmaşık BI (İş Zekası) ve join işlemleri için performanslı, yönetilen MPP (Massively Parallel Processing) ambarı sağlar. Her şeyi içeri almadan Redshift’ten S3 verilerini sorgulamak için Redshift Spectrum’u kullanın. Kinesis Data Firehose, akış halindeki olayları (event) S3 veya Redshift’e indirmek için yönetilen bir veri alım yoludur. Mimarların düştüğü yaygın tuzaklar arasında çok fazla küçük dosyanın yüksek Athena/Redshift ek yüküne (overhead) neden olması, kötü seçilmiş bölümleme anahtarlarının veri çarpıklığı (skew) yaratması ve birleştirme yapmamak veya sütun bazlı formatlara dönüştürmemek yer alır. Ödünleşimler gecikme ile maliyet arasındadır: Athena, anlık (ad-hoc) sorgular için düşük operasyonel maliyetlidir; Redshift ise daha yüksek sağlanmış (provisioned) maliyetle daha yüksek sürdürülebilir performans sağlar. Glue/Lake Formation aracılığıyla veri yönetişimi ve köken takibi (lineage), uyumluluk ve çoklu ekip sahipliği için esastır.

Akış, Gerçek Zamanlı İşleme ve Arama

Gerçek zamanlı veri alımı ve işleme için Kinesis Data Streams (shard tabanlı verim ve sıralama garantileri), Kinesis Data Firehose (hedef sistemlere (sink) yönetilen teslimat), Kinesis Data Analytics (SQL/Apache Flink ile işleme) veya Kafka uyumlu ihtiyaçlar için Amazon MSK kullanılır. Doğrudan AWS yerel sunucusuz entegrasyon için Kinesis’i; istemciler Kafka ekosistem araçlarına bağımlı olduğunda MSK’yı seçin. En az bir kez teslimat (at-least-once) semantiği, shard limitleri, tüketici (consumer) paralelliği ve yeterli sayıda shard sağlanması yaygın operasyonel tuzaklardır. Akışın devamında hızlı arama ve gözlemlenebilirlik için Amazon OpenSearch Service, indeksleme, neredeyse gerçek zamanlı arama ve yerleşik Kibana panoları sunar; indeks yaşam döngüsü yönetimi ve warm/cold katmanları eski veriler için maliyeti düşürür. Olayları (event) OpenSearch veya S3’e kalıcı olarak yazmadan önce zenginleştirmek/dönüştürmek için Kinesis + Lambda veya Kinesis + KDA kullanın. Yeniden denemeler veya yeniden oynatmalar yinelenen kayıtlara (duplicate) neden olacağından, tüketicileri (consumer) tasarlarken idempotency (tekrarlanan işlemin aynı sonucu vermesi) ve tekilleştirme (deduplication) mimarisine dahil edin. Karar kriterleri, verim (throughput) ve gecikmeyi dengeler: çok sayıda shard’a sahip Kinesis yüksek verimi destekler ancak maliyeti ve yönetimi artırır; Firehose ise tüketici (consumer) yükünü ortadan kaldırır ancak daha az esnek dönüşüm sunar.

Taşıma, Replikasyon, Yönetişim ve Operasyonel Dayanıklılık

Database Migration Service (AWS DMS) ve Schema Conversion Tool (SCT), homojen ve heterojen taşımalar için birincil taşıma araçlarıdır ve sürekli değişiklik verisi yakalamayı (change data capture - CDC) mümkün kılar. Taşıma desenleri arasında rehost (lift-and-shift), replatform (ör. Aurora’ya taşıma) ve uygun durumlarda DynamoDB’ye veya sunucusuz mimarilere yönelik refactor bulunur. DMS’i taşıma öncesi ve sonrası doğrulama, paralel tablo kopyalama ve LOB/LOBLOB’ların dikkatli bir şekilde ele alınmasıyla birlikte kullanın. Hesaplar arası ve bölgeler arası replikasyon, KMS anahtar erişimi, VPC peering veya Transit Gateway ve ağ bant genişliği planlaması gerektirir; bölgeler arasında düşük gecikmeli okumalar gerektiğinde Global Databases ve read replica’lar alternatiflerdir. Yönetişim ve güvenlik; veri paylaşımı için Lake Formation’ı, IAM en az ayrıcalık ilkesini, S3 ve RDS anlık görüntüleri (snapshot) için kaynak politikalarını ve genel ağa çıkışı (public egress) önlemek için VPC endpoint’lerini/PrivateLink’i içermelidir. Operasyonel tuzaklar arasında yetersiz izleme (gözden kaçan replika gecikmesi), yük devretme (failover)/runbook’lerin test edilmemesi ve toplu aktarımlar sırasındaki gizli ağ çıkış maliyetleri yer alır. Yedekleme, PITR (belirli bir zamana kurtarma) stratejisi ve otomatik kurtarma, RTO/RPO hedefleri arasındaki dengeyi etkiler; erişilebilirlik için replikasyonu, daha uzun süreli saklama ve uyumluluk için düzenli yedeklemelerle birleştirin.

Pratik Problem: Kullanım Senaryosu

Senaryo: Acme Retail, us-east-1 ve europe-west-1 bölgelerinde üretim iş yükleri bulunan çoklu hesaplı bir AWS Organization yapısında bir e-ticaret platformu işletmektedir. Tıklama akışlarını (clickstream) ve işlem olaylarını S3’te depolamakta ve minimum kesintiyle AWS’e taşınması gereken şirket içi (on-premises) bir OLTP veritabanı işletmektedirler.

Zorluk: OLTP veritabanını yüksek erişilebilirliğe sahip, bölgeler arası okuma ölçeklenebilirliği olan bir hedefe taşırken, aynı zamanda S3 üzerinde gerçek zamanlı veri alımı (ingestion) ve sorgulama yeteneğine sahip, yönetişimli bir analitik gölü (analytic lake) oluşturmak.

Önerilen Yaklaşım:

1. Şema dönüştürme için AWS DMS’i SCT ile birlikte kullanın ve şirket içi veritabanından us-east-1’deki Amazon Aurora’ya (Global Database) sürekli CDC kurun. Ayrıca europe-west-1’de bir Aurora read replica oluşturun.
2. Tıklama akışı ve işlem olaylarını Amazon Kinesis Data Streams ve Firehose aracılığıyla alın; ham olayları arabelleğe alıp (buffer) Parquet formatında, tarih ve bölgeye göre bölümlenmiş (partitioned) olarak S3’e teslim edin.
3. S3 verilerini AWS Glue ile kataloglayın, Lake Formation aracılığıyla erişim kontrolünü uygulayın ve iyileştirilmiş (curated) veri setleri üretmek için Glue job’ları (veya Glue Studio) ile ETL gerçekleştirin; bu veri setlerini Amazon Athena ve Redshift Spectrum aracılığıyla analistlerin kullanımına sunun.
4. Sık erişilen (hot) ürün ve oturum verilerinin yüksek okuma oranlı önbelleğe alınması (caching) için ElastiCache (Redis) ekleyin; CloudWatch ile uçtan uca izleme mekanizması kurun, Aurora’da Enhanced Monitoring’i etkinleştirin ve runbook’ler ile yük devretmeyi (failover) doğrulayın.

Gerekçe: Bu yaklaşım, DMS CDC kullanarak kesinti süresini en aza indirir, Aurora Global Database aracılığıyla düşük gecikmeli küresel okumalar sağlar, analitik çeviklik için yönetişimli bir S3 veri gölü kurar ve kurumsal dayanıklılık ve performans en iyi uygulamaları doğrultusunda önbelleğe alma ve ayrıştırılmış (decoupled) akış tabanlı veri alımı ile OLTP sistemleri üzerindeki yükü azaltır.

← Depolama ve Veri Yönetimi · Tüm alanlar · Migrasyon ve Modernizasyon →

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

Amazon'a göz atın →