Karma (Hybrid) Bulut Hosting Mimarisi ile Kendi Veri Merkezinizi Genel Bulutla Birleştirmek

Karma (Hybrid) Bulut Hosting Mimarisi Neden Gündemde?

Altyapı planlama toplantılarında bugün en çok tartışılan başlıklardan biri, mevcut veri merkezini tamamen kapatmak yerine onu genel bulutla akıllıca birleştirmek. Bir yanda yıllardır çalışan, amorti olmuş fiziksel sunucularınız, depolama sistemleriniz ve ağ altyapınız; diğer yanda ise dakikalar içinde ölçeklenebilen, dünya çapında bölgelere sahip genel bulut platformları var. Karma (hybrid) bulut hosting mimarisi, bu iki dünyayı birbirine kırmadan bağlamanızı sağlayan yaklaşım.

Karma bulut, kabaca kendi veri merkeziniz (veya colocation alanınız) ile bir veya daha fazla genel bulut sağlayıcısını tek bir mantıksal altyapı gibi çalıştırmanız anlamına gelir. Böylece kritik, regüle veya düşük gecikme isteyen iş yüklerini kendi tarafınızda tutarken; esneklik, coğrafi yayılım veya kısa süreli yüksek kapasite gerektiren kısımları genel buluta taşıyabilirsiniz. Bu yazıda, DCHost ekibi olarak sıkça kurduğumuz mimarilerden ve sahadaki deneyimlerden yola çıkarak, karma bulut hosting’i adım adım kurgulamanız için net bir yol haritası paylaşacağız.

Karma (Hybrid) Bulut Nedir, Ne Değildir?

Önce bazı kavramları netleştirelim. Pazarlama dili ile gerçek teknik mimari arasında genelde ciddi bir mesafe olur; kafa karışıklığı yaşamamak için temel ayrımları basitçe toparlayalım.

Karma (hybrid) bulut, şu üç parçanın birlikte çalışmasıdır:

• Kendi veri merkeziniz veya colocation alanınızda barınan fiziksel/dedicated sunucularınız
• Gerektiğinde ölçeklenen genel bulut kaynakları (sanal sunucu, depolama, veritabanı vb.)
• Bunları tek ağ, tek güvenlik katmanı ve tek izleme/operasyon modeliyle birleştiren bağlantı ve orkestrasyon katmanı

Çoklu bulut (multi-cloud) ise, birden fazla genel bulut sağlayıcısını kullanmak ama mutlaka kendi veri merkezinizle birleştirmek zorunda olmamanızdır. Örneğin sadece iki farklı genel bulut sağlayıcısı arasında dağıtılmış iş yükleri de çoklu buluttur ama karma bulut sayılmaz.

Kısaca:

• Karma bulut: Özel altyapınız (on-prem / colocation) + genel bulut(lar)
• Multi-cloud: Birden fazla genel bulut; özel altyapı olabilir de olmayabilir de

Karma bulutun asıl gücü, mevcut yatırımlarınızı çöpe atmadan, adım adım buluta açılmanızı sağlamasıdır. Özellikle KVKK, GDPR gibi regülasyonlar veya düşük gecikme gerektiren veritabanı, ERP, üretim hatları gibi sistemler söz konusuysa, tamamını genel buluta taşımak gerçekçi olmayabiliyor. Bu noktada karma mimari mükemmel bir ara katman sunuyor.

Kendi Veri Merkezinizi ve Bulutu Birlikte Kullanmanın Tipik Senaryoları

Sahada gördüğümüz projelerde karma buluta geçiş motivasyonları genelde üç ana başlıkta toplanıyor. Kendi durumunuzu bunlara göre konumlandırmak işe yarar.

1. Mevcut Uygulamayı Aşamalı Olarak Buluta Açmak

Yıllardır kendi veri merkezinizde çalışan bir monolit uygulamanız var; içinde ERP, CRM, raporlama, hatta web arayüzü bir arada. Tamamını yeniden yazmak hem pahalı hem riskli. Buna karşılık:

• Ön ucu (web, API, mobil backend) genel buluta taşıyıp
• Kritik veritabanlarını ve iç sistemleri kendi veri merkezinizde tutabilirsiniz.

Bu senaryoda uygulama, veri merkeziniz ile genel bulut arasında VPN veya özel hat üzerinden konuşur. Web katmanını buluta alarak hem ölçeklemeyi kolaylaştırır hem de dünya çapındaki kullanıcılara daha yakın sunucular kullanabilirsiniz. Veritabanının ayrılması ve sunucu mimarilerinin tasarımı için, daha önce ele aldığımız veritabanı sunucusunu uygulamadan ayırma rehberine göz atmak faydalı olacaktır.

