Otomatik ölçeklendirme: yatay mı dikey mi

Otomatik ölçeklenebilirlik nedir ve neden ihtiyacınız var?

Web sitenizin veya hizmetinizin trafiği aniden birkaç katına çıktığında ne olur? Altyapınız manuel olarak yönetiliyorsa, ya ciddi yavaşlamalarla karşılaşırsınız ya da en kötü durumda hizmet erişilemez hale gelir. Ölçeklenebilirlik (Scalability), sistemin artan yüke yanıt verebilme yeteneğidir ve otomatik ölçeklenebilirlik (Auto Scaling), bu sürecin insan müdahalesi olmadan ve önceden tanımlanmış kurallara göre gerçekleştirilmesidir.

Ölçeklenebilirlik için iki ana yaklaşım vardır: yatay (Horizontal) ve dikey (Vertical). Bu ikisi arasındaki seçim, hizmetinizin maliyetini, karmaşıklığını ve sürdürülebilirliğini doğrudan etkileyen en önemli mimari kararlardan biridir. Bu makalede, her iki yaklaşımı da teknik ayrıntılarıyla inceleyeceğiz, her birinin mimari ön koşullarını belirleyeceğiz ve son olarak ekiplerin genellikle düştüğü yaygın tuzakları gerçek örneklerle göstereceğiz.

Dikey Ölçeklenebilirlik (Vertical Scaling): Basit ama Sınırlı

Dikey ölçeklenebilirlikte, tek bir sunucunun gücünü artırırsınız: daha fazla RAM, daha güçlü CPU, daha hızlı disk (NVMe) veya daha yüksek hızlı ağ. Bu yönteme aynı zamanda Scale Up da denir. Örneğin, sunucunuzda 4 CPU çekirdeği ve 8 GB RAM varsa, bunu 16 çekirdek ve 64 GB RAM'e yükseltirsiniz.

Dikey ölçeklendirmenin avantajları

• Basitlik: Kodda veya uygulama mimarisinde hiçbir değişiklik gerekmez. Aynı sunucu, sadece daha güçlü hale gelir.
• Daha düşük operasyonel maliyetler: Birden fazla sunucu, Load Balancer veya düğümler arasında veri senkronizasyonu yönetmenize gerek yoktur.
• Tam uyumluluk: Baştan itibaren tek örnekli çalışacak şekilde tasarlanmış Legacy uygulamalar için mümkün olan tek seçenek olabilir.

Dikey ölçeklendirmenin dezavantajları ve sınırlamaları

• Donanım sınırı: Her sunucunun fiziksel bir sınırı vardır. Bir sunucuyu sonsuza kadar yükseltemezsiniz. Mevcut en büyük sunucuların bile belirli bir sınırı vardır.
• Tek Hata Noktası (Single Point of Failure): Aynı sunucuda donanımsal bir sorun olursa, tüm hizmet kaybolur.
• Doğrusal olmayan maliyet: Büyük sunucuların fiyatı üstel olarak artar. 64 çekirdekli bir sunucu genellikle 16 çekirdekli bir sunucunun 4 katı değil, birkaç katı maliyete sahiptir.
• Yükseltme için Downtime: Çoğu durumda, kaynak yükseltme sunucunun yeniden başlatılmasını gerektirir, bu da birkaç dakikalık hizmet kesintisi anlamına gelir.

Dikey ölçeklendirme ne zaman doğru seçimdir?

Trafiğiniz nispeten öngörülebilirse, keskin dalgalanmalar yoksa ve uygulamanız tek örnekli olarak yazılmışsa (birçok geleneksel PHP veya Node.js uygulaması gibi), dikey ölçeklendirme en basit ve en ekonomik seçenektir. Ayrıca, güçlü işlemler gerektiren ilişkisel veritabanları için dikey ölçeklendirme genellikle ilk tercihtir.

Yatay Ölçeklenebilirlik (Horizontal Scaling): Dağıtılmış Güç

Yatay ölçeklenebilirlikte, bir sunucuyu güçlendirmek yerine sunucu sayısını artırırsınız. Bu yönteme Scale Out denir. Bir sunucu saniyede 1000 isteğe yanıt veriyorsa, 5 sunucu ile 5000 isteği yönetebilirsiniz. Bu yaklaşım, modern Cloud-Native mimarilerin temelidir.

Yatay ölçeklendirmenin avantajları

• Neredeyse sınırsız ölçeklenebilirlik: Ağ altyapısı izin verdiği sürece daha fazla sunucu ekleyebilirsiniz.
• Yüksek hata toleransı: Sunuculardan biri arızalanırsa, diğerleri çalışmaya devam eder ve trafik aralarında dağıtılır.
• Doğrusal maliyet: Her birimin (sunucu) maliyeti sabittir. 10 sunucu, tam olarak bir sunucunun 10 katı maliyete sahiptir, daha fazla değil.
• Otomatik ölçeklenebilirlikte esneklik: Bir sunucu eklemek veya çıkarmak, donanım yükseltmekten çok daha basittir ve genellikle kesinti olmadan yapılır.

