Kurumlar için hibrit bulut

Kuruluşunuzun mevsimsel trafiğe sahip bir e-ticaret web sitesi olduğunu ve aynı zamanda tek bir kaydının bile kendi veri merkezinizin duvarlarından dışarı çıkmasını istemediğiniz hassas bir finansal veritabanına sahip olduğunu hayal edin. Her şeyi genel buluta emanet ederseniz, veri gizliliği konusunda endişelenirsiniz; her şeyi dahili tutarsanız, trafik zirveleri için yılın on bir ayı boşta kalacak sunucular satın almanız gerekir. Orta yol çözümü hibrit buluttur; iş yükünün bir kısmının dahili altyapıda (on-premises), bir kısmının genel bulutta çalıştığı ve bu ikisinin güvenli, düşük gecikmeli bir bağlantı üzerinden iletişim kurduğu bir mimaridir.

Bu makalede teorik bir tanım vermeyeceğiz. Gerçek bir kuruluşun neden hibrit buluta yönelmesi gerektiğini, neleri dahili tutması gerektiğini, iki taraf arasındaki bağlantının nasıl tasarlanacağını ve genellikle her şeyin nerelerde ters gittiğini anlayacağız.

Neden Hibrit Bulut? Moda Olmakla İlgisi Olmayan Üç Neden

Hibrit bulut lüks bir seçim değildir; çoğu durumda hem teknik gereksinimleri hem de yasal kısıtlamaları karşılayan tek seçenektir. Üç ana nedeni ayrıntılı olarak inceleyelim.

1. Yasanın Çıkışına İzin Vermediği Veriler

İran'da ve birçok ülkede finansal, tıbbi ve bazı devlet verileri, bunların ülke sınırları dışında veya hatta belirli bir veri merkezi dışında tutulmasını zorunlu kılan düzenlemelere tabidir. Kuruluşunuz bu tür verilerle çalışıyorsa, saf genel bulut pratik olarak seçeneklerden çıkar. Ancak bu, diğer bölümler için bulutun avantajlarından yararlanamayacağınız anlamına gelmez. Hassas veriler dahili sunucularda kalır ve genel web sunucusu veya test ortamı gibi daha az hassas bölümler bulutta çalışır.

2. Dalgalı İş Yükü ve Donanım Satın Alma Maliyeti

Yılın belirli iki haftasında trafiğinin normalin 50 katına çıktığı bir üniversite sınav kayıt sisteminiz olduğunu varsayalım. Bu zirveyi dahili sunucu satın alarak karşılamak isterseniz, normal ihtiyacın 50 katı donanım satın almanız ve yılın 11 ayı boşta tutmanız gerekir. Hibrit bulutta, temel kapasiteyi dahili tutar ve zirvede bulut örneklerini (instances) devreye alırsınız. Bu hem satın alma maliyetini düşürür hem de zirve bittikten sonra bulut kaynaklarını serbest bırakma esnekliği sağlar.

3. Gerçek Zamanlı İşlemler İçin Kritik Gecikme

Banka işlemlerinde dolandırıcılık tespiti veya üretim hattı kalite kontrolü gibi bazı işlemler 10 milisaniyenin altında gecikme gerektirir. Verileri yüzlerce kilometre uzakta olabilecek bir bulut veri merkezine göndermek bu gereksinimi ihlal eder. Bu işlemler dahili donanım üzerinde çalışmalıdır. Ancak nihai sonuçlarını sonraki analizler için buluta gönderebilirsiniz.

Neyi Dahili Tutmalıyız? Bir Karar Verme Çerçevesi

Hazır bir liste vermek yerine, üç soruluk bir çerçeve öneriyorum. Her hizmet veya veri için şu üç soruyu sorun:

1. Yasa veya sözleşme, verinin saklanacağı yeri belirtiyor mu? Evet ise, o veri dahili kalır.
2. Hizmet 20 milisaniyeden daha düşük bir gecikme gerektiriyor mu? Evet ise, coğrafi olarak çok yakın bir bulutunuz yoksa dahili çalıştırma zorunludur.
3. İş yükü dalgalanması ortalamanın 5 katından fazla mı? Evet ise, bu hizmet, zirve için donanım satın almak zorunda kalmamak adına bulut kısmı için iyi bir adaydır.

Bu çerçeveyle yaygın bir model ortaya çıkar: ana veritabanları, ödeme hizmetleri ve gerçek zamanlı işlemler dahili kalır; genel web sunucuları, test ve geliştirme ortamları, veri analizi hizmetleri ve toplu işlemler (batch) buluta gider.

Hibrit Bulutta Bağlantı Mimarisi; Her Şeyin Bozulduğu Yer

