מטמון רב-שכבתי: דפדפן→CDN→Varnish→Redis→DB

ריבוד מטמון רב-שכבתי: דפדפן → CDN → Varnish → Redis → DB

עבדנו על פרויקטים שבהם כל בקשת עמוד הפכה לעשרות שאילתות SQL. אפילו בלוג פשוט זחל. לאחר יישום ריבוד מטמון רב-שכבתי, זמן התגובה ירד מ-2000 אלפיות השנייה ל-80 אלפיות השנייה, ועומס מסד הנתונים ירד ב-95%. לקוחות מפחיתים משמעותית את עלויות התשתית לאחר אופטימיזציה כזו. הנה איך לבנות מערכת זו.

ריבוד מטמון רב-שכבתי הוא רצף של שכבות אחסון לתגובות. כל שכבה משרתת בקשה מבלי להעביר אותה הלאה. ככל שפגיעת מטמון מתרחשת קרוב יותר למשתמש, כך התגובה מהירה יותר. אסטרטגיה נכונה מפחיתה את העומס על מסד הנתונים ושרת היישום, ומשפרת את מדדי Core Web Vitals.

למה שכבה אחת לא מספיקה?

מטמון הדפדפן חוסך תעבורה אך לא עוזר בביקור הראשון. CDN מאיץ אספקת תוכן סטטי, אך עמודים דינמיים זקוקים לשכבה מהירה יותר. Varnish הוא פרוקסי הפוך חזק אך אינו יכול לאחסן מבני נתונים מורכבים. Redis פותר זאת אך דורש זיכרון RAM. השילוב של כלים אלה נותן אפקט מקסימלי: אתר טיפוסי לאחר הגדרה מקבל שיעור פגיעות >80% ב-CDN ו->70% ב-Varnish.

TTL מומלצים לסוגי תוכן שונים

יש להתאים TTL אלה בהתאם לתדירות שינוי התוכן. עבור פורטל חדשות, עדיף לשמור HTML במטמון למשך 2 דקות; עבור אתר תאגידי, שעה. אנו תמיד מבצעים בדיקות עומס כדי לוודא ששיעור הפגיעות עומד בערכי היעד.

איך להגדיר מטמון דפדפן?

# nginx: заголовки для браузерного кэша
location ~* \.(jpg|jpeg|png|gif|ico|css|js|woff2)$ {
    expires 1y;
    add_header Cache-Control "public, immutable";
}

location ~* \.html$ {
    add_header Cache-Control "public, max-age=0, s-maxage=300";
    add_header Vary "Accept-Encoding, Accept-Language";
}

ההוראה # nginx: заголовки для браузерного кэша location ~* \.(jpg|jpeg|png|gif|ico|css|js|woff2)$ { expires 1y; add_header Cache-Control "public, immutable"; } location ~* \.html$ { add_header Cache-Control "public, max-age=0, s-maxage=300"; add_header Vary "Accept-Encoding, Accept-Language"; } אומרת לדפדפן לא לאמת מחדש את הקובץ — מובטח שהוא לא ישתנה. זה נותן טעינה מיידית בביקורים חוזרים.

איך לחבר CDN?

---
# cloudflare page rules
- pattern: "*.company.com/assets/*"
  settings:
    cache_level: cache_everything
    edge_cache_ttl: 2592000 # 30 дней
    browser_cache_ttl: 31536000 # 1 год
---

CDN מוריד עומס מהשרת המקורי ומפחית TTFB עבור משתמשים מרוחקים גיאוגרפית.

Varnish: כוונון עדין

vcl 4.1;
backend default {
    .host = "app-server";
    .port = "8080";
}
sub vcl_recv {
    if (req.http.Authorization || req.http.Cookie ~ "session") {
        return (pass);
    }
    if (req.method != "GET" && req.method != "HEAD") {
        return (pass);
    }
    unset req.http.Cookie;
    return (hash);
}
sub vcl_backend_response {
    if (beresp.status == 200 || beresp.status == 301) {
        if (beresp.http.Content-Type ~ "text/html") {
            set beresp.ttl = 5m;
        } else if (beresp.http.Content-Type ~ "application/json") {
            set beresp.ttl = 1m;
        }
        unset beresp.http.Set-Cookie;
    }
    set beresp.grace = 1h;
}
sub vcl_deliver {
    if (obj.hits > 0) {
        set resp.http.X-Cache = "HIT";
    } else {
        set resp.http.X-Cache = "MISS";
    }
}

