OpenLiteSpeed Reverse Proxy ve Backend Yönetimi

Modern web mimarilerinde tek bir sunucunun her şeyi halletmesi artık pek mümkün değil. Uygulama sunucuları, cache katmanları, mikroservisler derken ortaya karmaşık bir yapı çıkıyor. İşte tam bu noktada reverse proxy devreye giriyor ve OpenLiteSpeed bu işi hem performanslı hem de yönetilebilir şekilde yapıyor. Bu yazıda OLS’nin reverse proxy yeteneklerini derinlemesine inceleyeceğiz, gerçek dünya senaryolarıyla backend yönetimini ele alacağız.

OpenLiteSpeed Reverse Proxy Nedir ve Neden Kullanılır?

Reverse proxy, istemcilerden gelen istekleri alıp arkadaki backend sunuculara ileten bir aracı katmandır. Nginx veya Apache’nin bu konuda köklü bir geçmişi olsa da OpenLiteSpeed, event-driven mimarisi sayesinde yüksek eşzamanlı bağlantılarda çok daha az kaynak tüketiyor.

OLS ile reverse proxy kurduğunuzda şu avantajları elde edersiniz:

SSL termination: TLS handshake’i OLS üstlenir, backend düz HTTP konuşabilir
Load balancing: Birden fazla backend arasında trafik dağıtımı
Health check: Backend sunucuları otomatik izleme ve devre dışı bırakma
Cache entegrasyonu: LSCache ile backend yanıtlarını önbellekleme
Bağlantı havuzu: Backend bağlantılarını yeniden kullanarak gecikmeyi azaltma

Tipik kullanım senaryoları şunlar oluyor: Node.js uygulaması önüne OLS koymak, birden fazla PHP-FPM pool yönetmek, Django veya FastAPI servislerini dışarıya açmak, Kubernetes pod’larına trafik yönlendirmek.

Temel Reverse Proxy Yapılandırması

OLS’de reverse proxy yapılandırması iki yolla yapılır: WebAdmin GUI üzerinden veya doğrudan konfigürasyon dosyalarını düzenleyerek. Ben her ikisini de göstereceğim ama production’da dosya tabanlı yaklaşımı tercih ediyorum, çünkü git ile versiyonlayabiliyorsunuz.

OLS’nin ana konfigürasyon dosyası genellikle şu konumdadır:

/usr/local/lsws/conf/httpd_config.conf

Virtual host konfigürasyonları ise burada bulunur:

/usr/local/lsws/conf/vhosts/

Basit bir Node.js uygulaması için reverse proxy kurulumu yapalım. Diyelim ki 3000 portunda çalışan bir Express.js uygulamanız var.

# Virtual host konfigürasyon dosyası oluştur
mkdir -p /usr/local/lsws/conf/vhosts/myapp
nano /usr/local/lsws/conf/vhosts/myapp/vhconf.conf

Virtual host konfigürasyon dosyasının temel hali:

docRoot                   /var/www/myapp/public
enableGzip                1
enableBr                  1

context / {
  type                    proxy
  handler                 backend_nodejs
  addDefaultCharset       off
}

extprocessor backend_nodejs {
  type                    proxy
  address                 127.0.0.1:3000
  maxConns                100
  pcKeepAliveTimeout      60
  initTimeout             60
  retryTimeout            0
  respBuffer              0
}

Bu basit yapılandırma bile birçok şeyi otomatik halledecek. OLS, bağlantı havuzunu yönetecek, timeout’ları kontrol edecek ve hata durumlarını loglayacak.

Load Balancer Olarak Kullanım

Gerçek dünya senaryosuna geçelim. Bir e-ticaret sitesinde trafik artışlarını yönetmek için 3 adet uygulama sunucusu kurduğunuzu varsayalım. OLS’yi load balancer olarak yapılandıralım:

# /usr/local/lsws/conf/vhosts/ecommerce/vhconf.conf

docRoot                   /var/www/ecommerce/public
enableGzip                1

