Google ACE: Depolama, Veritabanları ve Veri Hizmetleri — Çalışma kılavuzu

By Laurynas Brazys · 31 August 2026 · #google #ACE #certification #exam-prep #study-guide

Şunun bir parçası: Google Associate Cloud Engineer — Çalışma kılavuzu. Doğrulanmış cevaplarla şurada pratik yapın: Google sınav merkezi, veya şurada süreli deneme sınavları çözün: ExamRoll.io.

Genel Bakış

Bu bölüm, Google Cloud depolama, veritabanları ve analitik veri hizmetleri için pratik, operasyon odaklı bir referans sunar. Yapılandırma desenlerini, erişim kontrolünü, dayanıklılık mekanizmalarını, performans ve maliyet özelliklerini ve güvenli kurtarma uygulamalarını vurgular. Amaç, belirli bir iş yükü için hangi hizmetin kullanılacağına karar vermenize, operasyonel ödünleşimleri anlamanıza ve yaygın arıza modlarını öngörmenize yardımcı olmaktır.

Cloud Storage tasarımı, erişimi, yaşam döngüsü ve korunması

Cloud Storage, yapılandırılmamış veriler ve yedeklemeler için dayanıklı, yüksek erişilebilirliğe sahip bir nesne depolama hizmetidir.

• Bucket’lar ve nesneler: Bucket’lar, bir konumda (bölge veya çift/çoklu bölge) bulunan ve değişmez nesne sürümlerini içeren genel ad alanlarıdır. Giden ağ trafiğini (egress) en aza indirmek ve veri yerleşimi (data residency) gereksinimlerini karşılamak için bucket konumunu seçin.
• Depolama sınıfları: Erişim sıklığına göre Standard (sık erişilen), Nearline (~30 gün min.), Coldline (~90 gün min.) ve Archive (~365 gün min.) sınıflarını kullanın. Felaket kurtarma (DR) yedeklemeleri için Coldline yaygın bir varsayılandır. Bir bucket içinde nesne başına farklı sınıfları karıştırabilirsiniz.
• Yaşam döngüsü kuralları: Age, CreatedBefore, MatchesStorageClass ve NoncurrentVersion koşullarına göre geçişleri ve silmeleri otomatikleştirin. 90 günde geçiş yapmak ve 365 günde silmek için örnek:
  1. lifecycle.json: { “rule”: [ {“action”: {“type”: “SetStorageClass”, “storageClass”: “COLDLINE”}, “condition”: {“age”: 90}}, {“action”: {“type”: “Delete”}, “condition”: {“age”: 365}} ] }
  2. Uygulama: gsutil lifecycle set lifecycle.json gs://my-bucket
• Saklama ve yasal bekletmeler: Saklama politikaları, süre dolmadan nesnelerin silinmesini veya değiştirilmesini engeller; politikayı kilitlemek geri alınamaz bir işlemdir. Yasal bekletmeler nesne başına uygulanır ve silinmeden önce kaldırılmalıdır.

Erişim kontrolü ve paylaşım:

• Tek tip ve ayrıntılı erişim: İzinleri yalnızca IAM ile yönetmek için Tek Tip Bucket Düzeyinde Erişim’i (UBLA - Uniform Bucket-Level Access) tercih edin. Ayrıntılı erişim (nesne ACL’leri) eski bir yöntemdir ve denetlenebilirliği ve yayılımı karmaşıklaştırır. UBLA’yı etkinleştirmek ACL’leri devre dışı bırakır ve ACL’lere dayanan mevcut entegrasyonları anında etkileyebilir.
• İmzalı URL’ler: Google kimliği olmadan kısa süreli erişim için imzalı URL’ler kullanın. IAM ile imzalayarak hizmet hesabı anahtar dosyalarından kaçının: gcloud storage sign-url gs://my-bucket/path/object –duration=4h –impersonate-service-account sa-sharing@proj.iam.gserviceaccount.com Hizmet hesabının kendisi üzerinde veya bir imzalayan rolü aracılığıyla ‘service account token creator’ iznine sahip olduğundan emin olun.
• Şifreleme: Varsayılan olarak sunucu tarafı şifreleme; anahtarlar ve denetim izleri üzerinde kontrol sahibi olmanız gerektiğinde bucket veya nesne bazında CMEK’i etkinleştirin. KMS anahtarının kullanılabilirliğini ve rotasyonunu izleyin; CMEK’in kullanılamaması yüklemeleri ve şifre çözme işlemlerini engeller.
• Sürüm oluşturma: Üzerine yazma/silme işlemlerinden sonra güncel olmayan sürümleri saklamak için nesne sürüm oluşturmayı etkinleştirin. Güncel olmayan sürümlerin süresini doldurmak ve depolama artışını kontrol etmek için yaşam döngüsü kurallarıyla birleştirin. Çok sayıda sürüm mevcut olduğunda istemci tarafı listeleme mantığına dikkat edin.

