Dinamik site için reverse proxy ile edge cache

Siteyi reverse proxy üzerine kurdunuz, önbelleği açtınız ve şimdi aynı anda iki şikayetiniz var: hesabına giriş yapmış kullanıcı bir yenilemeden sonra tekrar giriş sayfasını görüyor; ve ürünü sepetten çıkarmış müşteri hâlâ aynı ürünü sepette görüyor. Her ikisinin de kökü aynı: proxy'ye hangi yanıtların hiç önbelleğe alınmaması gerektiğini söylemeden tüm sayfayı önbelleğe aldınız.

Edge cache, üç şeyi birbirinden ayırdığınızda doğru çalışır: herkesin aynı gördüğü genel yanıtlar, tek bir kullanıcıya ait özel yanıtlar ve asla saklanmaması gereken yanıtlar. Bu ayrım yapılmadığı sürece, önbelleği her açtığınızda yeni bir hata üretmiş olursunuz.

Edge cache neden dinamik sitede işe yaramaz

Kısa cevap: işe yarar, ama varsayılan ayarla değil. Sorun şu ki çoğu dinamik site anlamlı bir önbellek başlığı döndürmez. PHP'niz veya framework'ünüz bir 200 OK yanıtı gönderir ve bu kadar. Proxy bakar, hiçbir talimat görmez ve kendi varsayılan politikasına göre karar verir. Bazı proxy'ler hiçbir şeyi önbelleğe almaz ve siz önbelleğin bozuk olduğunu düşünürsünüz; bazıları her şeyi önbelleğe alır ve siz sitenin bozuk olduğunu düşünürsünüz.

Çözüm, uygulamanın önbellek kararını kendisinin bildirmesidir. Bu, proxy ayarlarıyla değil, Cache-Control başlıklarıyla yapılır. Proxy yalnızca uygulayıcıdır.

Kararı gerçekten veren başlıklar

Ürün listesi gibi genel bir sayfa şunu döndürmelidir:

Cache-Control: public, max-age=60, s-maxage=300, stale-while-revalidate=600

max-age tarayıcı içindir ve s-maxage CDN veya reverse proxy gibi paylaşımlı önbellek içindir. Bu ikisinin farkını ciddiye alın; yalnızca max-age koyarsanız, CDN onu kullanmaz ve siz edge cache'in etkinleşmediğini düşünürsünüz. 60 saniye değeri ürün listesi için bilinçlidir: daha kısası önbelleği işe yaramaz kılar, daha uzunu güncellenmiş fiyatların kullanıcıya geç ulaşması demektir.

Ve oturum açmış kullanıcı sayfası şunu döndürmelidir:

Cache-Control: private, no-store

private yalnızca kullanıcının kendi tarayıcısının saklayabileceğini söyler ve no-store tarayıcının bile saklamaması gerektiğini söyler. Sepet sayfası ve kullanıcı paneli için no-store seçin. Bedeli, her ziyaretin arka uca tam bir istek gitmesi ve hiçbir kaynak tasarrufunuz olmamasıdır. Bu bedeli ödeyin. Sepet sayfasını önbelleğe almak, sipariş kaybıyla telafi edilen bir tasarruftur.

Reverse proxy yapılandırması: nerede atlayacağız

Nginx'te önbellek kararını uygulamaya bırakın ve yalnızca emin olduğunuz yolları elle atlayın. Çalışan bir blok:

proxy_cache_path /var/cache/nginx levels=1:2 keys_zone=edge:100m
                 max_size=10g inactive=24h use_temp_path=off;

