Varnish Cache Nedir ve Nasıl Kurulur

Bir web sitesi büyüdükçe en görünür darboğaz genellikle uygulama katmanı olur. PHP her istekte veritabanına gider, şablonları derler, HTML üretir ve bunu tekrar tekrar yapar. Oysa bir haber sitesinin ana sayfası ya da bir kurumsal sitenin ürün listesi saniyeler içinde yüz kez istense bile çoğu ziyaretçiye aynı içeriği döner. İşte Varnish tam da bu tekrarı ortadan kaldırmak için tasarlanmış bir HTTP hızlandırıcıdır: üretilmiş bir sayfayı belleğe alır, aynı sayfa yeniden istendiğinde uygulama sunucusunu hiç rahatsız etmeden doğrudan RAM'den geri döner.

Bu yaklaşımın sonucu çoğu zaman çarpıcıdır. Backend'in yüz milisaniyede ürettiği bir sayfa, Varnish önbelleğinden birkaç milisaniyede servis edilir; sunucunun aynı anda taşıyabileceği eşzamanlı istek sayısı ise kat kat artar. Bu rehberde Varnish'in reverse proxy önbelleği olarak nasıl çalıştığını, backend tanımını, VCL diliyle hit/miss mantığını, TTL değerini, cookie ve giriş sayfalarını önbellekten nasıl dışarıda tutacağınızı, Nginx ve SSL ile nasıl katmanlayacağınızı ve WordPress ile birlikte kullanım notlarını uygulamalı örneklerle anlatacağım.

Varnish Cache Nedir ve Ne İşe Yarar#

Varnish Cache, web sunucunuzun (backend) önüne yerleşen bir reverse proxy ve HTTP önbellekleme katmanıdır. Ziyaretçiden gelen isteği önce Varnish karşılar; istenen içerik önbellekte varsa doğrudan bellekten döner, yoksa arkadaki gerçek sunucuya iletir, cevabı alır, kopyasını saklar ve ziyaretçiye gönderir. Bir sonraki aynı istek artık backend'e hiç ulaşmaz. Bu yüzden Varnish'e "HTTP accelerator" yani HTTP hızlandırıcı denir.

Önemli bir ayrım şudur: Varnish yalnızca HTTP trafiğini önbellekler. Redis ya da Memcached gibi araçlar uygulama içindeki nesneleri, veritabanı sorgu sonuçlarını veya oturum verilerini bellekte tutarken, Varnish tam sayfaları (ya da parçalarını) HTTP protokolü seviyesinde tutar. İkisi rakip değil, tamamlayıcıdır: Varnish sayfayı hiç üretmeden döner, Redis ise üretilmesi gereken sayfanın altındaki sorguları hızlandırır. Nesne önbelleğinin nasıl çalıştığını Redis rehberimizde daha ayrıntılı bulabilirsiniz.