Arıza modları ve azaltma yöntemleri:

• Yanlışlıkla silme veya üzerine yazma: Sürüm oluşturma ve saklama politikalarını kullanın. Sıkı uyumluluk için saklama politikasını kilitleyin.
• Yanlış yapılandırılmış genel erişim: Genel Erişimi Önleme (Public Access Prevention) ve UBLA’yı zorunlu kılın. Cloud Asset Inventory ve policy analyzer ile periyodik olarak denetleyin.
• Aşırı maliyetler: Yaşam döngüsü kuralları, nesne düzeyinde sınıflar ve ‘requester pays’ (istekçi öder) özelliği sürprizleri azaltır. Cloud Monitoring metrikleri ve bütçelerle izleyin.

Faydalı komutlar:

• UBLA ve saklama politikası ile bucket oluşturma: gcloud storage buckets create gs://my-bucket –location=us-central1 –uniform-bucket-level-access –default-storage-class=STANDARD gcloud storage buckets update gs://my-bucket –retention-period=365d

İşlem iş yükleri için blok ve dosya depolama

Compute Engine ve GKE için erişim desenine, performans ihtiyaçlarına ve dayanıklılık gereksinimlerine göre depolama seçin.

• Persistent Disk (PD): Dayanıklı blok depolama, bölgesel (zonal) veya coğrafi (regional). Türler: Sıralı iş hacmi için Standard (HDD); düşük gecikme süresi ve IOPS için Balanced (pd-balanced) ve SSD (pd-ssd). Regional PD, bölgeler (zone) arasında senkron olarak çoğaltma yaparak daha hızlı kurtarma sağlar. PD’nin anlık görüntüsü (snapshot) alınabilir, çevrimiçi olarak yeniden boyutlandırılabilir ve birden çok VM’ye salt okunur olarak eklenebilir (okuma-yazma için tek yazıcı).
  • Ödünleşimler: SSD’de daha yüksek IOPS maliyetleri; HDD rastgele G/Ç için uygun maliyetlidir ancak yüksek gecikme süresine sahiptir. Regional PD daha maliyetlidir ancak RTO’yu (Kurtarma Süresi Hedefi) azaltır.
• Local SSD: Çok yüksek IOPS ve düşük gecikme süresine sahip, NVMe veya SCSI ile bağlanan geçici depolama. Veriler VM durdurulduğunda/ana makine bakımı sırasında kaybolur; yalnızca geçici önbellekler veya çoğaltılmış veriler için kullanın. Veri kaybını önlemek için başka bir yere yedekleyin veya çoğaltın.
• Filestore: POSIX paylaşımlı dosya semantiği için yönetilen NFS. Basic katmanları bölgeseldir (zonal); Enterprise ve daha yüksek katmanlar, senkron çoğaltma ve daha yüksek IOPS ile coğrafi HA (yüksek erişilebilirlik) sunar. GCVE, HPC geçici depolama (scratch), medya işleme ve paylaşılan dosya kilitleme gerektiren uygulamalar için idealdir.
  • Ödünleşimler: NFS, istemci tarafı önbelleğe alma ve kilit semantiği getirir; iş hacmi ve gecikme süresi katmana göre değişir; local SSD gibi tek haneli mikrosaniye gecikme sürelerinde küçük rastgele G/Ç için uygun değildir.