2. Sezonluk Trafik Patlamaları İçin Bulutu Güvenlik Supabı Gibi Kullanmak

E-ticaret, biletleme, kampanya siteleri veya televizyon programı eşlik uygulamaları gibi projelerde trafik yükü yılın büyük kısmında makul, bazı günlerde ise katlanarak artıyor. Bu durumda:

• Normal dönemin yükünü karşılayan kendi fiziksel sunucularınız (veya DCHost üzerindeki dedicated/VPS altyapınız) baz alınır.
• Kampanya dönemlerinde genel bulutta geçici ek sunucular devreye alınır.

Bu yaklaşım, “her ay maksimum trafik gününe göre fatura ödemek” yerine, ortalama yük için optimize edilmiş bir çekirdek altyapı + gerektiğinde bulutta açılıp kapanan ek kapasiteler şeklinde maliyeti dengeler. Benzer ölçekleme stratejilerini detaylı anlattığımız sezonluk trafik patlamalarına hazırlık rehberi bu senaryoya birebir uyarlanabilir.

3. KVKK, Finans ve Üretim Sistemlerinde Veri Egemenliğini Korumak

Bazı sektörlerde, hassas verinin ülke dışına çıkmaması, hatta kimi zaman şirket sahasını dahi terk etmemesi gerekiyor. Örneğin:

• Finans ve ödeme sistemleri
• Sağlık verileri
• Üretim tesisine bağlı IoT/SCADA sistemleri

Bu tip iş yüklerinde veriler çoğunlukla kendi veri merkezinizde kalırken; sadece raporlama, analitik, web arayüzü veya anonimleştirilmiş veri işleme katmanları genel bulut kaynaklarıyla çalışabiliyor. Log’ları ve yedekleri de çok bölgeli bir yapıda yönetmek istiyorsanız, çok bölgeli mimarilerle felaket dayanıklılığı kurma rehberimiz bu noktada iyi bir referans olacaktır.

Karma Bulut Hosting Mimarisi İçin Temel Bileşenler

İster küçük bir pilot proje, ister komple şirket altyapısı olsun; her karma bulut kurgusunda mutlaka çözmeniz gereken bazı temel bileşenler var.

Ağ Bağlantısı: VPN, Özel Hat ve Segmentasyon

Karma mimarinin kalbi, özel ağ bağlantısıdır. Genel bulut üzerindeki kaynakların, sanki aynı LAN’deymiş gibi veri merkezinize bağlanması gerekir. Temel seçenekler:

• Site-to-site VPN: İnternet üzerinden şifreli tünel. Başlangıç için en pratik yöntem; bant genişliği ve gecikme değerlerini iyi hesaplamak gerekir.
• Özel hat / kiralık devre: MPLS, L2, metro ethernet gibi çözümlerle düşük gecikmeli, garantili bağlantı.
• Ağ segmentasyonu (VLAN, VRF): Veri merkeziniz tarafında, bulutla konuşan sunucuları ayrı ağ segmentlerinde tutarak güvenliği artırmak.

Küresel erişim ve gecikme süreleri açısından DNS tarafı da kritik. Farklı bölgelerdeki son kullanıcılara en yakın kaynağı yönlendirmek için GeoDNS ve çok bölgeli hosting mimarisi rehberinde anlattığımız teknikleri karma bulut ortamlarınıza da uygulayabilirsiniz.

Kimlik ve Erişim Yönetimi

On-prem ve bulut tarafında iki ayrı kullanıcı, iki ayrı rol yönetmek istemezsiniz. Uzun vadede sürdürülemez. İdeal senaryoda:

• Merkezi bir kimlik sağlayıcı (IdP) üzerinden hem veri merkezinizdeki hem buluttaki bileşenlere erişim verilir.
• SSH erişimi, bastion host’lar veya VPN üzerinden rol bazlı şekilde tanımlanır.
• Loglar merkezi bir sistemde toplanır, erişim denetimleri denetlenebilir olur.

Birden fazla sunucuda log ve erişim yönetiminin nasıl basitleştirilebileceğini görmek için, VPS log yönetimi ve merkezi loglama yazımıza göz atabilirsiniz; oradaki yaklaşımı karma bulut mimarinizde de rahatlıkla kullanabilirsiniz.