extprocessor app_server_1 {
  type                    proxy
  address                 192.168.1.101:8080
  maxConns                300
  pcKeepAliveTimeout      60
  initTimeout             60
  retryTimeout            300
  respBuffer              0
}

extprocessor app_server_2 {
  type                    proxy
  address                 192.168.1.102:8080
  maxConns                300
  pcKeepAliveTimeout      60
  initTimeout             60
  retryTimeout            300
  respBuffer              0
}

extprocessor app_server_3 {
  type                    proxy
  address                 192.168.1.103:8080
  maxConns                300
  pcKeepAliveTimeout      60
  initTimeout             60
  retryTimeout            300
  respBuffer              0
}

vhssl {
  keyFile                 /etc/letsencrypt/live/shop.example.com/privkey.pem
  certFile                /etc/letsencrypt/live/shop.example.com/fullchain.pem
  certChain               1
  sslProtocol             24
  ciphers                 ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256
}

Load balancer grubunu ayrı bir cluster olarak tanımlamak daha temiz bir yaklaşım:

# httpd_config.conf içine eklenecek cluster tanımı

extprocessor app_cluster {
  type                    loadbalancer
  children                app_server_1, app_server_2, app_server_3
  loadbalance             roundrobin
}

context / {
  type                    proxy
  handler                 app_cluster
  addDefaultCharset       off
}

loadbalance parametresi için seçenekler şunlar:

roundrobin: Sıralı dağıtım, en basit yöntem
leastconn: En az aktif bağlantıya sahip sunucuya yönlendir
random: Rastgele dağıtım
static: İlk sunucu her zaman öncelikli, diğerleri yedek

Üretim ortamında genellikle leastconn tercih ediyorum. Özellikle işlem süreleri değişken olan uygulamalarda daha adil bir dağıtım sağlıyor.

Health Check ve Otomatik Failover

Backend sunuculardan birinin çökmesi durumunda trafiği otomatik olarak yönlendirmek kritik önem taşır. OLS’nin health check mekanizması bunu hallediyor:

extprocessor app_server_1 {
  type                    proxy
  address                 192.168.1.101:8080
  maxConns                300
  pcKeepAliveTimeout      60
  initTimeout             60
  retryTimeout            300
  respBuffer              0
  
  # Health check ayarları
  pingPath                /health
  pingInterval            10
  pingTimeout             5000
  persistConn             1
}

Uygulama tarafında basit bir health check endpoint’i olması gerekiyor. Node.js için örnek:

# Express.js health check endpoint
cat > /var/www/myapp/health.js << 'EOF'
app.get('/health', (req, res) => {
  // Veritabanı bağlantısını da kontrol edebilirsiniz
  const healthCheck = {
    status: 'UP',
    timestamp: new Date().toISOString(),
    uptime: process.uptime()
  };
  
  try {
    res.status(200).json(healthCheck);
  } catch (error) {
    healthCheck.status = 'DOWN';
    res.status(503).json(healthCheck);
  }
});
EOF

OLS, pingPath endpoint’ine belirtilen aralıklarla istek gönderir. Yanıt gelmezse veya HTTP 5xx dönerse sunucuyu devre dışı bırakır, retryTimeout süresi dolunca tekrar dener.

Header Yönetimi ve Pass-Through Yapılandırması

Reverse proxy kullanırken backend uygulamanızın gerçek IP adresini görmesi önemli. Aksi takdirde tüm istekler OLS’nin IP’sinden geliyormuş gibi görünür, log analizleri anlamsızlaşır, rate limiting çalışmaz.

context / {
  type                    proxy
  handler                 app_cluster
  addDefaultCharset       off
  
  # Gerçek IP'yi ilet
  extraHeaders            set X-Real-IP $remote_addr
  extraHeaders            set X-Forwarded-For $remote_addr
  extraHeaders            set X-Forwarded-Proto $scheme
  extraHeaders            set X-Forwarded-Host $host
}