Arıza durumları:

• Ana makine bakımı: Local SSD veri kaybı; uygulama çoğaltması ile koruyun.
• Bölgesel (zonal) kesintiler: Zonal PD ve Basic Filestore kesintileri; HA için regional PD veya Filestore Enterprise kullanın.
• Anlık görüntü (snapshot) tutarlılığı: Uygulama tutarlı PD anlık görüntüleri için, çökme sonrası kurtarma pencerelerinden kaçınmak amacıyla dosya sistemini dondurma veya veritabanının yerel ‘quiesce’ (durgunlaştırma) özelliği ile koordine edin.

Yönetilen veritabanları ve veri hizmetleri

Cloud SQL (yönetilen MySQL, PostgreSQL, SQL Server):

• Yapılandırma: Makine şeklini, depolama türünü, bağlantıları (private IP tercih edilir), public IP kullanılıyorsa yetkili ağları, bakım pencerelerini ve performans teşhisi için insights’ı seçin. Bağlantı ve CPU sınırları içinde kalmak için bağlantı havuzu (connection pooling) kullanın (ör. Cloud SQL Auth Proxy, PGbouncer).
• Yüksek erişilebilirlik (HA): Bölgesel HA (Regional HA) örnekleri, başka bir zone’da senkron depolama replikasyonu ile bir standby (yedek) dağıtır; failover otomatiktir. Failover sırasında kısa bir yazma kesintisi penceresi beklenir.
• Replikalar: Okuma ölçeklendirmesi ve BI (iş zekası) yükünü hafifletmek için okuma replikaları (read replicas); geçişler için harici replikasyon. Replika gecikmesini (replica lag) izleyin ve idempotent (tekrar çalıştırıldığında aynı sonucu veren) okuyucular tasarlayın.
• Yedeklemeler ve PITR: Belirli bir zamana kurtarma (point-in-time recovery) için otomatik yedeklemeleri ve ikili/WAL (binary/WAL) günlük kaydını etkinleştirin. Geri yüklemeleri düzenli olarak test edin. gcloud sql instances patch my-sql –backup-start-time=03:00 –enable-bin-log
• Hata modları: Uzun süren işlemler (transactions) vacuum/checkpointing işlemlerini engeller; bağlantılardaki ani artışlar ’thrashing’e (verimsiz çalışma) neden olur; kota yetersizse depolama alanının otomatik büyümesi durabilir. CPU, bellek, bağlantılar, replika gecikmesi ve disk kullanımı için uyarılar ayarlayın.

Cloud Spanner:

• Ölçek ve bölgesellik: Senkron replikasyon ve güçlü küresel tutarlılık (strong global consistency) ile bölgesel (regional) veya çok bölgeli (multi-region) örnekler. Verim (throughput) ve depolama için node’ları ölçeklendirin; lider bölge (leader region) yerleşimi yazma gecikmesini etkiler.
• Şema ve anahtarlar: Hotspot’ları (yoğun erişim noktaları) önlemek için birincil anahtarları (primary keys) tasarlayın; zaman serisi verileri için yazma işlemlerini dağıtmak amacıyla hash’lenmiş veya rastgele bir önek içeren bileşik anahtarlar (composite keys) kullanın. Sorgu desenleri için ikincil dizinler (secondary indexes) kullanın ve sık filtrelenen sütunları birlikte depolamayı düşünün. Kilit çekişmesini (lock contention) en aza indirmek için işlemleri (transactions) küçük ve sınırlı tutun.
• İşlemler (Transactions): TrueTime aracılığıyla harici tutarlılığa (external consistency) sahip, güçlü tutarlı (strongly consistent), dağıtık işlemler. Yazma gecikmesi quorum ile sınırlıdır; çakışmalar iptal edilen işlemlerle sonuçlanır—üstel geri çekilme (backoff) ile yeniden deneyin.

