Hücre tabanlı mimari, bir hizmeti bağımsız örneklere, yani hücrelere böler. Her hücre, trafiğin bir alt kümesini bağımsız olarak işleyebilir. Bir ödeme platformu için her hücre, yük dengeleyicileri, uygulama sunucuları, veritabanları ve mesaj kuyrukları içeren eksiksiz bir yığına sahiptir. Bu hücreler, birçok kullanılabilirlik bölgesi boyunca dağıtılır ancak ağ ve veri katmanlarında diğer hücrelerden izole edilir. Trafik yönlendirme, müşteri tanımlayıcılarını kullanarak belirli parçalara dayanır ve bu, tek bir müşterinin yalnızca bir aktif hücreye yalnızca bağlanmasını sağlar; böylece hücreleri boşaltma ve döndürme yeteneği sağlanır, hizmet kesintisi olmadan.
Hücreler arası tutarlılık, kesişen endişeler (ör. dolandırıcılık tespiti, düzenleyici raporlama) için asenkron olay çoğaltması ile Değişiklik Veri Yakalama (CDC) akışları kullanılmaktadır. Intra-hücre işlemleri, yerel veritabanı kümeleri aracılığıyla ACID garantileri sağlar. Hücre dönüşümü, hücre sınırları içinde mavi-yeşil dağıtım desenlerinden yararlanırken, devre kesiciler ve sağlık kontrolüne dayalı trafik yönlendirme global Edge CDN katmanında kötüleşmiş hücreleri otomatik olarak izole etmek için birlikte çalışır.
Günlük 15 milyar dolarlık işlemi yöneten bir birinci seviye ödeme işleyici, bir veritabanı indeks bozulmasının kullanılabilirlik bölgelerinde yayıldığı ABD-Doğu bölgesindeki monolitik yapısında yıkıcı bir zincirleme arıza yaşadı. Bu, 40 milyon müşteriyi etkileyen 4 saatlik küresel bir kesintiye neden oldu ve PCI DSS kullanılabilirlik gereksinimlerini ihlal etti. Sonrasında yapılan analiz, paylaşılan altyapı bileşenlerinin gizli arıza bağımlılıkları yarattığını ve finansal sistemlerde yüksek kullanılabilirlik için gereken bağımsız arıza alanları ilkesini ihlal ettiğini ortaya koydu.
Çözüm A: Aktif-Aktif Çok Bölgesel Çoğaltma
Bu yaklaşım, çoklu ana veritabanı çoğaltması ile birlikte Galera Kümesi veya CockroachDB kullanarak birden fazla bölgede özdeş yığınlar dağıtmayı hedefler; bu sayede herhangi bir bölgede yazma işlemi yapılabilir. Ana avantaj, tam kaynak kullanımının sağlanması ve gecikmeyi azaltmak için coğrafi yerellik kullanılmasıdır. Ancak, finansal işlemler için çatışma çözümleme karmaşıklığı, ağ bölünmeleri sırasında çifte harcama veya tutarsız bakiye durumları gibi kabul edilemez riskler getirir. Ayrıca, vektör saatleri ve birleştirme çatışmalarını yönetiminin operasyonel yükü, işlem hacmi ile birlikte üssel olarak artmaktadır.
Çözüm B: Aktif-Pasif ve Sıcak Yedek
Sıcak yedek bir mimarinin uygulanması, yedek bölgeyi sürekli senkronize tutarak senkron çoğaltma ile gelir ve birincil arıza durumunda saniyeler içinde trafik almalıdır. Bu, güçlü bir tutarlılık sağlar ve açık failover orkestrasyonuyla bölünmüş beyin senaryolarını ortadan kaldırır. Kritik dezavantaj, normal işlemler sırasında %50 kaynak israfı ve tam geçiş olayları olmadan kademeli dönüş veya güncellemeler yapamamaktır. Bu, rutin bakım sürelerini zorlaştırır ve dağıtım riskini artırır.
Çözüm C: Belirleyici Yönlendirme ile Hücre Tabanlı Bölümlendirme
Seçilen mimari, müşteri tabanını 20 farklı hücreye böler; her bir hücre, küresel trafiğin %5'ini işler ve izole Kubernetes kümeleri, özel PostgreSQL ana bileşenleri ve bağımsız Kafka brokerları kullanır. Envoy Proxy yan bileşenleri, istekleri belirli hücrelere yönlendirmek için customer_id üzerinde tutarlı hashing uygularken, küresel kontrol düzlemi hücre sağlığını izler ve dönüşlerde trafik boşaltmasını düzenler. Bu, hücre düzeyindeki arızalar sırasında patlama alanını %5 kullanıcı ile sınırlar ve kanarya analizi ve otomatik geri alma tetikleyicileri kullanarak yeni hücre nesillerine trafik kaydırarak sıfır kesinti süresini sağlar.
Uygulamanın ardından, platform %99.999 kullanılabilirlik (yılda 5 dakikadan daha az kesinti) sağladı, olay patlama alanını %95 oranında azalttı ve hücre düzeyindeki kanarya dağıtımları aracılığıyla dağıtım riskini düşürdü; bu dağıtımlar, küresel dağıtım öncesinde üretim trafik alt kümesine karşı değişiklikleri doğruladı.
Çok hücreli hesaplarla alt hesaplar gibi birden fazla hücreyi kapsayan varlıklar için referans bütünlüğünü nasıl korursunuz?
Adaylar genellikle katı hücre İzolasyonu altında hücreler arası işlemlerin önlenebileceğini yanlış varsayar. Çözüm, hücreler arası işlemler için Saga deseni ile telafi eden işlemler uygular ve bunlar ayrı bir kontrol düzleminde çalışan hafif bir Temporal veya Camunda iş akışı motoru tarafından yönetilir. Hücreler arası işlemler için, sistem iki aşamalı onay (2PC) yalnızca koordinasyon aşaması için kullanırken, gerçek değişimler hücre içi kalır. Idempotent anahtarlar, dağıtılmış işlemler sırasında kısmi arızaların güvenli bir şekilde tekrar denenmesini sağlar ve finansal etki çoğaltımlarını önler. Ayrıca, malzeme görünümleri küresel salt okuma önbelleğinde tutarsızlığın engellenmeden hücreler arası sorguların gerçekleştirilmesini sağlar.
Hücrelerin, yasal sınırları aşması gerektiğinde veri yerleşimi uyumunu (ör. GDPR, PCI DSS) nasıl sağlardınız?
Birçok aday hücre yerleştirmesinin yasal etkilerini göz ardı etmektedir. Mimari, birincil veri depolamasının egemen sınırlar içinde kalmasını sağlarken, yedek hücrelerin şifreli sıcak yedekler olarak görev yapmasını ve kriptografik imha yeteneklerine sahip olmasını sağlayan coğrafi sınırlı hücreler uygulamaktadır. Homomorfik şifreleme teknikleri, dolandırıcılık tespit algoritmalarının hassas kişisel verileri (PII) yabancı yargı alanlarında şifrelenmiş olarak işlem yapmasına olanak tanır. Hücre trafik yönlendirme, coğrafi konuma duyarlı DNS (Route 53 Coğrafi Yakınlık Yönlendirme) ile birlikte çalışır, böylece AB müşterileri, felaket kurtarma senaryoları için açıkça yetkilendirilmedikçe ABD hücrelerini geçmez, otomatik veri yerleşimi denetimleri hücre yerleşiminin uyumunu doğrulamak için Kod olarak Altyapı (IaC) taraması yapar.
Başarısız bir hücre geri kazandığında, binlerce müşterinin aynı anda yeniden bağlanmaya çalışması ve yeniden açılan örneği aşırı yüklemesi gibi "gürültü kuşağı" problemlerini nasıl engellersiniz?
Bu ince operasyonel sorun sıklıkla ihmal edilir. Çözüm, özellikle hücreye yeniden girişte token bucket hız sınırlaması ve istemci SDK’larında üstel geri dönüş jitter kullanır. Hücre geri kazanıldığında, kontrol düzlemi, yönlendirme ağırlığını %0'dan %100'e kadar 15 dakikalık bir süre içinde doğrusal interpolasyon ile artırırken, p99 gecikme ve hata oranları izlenir. Bağlantı havuzlama ve uyumlu eşzamanlılık sınırları ile Envoy, bağlantı aşırılmasını önler. Isınma istekleri (sentetik işlemler), müşteri trafiğini kabul etmeden önce hücre sağlığını doğrulamak için kullanılır. Önbellek ısıtma işleri, soğuk depolama ile önbellek yığılmalarını önlemek için kurtarılan hücredeki Redis kümelerini proaktif olarak doldurur.