Backend uygulamanızın bu header’ları okuması gerekiyor. Nginx ile çalışanlara tanıdık gelecek bu yapı, OLS’de de aynı şekilde çalışıyor.

Güvenlik açısından önemli bir nokta: Backend’den dönen bazı header’ları gizlemek isteyebilirsiniz. Örneğin uygulama framework’ünüzü ifşa eden header’lar:

# Rewrite kurallarıyla güvenlik header'ları ekle ve istenmeyen header'ları kaldır
rewrite  {
  rules                   <<<END_rules
  RewriteRule ^(.*)$ $1 [L,E=LSWS_HEADER:X-Powered-By:]
  END_rules
}

WebSocket Desteği

Modern uygulamaların büyük çoğunluğu WebSocket kullanıyor. Canlı bildirimler, gerçek zamanlı güncelleme, chat uygulamaları… OLS’de WebSocket desteği için özel bir yapılandırma gerekiyor:

extprocessor websocket_backend {
  type                    proxy
  address                 127.0.0.1:3001
  maxConns                1000
  pcKeepAliveTimeout      3600
  initTimeout             60
  retryTimeout            0
  respBuffer              0
}

context /ws {
  type                    proxy
  handler                 websocket_backend
  addDefaultCharset       off
}

context /socket.io {
  type                    proxy
  handler                 websocket_backend
  addDefaultCharset       off
}

WebSocket bağlantıları uzun süreli tutulur, bu yüzden pcKeepAliveTimeout değerini yüksek tutmak önemli. Ben genellikle 3600 (1 saat) ya da daha fazla veriyorum, uygulamanın ihtiyacına göre.

Path Tabanlı Yönlendirme

Mikroservis mimarisinde farklı path’leri farklı backend’lere yönlendirmek çok yaygın. Örneğin /api trafiğini Node.js’e, /admin trafiğini ayrı bir servise, statik dosyaları ise direkt olarak sunmak:

# API servisi
extprocessor api_service {
  type                    proxy
  address                 127.0.0.1:3000
  maxConns                200
  pcKeepAliveTimeout      60
  initTimeout             30
  retryTimeout            300
  respBuffer              0
}

# Admin paneli
extprocessor admin_service {
  type                    proxy
  address                 127.0.0.1:4000
  maxConns                50
  pcKeepAliveTimeout      60
  initTimeout             30
  retryTimeout            300
  respBuffer              0
}

# Statik dosyalar için context
context /static {
  location                /var/www/myapp/static/
  allowBrowse             0
  enableExpires           1
  expiresDefault          A604800
}

# API yönlendirmesi
context /api {
  type                    proxy
  handler                 api_service
  addDefaultCharset       off
}

# Admin yönlendirmesi
context /admin {
  type                    proxy
  handler                 admin_service
  addDefaultCharset       off
}

Bu yapılandırmayla tek bir domain üzerinden birden fazla servisi yönetebilirsiniz. Frontend için CDN, API için uygulama sunucusu, yönetim paneli için ayrı bir servis – hepsi aynı OLS instance’ı üzerinden.

SSL Offloading ve Backend Güvenliği

SSL termination OLS’de yapıldığında backend’e düz HTTP gidiyor. Bu performans açısından avantajlı, ancak bazı durumlarda backend’e de HTTPS ile bağlanmak isteyebilirsiniz. Örneğin backend başka bir veri merkezindeyse:

extprocessor secure_backend {
  type                    proxy
  address                 https://backend.internal.example.com:443
  maxConns                100
  pcKeepAliveTimeout      60
  initTimeout             60
  retryTimeout            300
  respBuffer              0
}

Adresin başına https:// eklemek yeterli, OLS backend’e SSL ile bağlanacak.

İç ağda self-signed sertifika kullanıyorsanız sertifika doğrulamasını devre dışı bırakmanız gerekebilir. Bunu OLS WebAdmin’de extprocessor ayarlarından yapabilirsiniz. Ancak bu güvenlik riski oluşturur, production’da dikkatli olun.

