Aurora RDS'de bir race condition keşfedilme vakası

 (hightouch.com)
1 puan yazan GN⁺ 2025-11-16 | 1 yorum | WhatsApp'ta paylaş
  • AWS Aurora RDS'de ortaya çıkan race condition bug'ı deneysel olarak doğrulandı ve AWS'den nedenine ilişkin teyit alındı
  • Hightouch, olay işleme sistemini ölçeklerken Aurora'nın failover (yük devretme) sürecinde yazma instance'ı geçişinin başarısız olduğunu fark etti
  • Log analizi sonucunda, iki instance'ın aynı anda yazma işlemi yaptığı ve bunun depolama katmanında çakışma ile süreç sonlanmasına yol açtığı doğrulandı
  • AWS, iç sinyal işleme sorunu nedeniyle önceki writer'ın düşürülmesi tamamlanmadan yeni writer'ın terfi ettirildiğini resmi olarak doğruladı
  • Bu vaka, büyük ölçekli dağıtık sistemlerde eşzamanlılık kontrolünün önemini ve failover sırasında yazmayı durdurma prosedürünün gerekliliğini vurguluyor

Arka plan

  • 20 Ekim 2025'te AWS us-east-1 bölgesinde, DNS yönetim sistemindeki bir race condition bug'ı nedeniyle kesinti yaşandı
  • Hightouch bu nedenle olay işleme backlog'unun hızla arttığını ve sistem sınırına ulaştığını gördü
  • İş hacmini karşılamak için 23 Ekim'de Aurora RDS instance yükseltmesi gerçekleştirildi ve bu süreçte yeni bir race condition bug'ı keşfedildi

Hightouch olay sistemi mimarisi

  • Olay toplama ve iletiminden sorumlu sistem Kubernetes, Kafka ve Postgres(Aurora) bileşenlerinden oluşuyor
  • Postgres, batch metadata queue olarak kullanılıyor ve saniyede 500 bin olayı 1 saniye içinde işliyor
  • Aurora PostgreSQL, yalnızca yazma yapan (primary) instance, salt okunur (replica) instance ve paylaşımlı depolama katmanından oluşuyor

Yükseltme planı

  • Okuma instance'ı ekleme → mevcut reader'ı yükseltip failover önceliği verme → failover çalıştırma → mevcut writer'ı yükseltme → geçici reader'ı kaldırma
  • Bu prosedür AWS belgelerinde belirtilen yöntemdi ve staging ortamında yük testiyle doğrulanmış bir prosedürdü

Yükseltme denemesi ve sorunun ortaya çıkışı

  • 23 Ekim 16:39 EDT'de failover çalıştırıldıktan sonra mevcut writer'ın yeniden primary olarak geri dönmesi olayı yaşandı
  • İki denemede de aynı sonuç görüldü ve bazı servislerde yazılamama hatası (DatabaseError: cannot execute UPDATE in a read-only transaction) oluştu
  • Log analizi, iki instance'ın aynı anda yazma işlemi yaparken depolama çakışması nedeniyle sonlandığını gösteren kayıtları ortaya koydu