DNS, Yönlendirme ve SSL

Karma bulut kurduğunuzda, bazen aynı alan adını hem veri merkezinizdeki hem de buluttaki servisler için kullanmanız gerekebilir. Örneğin:

• api.ornek.com – genel buluttaki API katmanı
• db.ornek.com – veri merkezinizdeki veritabanı

Bu noktada DNS kayıtlarını, TTL değerlerini ve SSL/HTTPS terminasyon noktasını iyi tasarlamalısınız. DNS yönetimi ve TTL stratejileri için, DNS TTL değerlerini doğru ayarlamak üzerine rehberimiz karma bulut senaryolarında da sık başvurduğumuz bir kaynak.

Depolama, Yedekleme ve Arşiv

Karma bulutta veriyi nerede tutacağınız neredeyse her şeyden önemli. Sık gördüğümüz kombinasyonlar:

• Sıcak veri: Veritabanları ve aktif dosyalar; çoğunlukla veri merkezinizdeki NVMe/SAS disklerde veya DCHost üzerindeki yüksek performanslı VPS/dedicated sunucularda.
• Sıcak + replikalı: Aynı verinin hem veri merkezinizde hem de bulut tarafında replikasyonu, felaket kurtarma için.
• Soğuk / arşiv: Loglar ve eski yedekler; genellikle nesne depolama (object storage) üzerinde tutuluyor.

Bu üç katmanı nasıl dengeleyeceğinizi daha detaylı görmek isterseniz, sıcak-soğuk-arşiv depolama stratejisi rehberimiz karma bulut mimariniz için çok iyi bir çerçeve sunar.

İzleme, Loglama ve Alarm

Tek veri merkezinde dahi izleme kurmak başlı başına iştir; işin içine bir de genel bulut katmanı girince, “hangi uyarı nereden geliyor?” sorusu ciddi bir karmaşaya dönüşebilir. O yüzden en baştan şu hedefler konmalı:

• Hem on-prem hem bulut tarafındaki metrikler, tek bir izleme platformunda toplanmalı.
• Loglar mümkünse merkezi ve arama yapılabilir bir altyapıya akmalı.
• Alarm kuralları sadece teknik değil, iş etkisine göre (sipariş alamama, ödeme hata oranı vb.) tasarlanmalı.

Bu noktada, VPS kaynak kullanımı izleme rehberi ve Prometheus/Grafana tabanlı izleme yazılarımızda anlattığımız pratikleri bire bir karma bulut mimarilerine de taşıyoruz.

Adım Adım Karma Bulut Mimarisi Tasarımı

Şimdi teoriyi bir kenara bırakıp sahadaki akışa geçelim. Tipik bir karma bulut projesini DCHost ekibiyle birlikte şöyle kurguluyoruz:

Adım 1: İş Yükü Envanteri ve Sınıflandırma

Önce neye sahip olduğumuzu masaya yatırıyoruz:

• Uygulama listesi (web, API, arka plan işçileri, cron görevleri)
• Veritabanları (MySQL, PostgreSQL, MS SQL vb.)
• Depolama gereksinimleri (toplam GB/TB, IOPS, throughput)
• Dışa açık servisler (HTTP(S), API, FTP/SFTP, VPN vb.)

Her iş yükü için şu soruları netleştiriyoruz:

• Gecikme hassasiyeti nedir?
• Veri regülasyonu var mı (KVKK, sektör mevzuatı)?
• Yoğunluk profili nasıl (sürekli mi, sezonluk mu)?
• Uygulama modernize edilebilir mi yoksa monolit ve kapalı mı?

Adım 2: On-Prem ve Bulut Arasında Net Bir Sınır Çizmek

Envanteri gördükten sonra genelde şu tür kararlar ortaya çıkar:

• Veritabanları ve mesaj kuyrukları: Çoğu zaman kendi veri merkezinde veya DCHost üzerindeki dedicated/VPS sunucularda.
• Web/API katmanı: Buluta taşınmaya en uygun katman; CDN ve WAF ile desteklenebilir.
• Arka plan işçileri: Trafiğe göre hem on-prem hem bulut tarafında koşturulabilir.
• Statik dosyalar ve medya: Nesne depolama + CDN kombinasyonu en mantıklı çözüm.

Kendi sunucularınızı profesyonel veri merkezinde barındırıyorsanız, bu çekirdek katman için colocation hizmetinin avantajlarını anlattığımız rehber tam da burada devreye giriyor. Böylece şirket içi odalardan çıkıp, yüksek erişilebilirlikli bir veri merkezine taşınmış oluyorsunuz.

