Tableau'nun heartbeat'i bir Databricks serverless warehouse'u ayakta tuttu ve tek hafta sonunda 14 bin dolarlık fatura oluşturdu

Ne yaşandı

dev.to'da yayımlanan birinci ağızdan bir postmortem, bir ekibin Databricks serverless SQL warehouse'unun tek bir hafta sonunda yaklaşık 14.000 dolarlık maliyet oluşturmasını ayrıntılarıyla anlatıyor. Yazar, bir Pazar günü saat 02:14'te gelen PagerDuty alarmının, ekibin 48 saat içinde aylık bulut harcamasının yüzde 80'ini tükettiğini bildirdiğini yazıyor. Herkesin ilk baştan şüphelendiği pipeline o Cuma günü yayınlanmış, CI'dan geçmiş ve verisini zamanında yüklemişti. Başarısızlık doğrulukta değil, maliyetteydi.

Alışılmış şüphelilerin uymaması

Gönderiye göre yazarın ilk varsayımı bir Python işindeki kontrolden çıkan bir döngüydü. DBR 13.3 LTS ortamındaki cluster loglarında olağan dışı hiçbir şey görünmüyordu; standart günlük veri alımının ötesinde Spark sorgu geçmişinde de öyle. Faturalandırma panosu ölçeği net biçimde ortaya koyuyordu: üç ay boyunca düz seyreden harcamanın ardından sql_warehouse_prod_v2 adlı warehouse'ta neredeyse dikey bir yükseliş.

Auto-stop ayarı ilk bakışta masumiyet kanıtı gibi görünüyordu. Konsol, Serverless SQL Warehouse üzerinde 10 dakikalık bir auto-stop gösteriyordu; bu da warehouse boştayken kapanması gerektiği anlamına gelmeliydi. Yazar, hatanın cluster durumunu izlemek yerine session durumunu izlememek olduğunu fark etti. Warehouse aslında hiç boşta kalmıyordu.

Idle zamanlayıcısını sıfırlayan heartbeat

Kök neden, ekibin Tableau entegrasyonu ile serverless warehouse arasındaki gizli bir etkileşimdi. Catalog ve schema ayarlarıyla yapılandırılmış bir dashboard bağlantı dizesi, 8 dakikalık bir heartbeat aralığıyla system.information_schema sorgusu gönderiyordu. BI aracı geniş yetkilere sahip bir service principal üzerinden bağlandığı için session ayakta kalıyordu.

Her heartbeat, 10 dakikalık idle penceresi dolmadan önce geldiğinden zamanlayıcı süresiz biçimde sıfırlanıyordu. Databricks bu ping'leri aktif sorgu olarak sayıyordu; dolayısıyla warehouse hiçbir zaman idle eşiğine ulaşmıyor ve hiç durmuyordu. Sorgular milisaniyenin altında sürdüğü için ekibin performans izleminde hiç görünmemişlerdi. Boyutlandırma işleri daha da kötüleştirdi: Önemli ölçüde daha yüksek DBU oranıyla faturalanan bir Large warehouse, bir Starter warehouse'un taşıyabileceği metadata sorgularına hizmet ediyordu. Geleneksel bir cluster'da kaynak çekişmesi veya zaman aşımları bu durumu doğal olarak sonlandırabilirdi; hep hazır kalmak üzere tasarlanan serverless ise hazır olma durumunun bedelini ödemeye devam etti.

Çözüm

Gönderiye göre acil müdahale, Tableau bağlantısını sonlandırmak ve bağlantı koptuğu anda warehouse'un kapanması için auto-stop süresini 1 dakikaya ayarlamak oldu. Ekip ardından iş yüklerini ayırdı: Şimdi heartbeat yoğunluğu高的 dashboard trafiğini bir Serverless-Small warehouse karşılıyor, Large warehouse ise ad-hoc analist sorgularına ve ağır ELT işlerine ayrılmış durumda. BI bağlantı dizesi belirli bir Unity Catalog schema'sına yönlendirildi; böylece artık geniş kapsamlı information_schema taramalarını tetiklemiyor. Warehouse'lara maliyet merkezi ve sahip için özel etiketler eklendi; bu sayede ekip, DBU tüketimini toplulaştırmayı beklemek yerine dakikalar içinde faturalandırma çıktılarında izole edebiliyor.

Sonrasında eklenen güvenlik önlemleri

Ekip ardından benzer bir olayın sessizce tekrarlanamaması için yapısal değişiklikler getirdi:

• Warehouse boyutlandırma politikası: Terraform deposunda belgelenmiş bir muafiyet olmadan Medium'un üzerinde üretim warehouse'u bulunamaz. Daha büyük boyutlar pull request gerektiriyor ve CI, günlük işletme oranını işaretlemek için Databricks Billing API üzerinden maliyet tahmini çalıştırıyor.
• Kapsamlı service principal'lar: BI araçları artık yalnızca belirli schema'larla sınırlı salt okunur principal'lar kullanıyor; bu da gizli yükü yaratan catalog ve information_schema sorgularını engelliyor.
• Bütçe alarmı: Bir Lambda fonksiyonu her 6 saatte bir Databricks faturalandırma verisini sorguluyor ve günlük tüketim hızı 7 günlük hareketli ortalamadan yüzde 20'den fazla saparsa yüksek öncelikli bir Slack alarmı tetikliyor.
• Auto-stop disiplini: Kritik olmayan iş yükleri için 5 dakikadan uzun olmamalı.

Neden önemli

Bu hikaye, serverless'ın operasyonel yükü ortadan kaldırdığı fikrine karşı yararlı bir denge unsuru. Serverless node yönetimini ortadan kaldırıyor, ancak yazarın ifade ettiği gibi ekipler hâlâ session yaşam döngüsünün sahibi. Idle temelli kapatmalar ancak "boşta" tanımının güvenilirliği kadar güvenilir; BI heartbeat'leri, bağlantı keepalive'leri veya izleme probları gibi hafif istemciler bunları sessizce geçersiz kılabilir ve performans panolarında görünmez kalabilir. Çıkarım Databricks'ın ötesine genelleniyor: esneklik, operasyonel hataları doğrudan faturaya dönüştürüyor; dolayısıyla harcamanın telemetri gibi izlenmesi, yalnızca mutlak eşiklere değil varyans temelli alarmlara dayanması gerekiyor. Serverless veri platformlarına geçen ekipler için bu olaydan çıkan kontrol listesi kısa: warehouse'ları gerçek yüke göre boyutlandırın, service principal yetkilerini dar tutun, hızlı atıf için kaynakları etiketleyin ve toplamların yanında tüketim hızındaki değişime alarm kurun.