Ölçeklenebilir Yazılım Çözümleri

Ölçeklenebilir yazılım, işletmenin büyümesiyle birlikte artan yükü kaldırabilen sistemler tasarlamak demektir. Oplist'in başlangıçta 5 hastane ile başlayıp 200'den fazla hastanede çalışır hale gelmesi, bu konunun ne kadar kritik olduğunu gösteriyor.

Yanlış mimari seçim yapıldığında, sistem 10.000 eşzamanlı kullanıcıya çıktığında çöküş yaşanabilir. Bu rehberde, ölçeklenebilir bir yazılım sisteminin nasıl tasarlanacağını karar verici perspektifinden ele alacağız.

---

Ölçeklenebilirlik Nedir?

Ölçeklenebilirlik, sisteme daha fazla kullanıcı ve veri eklendiğinde performansın korunması veya artırılması anlamına gelir.

Bunun iki temel yolu var:

Dikey ölçeklendirme: Mevcut sunucuyu güçlendirmek (daha fazla CPU, RAM eklemek). Basit ve hızlı uygulanır, ancak fiziksel sınırları var ve pahalı. Tek bir hata noktası oluşturur.

Yatay ölçeklendirme: Sisteme daha fazla sunucu eklemek. Teorik olarak sınırsız büyüme sağlar ve maliyeti daha düşüktür, ancak veri senkronizasyonu gibi teknik zorluklar getirir.

Ölçeklenebilir sistemler genellikle yatay ölçeklendirmeyi tercih eder.

---

Monolitik Mimari vs Mikroservisler

Mimari seçimi, ölçeklenebilirlik stratejisinin temelidir.

Monolitik Mimari

Monolitik mimaride tüm işlevsellik tek bir uygulama içindedir. Web katmanı, API katmanı, iş mantığı ve veritabanı hepsi tek bir birim olarak çalışır.

Bu yaklaşımın avantajları basit dağıtım, hızlı geliştirme, kolay hata ayıklama ve tek veritabanı yönetimidir. Dezavantajları ise ölçeklendirme kısıtlılığı, bir bileşendeki hatanın tüm sistemi etkilemesi, teknoloji değişiminin zor olması ve büyüyen kod tabanının yönetim zorluğudur.

Mikroservis Mimarisi

Mikroservisler, her biri kendi görevini yapan küçük, bağımsız servislerdir. Örneğin kullanıcı servisi, randevu servisi ve ödeme servisi ayrı ayrı çalışır, her birinin kendi veritabanı vardır ve bir API Gateway üzerinden koordine edilir.

Avantajları: her servis bağımsız ölçeklenebilir, bir servis çökerse diğerleri çalışmaya devam eder, farklı teknolojiler kullanılabilir ve hızlı dağıtım yapılabilir. Dezavantajları ise yönetim karmaşıklığı (Kubernetes gibi araçlar gerektirir), dağıtık sistem sorunları, ağ gecikmeleri ve daha yüksek hosting maliyetidir.

Hangisini Seçmeli?

Faktör	Monolitik	Mikroservis
Başlangıç hızı	Çok hızlı	Yavaş
Ölçeklenebilirlik	Kısıtlı	Sınırsız
Hata yalıtımı	Zayıf	Güçlü
Dağıtım	Basit	Karmaşık
İşletme maliyeti	Düşük	Yüksek
Geliştirici sayısı	10'dan az	10 ve üzeri
Eşzamanlı kullanıcı	10.000'e kadar	10.000 ve üzeri

Genel tavsiyemiz: monolitik başlayın, büyüdükçe mikroservislere geçin. Bu geçiş "Strangle Fig Pattern" denilen bir yöntemle aşamalı olarak yapılabilir -- mevcut sistemi bir anda değiştirmek yerine, yeni özellikleri mikroservis olarak ekleyip eskilerini kademeli olarak taşırsınız.

---

CQRS: Okuma ve Yazma İşlemlerini Ayırmak

CQRS (Command Query Responsibility Segregation), yazma ve okuma işlemlerini iki ayrı kanal üzerinden yürütme yaklaşımıdır.

Neden gerekli? Çoğu uygulamada okuma işlemleri, yazma işlemlerinden çok daha fazladır. Bir sağlık sisteminde düşünün: günde binlerce kez doktor programı sorgulanır, ama yeni randevu oluşturma sayısı bunun çok altındadır. CQRS bu dengesizliği avantaja çevirir.

