Merhaba! Önceki dersimizde, buluta geçişin arkasındaki "nedenleri" inceledik ve sermaye giderlerinden (CapEx) operasyon giderlerine (OpEx) geçiş, ölçeklenebilirlik ve yönetilen hizmetlerin iş dünyasına kattığı değeri ele aldık. Artık bulutun stratejik avantajlarını bildiğinize göre, bu dersimizde Google'ın bu vaatleri nasıl yerine getirdiğine, yani altyapının "nerede" ve "nasıl" çalıştığına odaklanacağız.
Bu dersin sonunda, bir danışman olarak müşterilerinize çözüm tasarlarken en temel kararları vermenizi sağlayacak olan Google Cloud region (bölge), zone (alan) ve point of presence (varlık noktası) bileşenlerini, kullanılabilirlik (availability) ve gecikme (latency) gibi kritik faktörler açısından ayırt edebileceksiniz. Sistem mühendisliği geçmişinizden fiziksel veri merkezleri, felaket kurtarma (disaster recovery) sahaları ve coğrafi yedeklilik kavramlarına aşinasınız. Şimdi bu tecrübenizi, Google'ın küresel ölçekte sunduğu modern ve yazılım tanımlı altyapı yaklaşımıyla birleştireceğiz.
Küresel Bir Altyapı: Google'ın Dünyaya Yayılımı
Bulut bilişimin en büyük gücü, küresel ölçekte olmasıdır. Google, dünyanın dört bir yanını birbirine bağlayan devasa bir özel ağa sahiptir. Bu ağ, kıtaları birbirine bağlayan denizaltı fiber kabloları, veri merkezleri ve ağ uç noktalarından oluşur. Bu küresel yapı, uygulamalarınızı kullanıcılarınıza coğrafi olarak en yakın yerden sunmanıza ve aynı zamanda yüksek düzeyde dayanıklılık (resilience) sağlamanıza olanak tanır.
Aşağıdaki harita, Google'ın küresel ağının ve yatırımlarının boyutunu gözler önüne seriyor. Yeşil hatlar Google'ın sahip olduğu denizaltı kablo yatırımlarını, mavi hatlar ise mevcut ağ bağlantılarını göstermektedir.
Bu devasa altyapı, belirli bir hiyerarşiye göre düzenlenmiştir. En üstte kıtaları kapsayan Multi-Region yapılar, onların altında şehirleri veya ülkeleri temsil eden Region'lar ve en temel yapı taşı olarak da Zone'lar bulunur.
Şimdi bu hiyerarşinin her bir katmanını daha detaylı inceleyelim.
Region, Zone ve Edge Location: Temel Farklılıklar
Bu üç kavram, bulut coğrafyasının farklı ölçeklerini tanımlar. Danışmanlık yaparken bu terimleri doğru kullanmak, tasarlayacağınız mimarinin doğruluğu için kritik öneme sahiptir. Aşağıdaki İngilizce kaynak, bu üç kavramı çok net bir şekilde tanımlıyor ve aralarındaki farkları açıklıyor.
Cloud Regions and Availability Zones Explained (2026)
Bu kaynağın giriş bölümü, Region, Availability Zone ve Edge Location kavramlarının temel tanımlarını yapıyor. Bu tanımları okurken her birinin temel amacına odaklanın:
"Region vs availability zone vs edge location" başlığı altındaki Region tanımını, Availability Zone tanımını ve Edge Location (Point of Presence) tanımını dikkatle okuyun. Yazının sunduğu "şehir, bina ve teslimat dolabı" analojisi, bu üç kavramı aklınızda tutmanıza yardımcı olacaktır.
Okuduğunuz gibi, temel ayrım şu şekildedir:
-
Region (Bölge): Uygulamanızı ve verilerinizi barındıracağınız ana coğrafi konumdur. Örneğin,
europe-west3(Frankfurt) veyaus-east1(Güney Karolina) birer region'dır. Region seçimi, kullanıcılara olan gecikmeyi (latency) ve yasal uyumluluk/veri yerleşimi (data residency) gereksinimlerini doğrudan etkiler. Bölgeler birbirinden tamamen izole edilmiştir; bir bölgedeki sorun diğerini etkilemez. -
Zone (Alan): Bir region içindeki, birbirinden izole edilmiş bir veya daha fazla veri merkezinden oluşan bir dağıtım alanıdır. Örneğin,
europe-west3-a,europe-west3-bveeurope-west3-c, Frankfurt region'ı içindeki üç farklı zone'dur. Zone'ların temel amacı yüksek kullanılabilirlik (high availability) sağlamaktır. Bir uygulamayı birden fazla zone'a yayarak, bir veri merkezinin tamamını etkileyen bir elektrik kesintisi veya sel gibi felaketlerden korunmuş olursunuz. Her bir zone, bir "failure domain" (hata etki alanı) olarak kabul edilir. Sistem mühendisliği tecrübenizdeki birincil veri merkezi ve felaket kurtarma merkezi (DR site) kurulumuna benzetebilirsiniz; ancak burada iki site de aktif olarak çalışır ve aralarında çok yüksek hızlı, düşük gecikmeli bir ağ bağlantısı bulunur. -
Point of Presence (PoP) / Edge Location: Uygulamanızın çalıştığı yer değil, içeriğinizin (örneğin videolar, resimler) kullanıcılara daha hızlı ulaştırılması için önbelleğe alındığı (caching) küçük ağ konumlarıdır. Temel amacı, son kullanıcıya olan gecikmeyi (latency) en aza indirmektir. Bir kullanıcı Türkiye'den web sitenize bağlandığında, içeriği Frankfurt'taki sunucudan çekmek yerine, Türkiye'ye en yakın PoP'tan alır.
Uygulama Dayanıklılığı: Zonal, Regional ve Multi-Regional Mimariler
Region ve Zone kavramlarını anladıktan sonra, bir sonraki önemli adım, kaynaklarınızı bu coğrafi yapılarda nasıl dağıtacağınızı seçmektir. Bu seçim, uygulamanızın bir kesinti durumunda ne kadar dayanıklı olacağını belirler. Google Cloud'un resmi dokümanları, kaynakların bu coğrafi dağılımını çok güzel özetler.
Geography and regions | Get started
Google Cloud'un resmi dokümantasyonu olan bu kaynak, region ve zone kavramlarını Google'ın kendi perspektifinden açıklıyor. Ayrıca, kaynakların bu coğrafyada nasıl sınıflandırıldığını (zonal, regional, multi-regional) anlatıyor.
Lütfen "Regions and zones" başlığı altındaki temel tanımları gözden geçirin. Ardından, asıl önemli olan "Zonal resources", "Regional resources" ve "Multi-regional resources" başlıkları altındaki üç kaynak türünün açıklamalarını dikkatle okuyun. Her birinin hangi tür kesintilere karşı dayanıklı olduğuna odaklanın.
Bu kaynaklardan edindiğimiz bilgilerle, bir uygulamanın dayanıklılık seviyelerini şöyle özetleyebiliriz:
| Mimari Türü | Anlamı | Neye Karşı Korur? | Örnek Google Cloud Hizmeti |
|---|---|---|---|
| Zonal | Kaynak, tek bir zone içinde çalışır. | Donanım arızası | Compute Engine VM (varsayılan) |
| Regional | Kaynak, bir region içindeki birden çok zone'a otomatik olarak dağıtılır. | Tek bir zone'un kaybı | Cloud SQL (High Availability) |
| Multi-Regional | Kaynak, birden çok region'a otomatik olarak dağıtılır. | Tek bir region'ın tamamen kaybı | Cloud Storage, Spanner |
Bir danışman olarak, müşterinizin ihtiyacına göre doğru dayanıklılık seviyesini seçmek sizin göreviniz olacaktır. Çok kritik olmayan bir geliştirme sunucusu için zonal bir VM yeterliyken, bir e-ticaret sitesinin veritabanı mutlaka regional olmalıdır. Küresel bir uygulamanın kullanıcı verilerini tutan bir depolama çözümü ise multi-regional olabilir.
Google'ın bu farklı coğrafi yapılardaki hizmetleri yüksek performansla nasıl çalıştırdığını daha iyi anlamak için aşağıdaki kısa videoyu izleyebilirsiniz. Video, Google'ın devasa özel ağının, veri merkezleri arasındaki iletişimi nasıl sağladığını ve GKE, Spanner gibi hizmetlerin bu altyapıdan nasıl güç aldığını gösteriyor.
How does networking work across Google’s data centers?
Bu video, Google'ın veri merkezleri arasındaki ağ altyapısının nasıl çalıştığına dair hızlı bir genel bakış sunuyor.
Lütfen videonun tamamını izleyin. Özellikle ağın yedekliliğinin nasıl sağlandığına ve farklı hizmetlerin bu küresel altyapıyı nasıl kullandığına dikkat edin.
Bir Danışman Gözüyle: Region Nasıl Seçilir?
Müşteriniz için bir çözüm tasarlarken, kaynaklarınızı hangi region'da barındıracağınıza karar vermek ilk adımlardan biridir. Bu karar, rastgele verilmemelidir. Aşağıdaki kontrol listesi, bu seçimi yaparken size yol gösterecektir.
Cloud Regions and Availability Zones Explained (2026)
Bu kaynak, bir bulut projesi için doğru region'ı seçerken göz önünde bulundurmanız gereken faktörleri pratik bir kontrol listesi halinde sunuyor.
Lütfen "Data residency, data sovereignty and GDPR" başlığı altındaki uyumlulukla ilgili bölümü okuyun. Ardından "How to choose a region" başlığı altındaki dört maddelik kontrol listesini dikkatle inceleyin.
Özetle, bir region seçerken şu adımları izlemelisiniz:
- Uyumluluk ve Veri Yerleşimi (Compliance and Residency): İlk ve en önemli adım budur. Müşterinizin verileri, GDPR (Avrupa Birliği) veya KVKK (Türkiye) gibi yasal düzenlemeler gereği belirli bir coğrafi sınır içinde kalmak zorunda mı? Eğer öyleyse, bu kısıtlama seçeneklerinizi belirleyecektir.
- Kullanıcılara Olan Gecikme (Latency to Users): Uyumluluk gereksinimlerini karşılayan bölgeler arasından, müşterinizin hedef kitlesine coğrafi olarak en yakın olanı seçin. Türkiye'deki kullanıcıları hedefliyorsanız, Frankfurt veya Varşova gibi Avrupa bölgeleri, ABD'deki bir bölgeden daha düşük gecikme süresi sunacaktır.
- Hizmet Kullanılabilirliği (Service Availability): Her Google Cloud hizmeti veya özelliği her bölgede aynı anda kullanıma sunulmayabilir. İhtiyaç duyduğunuz spesifik hizmetlerin (örneğin belirli bir GPU modeli veya yeni bir veritabanı hizmeti) seçtiğiniz bölgede mevcut olduğunu doğrulayın.
- Maliyet (Cost): Aynı hizmetin fiyatı bölgeden bölgeye farklılık gösterebilir. Diğer üç kriteri karşıladıktan sonra, maliyet bir eşitlik bozucu faktör olabilir. Ancak genellikle maliyet, uyumluluk ve gecikmenin önüne geçmemelidir.
Özet ve Sonraki Adımlar
Bu dersimizde Google Cloud'un fiziksel altyapısının temel taşlarını ve bunların birbiriyle olan ilişkisini inceledik.
Anahtar Çıkarımlar:
- Region, ana coğrafi konumdur ve seçimini gecikme ile uyumluluk belirler.
- Zone, bir region içindeki izole bir hata etki alanıdır ve amacı yüksek kullanılabilirlik sağlamaktır.
- Point of Presence (PoP), içeriği kullanıcılara yaklaştırarak gecikmeyi azaltan bir önbellekleme noktasıdır; uygulama burada çalışmaz.
- Bir uygulamanın dayanıklılığı, kaynakların zonal, regional veya multi-regional olarak dağıtılmasıyla belirlenir.
- Bir danışman olarak region seçimi yaparken uyumluluk, gecikme, hizmet kullanılabilirliği ve maliyet faktörlerini bu sırayla değerlendirmelisiniz.
Artık bulutun "neden" değerli olduğunu ve Google'ın bu değeri sunmak için altyapısını "nerede" kurduğunu biliyoruz. Bir sonraki dersimizde, bu altyapının üzerinde sorumlulukların nasıl paylaşıldığını ele alacağız. Paylaşılan Sorumluluk Modeli'ni (Shared Responsibility Model) inceleyerek, bir bulut ortamında güvenliği sağlamak için Google'ın görevlerinin nerede bittiğini ve sizin (müşterinin) görevlerinizin nerede başladığını net bir şekilde öğreneceğiz.