Yatay ölçeklendirmenin zorlukları

• Mimari karmaşıklık: Uygulamanız Stateless olmalıdır, yani sunucunun yerel belleğinde hiçbir veri saklanmamalıdır. Oturumlar Redis veya merkezi bir veritabanında tutulmalıdır.
• Load Balancer ihtiyacı: Trafiği sunucular arasında dağıtmak için bir yük dengeleme katmanına ihtiyacınız vardır.
• Veri yönetimi: Bir veritabanı kullanıyorsanız, her birinin kendine özgü karmaşıklıkları olan Replication ve Sharding arasında bir seçim yapmalısınız.
• Daha zor hata ayıklama: Bir hata oluştuğunda, birden fazla sunucunun günlüklerini incelemeniz ve Correlation ID'leri takip etmeniz gerekir.

Yatay ölçeklendirme için mimari ön koşullar

Yatay ölçeklenebilirliği kullanabilmek için mimarinizin aşağıdaki koşulları sağlaması gerekir:

1. Stateless olma: Yerel dosya sisteminde veya sunucu belleğinde hiçbir veri saklanmamalıdır. Yüklenen dosyalar S3 veya MinIO gibi Object Storage üzerinde tutulmalıdır.
2. Merkezi oturum yönetimi: Oturumlar, sunucunun kendi belleğinde değil, Redis veya Memcached'de tutulmalıdır.
3. Ölçeklenebilir veritabanı: Veritabanı Master-Slave veya Cluster olarak yapılandırılmalıdır. Yoğun yazma işlemleri için Sharding gereklidir.
4. Health Check: Load Balancer, her sunucunun sağlığını kontrol edebilmeli ve arızalı sunucuları döngüden çıkarabilmelidir.

Pratik Karşılaştırma: Hangi Yaklaşım Sizin İçin Uygun?

Karar vermek için üç ana faktörü göz önünde bulundurmalısınız: trafik deseni, uygulamanın doğası ve bütçe.

Trafik deseni

Trafiğinizde keskin dalgalanmalar varsa (belirli gecelerdeki e-ticaret siteleri veya önemli haberlerin yayınlandığı haber hizmetleri gibi), yatay otomatik ölçeklendirme en iyi seçenektir. CPU %70'in üzerine çıkarsa yeni bir sunucu eklenmesi gibi bir kural tanımlayabilirsiniz. Dikey ölçeklendirmede bu pratik olarak imkansızdır çünkü donanım yükseltme zaman alır ve hızlıca azaltamazsınız.

Uygulamanın doğası

WebSocket veya çevrimiçi oyunlar gibi gerçek zamanlı uygulamalar, bağlantı durumunu koruma ihtiyacı nedeniyle yatay ölçeklendirmeyi zorlaştırır. Bu durumlarda, genellikle kendi sınırlamaları olan Sticky Session kullanılır. Batch Processing ve Queue tabanlı uygulamalar genellikle kolayca yatay olarak ölçeklenir.

Maliyetler

İstikrarlı ve az dalgalanan yükler için dikey ölçeklendirme genellikle daha ucuzdur çünkü Load Balancer maliyeti ve birden fazla sunucu yönetiminin karmaşıklığı yoktur. Ancak değişken yükler için yatay ölçeklendirme daha ekonomiktir çünkü düşük yük saatlerinde sunucu sayısını azaltabilir ve daha az maliyet ödeyebilirsiniz.

Pratik Örnekle Otomatik Ölçeklenebilirlik Uygulaması

Linux sunucularda çalışan bir web hizmetiniz olduğunu ve yatay otomatik ölçeklenebilirlik uygulamak istediğinizi varsayalım. Ana adımlar şu şekildedir:

1. Load Balancer Kurulumu

Öncelikle bir Load Balancer'a sahip olmalısınız. Nginx ile bunu kolayca yapabilirsiniz:

upstream backend {
    least_conn;
    server 10.0.0.11:8080 max_fails=3 fail_timeout=30s;
    server 10.0.0.12:8080 max_fails=3 fail_timeout=30s;
    server 10.0.0.13:8080 max_fails=3 fail_timeout=30s;
}

server {
    listen 80;
    location / {
        proxy_pass http://backend;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
    }
}

Bu yapılandırmada Nginx, trafiği üç sunucu arasında dağıtır ve bir sunucu art arda üç kez hata verirse, 30 saniye boyunca döngüden çıkarılır.

2. Otomatik Ölçeklenebilirlik Kuralının Tanımlanması

Otomatik ölçeklenebilirlik için Kubernetes Horizontal Pod Autoscaler veya bulut sağlayıcılarının Auto Scaling hizmetleri gibi araçları kullanabilirsiniz. Kubernetes'te basit bir kural tanımı şu şekildedir:

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: my-app-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: my-app
  minReplicas: 2
  maxReplicas: 10
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 70

Bu kural, pod'ların ortalama CPU kullanımı %70'in üzerine çıkarsa pod sayısını artır (10'a kadar) ve düşerse azalt (en az 2'ye kadar) der.