Yazma tarafında veriler ana veritabanına kaydedilir. Her yazma işlemi bir "olay" (event) üretir. Bu olay, okuma tarafındaki hızlı erişimli veritabanını (genellikle bir cache sistemi) günceller. Kullanıcılar veri okurken bu hızlı katmandan yanıt alır.

Avantajları: Okuma ve yazma bağımsız ölçeklenebilir. Okuma işlemleri cache sayesinde çok hızlı. Karmaşık sorgular optimize edilebilir.

Dezavantajları: Okuma ve yazma arasında kısa süreli veri gecikmesi olabilir (eventual consistency). Uygulama karmaşıklığı artar. Sağlık gibi kritik sistemlerde bu gecikme dikkatle yönetilmelidir.

---

Event-Driven Mimari: Servisler Arası İletişim

Event-driven (olay güdümlü) mimari, servisler arasında asenkron iletişim sağlar. Bir servis bir olay üretir, diğer servisler bu olayı dinleyip tepki verir.

Somut bir örnek: Bir randevu oluşturulduğunda "RandevuOluşturuldu" olayı yayınlanır. Bildirim servisi bu olayı dinler ve hastaya SMS ile e-posta gönderir. Ödeme servisi bu olayı dinler ve ödeme sürecini başlatır. Raporlama servisi bu olayı dinler ve istatistikleri günceller.

Bu yaklaşımda servisler birbirinden habersiz çalışır -- sadece olayları üretir ve dinler. Bu gevşek bağlılık (loose coupling), sistemin bakımını ve ölçeklendirmesini kolaylaştırır. Bir servise yeni bir dinleyici eklemek, mevcut servisleri değiştirmeyi gerektirmez.

Mesaj kuyruğu sistemleri (RabbitMQ, Apache Kafka gibi) bu iletişimi güvenilir şekilde yönetir. Mesajlar kuyrukta bekler, bir servis geçici olarak çökse bile mesaj kaybolmaz.

---

Veritabanı Ölçeklendirmesi

Veritabanı ölçeklendirmesi, ölçeklenebilir bir sistemin en kritik bileşenidir. Dört temel strateji vardır:

Strateji	Nasıl Çalışır	Avantajı	Dezavantajı
Read Replicas	Okuma işlemleri kopya veritabanlarına yönlendirilir	Okuma hızı artar	Yazma hala sınırlı
Sharding	Veri, birden fazla sunucuya bölüştürülür	Sınırsız ölçeklenme	Sunucular arası sorgu zorlaşır
Partitioning	Veri tarihe veya kategoriye göre bölünür	Sorgu performansı artar	Yönetim karmaşıklığı
NoSQL	MongoDB, Cassandra gibi sistemler kullanılır	Yüksek yazma performansı	ACID garantisi olmayabilir

Sağlık sistemi gibi bir projede sharding şu şekilde çalışabilir: hasta kimlik numarasına göre veriler farklı sunuculara dağıtılır. Hasta A'nın tüm verileri Sunucu 1'de, Hasta B'nin verileri Sunucu 2'de tutulur. Bu sayede her sunucu daha az veri yönetir ve sorgular daha hızlı çalışır.

---

Caching: Performansın Anahtarı

Cache (önbellek) stratejisi, performans artışının büyük bölümünü sağlar. İyi tasarlanmış bir cache sistemi, veritabanı yükünü %90'a kadar azaltabilir.

Cache katmanlı çalışır. İlk katman tarayıcı önbelleğidir (genellikle 1 gün). İkinci katman CDN önbelleğidir (genellikle 1 saat). Üçüncü katman uygulama önbelleğidir -- Redis gibi bir araçla (genellikle 5 dakika). Ancak bu katmanların hiçbirinde veri bulunamazsa, son çare olarak veritabanına sorgu yapılır.

Cache'in en zor tarafı "geçersiz kılma" (invalidation) stratejisidir:

Strateji	Tanım	Ne Zaman Kullanılır
TTL (Time To Live)	Belirli süre sonra otomatik sil	Veri güncelliği çok kritik değilse
Event-Based	Veri değiştiğinde cache'i sil	Sağlık uygulamaları gibi güncel veri gereken sistemler
LRU (Least Recently Used)	En az kullanılan veriyi sil	Bellek sınırı varsa

---

Cloud-Native Tasarım