Rate Limiting ve Güvenlik Katmanı

Reverse proxy konumundaki OLS, rate limiting için mükemmel bir yer. Backend’e gereksiz yük binmeden önce trafiği filtreleyebilirsiniz:

# httpd_config.conf içinde genel rate limiting
connTimeout               300
maxConnections            20000
maxSSLConnections         10000

# Virtual host bazında daha sıkı limitler
rewrite  {
  rules                   <<<END_rules
  RewriteCond %{REQUEST_URI} ^/api/login [NC]
  RewriteRule .* - [F,L]
  END_rules
}

OLS’nin mod_security entegrasyonu da bu katmanda devreye girebilir. Özellikle API gateway olarak kullandığınızda WAF özelliğini aktif etmek mantıklı.

Botları ve kötü niyetli tarayıcıları engellemek için:

# .htaccess veya vhconf.conf içinde
rewrite {
  rules <<<END_rules
  RewriteCond %{HTTP_USER_AGENT} (wget|curl|python-requests|Go-http-client) [NC]
  RewriteRule .* - [F,L]
  END_rules
}

Logging ve İzleme

Reverse proxy trafiğini izlemek için özel log formatı tanımlamak hayat kurtarır. Hangi backend’e ne kadar sürede cevap verdiğini görmek performans sorunlarını tespit etmek için kritik:

# httpd_config.conf içinde log formatı
log {
  useServer               0
  fileName                /usr/local/lsws/logs/myapp_access.log
  logFormat               "%h %l %u %t "%r" %>s %b "%{Referer}i" "%{User-Agent}i" %T/%D"
  logHeaders              5
  rollingSize             100M
  keepDays                30
  compressArchive         1
}

Log analizi için basit bir script:

#!/bin/bash
# Backend yanıt sürelerini analiz et
LOG_FILE="/usr/local/lsws/logs/myapp_access.log"

echo "=== En Yavaş 10 İstek ==="
awk '{print $NF, $7}' $LOG_FILE | sort -rn | head -10

echo ""
echo "=== 5xx Hataları ==="
grep '" 5' $LOG_FILE | awk '{print $9}' | sort | uniq -c | sort -rn

echo ""
echo "=== Saatlik İstek Dağılımı ==="
awk '{print $4}' $LOG_FILE | cut -d: -f2 | sort | uniq -c

Bu scripti cron’a ekleyip günlük rapor alabilirsiniz. Ben genellikle sabah 7’de çalıştırıp gece yarısından sonraki anormal trafiği sabah görüyorum.

Konfigürasyon Testi ve Graceful Reload

Değişiklik yaptıktan sonra OLS’yi yeniden başlatmadan konfigürasyonu test etmek isteyebilirsiniz:

# Konfigürasyon sözdizimini kontrol et
/usr/local/lsws/bin/lswsctrl configtest

# Graceful restart (mevcut bağlantıları kesmeden)
/usr/local/lsws/bin/lswsctrl restart

# Sadece konfigürasyonu yeniden yükle
kill -HUP $(cat /usr/local/lsws/admin/tmp/.lshttpd.pid)

Birden fazla sunucu yönetiyorsanız konfigürasyon değişikliklerini otomatize etmek için:

#!/bin/bash
# deploy_config.sh - OLS konfigürasyonunu güncelle ve test et

CONF_DIR="/usr/local/lsws/conf"
BACKUP_DIR="/backup/lsws-conf"

# Yedek al
TIMESTAMP=$(date +%Y%m%d_%H%M%S)
cp -r $CONF_DIR $BACKUP_DIR/conf_$TIMESTAMP