לפי תיעוד Varnish Cache, תקופת חסד מאפשרת לשרת מטמון מיושן כאשר השרת האחורי אינו זמין, מה שמשפר את הזמינות. ניתן להתאים אישית את מפתח ה-hash כדי להפריד מטמון לפי שפה או מכשיר.

איך לפתור בעיית פסילת מטמון?

ללא פסילה נכונה, משתמשים רואים נתונים מיושנים. אנו מתכננים מערכת אחידה: בעת שינוי נתונים, נשלח HTTP PURGE ל-Varnish, מפתחות Redis נמחקים, ותגי CDN מנוקים. דוגמה ב-Python:

def on_product_updated(product_id):
    redis.delete(f"product:{product_id}")
    requests.request('PURGE', f"http://varnish:6081/products/{product_id}")
    # Cloudflare purge by tag
    requests.post(f"https://api.cloudflare.com/client/v4/zones/{zone_id}/purge_cache", headers={"Authorization": f"Bearer {token}"}, json={"tags": [f"product-{product_id}"]})

טעות נפוצה היא הגדרת TTL ארוכים מדי ללא מנגנון פסילה. אנו ממליצים להשתמש בתגים ב-CDN וב-immutable ב-Varnish כדי להבטיח טריות נתונים. בתרחישים מסוימים, אנו משתמשים ב-Edge Functions לפסילה מיידית בקצה הרשת.

ניטור שיעור פגיעות לפי שכבה

אנו משתמשים במדדי Prometheus: # cloudflare page rules - pattern: "*.company.com/assets/*" settings: cache_level: cache_everything edge_cache_ttl: 2592000 # 30 дней browser_cache_ttl: 31536000 # 1 год , vcl 4.1; backend default { .host = "app-server"; .port = "8080"; } sub vcl_recv { if (req.http.Authorization || req.http.Cookie ~ "session") { return (pass); } if (req.method != "GET" && req.method != "HEAD") { return (pass); } unset req.http.Cookie; return (hash); } sub vcl_backend_response { if (beresp.status == 200 || beresp.status == 301) { if (beresp.http.Content-Type ~ "text/html") { set beresp.ttl = 5m; } else if (beresp.http.Content-Type ~ "application/json") { set beresp.ttl = 1m; } unset beresp.http.Set-Cookie; } set beresp.grace = 1h; } sub vcl_deliver { if (obj.hits > 0) { set resp.http.X-Cache = "HIT"; } else { set resp.http.X-Cache = "MISS"; } } . ערכי היעד מופיעים בטבלה למעלה. ניטור קבוע מאפשר התאמת TTL בזמן ומזהה בעיות פסילה.

מה כלול בעבודה?

1. ביקורת ארכיטקטורת המטמון הנוכחית — ניתוח יומני nginx, תצורות Varnish, פרמטרי Redis ומבנה CDN.
2. הגדרת מטמון דפדפן דרך nginx או .htaccess.
3. חיבור CDN (Cloudflare, CloudFront) עם כללי מטמון.
4. התקנה ותצורה של Varnish (4.1+) עם כללי חסד ו-hash.
5. תצורת Redis (קלאסטר, התמדה, מדיניות פינוי).
6. יצירת מערכת פסילה אחידה עם PURGE ו-API.
7. בדיקות עומס ואופטימיזציית TTL.
8. תיעוד והדרכת צוות.

לוח זמנים ועלות

הגדרת המחסנית המלאה אורכת 4 עד 7 ימי עבודה. העלות מחושבת באופן פרטני לפי מורכבות הפרויקט. לקוחות בדרך כלל מחזירים את ההשקעה תוך 2–3 חודשים באמצעות הפחתת עלויות שרת והגדלת המרות.

טעות נפוצה: הגדרות TTL שגויות

רבים מגדירים TTL זהים לכל סוגי התוכן. זה מוביל או למטמון יתר של נתונים דינמיים או לפסילה תכופה מדי של קבצים סטטיים. אנו בוחרים TTL לפי תדירות עדכון התוכן: סטטי — שנה, HTML — 5 דקות, JSON API — דקה. לאחר התצורה, אנו בודקים את שיעור הפגיעות ומתאימים לפי הצורך.

הזמינו ביקורת מטמון היום — נזהה צווארי בקבוק ונציע אסטרטגיה אופטימלית. קבלו ייעוץ להגדרת ריבוד מטמון רב-שכבתי לפרויקט שלכם.