Race condition'ın nedeni

  • Aurora'nın failover sürecindeki 3. adım (mevcut writer'ın düşürülmesi) ile 4. adım (yeni writer'ın terfi ettirilmesi) arasında race condition oluştu
  • Bunun sonucunda iki instance aynı anda yazma yetkisine sahip oldu ve çakışma yaşandı
  • Yazma trafiği kaldırılmış halde yeniden denendiğinde failover normal şekilde tamamlandı ve race condition hipotezi doğrulandı

AWS'nin doğrulaması ve yanıtı

  • AWS, iç inceleme sonrasında nedenin writer düşürme sinyalinin işlenmesindeki hata olduğunu ve bunun Hightouch'un yapılandırması veya trafik deseniyle ilgili olmadığını doğruladı
  • Düzeltmenin yol haritasına alındığı ve geçici önlem olarak failover sırasında yazmanın durdurulmasının önerildiği belirtildi

Nihai önlemler

  • Hightouch küme yükseltmesini tamamladı ve
    • kasıtlı failover öncesi yazmayı durdurma prosedürü ekledi
    • writer rolü değişimini izleyen gözlemlemeyi güçlendirdi
    • operasyon kılavuzunu (playbook) güncelledi

Başlıca dersler

  1. Migrasyon sırasında beklenmedik durum geçişlerine karşı kurtarma hazırlığı gerekli
  2. Gözlemlenebilirlik (observability), sorun tespitinin anahtarı
  3. Dağıtık sistem bileşenleri arasındaki etkinin en aza indirildiği tasarımın önemi büyük
  4. Test ortamı ile gerçek üretim ortamı arasındaki farkın farkında olunmalı

Orijinal metinde ek bilgi yok

İlgili okumalar

1 yorum

 
GN⁺ 2025-11-16
Hacker News yorumu

  • Bu yazıya bakınca, uygulama manuel failover sırasında da normalde olduğu gibi yazma trafiğini sürdürmeye çalışırsa her zaman başarısız olacakmış gibi görünüyor
    Ama aklıma birkaç soru geliyor. Diğer Aurora kullanıcıları neden bu sorunu sürekli yaşamıyor, AWS’nin bundan habersiz olması mümkün mü, biliyorsa neden bunu P0 seviyesinde acil bir sorun olarak ele almıyor merak ediyorum
    Belki de işin içinde devam eden transaction durumu veya timeout gibi ince koşullar vardır

    • Azure’da benzer bir sorunla uğraşmış biri olarak, birçok kişinin bunu yaşadığını ama yeniden başlatınca düzeldiği için üstünde durmadığını söyleyebilirim. Kök nedeni bulmak zor, vendor ile birlikte analiz süreci de o kadar sancılı ki çoğu kişi vazgeçiyor
    • Biz de AWS ile birlikte çalışırken aynı sorunu doğruladık. Trafik deseni özel değildi ve başka region’larda yeniden üretilemedi. Bu büyük olasılıkla Aurora’nın temel failover mekanizmasındaki bir kusur
    • Eskiden Python + MySQL kombinasyonunda SELECT ... FOR UPDATE ifadesinin sessizce başarısız olduğu ve transaction’ın autocommit moduna geçtiği bir bug yaşamıştım. Kimse ilgilenmediği için tek başıma konuşup durmuştum, birkaç ay sonra başka biri de aynı sorunu yaşadığını söyleyerek bana ulaştı. Sonunda düzeltildi ama ben çoktan ilgiyi kaybetmiştim
      İlgili bağlantı: Stack Overflow sorusu
    • AWS içeride neler olduğuna dair neredeyse hiçbir bilgi paylaşmıyor. API seviyesinin ötesindeki ayrıntıları vermediği için, böyle sorunları nadir görülen vakalar diye geçiştiriyormuş hissi veriyor
    • Sorunun bir kısmı, uygulamanın geri alınmış failover durumuna tepki verme biçiminden de kaynaklanıyor olabilir. Cache bozulduğu için yanlış primary’e yazmayı sürdürmeye çalışmış gibi görünüyor. Bu tür hatalar sık yaşansa bile retry ile düzelebildiğinden, kullanıcılar AWS’ye bildirmediği için AWS fark etmiyor olabilir

  • Aurora PostgreSQL’de birkaç kez beklenmedik davranışlar gördüm
    Özellikle Zero Downtime Patching (ZDP) sırasında session durumunun yanlış korunması yüzünden, basit sorgular bile statement_timeout süresinden çok daha erken iptal oluyordu
    Benim tahminim, istemci yeniden bağlandığında Aurora’nın önceki session’ın eski timer durumunu aynen devraldığı ve sorgunun bu yüzden hemen iptal edildiği yönünde

  • Biz de yazma trafiğinin çok yüksek olduğu bir ortamda düzenli olarak failover yapıyoruz ama AWS JDBC wrapper kullanarak bunu otomatik bir süreçle istikrarlı biçimde işletiyoruz

    • Pratikte Aurora’nın storage katmanı ACID ihlalini engelledi, yani veri bütünlüğü korunmuş oldu

  • Aurora’nın bu kadar temel bir invariant’ı koruyacağına güvenip para ödüyorsunuz; buna rağmen böyle bir sorun çıkması şaşırtıcı

    • Ama storage katmanının kendisi eşzamanlı yazmaları engelleyerek doğru çalıştı

  • Log’lara ve AWS’nin açıklamasına bakınca, orijinal yazının yazarının hipotezi yanlış gibi görünüyor
    Promotion başarısız olduktan sonra harici bir gözetim süreci cluster durumundaki tutarsızlığı algılayıp zorla sonlandırma (kill -9) yapmış gibi görünüyor. Storage alt sistemiyle ilgili mesajlar da bundan sonra ortaya çıkmış

  • Aurora ile RDS Postgres’in performans karşılaştırmasını sormak istiyorum.
    Multi-AZ ya da hızlı failover gerekmiyorsa, RDS üzerinde gp3 64k IOPS yapılandırmasıyla daha iyi performans almak mümkün mü? Aurora özellikle insert performansında yavaş ve maliyeti yüksek görünüyor. Benchmark’lar da RDS ayarlarını açıkça belirtmediği için güven vermiyor

    • Biz Aurora PG 14’te 1 writer + 1~2 reader yapılandırmasıyla daha iyi performans ve daha düşük maliyet elde ettik. Aurora’da ücretlendirme instance başına değil cluster düzeyinde storage üzerinden olduğu için avantajlı.
      Ayrıca IOPS’u doğrudan provision etmek gerekmiyor ve yaklaşık 80k IOPS sağlıyor.
      I/O ücretlendirmesinde de iki model var; pay-per-IO düşük yük ortamları için, sabit ücret modu ise IO’su yüksek iş yükleri için daha avantajlı.
      Bu arada Serverless neredeyse her zaman ekonomik değildi. Yalnızca kısa süreli zirve yükleri varsa işe yarıyor
    • Bizim ekip Aurora Postgres RDS’de I/O maliyetinin patlamasını yaşadı. Sadece birkaç fuzzy query yüzünden aylık fatura $3,000’ın üstüne çıktı; oysa normalde $100’ün altında olması gerekiyordu
    • Aurora’nın maliyet, performans ve gecikme taraflarının tümü hayal kırıklığı yarattı; sonunda on-prem PostgreSQL’e geçtik
    • Aurora MySQL açısından bakarsak, RDS’de aynı IOPS seviyesini yakalamak çok daha pahalıya geliyordu
    • Aurora EBS kullanmıyor ve storage tipi ya da gecikmeyi seçmenize izin vermiyor. Yalnızca I/O ücretlendirme modelini seçebiliyorsunuz

  • AWS mühendislerinin sözünü ettiği “lego blok modeli” burada net biçimde görülüyor
    Storage katmanını tamamen bağımsız tasarladıkları için, üst servisler başarısız olsa bile veri tutarlılığı korunmuş. Bence bu AWS mühendisliğinin iyi bir örneği

  • AWS’nin “failover sırasında yazmayı durdurun” tavsiyesinde bulunduğu söyleniyor; ilgili vaka numarasını paylaşmanız mümkün mü merak ediyorum

    • Biz de Aurora MySQL kullanıyoruz, bu yüzden bu tavsiyenin MySQL için de geçerli olup olmadığını doğrulamak istiyorum

  • Bunu yaşayan tek kişinin ben olmadığını görmek sevindirici

    • AWS Support başlangıçta buna replication lag diyerek itiraz etti ama kararını 24 saat önceki eski metriklere bakarak vermişti. Ne tür bir arıza yaşandığını ve neden başka region’larda yeniden üretilemediğini gerçekten bilmek istiyorum

  • Aurora’nın compute-storage ayrımı mimarisi ilginç
    MSSQL’deki Hyperscale de benzer bir yapıya sahip ve Azure servisleri içinde gerçekten kullanmaya değer bulduğum neredeyse tek ürün bu