Modern ölçeklenebilir sistemler genellikle bulut tabanlı (cloud-native) tasarlanır. Bu yaklaşımda Kubernetes gibi orkestrasyon araçları, uygulama kopyalarını otomatik olarak yönetir.

Örneğin, bir randevu servisi normalde 3 kopya (instance) olarak çalışabilir. CPU kullanımı %70'i aştığında Kubernetes otomatik olarak yeni kopyalar ekler, yük azaldığında kopyaları kaldırır. Bu "otomatik ölçeklendirme" (auto-scaling) sayesinde hem performans korunur hem de gereksiz kaynak harcanmaz.

Her kopya düzenli olarak sağlık kontrolünden (health check) geçer. Yanıt veremeyen bir kopya otomatik olarak yeniden başlatılır. Bu sayede sistem kesintisiz çalışır.

---

Ölçeklenebilirlik Testleri

Ölçeklenebilir bir sistem, canlı ortama çıkmadan önce mutlaka yük testi (load testing) ile doğrulanmalıdır.

Yük testi, sisteme binlerce eşzamanlı kullanıcı simüle ederek yapılır. Apache JMeter, k6 veya Locust gibi araçlar kullanılabilir. Tipik bir test senaryosunda 1.000 eşzamanlı kullanıcı 60 saniye boyunca API'ye istek gönderir. Yanıt süresi, hata oranı ve kaynak kullanımı ölçülür.

Canlı ortamda ölçeklenebilirlik sorunu yaşamak, hem kullanıcı kaybına hem de itibar zararına yol açabilir. Bu nedenle yük testleri düzenli olarak tekrarlanmalıdır.

---

Sık Sorulan Sorular

Monolitikten mikroservislere geçiş ne kadar sürer?
Küçük ekipler için 3-6 ay, büyük sistemler için 6-12 ay veya daha uzun. Aşamalı geçiş (Strangle Fig Pattern) önerilir.

CQRS'in dezavantajı nedir?
Okuma ve yazma arasında kısa süreli veri gecikmesi olabilir. Sağlık sistemleri gibi kritik uygulamalarda bu gecikme dikkatle yönetilmelidir.

Redis ve Memcached arasındaki fark nedir?
Redis daha zengin veri tipleri ve kalıcılık desteği sağlar. Memcached daha basit ve hafiftir. Çoğu projede Redis tercih edilir.

Kubernetes zorunlu mu?
Küçük uygulamalar Docker Compose ile çalışabilir. Mikroservis mimarisi ve yüksek trafik durumlarında Kubernetes önerilir.

Ölçeklenebilir yazılım ne kadara mal olur?
Monolitik başlangıç: 50.000-150.000 TL. Mikroservis altyapısı: 150.000-500.000 TL ve üzeri.

İlk günden mikroservis yapmalı mıyım?
Hayır. Monolitik başlayın, ürün-pazar uyumunu kanıtlayın, sonra ihtiyaca göre mikroservislere geçin.

Tek hata noktasını (single point of failure) nasıl önlerim?
Yük dengeleme (load balancing), yedeklilik (redundancy), otomatik geçiş (failover), sağlık kontrolleri ve devre kesici (circuit breaker) mekanizmaları kullanılır.

AWS, Azure ve Google Cloud arasında nasıl seçim yapmalıyım?
AWS pazar lideri ve en geniş hizmet yelpazesine sahip. Azure, Microsoft ekosistemiyle entegrasyonda güçlü. Google Cloud, makine öğrenmesi ve veri analitiğinde öne çıkıyor. Projenin ihtiyaçlarına göre değerlendirilmeli.

---

Sonuç

Ölçeklenebilir yazılım tasarımı başlangıçta yatırım gerektirir, ancak uzun vadede maliyetin geri kazanılmasını ve hızlı büyümeyi mümkün kılar.

Önerdiğimiz yol haritası üç aşamadan oluşuyor. Başlangıçta monolitik mimari, tek veritabanı ve basit bir yapı ile hızla piyasaya çıkın. Büyüme aşamasında veritabanı kopyaları, cache katmanları ve yük dengeleme ekleyin. Ölçeklendirme aşamasında ise mikroservislere geçiş, Kubernetes ile orkestrasyon ve event-driven mimari ile sınırsız büyüme altyapısını kurun.

Smart Maple olarak startup'tan kurumsal projelere kadar ölçeklenebilir mimariler tasarlıyor ve uyguluyoruz.

Daha fazla bilgi için: smart-maple.com