01Sorun ve çözüm
Yüksek erişilebilirlik mimarisi çalışmasında önce iş tarafıyla bir hedef belirleriz: hangi hizmet ne kadar kesintiyi tolere edebilir, hangi işlemde veri kaybı hiç kabul edilemez. Ardından istekten veritabanına kadar uzanan yolu çizer, her bileşenin arızasında ne olacağını tek tek sorgularız. Yedekliliği yalnızca gereken yerde kurar, devralmayı otomatikleştirir ve planlı tatbikatlarla çalıştığını kanıtlarız.
02Kimler için
Yüksek erişilebilirlik mimarisi kimler için gerekli
Kesintinin doğrudan gelir, itibar ya da operasyon kaybı anlamına geldiği sistemler için önceliklidir.
- Kampanya ve yoğun satış dönemlerinde kesintinin doğrudan ciro kaybı yarattığı e-ticaret ve pazaryeri satıcıları
- Kendi müşterilerine hizmet düzeyi taahhüdü veren SaaS ve platform şirketleri
- Ödeme, rezervasyon ya da sipariş alma gibi anlık işlemleri olan ve kesintide işlem kaybı yaşayan uygulamalar
- Fabrika, depo ya da saha ekiplerinin gün boyu kesintisiz kullandığı üretim ve lojistik sistemleri
- Geçmişte yaşadığı bir kesintinin ardından altyapısındaki zayıf noktaları sistematik olarak kapatmak isteyen ekipler
03İhtiyaçlar
Erişilebilirliği düşüren tasarım boşlukları
Devralma hiç denenmemişse sıradan bir donanım arızası bile uzun bir kesintiye dönüşebilir.
- 01
Durum bilgisini tutan sunucular
Oturum bilgisini ya da yüklenen dosyaları yerel diskinde tutan bir uygulama sunucusu çoğaltılamaz. Durum, ortak bir önbelleğe ve nesne depolamaya taşınarak sunucular birbirinin yerine geçebilir hâle gelir.
- 02
Elle devralınan veritabanı
Yedek veritabanı vardır ama birincil düştüğünde birinin uyanıp komut çalıştırması gerekir. Otomatik devralma, sağlık kontrolleri ve uygulamanın yeni birincile kendiliğinden bağlanması birlikte tasarlanır.
- 03
Çift birincil (split-brain) riski
Ağ kesintisinde iki düğümün aynı anda kendini birincil sanması veri çakışmasına yol açar. Çoğunluk oylaması (quorum) ve fencing mekanizmalarıyla aynı anda yalnızca bir düğümün yazma kabul etmesi sağlanır.
- 04
Gözden kaçan dış bağımlılıklar
DNS sağlayıcısı, ödeme altyapısı ya da tek bir bölgedeki depolama hizmeti de arıza noktası olabilir. Bu bağımlılıklar listelenir; her biri için kısıtlı çalışma modu ya da alternatif yol belirlenir.
04Özellikler
Yüksek erişilebilirlik mimarisi hizmetinin içerdiği çalışmalar
Her bileşen için yedeklilik düzeyi, maliyeti ve getirdiği karmaşıklıkla birlikte değerlendirilir.
- 01
Arıza modu analizi
Yük dengeleyici, uygulama sunucusu, veritabanı, kuyruk, önbellek ve ağ için “bu bileşen giderse ne olur” sorusu yanıtlanır; tek arıza noktaları önem sırasına konur.
- 02
Çok bölgeli ya da çok veri merkezli yerleşim
Bulutta uygulama ve veritabanı aynı bölge içindeki farklı erişilebilirlik alanlarına dağıtılır; daha yüksek hedeflerde ikinci bir bölge ya da veri merkezi devreye girer.
- 03
Veritabanı kümeleme
PostgreSQL için Patroni, SQL Server için Always On kullanılabilirlik grupları ya da yönetilen servislerin çoklu alan seçenekleri gibi yöntemlerle otomatik devralan veritabanı kurulur.
- 04
Kısmi arızada çalışmayı sürdürme
Öneri motoru ya da raporlama gibi yardımcı bir servis çöktüğünde ana işlemin sürmesi sağlanır; zaman aşımları, devre kesiciler ve yeniden deneme kuralları tanımlanır.
- 05
Devralma tatbikatları
Planlı bir pencerede sunucu kapatılır, veritabanı birincili düşürülür ya da bir erişilebilirlik alanı devre dışı bırakılır. Sistemin tepkisi ve kurtulma süresi ölçülerek raporlanır.
05Entegrasyonlar
Yedeklilik kurulan katmanlar
Her katmanın yedekliliği, bulut sağlayıcısının ya da kullanılan yazılımın kendi mekanizmalarıyla kurulur.
- 01
Trafik ve yük dengeleme
Bulut sağlayıcısının yönetilen yük dengeleyicileri, HAProxy ya da NGINX gibi çözümler ve sağlık kontrollü DNS yönlendirmesi kullanılır.
- 02
Uygulama ve konteyner katmanı
Kubernetes üzerinde birden çok kopya, düğümlere dağıtma kuralları ve otomatik ölçekleme; sanal sunucu tabanlı yapılarda ise otomatik ölçekleme grupları kurulur.
- 03
Önbellek ve kuyruk
Redis için replika ve Sentinel ya da küme modu, mesaj kuyrukları için çoğaltılmış yapı kurulur; böylece tek bir düğümün kaybı mesaj kaybı anlamına gelmez.
- 04
Depolama
Kullanıcı dosyaları bölgeler arası çoğaltma yapılabilen nesne depolamada tutulur; sunucu diskine bağımlılık kaldırılır.
06Süreç
Yüksek erişilebilirlik mimarisi hizmeti nasıl ilerler?
Adım 01
Analiz
İş akışınızı, kullanıcılarınızı ve mevcut sistemlerinizi dinleriz; kapsamı, öncelikleri ve kabul ölçütlerini yazılı hâle getiririz.
Adım 02
Tasarım
Ekran akışlarını ve veri modelini çıkarırız. Arayüzü sizinle gözden geçirip onay almadan geliştirmeye geçmeyiz.
Adım 03
Geliştirme
Kısa döngülerle çalışırız; her döngü sonunda çalışan bir sürümü test ortamında görürsünüz.
Adım 04
Test
İşlevsel testler, entegrasyon testleri ve temel güvenlik kontrolleriyle hataları yayından önce yakalarız.
Adım 05
Yayın
Sunucu, alan adı, yedekleme ve izleme ayarlarını yaparak canlıya alırız; ekibinize kısa bir kullanım eğitimi veririz.
Adım 06
Bakım
İsterseniz bakım ve destek anlaşmasıyla güncellemeleri, izlemeyi ve yeni geliştirmeleri sürdürürüz.
07Teknoloji
Yüksek erişilebilirlik ile maliyet arasındaki denge
Her bileşeni ikiye katlamak, maliyeti ve işletme karmaşıklığını da katlar. Yüksek erişilebilirlik hedefini bu yüzden hizmet bazında belirleriz: müşterinin ödeme yaptığı akış en yüksek yedeklilikle, iç raporlama ekranı daha sade bir yapıyla çalışabilir. Bölgeler arası eş zamanlı çoğaltma gibi pahalı ve gecikme ekleyen seçenekler ancak iş gereksinimi bunu açıkça istediğinde gündeme gelir.
Devamını okuDaha az göster
Yüksek erişilebilirlik, felaket kurtarmanın yerini tutmaz. Hatalı bir güncelleme ya da silinen bir tablo, çoğaltma yüzünden saniyeler içinde tüm kopyalara yayılır. Bu nedenle mimariyi her zaman bağımsız yedekler, değişikliklerin geri alınabildiği bir dağıtım süreci ve sürekli izlemeyle birlikte tasarlarız.
08Çalışma modelleri
Bu hizmette çalışma modelleri
- 01
Proje bazlı
Sabit kapsam, sabit fiyat ve belirli teslim tarihi
Kapsamı belli, teslim tarihi olan işler için.
- Yazılı kapsam ve kabul ölçütleri
- Sabit fiyat ve belirli teslim tarihi
- Teslim ve kabul adımları sözleşmede
- 02
Bakım ve destek
Aylık sözleşmeli, SLA'lı bakım, destek ve geliştirme saati
Yayındaki bir sistemin sürekliliği için.
- Aylık sözleşme ve SLA
- İzleme, güncelleme ve hata düzeltme
- Aylık geliştirme saati
- 03
Danışmanlık
Saatlik veya günlük teknik danışmanlık
Karar, denetim veya yön belirleme gereken durumlar için.
- Saatlik veya günlük çalışma
- Yazılı rapor ve öneriler
- Ekibinizle birlikte çalışma
09Sık sorulan sorular
Yüksek erişilebilirlik mimarisi hakkında sık sorulan sorular
Yüksek erişilebilirlik mimarisi fiyatları neye göre belirlenir?
Hedeflenen erişilebilirlik düzeyi, kapsama alınan hizmet ve bileşen sayısı, mevcut uygulamanın durumsuz hâle getirilmesi için gereken değişiklik ve tek bölge mi çok bölge mi çalışılacağı belirleyicidir. Yedek kaynakların doğuracağı sürekli altyapı maliyetini de teklifte ayrıca gösteririz.
Uygulamamızı değiştirmeden yüksek erişilebilirlik sağlanabilir mi?
Bir kısmı sağlanabilir. Yük dengeleyici ve veritabanı kümelemesi çoğu zaman uygulamaya dokunmadan kurulur. Ancak oturum ya da dosyaları yerel diskte tutan uygulamalarda küçük kod değişiklikleri gerekir; bunlar analiz aşamasında belirlenir.
Felaket kurtarma planı ile farkı nedir?
Yüksek erişilebilirlik, tek bir bileşen ya da alan arızalandığında hizmetin kesintisiz ya da çok kısa kesintiyle sürmesini hedefler. Felaket kurtarma ise bölgenin tamamen kaybı, veri bozulması ya da fidye yazılımı gibi büyük olaylardan sonra sistemi yeniden kurmayı planlar. İkisi birbirini tamamlar.
Kendi veri merkezimizde de bu mimari kurulabilir mi?
Kurulabilir. Sanallaştırma kümeleri, yedekli ağ ve depolama, veritabanı kümelemesi ile benzer bir yapı elde edilir. İkinci bir lokasyon için bulutu yedek alan olarak kullanan hibrit bir yapı da değerlendirilebilir.
Bir yüksek erişilebilirlik mimarisi firması sistemin gerçekten dayanıklı olduğunu nasıl kanıtlar?
Tasarım belgesiyle değil, tatbikatla. Planlı pencerelerde bileşenleri kasıtlı olarak devre dışı bırakır, sistemin tepkisini ve kurtulma süresini ölçer, sonucu raporlarız. Tatbikatta bulunan eksikler kapatılmadan iş tamamlanmış sayılmaz.
Kurulumdan sonra mimarinin bakımı gerekir mi?
Gerekir. Yeni servisler eklendikçe tek arıza noktaları yeniden oluşabilir, sürüm yükseltmeleri kümeleme ayarlarını etkileyebilir. Dönemsel tatbikat ve gözden geçirme için bakım ve destek anlaşması yapılabilir.
10İlgili hizmetler