Veri yerleşimi için çok bölgeli barındırmayı öğrenin: bulut bölgelerini nasıl seçeceğinizi, gecikmeyi nasıl yöneteceğinizi ve denetimler ile müşteri incelemeleri için veri akışlarını nasıl belgeleyeceğinizi.
Veri yerleşimi soruları genellikle basit bir müşteri talebiyle başlar: “Verilerimizi ülkemizde tutabilir misiniz?” Zor kısım, kullanıcıların, yöneticilerin ve destek ekiplerinin global olabilmesidir. Çok bölgeli barındırma, günlük işleri engellemeden yerel depolama gereksinimlerini karşılamanın yoludur.
Bu seçim üç pratik kararı etkiler:
Eğer bunlardan herhangi biri anlaşılmış bölge dışında gerçekleşiyorsa, ana veritabanı “yerel” kalsa bile sınır aşan transfer oluşabilir.
Çok bölgeli kurulumlar uyumluluğa yardımcı olur, ama bedeli vardır. Basitliği kontrol ile takas edersiniz. Maliyetler artar (daha fazla altyapı ve izleme). Karmaşıklık yükselir (replikasyon, failover, bölgeye özel yapılandırma). Performans da etkilenebilir; çünkü istekleri ve işlemleri dünyanın en yakın sunucusu yerine bölge içinde tutmanız gerekebilir.
Yaygın bir örnek: bir AB müşterisi AB’da sadece depolama istiyor, ancak iş gücünün yarısı ABD’de. ABD’deki yöneticiler giriş yapıp dışa aktarma işlemleri yaparsa, bu erişim ve transfer soruları doğurur. Temiz bir kurulum, AB’de neyin kaldığını, neyin uzaktan erişilebileceğini ve hangi korumaların uygulanacağını açıkça belirtir.
Çoğu ekip, şu durumlardan biri ortaya çıktığında barındırma bölgelerini tekrar gözden geçirir:
Veri yerleşimi, verinin “at rest” yani dinlenme halinde nerede saklandığıdır. Veritabanı dosyaları, nesne depolama ve diskte duran yedekler buna dahildir.
İnsanlar sıklıkla yerleşimi, veri erişimi ve veri transferiyle karıştırır. Erişim, veriyi kimin okuyup değiştirebileceğiyle ilgilidir (örneğin başka bir ülkedeki destek mühendisi). Transfer ise verinin nereden geçtiğini anlatır (örneğin sınır aşan bir API çağrısı). Ana veritabanı yerel kalsa bile analiz, izleme veya destek için verinin rutin olarak başka bir bölgeye gönderilmesi transfer kurallarını ihlal edebilir.
İşleme, verilerle ne yaptığınızdır: saklama, indeksleme, arama, eğitim veya rapor üretme. İşleme, depolamadan farklı bir yerde olabilir; bu yüzden uyumluluk ekipleri genellikle her ikisini de ister.
Bu tartışmaları somut yapmak için verinizi birkaç günlük kovaya ayırın: müşteri içeriği (dosyalar, mesajlar, yüklemeler), hesap ve fatura verileri, meta veriler (ID’ler, zaman damgaları, yapılandırma), operasyonel veriler (günlükler ve güvenlik olayları) ve kurtarma verileri (yedekler ve replikalar).
İncelemelerde neredeyse her zaman iki şey sorulur: her bir kovanın nerede saklandığı ve nereye gidebileceği. Müşteriler ayrıca insan erişiminin nasıl kontrol edildiğini de sorabilir.
Pratik bir örnek: ana veritabanınız Almanya’da (saklama) ama hata takibi ABD’de (transfer). Müşteri içeriği Almanya’dan çıkmasa bile günlükler kullanıcı ID’leri veya istek parçacıkları içerebilir. Bu yüzden günlükler ve analizler dokümantasyonda kendi satırlarını hak eder.
Dokümante ederken cevaplamayı hedefleyin:
Açık terimler önceden zaman kazandırır; özellikle müşteriler basit, güvenli bir açıklama istediğinde.
Bölgeleri seçmeden önce hangi veriye sahip olduğunuzu ve verinin yığınınızın nerelerine değdiğini yazın. Bu temel gibi görünür ama “bölgede kaldığını sanıyorduk” sürprizlerini önlemenin en hızlı yoludur.
Yasalardan çok veri türleriyle başlayın. Çoğu ürün karışık veri tutar: müşteri hesap detayları (KİŞİSEL VERİ), ödeme kayıtları (genelde token’lanmış ama hassas), destek konuşmaları ve telemetri (günlükler, olaylar). Türev verileri de dahil edin: raporlar, analiz tabloları, yapay zeka ile üretilen özetler.
Sonra veriyi görebilen veya saklayabilen her sistemi listeleyin. Genelde uygulama sunucuları, veritabanları, yüklemeler için nesne depolama, e-posta ve SMS sağlayıcıları, hata izleme, müşteri destek araçları ve CI/CD veya yönetici konsolları bu listeye girer. Snapshot, yedek veya dışa aktarma kullanıyorsanız bunları ayrı veri depoları olarak ele alın.
Veri yaşam döngüsünü sade bir dille yakalayın: verinin nasıl toplandığı, nerede saklandığı, hangi işlemlere tabi tutulduğu (arama, faturalama, moderasyon), kimlerle paylaşıldığı (tedarikçiler, iç ekipler), ne kadar süreyle tutulduğu ve silmenin gerçekten nasıl işlediği (yedekler dahil).
Envanteri kullanılabilir tutun. Küçük bir kontrol listesi çoğunlukla yeterlidir: veri türü, sistem, bölge (saklama ve işleme), hareketi ne tetikler (kullanıcı işlemi, arka plan işi, destek talebi) ve saklama.
Yerleri seçmeden önce verinin gerçekte nereye gittiğine dair basit bir resme ihtiyacınız var. Bölge planlaması, kişiye açıklayamadığınız bir yol olduğunda yalnızca evrak işinde başarısız olabilir.
Basit dilde bir diyagramla başlayın. Bir sayfa yeterlidir. Bir hikaye gibi yazın: bir kullanıcı giriş yapar, uygulamayı kullanır, veriler saklanır ve destekleyici sistemler neyi kaydettiğini yazar. Ardından her adımı iki şeyle etiketleyin: nerede çalıştığı (bölge veya ülke) ve verinin dinlenme halinde mi (saklanıyor) yoksa transit mi (hareket halinde).
Sadece mutlu yolu çizmekle kalmayın. İnsanları şaşırtan akışlar operasyonel olanlardır: destek mühendisinin ekran görüntüsüyle ticket açması, olay müdahalesinde geçici erişim, veritabanı yedekten geri yükleme veya müşteri için dışa aktarma.
Haritayı dürüst tutmanın hızlı bir yolu şunları kapsamasıdır:
Üçüncü tarafları da ekleyin; önemsiz görünseler bile. Ödeme, e-posta teslimi, analiz ve müşteri destek araçları genellikle tanımlayıcıları işler. Hangi veriyi aldıklarını, nerede işlediklerini ve bölge seçimini yapıp yapamayacağınızı not edin.
Harita netleşince, bölge seçimi tahmin değil eşleştirme olur.
Bulut haritasıyla başlamayın; kuralı sorun. Müşterilerinizin veya düzenleyicinin gerçekte ne istediğini sorun: verinin hangi ülkede (veya ülkeler kümesinde) kalması gerektiği, açıkça yasaklanan yerlerin olup olmadığı ve dar istisnaların (örneğin başka bir ülkeden destek erişimi) kabul edilip edilmediği.
Ana karar sınırın ne kadar sıkı olduğudur. Bazı programlar tek ülke demektir: depolama, yedekler ve yönetici erişimi tek bir ülke içinde kalmalı. Diğerleri daha geniş bir alan (örneğin tanımlanmış bir ekonomik bölge) kabul eder, yeter ki verinin nerede saklandığını ve kimlerin eriştiğini gösterebilesiniz.
Taahhütte bulunmadan önce her aday bölgeyi gerçek kısıtlarla doğrulayın:
Yakınlık önemli ama ikinci planda kalmalı. Performans için kullanıcılara en yakın uygun bölgeyi seçin. Ardından operasyonları süreç ve erişim kontrolleri (rol tabanlı erişim, onaylar, break-glass hesaplar) ile yönetin; veriyi kolayca yönetilebilecek yere taşımak yerine.
Son olarak kararı yazın: izin verilen sınır, seçilen bölgeler, failover planı ve çıkmasına izin verilen (varsa) veriler. O tek sayfa, anketlerde saatler kazandırır.
Gecikme çoğunlukla fiziksel mesafe ve kaç kez veri sorguladığınızla ilgilidir. Mesafe önemli, ama ekstra veritabanı round-trip’leri, ağ yönlendirmesi ve servislerin ölçeklenirken yaşadığı yavaş başlangıçlar da etkilidir.
Değişiklik yapmadan önce ölçün. 3–5 ana kullanıcı eylemi seçin (giriş, pano yükleme, sipariş oluşturma, arama, rapor dışa aktarma). Önemli coğrafyalardan p50 ve p95’i izleyin. Bu değerleri sürümler arasında karşılaştırabileceğiniz bir yerde tutun.
Basit kural: korunan verileri ve onlara dokunan yolları yerel tutun, gerisini küresel dostu yapın. En büyük performans kazanımları genellikle bölge-ötesi sohbeti azaltmaktan gelir.
Almanya’daki bir kullanıcıya ait veriler AB’de kalmalıysa, o kiracı için uygulama sunucusu, birincil veritabanı ve arka plan işleri AB’de olmalı. Her istekte başka bir bölgeye auth ve oturum denetimi göndermekten kaçının. Sayfa başına yapılan fazla veritabanı çağrılarını azaltın.
Cache yardımcı olur, ama nerede tutulduğuna dikkat edin. Genel veya hassas olmayan içeriği küresel olarak cacheleyin. Kiracıya özel veya düzenlenen verileri izinli bölge içinde tutun. Toplu işlemler de yardımcı olabilir: onlarca küçük bölge-ötesi istek yerine bir zamanlanmış güncelleme genelde daha iyidir.
Her şey aynı hızda olmak zorunda değil. Giriş ve temel kaydetme eylemlerini “anında hissetmelik” olarak ele alın. Raporlar, dışa aktarmalar ve analizler daha yavaş olabilir; bunu beklentiye bağlayın.
Statik varlıklar genellikle en kolay kazançtır. JavaScript paketleri ve resimleri kullanıcıya yakın sunun; API’leri ve kişisel verileri ise yerleşim bölgesinde tutun.
En güvenli başlangıç, müşteri verisini net şekilde bir bölgeye bağlayan, aynı zamanda arızadan kurtarma için yol veren bir tasarımdır.
Active-passive genelde denetçilere ve müşterilere açıklaması daha kolaydır. Bir kiracı için bir bölge birincildir; ikincil bölge sadece failover veya sıkı kontrol edilen felaket kurtarma sırasında kullanılır.
Active-active kesinti süresini azaltıp yerel hızı artırabilir ama şu zorlu soruları gündeme getirir: hangi bölge gerçeğin kaynağıdır, nasıl sapma önlenir ve replikasyon kendisi transfer sayılır mı?
Pratik seçim yolu:
Veritabanları için kiracı bazlı bölgesel veritabanları en anlaşılır olandır: her kiracının verisi bölgesel bir Postgres örneğinde yaşar ve çapraz-kiracı sorgularını zorlaştıracak kontroller vardır.
Çok sayıda küçük kiracınız varsa partition’lar işe yarayabilir, ama partition’ların kesinlikle bölgeden çıkmayacağını ve araçlarınızın kazara bölge-ötesi sorgular çalıştırmayacağını garanti edebilmelisiniz. Kiracı veya coğrafya bazlı sharding genelde uygulanabilir bir orta yol sunar.
Yedekleme ve felaket kurtarma için açık bir kural gerekir. Yedekler bölgede kalırsa geri yüklemeleri gerekçelendirmek daha kolaydır. Yedekleri başka bir bölgeye kopyalarsanız, yasal dayanak, şifreleme, anahtarın yeri ve kimlerin geri yükleme tetikleyebileceğini belgelemeniz gerekir.
Günlükler ve gözlemlenebilirlik, kazara transferlerin gerçekleştiği yerdir. Metrikler genelde toplu ve düşük riskliyse merkezileştirilebilir. Ham günlükler, izler ve hata yükleri kişisel veri içerebileceğinden bölgesel tutulmalı ya da agresif şekilde maskeleme yapılmalıdır.
Çok bölgeli geçişi altyapar arka planda yapılan bir değişiklik gibi değil, bir ürün yayını gibi ele alın. Yazılı kararlar, küçük bir pilot ve incelemede gösterebileceğiniz kanıtlar isteyeceksiniz.
Uymanız gereken kuralları yakalayın: izin verilen konumlar, kapsamdaki veri türleri ve “iyi”nin ne olduğu. Kabul kriterlerini de ekleyin: kabul edilebilir gecikme, kurtarma hedefleri ve hangi durumların onaylı sınır aşması sayıldığı.
Her müşterinin nasıl bir bölgeye yerleştirileceğine ve bu seçimin nasıl uygulanacağına karar verin. Basit tutun: yeni kiracılara bir varsayılan, mevcut kiracılara açık atama ve istisnalar için onay gereksinimi. Yönlendirme uygulama trafiği, arka plan işleri ve yedeklerin/logların nereye düştüğünü kapsamalı.
Her bölge için tam yığını ayağa kaldırın: uygulama, veritabanı, sırlar, izleme ve yedekler. Ardından bir pilot kiracıyı geçmiş verileriyle birlikte uçtan uca taşıyın. Geri dönebilmek için taşıma öncesi bir snapshot alın.
Gerçek kullanımı taklit eden testler çalıştırın ve sonuçları saklayın:
Kiracıları küçük gruplarla taşıyın, değişiklik günlüğü tutun ve hata oranlarını ile destek hacmini izleyin. Her taşıma için önceden onaylanmış bir geri alma tetikleyicisi (örneğin 15 dakika boyunca yükselen hatalar) ve önceki bölgeye dönmeyi pratik hale getiren bir yolunuz olsun.
İyi bir barındırma tasarımı bile bunu açıkça açıklayamadığınızda uyumluluk incelemesinde başarısız olabilir. Dokümantasyonu sistemin bir parçası gibi değerlendirin: kısa, doğru ve güncel tutması kolay.
Bir sayfalık özetle başlayın; teknik olmayan bir inceleyicinin hızlıca okuyabileceği şekilde. Hangi verinin bölgede kalması gerektiğini, nelerin çıkabileceğini ve nedenini (faturalama, e-posta teslimi, tehdit algılama vb.) söyleyin. Varsayılan duruşunuzu sade dille belirtin: müşteri içeriği bölge içinde tutulur, açıkça belgelenmiş istisna olmadıkça.
Ardından iki destekleyici belgeyi güncel tutun:
Yedekler ve geri yüklemeler (yedeklerin nerede tutulduğu, saklama, kimlerin geri yükleme başlatabileceği) ile olay/destek erişim süreci (onaylar, kayıt, zaman sınırlı erişim, gerekiyorsa müşteri bilgilendirmesi) konularında kısa bir operasyon notu ekleyin.
İfadeyi müşteri hazır hale getirin. Güçlü bir kalıp: “X’te saklanır, Y’de işlenir, Z ile transferler kontrol edilir.” Örnek: “Kullanıcı tarafından oluşturulan içerik AB bölgesinde saklanır. Destek erişimi bilet onayı gerektirir ve kayıt altına alınır. Toplu metrikler AB dışında işlenebilir ancak müşteri içeriği içermez.”
Kanıtları dokümanlara yakın tutun. Bölge yapılandırma ekran görüntüleri, ana ortam ayarları ve erişim onaylarını ve bölge-ötesi trafik kontrollerini gösteren küçük bir denetim günlüğü dışa aktarısı saklayın.
Çoğu sorun ana veritabanı ile ilgili değildir. Etrafındaki ekstralarda çıkar: gözlemlenebilirlik, yedekler ve insan erişimi. Bu boşluklar müşterilerin ve denetçilerin önce sordukları şeylerdir.
Yaygın bir tuzak, günlükleri, metrikleri ve izleri zararsız sayıp bunları varsayılan küresel bölgeye göndermektir. Bu kayıtlar çoğunlukla kullanıcı ID’leri, IP adresleri, istek parçacıkları veya destek notları içerir. Uygulama verisi ülke içinde kalmalıysa, gözlemlenebilirlik verileri için de aynı kuralı uygulayın veya agresif şekilde maskeleyin.
Bir diğer sık unutulan alan yedekler ve felaket kurtarma kopyalarıdır. Ekipler üretimin nerede çalıştığına bakarak yerleşimi iddia edip snapshot, replikalar ve geri yükleme testlerini unutabilir. Eğer bir EU birinciliğiniz ve “acil durum” için ABD yedeğiniz varsa, transfer yaratmışsınız demektir. Yedek lokasyonları, saklama süreleri ve geri yükleme süreçlerinin verdiğiniz sözle eşleştiğinden emin olun.
Erişim bir diğer zayıf nokta. Küresel admin hesapları sıkı kontroller olmadan uygulamada yerleşimi pratikte bozabilir. En az ayrıcalıklı rolleri kullanın, mümkünse bölgeye özgü erişim uygulayın ve kimlerin nereden eriştiğini gösteren denetim izlerini saklayın.
Diğer sık karşılaşılan eksiklikler: farklı yerleşim ihtiyaçları olan kiracıları aynı veritabanı veya arama indeksinde karıştırmak, operasyonel olarak yönetmeden önce active-active tasarımlarını fazla karmaşık hale getirmek ve “çok bölgeli”yi slogan olarak ele almak yerine zorunlu kurallar haline getirmemek.
Kurulumu “tamamlandı” diye adlandırmadan önce hem uyumluluk hem de gerçek dünya performansını kapsayan hızlı bir gözden geçirme yapın. İki soruyu güvenle yanıtlayabilmek istiyorsunuz: düzenlenen veri nerede yaşıyor ve bir şey kırıldığında ne oluyor?
Her kararın envanter ve veri akış haritasına bağlı olduğundan emin olun:
Eğer “destek üretim verisini hiç görüntüler mi, nereden?” sorusunu cevaplayamıyorsanız, müşteri anketine hazır değilsiniz demektir. Destek erişim sürecini (roller, onay, zaman limitleri, kayıt) yazın ki tekrarlanabilir olsun.
Bir müşteri profili seçin ve geniş dağıtımdan önce küçük bir pilot çalıştırın. Ortak ve yerleşim kuralları net bir profil (örneğin “AB müşterisi, AB-only depolama”) iyi seçimdir. Daha sonra tekrar kullanılabilir kanıtlar toplayın: bölge ayarları, erişim günlükleri ve failover test sonuçları.
Daha hızlı denemeler ve bölge seçimleri için Koder.ai (koder.ai) gibi araçlar faydalı olabilir; sohbetten uygulama inşa edip dağıtma, kaynak kodu dışa aktarma ve snapshot/geri alma gibi özellikler, bölge değişikliklerini test ederken ve hızlı kurtarma gerektiğinde işe yarar.
Veri yerleşimi, verinin dinlenme halinde olduğu yerdir (veritabanları, nesne depolama, yedekler). Veri transferi, verinin transit halinde sınır aşmasıdır (API çağrıları, replikasyon, dışa aktarmalar). Veri erişimi ise veriyi kimlerin nereden görüntüleyip değiştirebileceği ile ilgilidir.
Yerleşimi sağlarken yine de transferler veya erişim endişeleri yaratabilirsiniz (örneğin, günlükleri başka bir bölgeye göndermek veya destek personelinin başka bir ülkeden veri görüntülemesi).
Önce tek bir “varsayılan bölge içinde” kurulumla başlayın ve yalnızca net bir gereksinim (sözleşme, düzenleyici kural, kamu sektörü gereksinimi veya satamayacağınız bir müşteri segmenti) ortaya çıkınca yeni bölgeler ekleyin.
Çok bölgeli yapı maliyet ve operasyonel iş yükü getirir (replikasyon, izleme, olay yönetimi), bu yüzden genellikle gelire veya kesin bir uyumluluk ihtiyacına bağlandığında uygulanmalıdır.
Bunu bir tahmin işi değil envanter işi olarak ele alın. Veri kovalarını listeleyip her birinin nerede saklandığını ve işlendiğini belirleyin:
Ardından bu kovalara dokunan tüm sistemleri (uygulama sunucuları, arka plan işleri, analiz, izleme, e-posta/SMS, destek araçları) kontrol edin.
Günlükler, kullanıcı ID’leri, IP adresleri ve istek parçacıkları içerebildiğinden yerleşim kurallarını kazara ihlal eden yaygın bir kaynaktır.
İyi varsayılanlar:
Erişim kurallarını açık hale getirin ve zorlayın:
Ayrıca uzak ülkelerden erişimin izinli olup olmadığını ve hangi güvencelerle olacağını önceden belirleyin.
Yedekler ve felaket kurtarma yerleşim taahhüdünün bir parçasıdır. Onaylanmış bölgenin dışında yedek tutuluyorsa transfer oluşur.
Pratik yaklaşım:
Active-passive genelde en basitidir: kiracı başına birincil bölge ve sadece felaket kurtarma/denetimli durumlarda kullanılan ikincil bölge.
Active-active daha yüksek erişilebilirlik ve yerel performans sağlar ama çatışma yönetimi, tutarlılık ve replikasyonun transfer sayılıp sayılmayacağı gibi karmaşıklıkları getirir. Yerleşim sınırları sıkıysa önce active-passive ile başlayın.
Duyarlı yolları yerel tutun ve bölge-ötesi etkileşimi azaltın:
İşinizi bir ürün yayını gibi ele alın:
Kısa ve somut tutun. Çoğu inceleme şu soruların net yanıtını ister:
Bir sayfalık özet, basit bir veri akış haritası ve sistem tablosu genellikle yeterlidir.