# Yeni konfigürasyonu uygula
cp /deploy/lsws-conf/* $CONF_DIR/vhosts/myapp/

# Sözdizimi kontrolü
if /usr/local/lsws/bin/lswsctrl configtest; then
  echo "Konfigürasyon geçerli, yeniden yükleniyor..."
  /usr/local/lsws/bin/lswsctrl restart
  echo "OLS başarıyla yeniden yüklendi"
else
  echo "HATA: Konfigürasyon geçersiz, önceki sürüme dönülüyor..."
  cp -r $BACKUP_DIR/conf_$TIMESTAMP/* $CONF_DIR/
  exit 1
fi

Gerçek Dünya Senaryosu: Django Uygulaması

Bir Django uygulamasını OLS arkasında çalıştıralım. Django, Gunicorn WSGI sunucusuyla birlikte çalışır ve OLS bu servisi reverse proxy olarak sunar:

# Gunicorn servisi systemd ile başlatılıyor
# /etc/systemd/system/gunicorn.service
cat > /etc/systemd/system/gunicorn.service << 'EOF'
[Unit]
Description=Gunicorn Django App
After=network.target

[Service]
User=www-data
Group=www-data
WorkingDirectory=/var/www/djangoapp
ExecStart=/var/www/djangoapp/venv/bin/gunicorn 
          --workers 4 
          --bind 127.0.0.1:8000 
          --timeout 120 
          --access-logfile /var/log/gunicorn/access.log 
          --error-logfile /var/log/gunicorn/error.log 
          djangoapp.wsgi:application
Restart=always

[Install]
WantedBy=multi-user.target
EOF

systemctl daemon-reload
systemctl enable gunicorn
systemctl start gunicorn

OLS virtual host konfigürasyonu:

# /usr/local/lsws/conf/vhosts/django/vhconf.conf

docRoot                   /var/www/djangoapp/static

extprocessor gunicorn_backend {
  type                    proxy
  address                 127.0.0.1:8000
  maxConns                50
  pcKeepAliveTimeout      300
  initTimeout             120
  retryTimeout            300
  respBuffer              0
}

# Statik dosyalar OLS'den direkt sunulsun
context /static {
  location                /var/www/djangoapp/staticfiles/
  allowBrowse             0
  enableExpires           1
  expiresDefault          A2592000
}

context /media {
  location                /var/www/djangoapp/media/
  allowBrowse             0
  enableExpires           1
  expiresDefault          A2592000
}

# Diğer her şeyi Django'ya yönlendir
context / {
  type                    proxy
  handler                 gunicorn_backend
  addDefaultCharset       off
}

Bu yapılandırmayla statik dosyalar doğrudan OLS tarafından sunulur, Django uygulamasına gereksiz yük binmez. Django’nun collectstatic komutuyla toplanan dosyalar staticfiles/ klasöründe olacak ve OLS bunları çok daha hızlı serve edecek.

Sonuç

OpenLiteSpeed’in reverse proxy yetenekleri, Nginx’e kıyasla belki daha az bilinse de gerçek anlamda kurumsal düzeyde özellikler sunuyor. Event-driven mimarisi sayesinde yüksek eşzamanlı bağlantılarda diğer sunuculardan daha az kaynak tüketiyor. Health check, load balancing, SSL offloading ve WebSocket desteği gibi özellikleri tek bir konfigürasyon dosyasında yönetebiliyorsunuz.

Buraya kadar anlattıklarımı özetlemek gerekirse: Path tabanlı yönlendirmeyle mikroservis mimarisi kurabilirsiniz, leastconn algoritmasıyla akıllı load balancing yapabilirsiniz, health check mekanizmasıyla otomatik failover sağlayabilirsiniz ve graceful reload ile zero-downtime deployment gerçekleştirebilirsiniz.

Eğer şu an Nginx veya Apache ile reverse proxy yapıyorsanız ve performans sıkıntısı yaşıyorsanız, OLS’yi test ortamında denemenizi kesinlikle tavsiye ederim. Geçiş süreci göründüğü kadar zor değil, konfigürasyon dili birkaç saatte oturuyor. Akıllıca yapılandırılmış bir OLS reverse proxy, backend sunucularınızın ömrünü ciddi ölçüde uzatacak.

OpenLiteSpeed ile Reverse Proxy ve Backend Yönetimi