3. Veritabanı Yönetimi

MySQL kullanıyorsanız, yatay ölçeklendirme için Replication kurmanız gerekir. Master-Slave yapılandırmasının basit bir örneği:

-- Master sunucuda
[mysqld]
server-id = 1
log_bin = /var/log/mysql/mysql-bin.log
binlog_do_db = myapp

-- Slave sunucuda
[mysqld]
server-id = 2
relay-log = /var/log/mysql/mysql-relay-bin.log

Ardından Slave üzerinde şu komutu çalıştırın:

CHANGE MASTER TO
  MASTER_HOST='10.0.0.20',
  MASTER_USER='replica',
  MASTER_PASSWORD='secret',
  MASTER_LOG_FILE='mysql-bin.000001',
  MASTER_LOG_POS= 107;
START SLAVE;

Önemli not: Yalnızca okuma (SELECT) işlemlerini Slave'lere yönlendirin ve yazma (INSERT/UPDATE) işlemlerini Master'da tutun.

Otomatik Ölçeklenebilirlikte Yaygın Tuzaklar

Birçok ekip, otomatik ölçeklenebilirliği uyguladıktan sonra beklenmedik sorunlarla karşılaşır. İşte en yaygın tuzaklar:

Tuzak 1: Oturum ve State'i Göz Ardı Etmek

Uygulamanızın oturumu yerel bellekte sakladığını varsayalım. Load Balancer, kullanıcının isteğini başka bir sunucuya yönlendirdiğinde, kullanıcı sistemden çıkar. Çözüm: Oturumu Redis'e taşıyın. Node.js ve Express ile basit bir örnek:

const session = require('express-session');
const RedisStore = require('connect-redis')(session);

app.use(session({
    store: new RedisStore({ host: 'redis.internal', port: 6379 }),
    secret: 'your-secret-key',
    resave: false,
    saveUninitialized: false
}));

Tuzak 2: Veritabanı Ölçeklendirmeyi Unutmak

Birçok ekip yalnızca uygulama sunucularını ölçekler ancak veritabanını tek sunucuda tutar. Sonuç: Uygulama hızlanır ancak veritabanı darboğaz haline gelir. Veritabanınız %100 CPU'ya ulaştıysa, daha fazla uygulama sunucusu eklemek hiçbir işe yaramaz. Önce veritabanını ölçeklendirmelisiniz.

Tuzak 3: Aşırı Dalgalanma (Thrashing)

Ölçeklenebilirlik kuralını çok hassas ayarlarsanız, sistem sürekli sunucu ekleyip çıkarabilir. Bu, ek maliyete ve istikrarsızlığa neden olur. Bunu önlemek için Cooldown Period kullanın. Kubernetes'te, pod'ların hızlıca kaldırılmasını önlemek için --horizontal-pod-autoscaler-downscale-stabilization parametresini artırabilirsiniz.

Tuzak 4: Cold Start'ı Göz Ardı Etmek

Yeni bir sunucu eklendiğinde, uygulamanın ayağa kalkması ve önbelleğinin (Cache) ısınması birkaç dakika sürer. Kuralınız çok geç tepki verirse, ilk birkaç dakika içinde hizmet hatalarla karşılaşır. Çözüm: Zaman veya takvim olaylarına dayalı önleyici ölçeklendirme (Proactive Scaling) kullanın. Örneğin, her gece saat 8'de trafiğin arttığını biliyorsanız, önceden sunucu ekleyin.

Özet ve Son Öneri

Yatay ve dikey ölçeklenebilirlik arasında seçim yapmak tek boyutlu bir karar değildir. Birçok başarılı sistem her ikisinin bir kombinasyonunu kullanır: ana veritabanı için dikey ölçeklendirme ve uygulama katmanı için yatay ölçeklendirme. Anahtar nokta, ölçeklenebilirliği sonradan eklenen bir özellik olarak görmemektir; baştan itibaren Stateless mimari ve Replication yapılabilir bir veritabanı tasarlarsanız, gelecekte daha fazla seçeneğiniz olur.

Yeni başladıysanız ve trafiğiniz düşükse, dikey ölçeklendirme ile başlayın. Ancak donanım sınırına yaklaştığınızda veya trafik dalgalanmanız arttığında, yatay ölçeklendirmeye geçişi planlayın. Bu süreçte, bulut altyapı yönetimi araçları size büyük ölçüde yardımcı olabilir; örneğin, ServerNet tarafından sunulan bulut hizmetleri, Auto Scaling kurallarını yerel olarak tanımlama imkanı sağlar, böylece manuel yönetim gerektirmeden altyapınız trafikle birlikte hareket eder.

Son olarak, ölçeklenebilirliğin yalnızca donanımla ilgili olmadığını unutmayın; doğru tasarım, sürekli izleme ve başarısızlığa hazırlıkla ilgilidir. Sisteminizi, bir bileşenin arızasının tüm sistemi çökertmeyeceği şekilde tasarlayın.