Hibrit bulutun en büyük teknik zorluğu, iki taraf arasındaki bağlantıdır. Bu bağlantı doğru tasarlanmazsa, tüm mimari çöker. Üç bağlantı katmanını ayrı ayrı tasarlamanız gerekir.

Ağ Katmanı: VPN mi, Özel Bağlantı mı?

En basit yol, dahili veri merkezi ile bulut VPC'si arasında bir VPN tüneli kurmaktır. Başlangıç ve düşük hacimler için IPSec Site-to-Site VPN yeterlidir. Ancak iki sınırlaması vardır: bant genişliği internetinizle sınırlıdır ve kararlılığı internet bağlantınızın kalitesine bağlıdır.

Taşınan veri hacmi yüksekse (örneğin günde 50 GB'den fazla) veya yüksek kararlılık gerekiyorsa, özel bağlantı düşünmelisiniz. Birçok bulut sağlayıcısı, veri merkezinize özel bir hat üzerinden bağlanan doğrudan bağlantı (Direct Connect) hizmeti sunar. Bu durumda gecikme daha kararlı ve bant genişliği öngörülebilirdir.

Önemli bir not: Asla tek bir hatta güvenmeyin. Biri kesilirse trafiğin diğer yoldan geçmesi için en az iki yedekli (redundant) bağlantı yolu tasarlayın.

Veri Katmanı: Çift Yönlü Senkronizasyon

Dahili bir veritabanınız olduğunda ve bulut uygulamalarının da buna ihtiyacı olduğunda iki seçeneğiniz vardır:

• Doğrudan Erişim: Bulut uygulamaları ağ bağlantısı üzerinden dahili veritabanına bağlanır. Basittir ancak bağlantı kesilirse bulut uygulamaları çalışmaz.
• Veri Senkronizasyonu: Verilerin bir kopyası bulutta tutulur ve periyodik olarak (örneğin her 5 dakikada bir) dahili kaynakla senkronize edilir. Bulut uygulamaları kendi yerel kopyalarına bağlanır. Bu yöntem daha dayanıklıdır ancak senkronizasyon karmaşıklığını ekler.

Senkronizasyon için PostgreSQL için pglogical veya MySQL için MySQL Replication gibi açık kaynaklı araçlar çalışır. Kritik nokta, senkronizasyonun çift yönlü olması ve çakışma çözümünün (conflict resolution) tanımlanmış olmasıdır. Örneğin, bir kayıt hem dahili tarafta hem de bulut tarafında düzenlenirse, hangi sürüm kazanır?

# Örnek: pglogical ile dahiliden buluta tek yönlü replication ayarı
-- Dahili sunucuda (provider)
SELECT pglogical.create_node(
    node_name := 'internal',
    dsn := 'host=192.168.1.10 port=5432 dbname=mydb'
);

-- Bulut sunucusunda (subscriber)
SELECT pglogical.create_node(
    node_name := 'cloud',
    dsn := 'host=10.0.0.5 port=5432 dbname=mydb'
);
SELECT pglogical.create_subscription(
    subscription_name := 'internal_to_cloud',
    provider_node := 'internal',
    replication_sets := '{default}'
);

Uygulama Katmanı: Dayanıklılık ve Önbellek

Bulutta çalışan uygulamalar, geçici bağlantı kesintilerine dayanacak şekilde tasarlanmalıdır. Bu, Circuit Breaker ve Backoff ile Retry desenlerinin kullanılması anlamına gelir. Ayrıca, bağlantıya olan bağımlılığı azaltmak için önbellek (Cache) kullanın. Örneğin, bulut uygulaması saatte bir değişen ürün listesine ihtiyaç duyuyorsa, bunu Redis'te önbelleğe alın ve saatte bir dahili kaynaktan güncelleyin. Bu, bağlantıdan geçen istek sayısını büyük ölçüde azaltır.

Hibrit Bulut Sınırında Güvenlik

Dahili ağ buluta bağlandığında saldırı yüzeyi büyür. Birkaç zorunlu önlemi ciddiye alın:

Segmentasyon ve Mikro Segmentasyon

Dahili ağı ayrı bölümlere ayırın. Hassas veritabanları ayrı bir VLAN'da olmalı ve yalnızca bir Jump Server üzerinden erişilebilir olmalıdır. Bulut tarafında da yalnızca gerekli portları açan Security Group'lar kullanın. Örneğin, bulut uygulaması yalnızca dahili veritabanının 5432 portuna ihtiyaç duyuyorsa, buluttan dahili tarafa başka hiçbir port açık olmamalıdır.

Aktarım ve Bekleme Sırasında Şifreleme

İki taraf arasındaki tüm trafik TLS veya IPSec ile şifrelenmelidir. Her iki tarafta depolanan veriler de şifrelenmelidir. Şifreleme anahtarları için, anahtarları merkezi olarak yöneten ve erişimi kaydeden bir anahtar yönetim hizmeti (KMS) kullanın.

İzleme ve Uyarı

İki taraf arasındaki geçen trafiği izleyin. Anormal veri hacmi, başarısız bağlantı sayısı veya anormal zaman desenleri bir ihlalin işareti olabilir. İzleme için Prometheus ve Grafana, uyarı için Alertmanager gibi araçlar yaygın açık kaynaklı seçimlerdir.

Pratik Senaryo: Mevsimsel Zirveli E-Ticaret Sitesi

Her şeyin somutlaşması için birlikte eksiksiz bir senaryo tasarlayalım. Belirli günlerde (Yalda Gecesi veya bayram gibi) trafiğinin 20 kat arttığı bir e-ticaret siteniz olduğunu varsayalım.

Önerilen Mimari

• Dahili: Ana PostgreSQL veritabanı, ödeme hizmeti, depo yönetimi ve muhasebe yazılımı.
• Bulut: Nginx web sunucuları, uygulama sunucuları (örneğin Node.js veya PHP-FPM), önbellek ve oturum için Redis ve test ortamı.

Normal durumda, web ve uygulama için 2 bulut örneği yeterlidir. Zirvede, Auto Scaling ile örnek sayısı otomatik olarak 20'ye ulaşır. Bulut uygulamaları özel bağlantı üzerinden dahili veritabanına bağlanır. Veritabanı üzerindeki yükü azaltmak için, sık yapılan tüm okumalar (ürün listesi ve fiyatlar gibi) Redis'te önbelleğe alınır ve yalnızca yazmalar (siparişler) doğrudan veritabanına gider.

Arıza Yönetimi

İki taraf arasındaki bağlantı kesilirse ne olur? Bulut uygulamaları, siparişleri yerel bir kuyrukta (örneğin aynı bulut örneğinde RabbitMQ) tutacak ve bağlantı geri geldiğinde bunları dahili veritabanına gönderecek şekilde tasarlanmalıdır. Bu desene Store and Forward denir ve hibrit bulutta dayanıklılık için hayati öneme sahiptir.

Hibrit Bulut Uygulamasında Yaygın Hatalar

Son olarak, neredeyse tüm başarısız projelerde gördüğüm dört hatayı gözden geçirelim:

1. Ağ Gecikmesini Göz Ardı Etmek: Bağlantı kurulduğu için gecikmenin önemsiz olduğunu varsayarlar. Bulut uygulamasının dahili veritabanına yaptığı her isteğin ağdan iki kez geçtiğini (gidiş ve dönüş) unuturlar. Tek yönlü gecikme 5 milisaniyeyse, her sorgu 10 milisaniye daha uzun sürer. Saniyede binlerce sorgusu olan uygulamalar için bu sayı felakettir.
2. Bağlantı Kesintisini Test Etmemek: Test ortamında bağlantı kesintisini simüle etmezler. Gerçekten kesildiği gün, bulut uygulamalarının tamamen çalışmadığını yeni fark ederler.
3. Tek Yönlü Senkronizasyon: Verileri yalnızca dahiliden buluta senkronize ederler ve bazı verilerin (kullanıcı sepetleri gibi) bulutta üretildiğini ve dahiliye geri dönmesi gerektiğini unuturlar.
4. Çıkış Stratejisinin Olmaması: Bir gün buluttan çıkmak veya sağlayıcıyı değiştirmek isterseniz, verileri nasıl geri getirirsiniz? Bunu ilk günden tasarlamalısınız, ihtiyaç duyduğunuzda değil.

Sonuç

Hibrit bulut, hem genel bulutun avantajlarından (ölçeklenebilirlik, değişken maliyet) yararlanmanıza hem de hassas verilerin kontrolünü elinizde tutmanıza olanak tanıyan olgun bir mimaridir. Başarının anahtarı, her hizmetin çalışma yeri hakkında bilinçli kararlar vermek, ağ bağlantısını ve veri senkronizasyonunu dikkatli tasarlamak ve kesintilere hazırlıklı olmaktır. Bu üç ayağı ciddiye alırsanız, hibrit bulut kuruluşunuzun en güçlü altyapı araçlarından biri haline gelir. Yeni başladıysanız, küçük ve hassas olmayan bir iş yüküyle başlayın, deneyim kazanın ve ardından mimariyi genişletin.