Editörden

Yedekliliğin çalıştığını ancak kapatıp denediğinde bilirsin. AWS’nin yazısı, bir Availability Zone’u günlerce boşaltarak yapılan tatbikatların neleri ortaya çıkardığını anlatıyor. Yanında iki veritabanı haberi var: Spanner’ın her yerde çalışan sürümü ve Lakebase’de maliyet kontrolü.

Günün Kapağı
AWS Architecture Blog 30 Eylül 202616 dk okuma ileri

Bir Availability Zone’u günlerce boşaltmak: ARC Zonal Shift ile N-1 tatbikatı

Running multi-day AZ evacuation drills with ARC Zonal Shift · Antoine Boucherie

‘Bir AZ düşerse ayakta kalırız’ cümlesi, bunu gerçekten denemedikçe bir varsayımdır. AWS’nin yazısı, bir Availability Zone’u 48-72 saat boyunca trafikten çıkarıp sistemi N-1 kapasiteyle (bir zone eksik) çalıştıran tatbikatları anlatıyor. Kısa bir tatbikat anlık sorunları yakalar; günlerce süren tatbikat ise zamanla ortaya çıkan sorunları yakalar.

Tatbikatların açığa çıkardığı hata türleri öğretici: otomatik ölçekleme (kapasite kalan zone’larda yeterince hızlı büyüyor mu), eski DNS kayıtları (istemciler boşaltılmış zone’a hâlâ gidiyor mu), nöbet ve rotasyon süreçleri (insanlar ve runbook’lar çok günlük bir durumu kaldırıyor mu) ve sabitlenmiş veritabanı bağlantıları (bağlantılar eski zone’daki örneğe yapışık kalıyor).

Mekanizma tarafında ARC Zonal Shift, Kubernetes (EKS) üzerinde ilgili zone’daki düğümleri yeni pod’lara kapatıyor (cordon) ve o zone’daki uç noktaları EndpointSlice’tan çıkarıyor; böylece trafik kalan zone’lara akıyor.

Öne çıkanlar

  • Yedekliliği test etmeyen sistem, yedekliliği olduğunu varsayan sistemdir.
  • Günlerce süren tatbikat, saatlik tatbikatın göremediği zamanla biriken sorunları gösterir.
  • Sorunların çoğu kodda değil çevrede: DNS, bağlantı havuzu, ölçekleme ve insan süreçleri.
  • N-1 kapasite planı, kalan zone’ların tüm yükü kaldırabildiğini ölçmeden anlamsızdır.

Neden önemli?

Çok-AZ mimari çizmek kolay, çalıştığını kanıtlamak zor. Tatbikat, ‘olursa ne olur’ sorusunu planlı bir deneye çevirir ve gerçek kesintiden önce hataları ucuza bulur.

Sende karşılığı

Bu desenin küçük ölçekli hâli bugün senin elinde: Tradebot ya da Mobit’i docker-compose ile çalıştırıyorsan, veritabanı konteynerini bilerek durdur ve uygulamanın ne kadar sürede toparlandığına bak. Bağlantı havuzun (HikariCP) ölü bağlantıyı tespit edip yeniden bağlanıyor mu? maxLifetime ve connectionTimeout ayarlarının anlamı tam burada ortaya çıkar. Sonucu bir RESILIENCE.md dosyasına ‘ne denedim, ne bozuldu, ne düzelttim’ diye yaz: mülakatta ‘dayanıklılığı test ettim’ diyebilmenin somut kanıtı.

Sözlük

Availability Zone (AZ) erişilebilirlik bölgesi
Bir bulut bölgesi içinde fiziksel olarak ayrı, bağımsız arızalanabilen veri merkezi grubu.
zonal shift zone kaydırma
Trafiği sorunlu ya da boşaltılan bir zone’dan diğer zone’lara yönlendirme.
N-1 N-1 kapasite
Bir bileşen (örneğin bir zone) kaybedilse bile yükü taşıyabilecek kapasite planı.
cordon düğümü kapatma
Kubernetes’te bir düğüme yeni pod atanmasını engelleme.
Orijinali oku

Kısa Kısa

Google Cloud Blog 30 Eylül 20265 dk okuma orta

Spanner artık her yerde: Spanner Omni genel kullanıma açıldı

Spanner Omni, deploy-anywhere version of Spanner, is now GA

Google, Spanner’ın istediğin yere kurulabilen sürümü Spanner Omni’yi genel kullanıma açtı. Yazıya göre ürün yaklaşık 2 milyon kez indirilmiş; mimaride iş yapan worker düğümleri var ve denemek için ücretsiz bir geliştirici sürümü sunuluyor. Böylece Spanner’ın dağıtık, güçlü tutarlı veritabanı modelini yalnızca Google Cloud’da değil, kendi ortamında da denemek mümkün.

  • Yönetilen bir bulut veritabanı, kendi ortamında çalışacak biçimde paketlenebiliyor.
  • Ücretsiz geliştirici sürümü, dağıtık SQL’i öğrenmek için düşük giriş bariyeri.

Sende karşılığı

Dağıtık veritabanı kavramlarını (güçlü tutarlılık, dağıtık işlem) öğrenmek için ücretsiz geliştirici sürümünü yerel makinede dene; bu gazetenin 2 Ekim sayısındaki Spanner queues yazısını da aynı ortamda deneyebilirsin.

Sözlük

strong consistency güçlü tutarlılık
Her okumanın en son yazılan değeri görmesini garanti eden tutarlılık modeli.
Orijinali oku
Databricks Engineering 30 Eylül 202610 dk okuma orta

Postgres’te maliyeti düşüren üç ayar: paylaşımlı dallar, otomatik ölçekleme, sıfıra inme

A practical guide to cost optimization with Lakebase Postgres

Databricks’in Lakebase rehberi maliyeti üç yerden kısmayı öneriyor. Dallar (branch) depolamayı paylaşıyor, yani bir geliştirme ya da test kopyası verinin tamamını ikinci kez saklamıyor. Otomatik ölçekleme ve sıfıra inme (scale to zero) boşta kalan hesaplama maliyetini azaltıyor. Veri senkronizasyonunda da üç mod var: snapshot, triggered ve continuous; ne kadar taze veri gerektiğine göre seçilince gereksiz sürekli senkronizasyon maliyeti önleniyor.

  • Dal depolamayı paylaşıyorsa test ortamı kopya maliyeti getirmez.
  • Boşta kalan veritabanını kapatmak, en ucuz optimizasyondur.
  • Senkronizasyon modunu tazelik ihtiyacına göre seç: her veri sürekli akmak zorunda değil.

Sende karşılığı

Aynı mantık kendi geliştirme ortamında da geçerli: Mobit için yalnızca ihtiyaç anında açılan bir test veritabanı kullan. Neon gibi dal destekli bir Postgres sağlayıcısı ile ücretsiz katmanda ‘her pull request için bir veritabanı dalı’ deseni denenebilir.

Sözlük

scale to zero sıfıra ölçekleme
Kullanılmayan hesaplama kaynağını tamamen kapatıp istek gelince yeniden açma.
database branching veritabanı dallandırma
Bir veritabanının kopyasını veriyi çoğaltmadan, sadece değişenleri saklayarak oluşturma.
Orijinali oku