Varnish'i özellikle şu senaryolarda düşünmelisiniz: yüksek trafikli içerik siteleri, kampanya dönemlerinde ani yük alan e-ticaret sitelerinin listeleme sayfaları, API yanıtlarının bir kısmının değişmediği servisler ve backend'i pahalı olan (ağır CMS'ler) kurulumlar. Buna karşılık her istekte kişiye özel çıktı üreten paneller, ödeme adımları ve gerçek zamanlı uygulamalar için önbellekleme kuralları çok daha dikkatli yazılmalıdır.

Varnish Nasıl Çalışır (Reverse Proxy Mantığı)#

Varnish'in kalbinde bir durum makinesi vardır. Gelen her istek vcl_recv ile başlar, oradan önbellekte arama (vcl_hash), bulunursa vcl_hit, bulunamazsa vcl_miss ve backend'e gidiş, backend cevabı geldiğinde vcl_backend_response, son olarak istemciye teslim için vcl_deliver aşamalarından geçer. Bu akışın her adımına VCL (Varnish Configuration Language) ile müdahale ederek "bu isteği önbelleğe alma", "şu cookie'yi yok say", "bu cevabı 10 dakika sakla" gibi kararlar verirsiniz.

Varsayılan olarak Varnish oldukça muhafazakârdır. HTTP standardına uyar: bir istekte Cookie başlığı varsa ya da cevap Set-Cookie içeriyorsa, o cevabı önbelleğe almaz; çünkü içeriğin kullanıcıya özel olabileceğini varsayar. GET ve HEAD dışındaki metodları (POST, PUT, DELETE) hiç önbelleklemez, backend'e geçirir. Bu güvenli varsayılan sayesinde yanlış yapılandırmada bile birinin sepetini başkasına gösterme riski en aza iner.

Önbellek "hit" olduğunda backend'e hiç gidilmez; bu Varnish'in asıl gücüdür. Backend çökmüş olsa bile, elinizde geçerli (ya da grace süresi içinde biraz bayat) bir kopya varsa Varnish siteyi ayakta tutmaya devam edebilir. Aşağıdaki tablo temel kavramları özetler.

Ubuntu Üzerinde Varnish Kurulumu#

Kuruluma geçmeden önce mimariyi netleştirin. Varnish HTTPS'i kendi başına sonlandırmaz; TLS sonlandırmayı önündeki Nginx (ya da bir yük dengeleyici) yapar, arkasında ise gerçek uygulama sunucusu durur. Klasik dizilim şudur: istemci, sonrasında TLS için Nginx (443), sonra Varnish (6081), sonra backend Nginx/Apache (8080). Bu katmanı birazdan ayrıntılandıracağız; şimdi Varnish'i kuralım.

Güncel bir Ubuntu sunucuda kurulum paket deposundan yapılır:

sudo apt update
sudo apt install varnish -y

# Sürümü ve servis durumunu doğrulayın
varnishd -V
sudo systemctl status varnish

Varnish'in hangi portu dinleyeceğini ve ne kadar bellek ayıracağını systemd servis birimiyle ayarlarsınız. Servis dosyasını doğrudan düzenlemek yerine bir override oluşturmak en temiz yoldur:

sudo systemctl edit varnish

Açılan dosyaya dinleme portunu ve önbellek boyutunu yazın. malloc,512m ifadesi 512 MB RAM'i önbelleğe ayırır; trafiğinize göre büyütebilirsiniz.

[Service]
ExecStart=
ExecStart=/usr/sbin/varnishd \
  -a :6081 \
  -f /etc/varnish/default.vcl \
  -s malloc,512m \
  -p thread_pool_min=50 \
  -p thread_pool_max=1000

Ardından yapılandırmayı yeniden yükleyip servisi başlatın:

sudo systemctl daemon-reload
sudo systemctl restart varnish
sudo systemctl enable varnish

# 6081'in dinlendiğini doğrulayın
sudo ss -tlnp | grep 6081

Bellek boyutunu belirlerken cömert davranın ama abartmayın: önbellek RAM'i tükendiğinde Varnish en az kullanılan nesneleri (LRU) atar, bu da hit oranını düşürür. Trafik büyüklüğüne uygun bir VDS ya da sanal sunucu seçmek burada belirleyicidir; ihtiyaçlarınıza göre bir plan seçmek için VDS sunucu ve sanal sunucu sayfalarımıza bakabilirsiniz.

Backend Tanımı ve VCL Temelleri#

Varnish'in yapılandırma dosyası /etc/varnish/default.vcl içindedir ve her şeyden önce bir backend tanımı ister. Backend, Varnish'in içeriği alacağı arka sunucudur; genellikle aynı makinede farklı bir portta çalışan Nginx ya da Apache olur. En temel tanım şöyledir:

vcl 4.1;

backend default {
    .host = "127.0.0.1";
    .port = "8080";
    .connect_timeout = 5s;
    .first_byte_timeout = 30s;
}

Backend'in sağlıklı olup olmadığını Varnish'in kendisinin izlemesini isterseniz bir sağlık kontrolü (probe) ekleyebilirsiniz. Probe belirli aralıklarla backend'e istek atar; başarısız olursa Varnish o backend'i "hasta" işaretleyip mümkünse grace süresince eski kopyaları servis etmeye devam eder.

probe saglik {
    .url = "/healthz";
    .interval = 5s;
    .timeout = 2s;
    .window = 5;
    .threshold = 3;
}

backend default {
    .host = "127.0.0.1";
    .port = "8080";
    .probe = saglik;
}

VCL'in temel yapı taşları sub bloklarıdır. En sık dokunacağınız iki blok vcl_recv (istek geldiğinde ne yapılacağı) ve vcl_backend_response (backend cevabı geldiğinde ne yapılacağı) bloklarıdır. Örneğin statik dosyaları her zaman önbelleklemek, admin yollarını hiç önbelleklememek için vcl_recv içinde koşullar yazarsınız. Değişikliklerinizi uygulamadan önce sözdizimini test etmek iyi bir alışkanlıktır:

# VCL sözdizimini derleyerek doğrula (servisi durdurmadan)
sudo varnishd -C -f /etc/varnish/default.vcl > /dev/null && echo "VCL gecerli"

# Sorunsuzsa servisi yeniden yükle
sudo systemctl reload varnish

Hit/Miss Mantığı, TTL ve Önbellek Kontrolü#

Bir cevabın ne kadar süre önbellekte kalacağını belirleyen değer TTL'dir. TTL'yi iki yerden yönetebilirsiniz: en doğrusu backend'in gönderdiği Cache-Control ve Expires başlıklarıdır. Backend Cache-Control: max-age=600 derse, Varnish o nesneyi 10 dakika taze sayar. Backend başlık göndermiyorsa ya da onu ezmek isterseniz, TTL'yi VCL içinde vcl_backend_response bloğunda beresp.ttl ile ayarlarsınız.

sub vcl_backend_response {
    # Statik varlıkları uzun süre sakla
    if (bereq.url ~ "\.(css|js|png|jpg|jpeg|gif|ico|woff2?|svg)$") {
        set beresp.ttl = 7d;
        unset beresp.http.Set-Cookie;
    }

    # Backend TTL vermediyse varsayılan makul bir değer ata
    if (beresp.ttl <= 0s) {
        set beresp.ttl = 2m;
        set beresp.grace = 1h;
    }
}

Buradaki grace çok değerlidir: TTL dolduktan sonra bile backend cevap veremiyorsa, Varnish grace süresi boyunca biraz bayat kopyayı servis eder ve arka planda yenilemeyi dener. Böylece backend'de kısa bir kesinti yaşansa bile ziyaretçi bunu fark etmez.

Önbelleğin hit mi miss mi verdiğini görmek için canlı gözlem araçlarını kullanın. varnishstat özet metrikleri, varnishlog ise istek istek ayrıntıyı gösterir. Ayrıca yanıta bir hata ayıklama başlığı ekleyerek tarayıcıda kolayca kontrol edebilirsiniz.

sub vcl_deliver {
    if (obj.hits > 0) {
        set resp.http.X-Cache = "HIT";
    } else {
        set resp.http.X-Cache = "MISS";
    }
    set resp.http.X-Cache-Hits = obj.hits;
}

# Anlık hit/miss oranı ve bellek kullanımı
varnishstat

# Belirli bir URL için istek yaşam döngüsünü izle
varnishlog -q "ReqURL ~ '^/urunler'"

Cookie ve Login Sayfalarını Bypass Etme#

Önbelleklemenin en kritik ve en çok hataya açık kısmı budur: kişiye özel içeriği asla ortak önbelleğe koymamak. Bir kullanıcının oturum çerezini taşıyan sayfayı önbelleğe alırsanız, aynı sayfayı isteyen başka birine o kullanıcının verisini gösterebilirsiniz. Varnish varsayılan olarak cookie'li istekleri geçirir ama gerçek dünyada siteler tarayıcıya sürü halinde analytics ve tercih çerezi bırakır; bunlar önbelleği anlamsızca devre dışı bırakır. Çözüm, önemsiz çerezleri temizleyip yalnızca gerçek oturum çerezlerini bypass sebebi saymaktır.

Aşağıdaki vcl_recv bloğu iki iş yapar: yönetim ve giriş yollarını her zaman backend'e geçirir (pass), sıradan sayfalarda ise analytics çerezlerini soyup geriye anlamlı bir cookie kalmıyorsa çerez başlığını tümüyle kaldırarak önbelleğe uygun hale getirir.

sub vcl_recv {
    # Kişiye özel yollar önbelleğe girmesin
    if (req.url ~ "^/(admin|hesabim|sepet|odeme|giris|wp-admin|wp-login)") {
        return (pass);
    }

    # Oturum çerezi varsa bypass et
    if (req.http.Cookie ~ "(PHPSESSID|session|auth_token|wordpress_logged_in)") {
        return (pass);
    }

    # Analytics ve tercih çerezlerini temizle
    if (req.http.Cookie) {
        set req.http.Cookie = regsuball(req.http.Cookie,
            "(^|;\s*)(_ga|_gid|_gat|_fbp|__utm[a-z]+|cf_[a-z]+)=[^;]*", "");
        set req.http.Cookie = regsub(req.http.Cookie, "^\s*;\s*", "");

        # Geriye anlamlı çerez kalmadıysa başlığı tümden kaldır
        if (req.http.Cookie ~ "^\s*$") {
            unset req.http.Cookie;
        }
    }
}

Backend tarafında da dikkatli olun: statik varlıklar için gelen gereksiz Set-Cookie başlıklarını yukarıdaki vcl_backend_response örneğinde olduğu gibi silin, aksi halde Varnish o cevapları önbelleklemeyi reddeder. Kişiye özel bir bilgi sızmaması için giriş, sepet ve ödeme adımlarını daima pass listesinde tutmak, önbelleklemenin altın kuralıdır. Ödeme ve oturum akışlarının güvenliğini bir üst seviyeye taşımak için WAF ve DDoS koruma çözümlerini de değerlendirmelisiniz.

Nginx, SSL ve Katmanlı Mimari#

Varnish HTTPS trafiğini doğrudan işleyemez; şifreli isteği çözmesi gereken bir katmana ihtiyaç duyar. Modern kurulumda TLS sonlandırmayı Nginx yapar, ardından düz HTTP olarak Varnish'e iletir, Varnish de gerektiğinde arkadaki uygulama sunucusuna geçer. Böylece SSL yükü Varnish'in dışında kalır ve sertifika yönetimi tanıdık Nginx tarafında toplanır. Nginx'i sıfırdan kurmak isterseniz Nginx kurulum rehberimiz adım adım anlatıyor.

Önde duran Nginx'in yapılandırması, 443'te dinleyip isteği Varnish'in 6081 portuna proxylemekten ibarettir. Gerçek istemci IP'sinin kaybolmaması için X-Forwarded-For ve X-Forwarded-Proto başlıklarını iletmek önemlidir.

server {
    listen 443 ssl http2;
    server_name ornek.com.tr;

    ssl_certificate     /etc/ssl/certs/ornek.crt;
    ssl_certificate_key /etc/ssl/private/ornek.key;

    location / {
        proxy_pass http://127.0.0.1:6081;
        proxy_set_header Host              $host;
        proxy_set_header X-Real-IP         $remote_addr;
        proxy_set_header X-Forwarded-For   $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

# HTTP'yi HTTPS'e yönlendir
server {
    listen 80;
    server_name ornek.com.tr;
    return 301 https://$host$request_uri;
}

Bu mimaride akış nettir: istemci 443'te Nginx ile şifreli konuşur, Nginx düz HTTP olarak 6081'de Varnish'e verir, Varnish önbellekte yoksa 8080'deki backend Nginx/Apache'ye gider. Aşağıdaki tablo katmanların rollerini özetler.

Geçerli bir sertifika olmadan bu kurgu çalışmaz; ücretsiz ya da ücretli sertifika seçenekleri için SSL sayfamıza göz atın. Katmanlı mimarinin işletim yükünü üstlenmek istemiyorsanız, sunucu kurulumunu ve bakımını bizim yürüttüğümüz sunucu yönetimi hizmetiyle bu işi uzmanlara bırakabilirsiniz.

WordPress ile Varnish Kullanımı#

WordPress, Varnish için ideal adaylardan biridir çünkü ziyaretçilerin ezici çoğunluğu giriş yapmamış, yani herkese aynı HTML'i gören anonim kullanıcılardır. Bu kullanıcılara sayfayı önbellekten servis edip PHP ve MySQL'i tamamen atlatmak, WordPress'i çok daha fazla eşzamanlı ziyaretçiye dayanıklı hale getirir. Kritik nokta, giriş yapmış kullanıcıları ve yorum yapanları önbellekten dışarıda tutmaktır; bunu bir önceki bölümdeki wordpress_logged_in ve wp-admin kurallarıyla zaten hallettik.

Pratikte WordPress ile Varnish'i bir arya getirmenin en temiz yolu, önbelleği içerik güncellendiğinde temizleyen bir eklenti kullanmaktır. Bir yazı yayımlandığında ya da güncellendiğinde eklenti Varnish'e bir PURGE isteği göndererek ilgili sayfaları geçersiz kılar, böylece ziyaretçi hep güncel içeriği görür. PURGE'ün Varnish tarafında çalışması için vcl_recv içine küçük bir izin bloğu eklemeniz gerekir:

acl temizleme {
    "127.0.0.1";
    "localhost";
}

sub vcl_recv {
    if (req.method == "PURGE") {
        if (!client.ip ~ temizleme) {
            return (synth(405, "Izin yok"));
        }
        return (purge);
    }
}

WooCommerce gibi e-ticaret eklentileri kullanıyorsanız cart, checkout, my-account yollarını mutlaka pass listesinde tutun; bu sayfalar kişiye özeldir ve önbelleklenirse sepet karışması gibi ciddi sorunlar çıkar. Sürekli değişen fiyat ve stok bilgisi olan ürün sayfalarında ise TTL'yi düşük tutmak (örneğin 60-120 saniye) ve grace ile desteklemek dengeli bir seçimdir. WordPress altyapınızın bakımını profesyonelce yürütmek için WordPress bakım ve WordPress'e optimize hosting paketlerimiz işinizi kolaylaştırır; genel barındırma ihtiyaçları için web hosting ve bayi hosting seçeneklerine de bakabilirsiniz. Bir önbellek katmanı eklerken site hızınızın arama sıralamasına etkisini de gözden kaçırmayın; bu konuda SEO tarafında yapılabilecekler ayrı bir başlıktır.

Sıkça Sorulan Sorular#

Varnish ile Redis arasındaki fark nedir?#

Varnish tam HTTP sayfalarını önbelleğe alarak isteği backend'e hiç göndermezken, Redis uygulamanın içindeki nesneleri, sorgu sonuçlarını ve oturum verilerini bellekte tutar. Yani Varnish sayfayı üretmeden döner, Redis ise sayfa üretilirken altındaki pahalı işlemleri hızlandırır. İkisi rakip değildir; büyük sitelerde çoğu zaman birlikte kullanılır ve toplam etkileri toplamdan fazladır.

Varnish HTTPS trafiğini kendi başına yönetebilir mi?#

Hayır, Varnish tasarımı gereği TLS sonlandırma yapmaz ve şifreli trafiği doğrudan işlemez. Bu yüzden önüne TLS'i çözen bir Nginx ya da yük dengeleyici koyar, Varnish'e düz HTTP olarak iletirsiniz. Bu ayrım aslında bir avantajdır çünkü şifreleme yükü Varnish'in dışında kalır ve sertifika yönetimi tek bir katmanda toplanır.

Giriş yapmış kullanıcılar yanlış içerik görür mü?#

Kurallarınızı doğru yazdıysanız görmez. Oturum çerezi taşıyan istekleri ve giriş, sepet, ödeme, yönetim gibi yolları önbellekten dışarıda tutan bir pass mantığı kurduğunuzda kişiye özel sayfalar hep backend'den taze üretilir. Riskli olan senaryo, oturum çerezlerini yok sayıp her şeyi önbelleğe almaktır; bu yüzden çerez temizleme kuralları dikkatle test edilmelidir.

Önbelleği içerik değiştiğinde nasıl temizlerim?#

En yaygın yöntem PURGE ya da BAN isteğidir. Bir yazı güncellendiğinde uygulamanız ya da eklentiniz Varnish'e ilgili URL için bir PURGE isteği gönderir, Varnish o nesneyi önbellekten atar ve bir sonraki istek taze içeriği alır. Daha geniş desenler için (örneğin bir kategori altındaki tüm sayfalar) URL kalıbına göre çalışan BAN komutunu kullanabilirsiniz.

Ne kadar RAM ayırmalıyım?#

Bu tamamen sık istenen benzersiz sayfa sayınıza bağlıdır. Önbelleğe girecek toplam içerik RAM'e sığdığında hit oranı yüksek olur; bellek dolunca Varnish en az kullanılan nesneleri atmaya başlar ve verim düşer. Küçük bir blog için birkaç yüz megabayt yeterken, geniş kataloglu bir site için birkaç gigabayt gerekebilir; varnishstat çıktısındaki nesne atma metriklerini izleyerek boyutu zamanla ayarlayabilirsiniz.

Varnish paylaşımlı hostingde çalışır mı?#

Varnish sistem seviyesinde bir servis olduğu için genellikle root erişimi ister ve bu yüzden klasik paylaşımlı hosting ortamlarında kendiniz kuramazsınız. Kendi önbellek katmanınızı yönetmek istiyorsanız bir VDS ya da sanal sunucu tercih etmeniz gerekir. Paylaşımlı planlarda ise barındırma sağlayıcısının sunduğu yerleşik önbellek çözümlerinden yararlanmak daha pratik olur.

Kapanış#

Varnish, doğru kurgulandığında sitenizin en pahalı katmanını (uygulama ve veritabanını) çoğu istek için tamamen devre dışı bırakır; sonuç milisaniyelerle ölçülen yanıt süreleri ve kat kat artan eşzamanlı kapasitedir. Anahtar noktalar nettir: backend'i sağlıklı tanımlayın, TTL ve grace değerlerini bilinçli seçin, kişiye özel yolları mutlaka pass listesinde tutun ve HTTPS için önüne Nginx yerleştirin. Bu dört ilkeye sadık kaldığınız sürece hem hızlı hem güvenli bir önbellek katmanı elde edersiniz.

Bu mimariyi kurmak için root erişimli bir sunucuya ihtiyacınız var; Clou.TR olarak yüksek performanslı VDS ve sanal sunucu planlarımızla ihtiyacınıza uygun bir altyapı sunuyoruz. Kurulum ve bakımı uzmanlara bırakmak isterseniz sunucu yönetimi hizmetimiz devreye girer; WordPress tarafında ise WordPress hosting paketlerimiz önbellek ve hız optimizasyonunu sizin için hazır getirir. Uygun bir sunucu seçmek ya da mevcut sitenizi ücretsiz taşımak için ekibimizle iletişime geçebilirsiniz.