Adım 3: Ağ Topolojisi ve Güvenli Bağlantı Tasarımı

Sırada, iki dünyayı nasıl bağlayacağınızı kurgulamak var. Sık kullandığımız bir şema şöyle:

• Veri merkezinizde ana router/firewall ve DMZ segmenti
• Genel bulut tarafında özel ağ (VPC/VNet muadili) ve alt ağlar
• Bu ikisi arasında şifrelenmiş site-to-site VPN veya özel hat

Burada kritik karar, trafiği nerede termin edeceğiniz. Örnek:

• Web trafiğini CDN veya bulut tarafındaki load balancer’da termin edip, veri merkezine sadece API/veritabanı trafiği yönlendirebilirsiniz.
• İç yönetim panellerine doğrudan erişimi tamamen kısıtlayıp, yalnızca VPN ile erişim verebilirsiniz.

Adım 4: Güvenlik, Segmentasyon ve Sıfır Güven Yaklaşımı

Karma bulut, yanlış kurgulanırsa güvenlik yüzey alanını katlayarak artırır. O yüzden tasarım aşamasında şu prensipleri uyguluyoruz:

• En az ayrıcalık: Her servis sadece konuşması gereken port ve IP’lere erişebilsin.
• Ağ segmentasyonu: Web, uygulama, veritabanı ve yönetim katmanlarını ayrı VLAN/alt ağlarda tutmak.
• Güvenli yönetim: SSH, RDP ve panel erişimleri yalnızca bastion host veya VPN üzerinden.
• Merkezi loglama ve alarm: Şüpheli girişimleri erken yakalayacak WAF ve IDS/IPS katmanları.

Bu noktada, özellikle yönetim panelleri ve kontrol arayüzlerini nasıl sıkılaştırabileceğinizi anlattığımız mTLS ile yönetim panellerini koruma rehberi karma bulut kurarken de ciddi anlamda işinizi kolaylaştırır.

Adım 5: Yedekleme, Replikasyon ve Felaket Kurtarma

Karma mimarinin en güzel yanlarından biri, yedekler ve felaket kurtarma için doğal bir ikinci ortam sunmasıdır. Örneğin:

• Veri merkezinizdeki veritabanını, buluttaki bir veritabanına asenkron replike edebilirsiniz.
• Yedekleri buluttaki nesne depolamaya, ek olarak başka bir DCHost lokasyonuna aktarabilirsiniz.
• Uygulama tarafında ise “soğuk standby” bulut sunucularını sadece felaket anında ayağa kaldırabilirsiniz.

Gerçek bir felaket kurtarma planının nasıl yazılacağı, test edileceği ve runbook haline getirileceğiyle ilgili detaylar için, felaket kurtarma planı rehberimizi mutlaka okumanızı öneririm.

Adım 6: Gözlemlenebilirlik, Kapasite ve Maliyet Yönetimi

İlk kurulumdan sonra asıl maraton başlıyor: Sistemi ayakta ve optimize tutmak. Burada üç temel alan var:

• Performans: Hem on-prem hem bulut tarafındaki CPU, RAM, disk IO ve ağ gecikmelerini izlemek.
• Maliyet: Genel bulut tarafında “boşta çalışan ama para yakan” kaynakları yakalamak, otomatik ölçeklemeyi doğru kurmak.
• Güncelleme ve değişiklik yönetimi: Konfigürasyon yönetimi ve altyapı otomasyonu (Terraform, Ansible vb.) ile insan hatasını azaltmak.

Karma bulut projelerinde özellikle VPS–bulut entegrasyon trendleri yazımızda anlattığımız yaklaşımları kullanıyoruz: çekirdek iş yüklerini DCHost üzerinde stabil tutup, esnek katmanı bulut tarafında çalıştırmak gibi.

DCHost ile Karma Bulut Kurgularken Dikkat Ettiğimiz Noktalar

DCHost tarafında müşterilerle karma bulut projeleri kurgularken genelde şu çerçeve üzerinden ilerliyoruz:

• Çekirdek altyapı: Veritabanları, cache ve kritik iç servisler için DCHost üzerinde yüksek performanslı VPS veya dedicated sunucular; gerekirse colocation ile müşterinin kendi donanımı.
• Ağ ve güvenlik: Veri merkezimiz ile müşterinin ofisi/genel bulut ortamı arasında güvenli tüneller, firewall politikaları, WAF entegrasyonları.
• Çok bölgeli tasarım: Gerektiğinde farklı lokasyonlarımızda yedek sunucular ve DNS tabanlı otomatik failover senaryoları.
• Gözlemlenebilirlik: DCHost altyapısındaki metrik ve logları, müşterinin bulut tarafındaki izleme sistemleriyle konuşturmak.