Firestore ve Bigtable:

• Firestore (Native modu): Koleksiyonlar, gerçek zamanlı dinleyiciler (real-time listeners), işlem başına 500 dokümana kadar olan işlemler (transactions) ve doküman okumaları ile çoğu sorgu için güçlü tutarlılık (strong consistency) sunan bir doküman deposu (document store). Mobil/web uygulaması verileri, hiyerarşik JSON ve olay güdümlü (event-driven) uygulamalar için en iyisidir.
• Bigtable: Petabayt ölçeği ve 10ms altı gecikme süresi için geniş sütunlu (wide-column) veritabanı. Yalnızca tek satırlı işlemler (single-row transactions); hotspotting’i (yoğun erişim noktaları) önlemek için satır anahtarları (row keys) tasarlayın. Zaman serisi, IoT, kişiselleştirme ve büyük ölçekli sayaçlar için idealdir. Anlık (ad-hoc) join’ler veya karmaşık birleştirmeler (aggregations) için uygun değildir.

Memorystore:

• Redis ve Memcached: Mikrosaniye-milisaniye düzeyinde gecikme süresi için bellek içi (in-memory) önbellekler. Basic katmanında HA yoktur; Standard katmanı Redis için otomatik failover ile bölgesel HA (regional HA) sağlar. Geçici (ephemeral) olarak kabul edin; kayıt sistemi (system of record) olarak kullanmayın.

BigQuery:

• Dataset’ler ve tablolar: Dataset’e göre düzenleyin; proje, dataset, tablo, sütun ve satır düzeylerinde erişimi kontrol edin. Taranan bayt miktarını ve maliyeti kontrol etmek için bölümlenmiş (partitioned) ve kümelenmiş (clustered) tablolar kullanın.
• Yükleme ve sorgu işleri: Cloud Storage, Cloud SQL dışa aktarımları veya akış eklemelerinden (streaming inserts) yükleme yapın. Maliyeti tahmin etmek için deneme çalıştırmaları (dry runs) kullanın: bq query –use_legacy_sql=false –dry_run=true ‘SELECT …’
• Erişim kontrolü: Salt okunur (read-only) tüketiciler için dataset kapsamında BigQuery Data Viewer izni verin; en az ayrıcalık (least privilege) ilkesi için yetkilendirilmiş görünümler (authorized views) veya satır/sütun düzeyinde güvenlik (row-level/column-level security) kullanın.

Veri taşıma, geçiş, doğrulama ve operasyonel ödünleşimler

Geçiş ve transfer:

• Database Migration Service (DMS): Replikasyon yoluyla minimum kesinti süresiyle Cloud SQL’e homojen geçişler için. Gecikme metrikleri ve checksum karşılaştırmaları ile geçişi doğrulayın.
• Cloud Storage transferleri: Tekrarlayan veya olay güdümlü transferler için Storage Transfer Service; tek seferlik senkronize kopyalar için checksum’larla birlikte gsutil -m rsync; büyük çevrimdışı taşımalar için Transfer Appliance.
• İçe/dışa aktarma: Cloud SQL, Cloud Storage’a dışa aktarır; yeniden içe aktarma, PITR başlangıcı ve veri doğrulamasını destekler. BigQuery, Cloud Storage’dan toplu yüklemeleri ve alt sistemlerde kullanım için Avro/Parquet’e dışa aktarmayı destekler.
• Doğrulama: Nesne checksum’ları (CRC32C), satır sayıları, örnekleme sorguları ve uygulama düzeyindeki değişmezleri kullanın. BigQuery için, kaynak ve hedef arasında GROUP BY sayılarını veya hash’lerini karşılaştırın.

Performans, kullanılabilirlik, kapasite ve maliyet ödünleşimleri:

• Cloud Storage: İşlem gücünü ortak konumlandırarak çıkış trafiğini (egress) optimize edin; erişim sıklığına göre sınıfları seçin; bölgeler arası dayanıklılık ve daha yüksek depolama maliyetiyle daha yüksek kullanılabilirlik için çift/çoklu bölge kullanın.
• PD/Filestore: Düşük gecikmeli IO için SSD; verim (throughput) için HDD; HA için bölgesel replikasyon; kısıtlamayı (throttling) önlemek için IOPS’u doğru boyutlandırın.
• Cloud SQL: Dikey ölçeklendirme basittir ancak sınırlıdır; okuma replikaları (read replicas) okuma trafiğini azaltır; HA, okuma kapasitesini artırmadan kullanılabilirlik ekler; depolama sınıfı gecikmeyi ve maliyeti etkiler.
• Spanner: Güçlü tutarlılıkla yatay olarak ölçeklenir; premium maliyeti, küresel RPO/RTO ve basitleştirilmiş sharding ile dengelenir. Yazma işlemleri, anahtar tasarımına ve lider bölge gecikmesine duyarlıdır.
• Firestore/Bigtable/Memorystore: Gecikme süresi, veri modeli ve tutarlılığa göre seçim yapın. Bellek içi önbellekler (in-memory caches) veritabanı yükünü azaltır ancak önbellek geçersiz kılma (cache-invalidation) karmaşıklığı ekler.
• BigQuery: İsteğe bağlı (on-demand) maliyet, taranan baytlarla orantılıdır; bölümleme/kümeleme (partitioning/clustering) ve koşul aktarımı (predicate pushdown) harcamayı azaltır. Sabit oranlı (flat-rate) rezervasyonlar, taahhüt karşılığında öngörülebilirlik sunar.

Sorun giderme ve güvenli kurtarma:

• Cloud Storage: Kurtarma için nesne sürüm oluşturma (object versioning) ve saklama (retention) kullanın; okuma/yazma olaylarını denetlemek için Cloud Logging veri erişim günlüklerini inceleyin; kurtarma sırasında CMEK anahtarlarının etkin olduğundan emin olun.
• PD/Filestore: Anlık görüntülerden (snapshots) veya yedeklerden geri yükleyin; fsck ve veritabanı kurtarma modlarını çalıştırın; anlık görüntü almadan önce uygulama düzeyinde sessizleştirme (quiesce) ile tutarlılığı sağlayın.
• Cloud SQL: Birincil (primary) sistemde veri kaybını önlemek için PITR ile yeni bir örneğe (instance) geri yükleyin; salt okunur testlerle doğrulayın; güvenli geçiş desenleri için güvenlik duvarını ve özel DNS’yi koruyun.
• Spanner/Bigtable: Anahtar erişimindeki dengesizlik (skew) yoluyla hotspotting’i araştırın; gecikmeyi ve kısıtlamayı (throttling) izlemek için Monitoring’i kullanın; iptal edilen işlemler veya hız sınırlı operasyonlar için geri çekilme (backoff) ve yeniden deneme (retry) mekanizmaları uygulayın.
• BigQuery: Yürütme ayrıntılarıyla yavaş sorguları teşhis edin; bölümler ve kümeleme ekleyin; SELECT * kullanımını sınırlayın; uygun olduğunda ara sonuçları somutlaştırın (materialize). Zaman yolculuğu (time travel) penceresi içinde silinmiş tabloları, bir anlık görüntüyü geri yükleyerek veya bir anlık görüntü zamanından kopyalayarak kurtarın.

Pratik Problem Senaryosu

Contoso Retail, işlem sistemleri için anlık zaman kurtarma (point-in-time recovery) özelliğini etkinleştirirken ve erişim kontrollerini sıkılaştırırken yedekleme ve analiz verilerini birleştiriyor. Şunları yapmaları gerekiyor: uygulama yedeklerini otomatik katmanlandırma ile depolamak, üçüncü taraflara kısa süreli dosya paylaşımı sağlamak, küçük bir ilişkisel iş yükü için PITR’ı etkinleştirmek ve analiz sorgu maliyetlerini yürütmeden önce tahmin etmek.

Yaklaşım:

1. UBLA, saklama (retention) ve yaşam döngüsü (lifecycle) özelliklerine sahip bölgesel bir Cloud Storage bucket’ı oluşturun.
   • Komut:

undefined

undefined

undefined

• Gerekçe: UBLA, yetkilendirmeyi IAM’de merkezileştirir ve denetlenebilirliği artırır. Bir yıllık saklama süresi, yanlışlıkla silinmeyi önler. Yaşam döngüsü, maliyeti kontrol etmek için yedekleri 90 gün sonra Coldline’a taşır ve süreleri dolduğunda siler.

2. Özel bir hizmet hesabı aracılığıyla yedekleme işleri için yalnızca yazma erişimi verin.
   • Komut:

undefined

• Gerekçe: storage.objectCreator, en az ayrıcalık ilkesine bağlı kalarak meta veri manipülasyonunu ve hassas yedeklerin geri okunmasını engeller.

3. Anahtar dağıtmadan, imzalı bir URL kullanarak hassas bir yedeği bir tedarikçiyle dört saatliğine paylaşın.
   • Komut:

undefined

• Gerekçe: Zamana bağlı, kimliksiz erişim, harici kimlikler veya uzun ömürlü sırlar oluşturmaktan kaçınır. Kimliğe bürünme (impersonation), merkezileştirilmiş KMS destekli imzalama kullanır ve sızdırılmış anahtar risklerini ortadan kaldırır.

4. Sipariş veritabanı için Cloud SQL yedeklemelerini ve PITR’ı etkinleştirin.
   • Komut:

undefined

• Gerekçe: Otomatik yedeklemeler artı ikili/WAL günlüğü, saklama penceresi içindeki herhangi bir saniyeye geri yükleme noktaları sağlar, bu da mantıksal bozulmalara ve operatör hatalarına karşı koruma sağlar.

5. Yeni bir örneğe geri yükleyerek ve geçişten önce verileri doğrulayarak kurtarmayı test edin.
   • Komut:

undefined

undefined

• Gerekçe: Ayrı bir örneğe geri yüklemek, üretimi etkilemekten kaçınır ve herhangi bir DNS veya uygulama düzeyinde değişiklik yapmadan önce checksum’lar ve örnek sorgular aracılığıyla doğrulamaya olanak tanır.

6. Bir deneme çalıştırması (dry run) ile BigQuery sorgu maliyetini tahmin edin ve bölümleme (partitioning) ile optimize edin.
   • Komut:

undefined

• Gerekçe: Deneme çalıştırmaları, taranacak baytları ortaya çıkarır; sale_date’in sınırlı bir koşul ile bir bölüm sütunu olmasını sağlamak, taranan baytları azaltır ve isteğe bağlı (on-demand) maliyetleri kontrol eder.

7. Erişimi izleyin ve denetleyin.

   • Adımlar:
     • Cloud Storage ve BigQuery için Veri Erişimi (Data Access) günlüklerini etkinleştirin.
     • Cloud SQL bağlantıları, disk kullanımı ve yedekleme hataları için Cloud Monitoring uyarıları yapılandırın.
   • Gerekçe: Veri Erişimi günlükleri, uyumluluk için nesne düzeyinde okuma/yazma görünürlüğü sağlar. Proaktif uyarılar MTTR’yi kısaltır ve yedeklemelerin ve PITR’ın etkili kalmasını sağlar.

8. Hata modlarını ve müdahale kılavuzlarını (runbook) belgeleyin.

   • Adımlar:
     • Nesne sürümü geri yüklemeleri, imzalı URL iptali, Cloud SQL PITR ve zaman yolculuğu (time travel) kullanarak BigQuery tablo kurtarma prosedürlerini kaydedin.
   • Gerekçe: Açık ve test edilmiş müdahale kılavuzları, olaylar sırasında operasyonel riski azaltır ve ekipler arasında güvenli kurtarma uygulamalarını standartlaştırır.

← VPC Ağ İletişimi · Tüm alanlar · Dağıtım →

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

Google'a göz atın →