Azure Synapse: Silinen Workspace Adı Serbest Kalmadı
Kurumsal analitik projelerinde Azure Synapse Analytics genellikle tek bir hizmet olarak değil, bir platform olarak konumlanır: veri gölü, ayrılmış ve sunucusuz SQL motorları, Spark havuzları, veri hatları ve bunların tamamını çevreleyen kimlik ve ağ yapılandırması. Bu bütünlük, workspace adını sıradan bir etiket olmaktan çıkarır. Bağlantı dizeleri, veri hattı tanımları, bağlı hizmetler, izleme sorguları ve dokümantasyon o ada bağlanır.
Bu nedenle üretim geçişlerinde sık rastlanan bir tercih vardır: ortamı yeniden kurarken aynı adı kullanmak. Onlarca bağlantı dizesini güncellemek yerine yeni ortamı eski adla ayağa kaldırmak, geçiş penceresini belirgin biçimde kısaltır. Aşağıda anlatılan vaka, bu tercihin beklenmedik bir yerde takıldığı bir üretim geçişini konu alıyor. Kurum, ortam ve abonelik bilgileri anonimleştirildi; teknik akış korundu.
Olayın Başlangıcı: Silme Başarılı, Oluşturma Reddedildi
Planlı geçişin ilk adımı mevcut workspace’in silinmesiydi. Silme işlemi hatasız tamamlandı, portal kaynağı listeden düşürdü ve ekip bir sonraki adıma geçti: aynı adla yeni workspace oluşturmak.
Oluşturma isteği reddedildi. Hata, adın halihazırda kullanımda olduğunu söylüyordu. İlk refleks beklemek oldu; asenkron temizliklerin tamamlanması için birkaç saat tanındı. Sonuç değişmedi. Ertesi gün tekrar denendiğinde de aynı yanıt geldi.
Bu noktada durum sıradan bir gecikme olmaktan çıktı. Silinen bir kaynağın adı, kaynağın kendisi ortada görünmezken kullanımda görünüyordu ve bu durum saatler değil günler boyunca sürüyordu. Geçiş penceresi ise daralıyordu.
Alternatif basit görünüyordu: farklı bir ad seçmek. Ancak bu tercihin bedeli, geçişin kendisinden büyüktü. Workspace adı yalnızca portalda görünen bir etiket değildi; bağlı hizmet tanımlarında, veri hattı parametrelerinde, dış sistemlerin bağlantı dizelerinde, izleme sorgularında ve operasyon dokümanlarında yer alıyordu. Bunların tamamını değiştirmek, test etmek ve onaylatmak planlanan bakım penceresine sığmıyordu. Dolayısıyla ismin geri kazanılması teknik bir tercih değil, takvimsel bir zorunluluk haline geldi.
İlk Araştırma: Kaynak Yok, İsim Dolu
Teşhisin ilk aşaması, ismi gerçekten tutan bir kaynağın var olup olmadığını kanıtlamaktı. Sırasıyla şunlar kontrol edildi: abonelik ve kaynak grubu düzeyinde ARM kayıtları, kiracı genelinde Resource Graph sorguları, hedef bölgedeki Synapse kaynakları ve workspace’in yönetilen kaynak grubunun varlığı.
Hiçbiri sonuç vermedi. Adı taşıyan aktif bir kaynak yoktu. Buna karşılık ARM’ın isim uygunluk uç noktası net bir yanıt veriyordu: ad kullanılamaz, gerekçe olarak da zaten var olduğu belirtiliyordu.
az rest --method post \
--url "https://management.azure.com/subscriptions/<ABONELIK>/providers/\
Microsoft.Synapse/checkNameAvailability?api-version=2021-06-01" \
--headers "Content-Type=application/json" \
--body '{"name":"<WORKSPACE-ADI>","type":"Microsoft.Synapse/workspaces"}'Bu uç noktanın kritik bir özelliği var: abonelik bağlamında çağrılsa da aslında küresel bir kayıt defterini sorgular. Synapse workspace adları abonelik ya da kiracı düzeyinde değil, tüm Azure genelinde benzersizdir; çünkü ad doğrudan bir DNS etiketine dönüşür. Bir workspace ayağa kalktığında adı üç ayrı uç noktada belirir: SQL uç noktası, geliştirme uç noktası ve sunucusuz havuz uç noktası. Dolayısıyla isim, kaynağın bir özelliği değil, küresel ad alanında tutulan ayrı bir kayıttır.
Bu ayrım vakanın anahtarıydı. Kaynağın silinmiş olması, adın serbest bırakıldığı anlamına gelmiyordu.
Yanlış İz: Soft-Delete Sanılan Şey
Bu aşamada ilk hipotez soft-delete oldu. Azure’da birçok hizmet silinen kaynağı bir süre geri alınabilir durumda tutar ve bu sırada adı rezerve eder. Anahtar kasaları, makine öğrenmesi çalışma alanları ve bazı yapılandırma hizmetleri bu davranışı sergiler.
Ancak Synapse için bu hipotez yanlıştır ve bunu netleştirmek gerekir: Synapse workspace’lerinde belgelenmiş bir soft-delete mekanizması yoktur. Silinen bir workspace geri alınamaz; ayrılmış SQL havuzları, Spark havuzları, bağlı hizmetler ve veri hatları kalıcı olarak gider. Sık karşılaşılan “soft-deleted workspace” ifadesi aslında Azure Machine Learning’e aittir ve Synapse ile karıştırılır.
Geriye daha az bilinen bir mekanizma kalıyordu. Synapse workspace’i kendi başına duran bir kaynak değil; arkasında bir yönetilen kaynak grubu ve bir mantıksal SQL sunucusu çalışır. Bunları workspace adına yöneten şey, birinci taraf bir hizmet sorumlusudur. Eğer bu sorumlunun abonelik düzeyinde ilgili SQL yetkisi yoksa, silme işlemi üst kaynağı kaldırırken alt kayıtları temizleyemez. Portal başarı döner, arkada artık kalır.
Destek Sürecinin Başlaması
Üretim geçişi durduğu ve alternatif bir ad kullanmak onlarca bağlantı dizesinin değiştirilmesi anlamına geldiği için destek talebi en yüksek önem derecesiyle açıldı. Bu noktada süreç, teknik bir sorundan operasyonel bir koordinasyon sorununa dönüştü.
En yüksek önem derecesindeki talepler zaman dilimleri arasında devredilerek kesintisiz ilerler. Vaka EMEA’da açıldı, mesai bitiminde ABD ekibine, oradan APAC ekibine devredildi. Bu model hız kazandırır ama bir bedeli vardır: her devirde bağlam yeniden aktarılır ve eksik aktarılan her ayrıntı bir tur kaybettirir.
Bu bedeli azaltan tek şey, kanıtın tek bir yerde ve değişmez biçimde toplanmasıdır. Vakada şunlar biriktirildi: oluşturma isteğinin ham hata gövdesi ve ilişkilendirme kimliği, isim uygunluk çağrısının tam yanıtı, adı taşıyan kaynak bulunmadığını gösteren Resource Graph çıktıları, silme işleminin etkinlik günlüğü kayıtları ve denenen adımların zaman damgalı listesi. Her devirde aynı dosya paylaşıldı.
Uygulanan Teknik Adımlar
Destek ekibiyle birlikte yürütülen adımlar, en olası nedenden en az olasıya doğru ilerledi.
Önce arkada kalmış olabilecek mantıksal SQL sunucusu kaydı arandı ve abonelikte adı taşıyan artık kayıtlar tespit edildi. Ardından bu kayıtların düzgün biçimde kaldırılabilmesi için gereken yetkilendirme tamamlandı.
Bu adım, benzer durumlarda sık atlanan bir noktaya dokunuyor. Synapse’in birinci taraf hizmet sorumlusu, workspace adına yönetilen kaynak grubunu ve mantıksal SQL sunucusunu yönetir. Bu sorumlunun abonelik düzeyinde SQL sunucusu yetkisi yoksa silme işlemi üst kaynağı kaldırır ama alt kayıtları temizleyemez. Belgelenen yaklaşım üç adımlıdır: sorumluya abonelik kapsamında geçici olarak ilgili rol atanır, silme veya temizlik işlemi tamamlanır, ardından rol geri alınır. Son adım önemlidir; aksi halde abonelikte kalıcı ve gereksiz bir yükseltilmiş yetki bırakılmış olur.
Aynı kontrol yönetilen kaynak grubu için de yapıldı. Bu grup workspace adını taşıyan bir adlandırma kuralıyla oluşturulur ve silme sonrasında geride kalması mümkündür; kaldığı durumda elle silinmesi gerekir.
Her adımdan sonra isim uygunluk uç noktası yeniden çağrıldı. Bu, sürecin en önemli disiplinlerinden biriydi: portalda kaynak görünmemesi bir kanıt değildir, ismin serbest kaldığını yalnızca bu uç nokta söyler.
Beklenmeyen Durum: Yetim Rezervasyon
Artıkların temizlenmesi sorunu çözmedi. Abonelikte adı taşıyan hiçbir kayıt kalmamıştı, yönetilen kaynak grubu yoktu, mantıksal sunucu kaydı silinmişti. Buna rağmen isim uygunluk çağrısı aynı yanıtı vermeye devam etti.
Ortaya çıkan tablo şuydu: adı tutan şey artık bir kaynak değildi. Küresel ad alanındaki rezervasyon kaydı, kendisini yaratan kaynaklardan bağımsız hale gelmişti. Müşteri tarafından erişilebilen hiçbir arayüz bu kaydı görmüyor, hiçbir komut onu silemiyordu. Abonelik sahibinin yetkisi bu katmana ulaşmıyordu.
Bu tür kayıtlar için kullanılan tanım yetim rezervasyondur: ilgili kaynak yaşam döngüsü tamamlanmış, ancak ad kaydı geride kalmıştır. Çözümü müşteri tarafında değildir.
Son Çözüm: Ürün Grubu Müdahalesi
Vaka, destek mühendisliğinin ötesine, hizmetin ürün grubuna yükseltildi. Bu seviyeye çıkan talepler için belirleyici olan şey aciliyet dili değil, kanıtın eksiksizliğidir. Ürün grubu meta veri katmanında inceleme yaparken müşteri tarafından sağlanan zaman damgaları, ilişkilendirme kimlikleri ve isim uygunluk yanıtlarının geçmişi doğrudan kullanılır.
İnceleme, adın küresel kayıt defterinde karşılığı olmayan bir rezervasyon tarafından tutulduğunu doğruladı. Kayıt ürün grubu tarafından temizlendi ve isim uygunluk çağrısı ilk kez olumlu yanıt döndürdü. Yeni workspace aynı adla oluşturuldu, bağlantı dizeleri değiştirilmeden geçiş tamamlandı.
Sürecin toplam süresi, teknik müdahalenin kendisinden çok koordinasyona harcandı. Asıl temizlik işlemi kısa sürdü; ona ulaşmak günler aldı.
Teknik Çıkarımlar
Vakadan çıkan en önemli sonuç, silme işleminin atomik olmadığıdır. Bir workspace silindiğinde farklı bileşenler farklı davranır ve bunu bilmeden yapılan geçiş planları kırılgandır.
| Bileşen | Silme sonrası davranışı |
|---|---|
| Workspace kaydı | Kalıcı olarak silinir, geri alınamaz. Soft-delete yoktur. |
| Ayrılmış SQL havuzu | Düşürülürken son anlık görüntü alınır ve yedi gün saklanır. |
| Sunucusuz SQL | Yedekleme ve geri yükleme yoktur. |
| Veri gölü içeriği | Depolama hesabı ayrı kaynaktır, silinmez; yeni workspace’e bağlanabilir. |
| Veri hatları, not defterleri | Git entegrasyonu veya şablon yedeği yoksa kurtarılamaz. |
| Yönetilen kaynak grubu | Geride kalabilir, elle silinmesi gerekebilir. |
| Workspace adı | Küresel bir DNS etiketidir; kaynak gitse de rezerve kalabilir. |
Buradan doğrudan bir isimlendirme stratejisi çıkıyor. Ada sürüm veya dönem eki eklemek, yeniden kullanım ihtiyacını baştan ortadan kaldırır. Bağlantı dizelerini workspace adına sabitlemek yerine yapılandırma servisi üzerinden yönetmek, adın değişmesini üç dakikalık bir işe indirir. Bu iki alışkanlık, anlatılan vakanın tekrarını imkânsız kılmaz ama etkisini önemsizleştirir.
Üretim Geçişleri İçin Kontrol Listesi
Silme kararı verilmeden önce yapılması gerekenler, en ucuzdan en pahalıya doğru:
- Adı yeniden kullanacak mısınız, netleştirin. Kullanmayacaksanız bu vakanın tamamı sizi ilgilendirmez; kullanacaksanız aşağıdakiler zorunludur.
- Artifact’ları dışarı alın. Veri hatları ve not defterleri yalnızca Git entegrasyonu veya şablon dışa aktarımıyla kurtarılabilir.
- Ayrılmış havuzların yedi günlük penceresini takvime yazın. Geri dönüş ihtimali varsa pencere kapanmadan karar verin.
- Silmeden önce isim uygunluk çağrısını kaydedin. Silme sonrası karşılaştırma yapabilmek için başlangıç durumu elinizde olsun.
- Silme sonrası artıkları doğrulayın. Yönetilen kaynak grubu ve mantıksal sunucu kaydı gitti mi, ayrıca bakın.
- Yeniden oluşturmayı hemen denemeyin, önce ismi sorgulayın. Uygunluk uç noktası olumsuz dönerse portal denemesi zaman kaybıdır.
- Alternatif ad planını hazır tutun. Geçiş penceresi dar ise, ikinci bir ada geçmenin maliyetini önceden hesaplayın.
Öğrenilen Dersler
- Silinen kaynak, tamamen silinmiş demek değildir. Portalda görünmemek bir kanıt değil, yalnızca bir görüntüdür.
- Azure hizmetleri arasında görünmeyen bağımlılıklar vardır. Synapse’in arkasındaki mantıksal sunucu ve yönetilen kaynak grubu, ayrı yaşam döngülerine sahiptir.
- İsimler kaynaklardan bağımsız yaşayabilir. Küresel ad alanındaki kayıt, kaynak silindikten sonra da varlığını sürdürebilir.
- Soft-delete her hizmette yoktur. Synapse’te bulunmayan bu mekanizmayı varsaymak, teşhisi yanlış yöne çevirir.
- Ürün grubuna giden vakalarda kanıt her şeydir. Aciliyet dili değil, zaman damgalı ve tekrarlanabilir kayıtlar ilerletir.
- Kritik sistemler için ikinci plan zorunludur. Aynı adla kurulum garanti değilse, alternatif ad senaryosu geçiş planında yazılı olmalıdır.
Kaynaklar
Bu yazıdaki mekanizmalar Microsoft’un resmî dokümantasyonuna ve Q&A kayıtlarına dayanıyor; vaka anlatısı anonimleştirilmiştir.
- Check Name Availability — Synapse REST API — İsim uygunluk uç noktasının istek ve yanıt şeması; teşhisin dayandığı çağrı.
- Create a Synapse workspace using Azure CLI — Adın küresel benzersizlik gereksinimi ve oluşturma akışı.
- Restore a dedicated SQL pool from a deleted workspace — Ayrılmış havuzların yedi günlük anlık görüntü penceresi.
20+ yıl deneyimli Azure Solutions Architect. Microsoft sertifikalı bulut mimari ve DevOps danışmanı. Azure, yapay zekâ ve bulut teknolojileri üzerine Türkçe teknik içerikler üretiyor.
Yorum gönder