“Tamamını buluta taşımalı mıyım, yoksa DCHost + genel bulut kombinasyonu mu kurmalıyım?” sorusunu soran projelerde, genelde önce colocation, dedicated ve bulut altyapı karşılaştırması yapıp, ardından karma mimariyi bunun üzerine inşa ediyoruz.

Yayına Alırken Test, Geçiş ve Operasyon

Tasarladığınız mimari ne kadar iyi olursa olsun, yayına alırken yapılacak bir hata tüm kazanımları silebilir. Karma bulutta özellikle şu üç adımı atlamıyoruz:

Önce Geliştirme ve Staging Ortamı

Karma bulut mimarisini önce küçük ölçekte, geliştirme ve test ortamında uygularız. Örneğin:

• Veritabanı DCHost üzerindeki staging sunucuda,
• Uygulama ise genel buluttaki test sunucularında çalışır.

DNS, SSL, VPN ve firewall kurallarını bu ortamda test edip, sorunları erken yakalamak yayına geçişteki riski çok ciddi oranda düşürür.

Aşamalı Geçiş: Blue-Green veya Canary Dağıtımı

Tüm trafiği bir anda yeni karma mimariye taşımak yerine, trafiği kademeli olarak yönlendirmek en sağlıklı yöntemdir. Bunun için:

• Blue-green dağıtım: Eski ve yeni mimari aynı anda ayakta tutulur; DNS veya load balancer ile trafik yeni ortama yavaş yavaş aktarılır.
• Canary dağıtımı: Trafiğin küçük bir yüzdesi yeni ortama verilir, metrikler izlenir ve kademeli olarak artırılır.

Bu yaklaşımların pratik detaylarını blue-green deployment ile sıfır kesinti güncelleme rehberimizde bulabilirsiniz; karma bulut geçişlerinde de bire bir uygulanabilir.

Runbook ve Olay Yönetimi

Karma mimaride arıza olduğunda “şimdi ne yapıyoruz?” sorusunun cevabı, kişilerde değil dokümantasyonda olmalı. Bu yüzden:

• Her kritik senaryo için (veritabanı arızası, VPN kopması, DNS hatası) adım adım runbook hazırlarız.
• İzleme sistemlerindeki alarmlar, doğrudan ilgili runbook’a link verir.
• Olay sonrası mutlaka postmortem yapılır; nelerin otomatikleştirilebileceği tartışılır.

Sonuç ve Yol Haritası: Küçük Bir Pilotla Başlayın

Karma (hybrid) bulut hosting mimarisi, “her şeyi buluta taşıyalım” ile “asla veri merkezinden çıkmayalım” arasındaki gri bölgeyi çok iyi dolduruyor. Mevcut yatırımınızı koruyup, aynı zamanda esneklik, küresel erişim ve felaket dayanıklılığı kazanmanızı sağlıyor. Ancak doğru kurgulanmadığında; çift yönetilen altyapılar, karmaşık ağ topolojileri ve kontrol edilemeyen bulut faturalarıyla baş başa kalmak da mümkün.

Burada en sağlıklı yaklaşım, tek seferde dev bir dönüşüm yerine küçük ama iyi tanımlanmış bir pilot proje ile başlamak. Örneğin sadece web katmanını veya tek bir mikroservisi genel buluta çıkarıp, veritabanını DCHost üzerindeki sunucunuzda tutarak işe koyulabilirsiniz. İzleme, yedekleme, güvenlik ve maliyet tarafında rahat ettiğinizde, diğer iş yüklerini de yavaş yavaş bu modele taşımanız çok daha güvenli olur.

Eğer “bizim senaryomuzda hangi iş yükü nerede durmalı, ağı nasıl tasarlamalıyız?” sorularını netleştirmek istiyorsanız, DCHost ekibiyle birlikte mevcut altyapınızı inceleyip size özel bir karma bulut yol haritası çıkarmaktan memnuniyet duyarız. İhtiyacınıza göre colocation, dedicated, VPS ve genel bulut kombinasyonlarıyla, ölçeklenebilir, yönetilebilir ve maliyeti öngörülebilir bir mimariyi birlikte kurabiliriz.