Fiziksel mimari katmanı tasarımı: client-server, cloud, nonfunctional gereksinimler

Analiz bitti, modeller dengelendi. Tasarımda ilk büyük karar: bu yazılım hangi makinelerde çalışacak ve parçaları nasıl dağıtılacak? Fiziksel mimari katmanı (physical architecture layer) bu soruya cevap verir. Kararı belirleyen şey, 5. haftada topladığın nonfunctional gereksinimlerdir: performans, güvenlik, operasyonel ortam, kültürel ve politik kısıtlar. Sınavda mimari türlerinin karşılaştırması, cloud modelleri ve “bu gereksinimler için hangi mimari” senaryosu gelir; bazen bir erişilebilirlik hesabı.

Altın kurallar:

1. Her uygulamanın dört işi var: veri saklama, veri erişimi, iş mantığı, sunum. Mimari bunların nerede çalıştığıdır.
2. Thin client = sadece sunum. İş mantığı sunucudadır.
3. Nonfunctional gereksinim mimariyi seçer, tersi değil.
4. Erişilebilirlik hesabı: kesinti = toplam süre × (1 − oran). Seri bileşenlerde oranlar çarpılır.

Dört temel bileşen

Mimari türleri

Server-based architecture

Dört bileşenin hepsi merkezi bir sunucuda (eskiden mainframe) çalışır; istemci sadece tuşları gönderen ve ekranı gösteren bir terminaldir.

• Artı: merkezi kontrol, güvenlik, tek yerde bakım.
• Eksi: sunucu darboğaz olur, büyütmek pahalı ve kademeli değil (yeni ve çok daha büyük sunucu almak gerekir).

Client-based architecture

İstemci sunum, iş mantığı ve veri erişimini yapar; sunucu sadece dosyaları saklar (dosya sunucusu).

• Artı: basit, geliştirmesi kolay.
• Eksi: bütün veri ağ üzerinden istemciye taşınır, ağ yükü büyük; çok kullanıcıda performans düşer.

Client-server architecture

İş bölünür: istemci sunumdan sorumludur, sunucu verilerden; iş mantığı ikisine ya da ayrı sunuculara dağıtılır.

Two-tier
[Client: presentation + app logic]
          |
[DB server: data access + storage]

Three-tier
[Client: presentation]
          |
[App/web server: application logic]
          |
[DB server: data access + storage]

N-tier
[Client] - [Web srv] - [Order svc]
                     - [Payment svc]
                     - [DB server]

Middleware, farklı katmanlardaki yazılımların birbiriyle konuşmasını sağlayan ara yazılımdır (mesaj kuyrukları, API ağ geçitleri).

Thin vs thick client: Thin client sadece sunum yapar (web tarayıcısı). Thick (fat) client iş mantığının bir kısmını da çalıştırır (bazı masaüstü ya da mobil uygulamalar). Thin client’ın bakımı kolaydır; thick client çevrimdışı çalışabilir ve sunucu yükünü azaltır.

Karşılaştırma

Cloud computing

Donanım ve yazılım kaynakları internet üzerinden, kullandıkça öde modeliyle kiralanır. Temelinde virtualization vardır: bir fiziksel sunucu birden çok sanal makineyi çalıştırır.

Artıları: ilk yatırım düşük, hızlı büyüme (elasticity), bakım sağlayıcıda. Eksileri: sağlayıcıya bağımlılık (vendor lock-in), verinin nerede durduğu (yasal uyum), uzun vadede maliyet, internet bağlantısına bağımlılık.

Diğer kavramlar: ubiquitous computing / Internet of Things (sensörler, turnikeler, akıllı cihazlar sisteme bağlanır), green IT (enerji verimliliği, sanallaştırma ile daha az fiziksel sunucu).

Nonfunctional gereksinimlerden mimariye

Erişilebilirlik hesabı

Erişilebilirlik (availability) sistemin kullanılabilir olduğu zamanın oranıdır. Bir yıl 365 × 24 = 8,760 saattir.

$\text{izin verilen kesinti} = 8760 \times (1 - A)$

A        Yıllık kesinti
99%      87.6 saat
99.5%    43.8 saat
99.9%    8.76 saat  (525.6 dk)
99.99%   52.56 dk

Seri bileşenler: Web sunucusu (%99) ve veritabanı (%99.5) birlikte çalışmak zorundaysa:

$A = 0.99 \times 0.995 = 0.98505 \approx \%98.5$

Toplam, en zayıf halkadan bile düşük. Çözüm: yedekli (redundant) sunucular, yük dengeleyici.

Kapasite tahmini

Kampüs yemek uygulamasında öğle arası 2,000 aktif kullanıcı, kişi başı dakikada yaklaşık 5 istek:

2,000 x 5 = 10,000 istek/dk
10,000 / 60 ≈ 166.67 istek/sn

Sunucu seçimi bu tepe değere ve bir güvenlik payına göre yapılır.

Çözümlü örnek: FitHub için mimari kararı

Gereksinimler:

• O1. Üyeler mobil uygulama ve web üzerinden erişir; turnikeler (IoT) check-in yapar. (operational)
• P1. Akşam 18:00-21:00 arası 5 şubede eşzamanlı 1,500 kullanıcı. (performance)
• P2. %99.9 erişilebilirlik; turnike çalışmazsa üye içeri giremez. (performance)
• S1. Kart verisi saklanmayacak, ödeme dış sağlayıcıda. (security)
• C1. Kişisel veriler Türkiye’deki ya da KVKK’ya uygun bir bölgede saklanacak. (cultural and political)

Karar: Three-tier (n-tier) client-server, PaaS üzerinde.

Deployment diagram

+------------------+     +-------------------+
| <<device>>       |     | <<device>>        |
| Member phone     |     | Turnstile (IoT)   |
| [fithub.apk]     |     | [gate-agent]      |
+--------+---------+     +---------+---------+
         | HTTPS                   | HTTPS
         v                         v
+--------------------------------------------+
| <<execution env>> PaaS app tier (x3)       |
| [fithub-api.jar]                           |
+--------------------+-----------------------+
                     | TCP (private network)
+--------------------v-----------------------+
| <<node>> Managed DB (primary + replica)    |
+--------------------------------------------+

Node (küp; burada kutu) donanım ya da çalışma ortamıdır, köşeli parantezdekiler artifact’lardır, oklar communication path.

Donanım ve yazılım spesifikasyonu

Tasarımın çıktılarından biri, satın alınacak ya da kiralanacak kaynakların listesidir:

Spesifikasyon tedarikçilere (vendor) gönderilir; teklifler fiyat, performans, destek ve güvenilirliğe göre karşılaştırılır. Bütün maliyet hesaba katılır: lisans, kurulum, eğitim, bakım (total cost of ownership).

Sık yapılan hatalar