server {
    listen 443 ssl http2;

    location / {
        proxy_cache edge;
        proxy_cache_key "$scheme$request_method$host$request_uri";
        proxy_cache_valid 200 301 302 5m;
        proxy_cache_bypass $cookie_sessionid $http_authorization;
        proxy_no_cache     $cookie_sessionid $http_authorization;
        add_header X-Cache-Status $upstream_cache_status;
        proxy_pass http://backend;
    }

    location /cart/    { proxy_pass http://backend; }
    location /account/ { proxy_pass http://backend; }
    location /api/     { proxy_pass http://backend; }
}

proxy_cache_bypass ve proxy_no_cache satırları işin kalbidir. Birincisi, bu koşul sağlanırsa önbellekten okuma ve doğrudan arka uca git der; ikincisi yanıtı saklama der. Yalnızca birincisini koyarsanız, kullanıcının kişisel yanıtı önbelleğe oturur ve bir sonraki kullanıcıya sunulur. Bu tam olarak "Kullanıcı A, Kullanıcı B'nin bilgilerini görüyor" şeklinde bildirilen hatadır.

X-Cache-Status başlığını mutlaka ekleyin. O olmadan tahmin yürütüyorsunuz demektir. Basit bir curl -I ile HIT mi, MISS mi yoksa BYPASS mı aldığınızı görürsünüz:

curl -sI https://example.com/products | grep -i x-cache-status

Sürekli MISS görüyorsanız, muhtemelen oturum çerezi anonim ziyaretçi için bile tüm isteklere ekleniyor. Bunu tarayıcıda veya çerezsiz curl -I ile kontrol edin.

Burada hata yapıyorlar

Gördüğüm en yaygın hata: ekip oturum çerezini yol ayrımı yapmadan ana alan adına tanımlıyor. Sonuç, her anonim ziyaretçinin de bir oturum çerezi olması, proxy_cache_bypass koşulunun herkes için sağlanması ve HIT oranının sıfırda kalmasıdır. Belirtisi şudur: her şey doğru yapılandırılmış görünür, sunucu sebepsiz yere yük altındadır ve kimse önbelleğin neden çalışmadığını anlamaz. Çözüm: oturum çerezini ilk ziyarette değil, yalnızca başarılı girişten sonra tanımlayın.

Edge cache ve CDN: karar yerindeki fark

Kendi sunucunuzdaki reverse proxy ve CDN ikisi de edge cache'tir, ama karar yeri farklıdır. Trafiğiniz ağırlıklı olarak tek bir coğrafyadan geliyorsa ve arka uç aynı bölgedeyse, yerel reverse proxy yeterlidir ve daha az karmaşıktır. Kullanıcılar birkaç kıtadan geliyorsa, CDN ağ gecikmesini azaltır ama önbellek atlama mantığı üzerinde daha az kontrolünüz olur.

Oturum açmış kullanıcıları olan dinamik site için tercihim: önce yerel reverse proxy'yi düzeltin, sonra önüne CDN koyun. Tersini yaparsanız, hangi katmanın yanlış yanıtı önbelleğe aldığını hata ayıklamak kat kat zorlaşır. İçerik dağıtım seçeneklerini tanımak için içerik dağıtım ağı iyi bir başlangıç noktasıdır.

Ayrı kalması gereken üç katman

Dinamik bir siteniz olduğunda, yanıtları üç sepete koyun ve her sepet için sabit bir politika tanımlayın:

• Genel ve önbelleğe alınabilir: ana sayfa, ürün listesi, kategori sayfaları, statik dosyalar. Belirli bir s-maxage ile public.
• Özel: kullanıcı paneli, sepet, sipariş geçmişi. private, no-store ve proxy'de önbelleği atlama.
• Hassas: token alan API yolları, ödeme sayfaları. İstisnasız tam atlama.

Daha az söylenen bir nokta: POST metoduyla API yanıtlarını önbelleğe almak yanlıştır, ama çoğu kişi "hız kazanıyoruz" diye yapar. API'niz idempotent değilse, onu önbelleğe almak bir finansal işlemin iki kez çalışması veya hiç çalışmaması anlamına gelebilir. Metodu proxy_cache_key içine koyun ki GET ve POST asla birbirine karışmasın.

Yayından sonra önbellek temizleme

Her dağıtımdan sonra edge cache temizlenmelidir, yoksa kullanıcılar eski sürümü görür. Statik dosyaları adlarında hash ile sürümlüyorsanız (app.a3f9c1.js), temizlemeye gerek yoktur ve max-age değerini bir yıla ayarlayabilirsiniz. HTML için hedefli temizleme yeterlidir:

curl -X PURGE https://example.com/products

Bu komut yalnızca Nginx'te purge modülünü etkinleştirdiyseniz çalışır. Etkin değilse, daha hızlı yol önbellek sürümünü proxy_cache_key içine dahil etmek ve dağıtımdan sonra değerini değiştirmektir. Yapılandırmada okunan bir ortam değişkeni bunu restart olmadan yapar.

Edge cache'i ne zaman kapatmalısınız

Siteniz birkaç yüz eşzamanlı ziyaretten azsa ve tüm kullanıcılar oturum açmışsa, edge cache yalnızca ek karmaşıklık katar. Bu durumda veritabanı ve indeks optimizasyonu daha fazla getiri sağlar. Edge cache değerini, anonim ziyaretçinin oturum açmış kullanıcıya oranı yüksek olduğunda ve aynı genel sayfalar trafiğin büyük bir kısmını oluşturduğunda kanıtlar.

Trafiği sert dalgalanan siteler için edge cache'i otomatik ölçeklendirme ile birleştirmek mantıklıdır: önbellek baskıyı azaltır ve ölçeklendirme kalan pikleri emer. Ve hangi isteklerin gerçekten arka uca ulaştığını bilmek istiyorsanız, sunucu izlemeyi herhangi bir önbellek değişikliğinden sonra değil, önce kurun.

Hâlâ tek bir sunucuda çalışıyorsanız ve önbelleği uygulamadan ayrı tutmak istiyorsanız, bir bulut altyapısı (IaaS) proxy katmanını arka uçtan bağımsız yönetmenize olanak tanır. Daha ağır ve çok servisli yükler için yönetilen Kubernetes bir sonraki seçenektir, ama tek bir sunucu yanıt verdiği sürece ona yönelmeyin.

Sık sorulan sorular

Önbelleği etkinleştirdikten sonra kullanıcılar neden hesaptan çıkıyor?

Çünkü giriş sayfası veya ana sayfa yanıtı public başlığıyla önbelleğe alınmıştır ve tarayıcı veya CDN aynı yanıtı bir sonraki kullanıcıya verir. Oturum çerezi önbelleğe alınmış yanıtta yoktur veya başka bir kullanıcıya aittir. Çözüm, oturuma bağlı her yolun proxy_cache_bypass ile önbellekten çıkarılması ve yanıtının private, no-store döndürmesidir.

Edge cache'te max-age ve s-maxage farkı nedir?

max-age yanıtın kullanıcının tarayıcısındaki geçerlilik süresidir ve s-maxage CDN ve reverse proxy gibi paylaşımlı önbelleklerdeki geçerlilik süresidir. Yalnızca max-age koyarsanız, edge cache onu kullanmaz ve siz önbelleğin etkinleşmediğini düşünürsünüz. Genel sayfalar için ikisini birlikte koyun.

Edge cache'in gerçekten çalıştığını nasıl anlarım?

Yanıtlara X-Cache-Status başlığını ekleyin ve curl -sI ile değerinin HIT mi yoksa MISS mi olduğunu kontrol edin. Sürekli MISS görüyorsanız, muhtemelen oturum çerezi tüm isteklere ekleniyor ve bypass koşulu herkes için sağlanıyor. Bunu çerezsiz bir istekle test edin.

API yanıtlarını önbelleğe almak doğru mu?

Yalnızca GET istekleri ve belirli bir kullanıcıya bağlı olmayan genel yanıtlar için. POST'u veya tokene bağlı herhangi bir yanıtı önbelleğe almak, bir kullanıcının verisinin başka bir kullanıcıya sunulmasına veya bir finansal işlemin iki kez çalışmasına neden olur. HTTP metodunu önbellek anahtarına dahil edin ki bu ikisi asla birbirine karışmasın.