CDN კაშხალი და TTL ოპტიმიზაცია

Cache-Control: public, max-age=31536000, immutable

Cache-Control: public, s-maxage=300, max-age=60, stale-while-revalidate=600, stale-if-error=86400
ETag: "a1c3..."

ქეშის გასაღები: დიზაინი და ნორმალიზაცია

მიზანია, რომ არსებითად იგივე მოთხოვნები მოხვდეს იმავე ობიექტში.

URL- ის ნორმალიზაცია: რეესტრი, ორმაგი სლაში, trailing slash, query პარამეტრების შეკვეთა.
„ხმაურის“ უგულებელყოფა: 'utm _', 'fbclid', 'gclid', თვითნებური რეფლექსები.
შეზღუდული Vary: მხოლოდ ნამდვილად მნიშვნელოვანი სათაურები ('Accept-Encoding', ზოგჯერ 'Accept', 'Accept-Language' ლოკალისთვის).
მოწყობილობების კლასი: საჭიროების შემთხვევაში, გამოიყენეთ 2-3 კლასი (მობილური/desktop/tablet), და არა უსასრულო მომხმარებლის აგენტის ფილიალები.
Auth კონტექსტი: ნაგულისხმევი არ გადააგდოთ პირადი; გამოიყენეთ signed-SNDs/cookies-bypass ან საჯარო/პირადი გზების გამიჯვნა.

Surrogate-Key: product:123 catalog
Cache-Control: public, s-maxage=300, stale-while-revalidate=600
Vary: Accept-Encoding

TTL შინაარსის სტრატეგიები

შეზღუდული შესაძლებლობის მქონე პოლიტიკა

By URL/Prefix: „ჩამოიხრჩო ყველაფერი '/static/2025-11-05/“.
By Tag/Key: „ამოიღეთ ყველა 'catalog' და 'product: 123'“.
Soft purge: გაანადგურა, როგორც მოძველებული, არ წაშალოთ ობიექტი - უფრო სწრაფად, ვიდრე ხელახლა შევსება.
Event-driven: CI/CD ან admin მოვლენა იწვევს webhook „invalidate tags“.

რეკომენდაცია: გააერთიანეთ ორივე ტაქტიკა: ასეტებისთვის ტრასების ვერსია + tag purge შინაარსის/გვერდისთვის.

Tiered-cache, origin-shield и prewarm

Tiered-cache: CDN- ის რეგიონალური ფენები უფრო ნაკლებია ვიდრე origin- ის მოთხოვნა.
Origin-shield: ერთი „ფარიანი“ POP origin - აუმჯობესებს ადგილსამყოფელსა და ჰიტ-რატიოს.
Prewarm (pre-fetch): ცხელი URL/kash დათბობა ivent/გამოშვებამდე.
Negative-cache: მოკლედ დააკვირდით 5xx/Timeout (30-120 წ.) ისე, რომ არ შეავსოთ origin ქარიშხლის ქარიშხლით.

კეში API: როდის შეგიძლიათ

მხოლოდ GET/HEAD და idempotent.
გასაღები: გზა + მნიშვნელოვანი query (მაგალითად, '? category =... & page =...').
შესაბამისობა: 'ETag '/' Last-Modified' და მოკლე 's-maxage'.
მომხმარებლის ფილტრები: გააკეთეთ პერსონალიზაცია კლიენტის/edge ფუნქციისთვის, ან გამოიყენეთ signed-requests + „საჯარო“ პასუხი.

Cache-Control: public, s-maxage=30, max-age=5, stale-while-revalidate=120, stale-if-error=600
ETag: "feed-v42"

ქეში მოწამვლისგან დაცვა

URL/სათაურების მკაცრი ნორმალიზაცია; პარამეტრების თეთრი სია გასაღებით.
საეჭვო სათაურების/დუბლიკატების მოჭრა ('X-Forwarded-', გაფართოვდა 'Accept').
'Vary' შეზღუდვა და ზომის კონტროლი/სათაურების რაოდენობა.
დომენების გამიჯვნა: პირადი/ადმინი - ცალკე სახელზე ქეშის გარეშე.
პასუხების შესაბამისობა: ნუ დააყოვნებთ 4xxx- ს (გარდა სტატიკოსებისთვის 404), ნუ დააკვირდებით „მომხმარებლის“ გვერდებს აშკარა პოლიტიკის გარეშე.

შეკუმშვა და ფორმატები

Brotli ტექსტური (js/css/json), gzip - fallback; შეკუმშული ასეტები დასაშვებია.
სურათები: webp/avif, სადაც მხარდაჭერა; გამოიყენეთ 'Vary: Accept' + წარმოებულები.
ვიდეო/აუდიო Range-requests: CDN ქოთნები.
შინაარსი-Negotiation: შეინარჩუნეთ დაბალი საკვანძო კარდინალობა (მოწყობილობების კლასი ნედლეული UA- ს ნაცვლად).

დაკვირვება და SLO

ძირითადი მეტრიკა

Hit-ratio (by bytes/requests) на edge/tier/shield.
p50/95/99 TTFB რეგიონებში და ტიპებში (სტატიკური/API).
Fill-rate/Origin egress - რამდენი მიდის origin- ში.
304 რატი და საშუალო პასუხი.
Error budget: 'stale-if-error '/' SWR' გამოშვებების წილი; purge სიხშირე.

SLO მაგალითები

'p95 TTFB' რეგიონალური სტატიკა 120-150 ms, API GET საკეტებით 200-250 ms.
Edge hit-ratio სტატიკა - 90%, ნახევრად დინამიკა - 60%.
Stale ფილიალიდან პასუხების წილი შეცდომებით არის 0. 5% 30 დღეში.

დამცავი ფურცლები

Nginx (reverse-proxy CDN- ის წინ ან self-PoP- ში)

nginx proxy_cache_path /var/cache/nginx levels=1:2 keys_zone=CDN:512m max_size=100g inactive=7d;

map $args $clean_args {
"~(^    &)(utm_    gclid    fbclid) """; # default $ args simplified example;
}

server {
listen 443 ssl http2;
set $cache_key "$scheme$request_method$host$uri?$clean_args    $http_accept    $http_accept_encoding";
location /static/ {
proxy_cache CDN;
proxy_cache_key $cache_key;
proxy_ignore_headers Set-Cookie;
add_header Cache-Control "public, s-maxage=86400, max-age=3600, stale-while-revalidate=600" always;
proxy_pass https://origin_static;
}

location /api/public/ {
proxy_cache CDN;
proxy_cache_key $cache_key;
proxy_cache_valid 200 30s;
add_header Cache-Control "public, s-maxage=30, max-age=5, stale-while-revalidate=120, stale-if-error=600" always;
proxy_set_header If-None-Match $upstream_http_etag;
proxy_pass https://origin_api;
}
}

Envoy (SWR + negative-cache, კონცეფცია)

yaml http_filters:
- name: envoy. filters. http. cache typed_config:
"@type": type. googleapis. com/envoy. extensions. filters. http. cache. v3. CacheConfig typed_config:
"@type": type. googleapis. com/envoy. extensions. cache. simple_http_cache. v3. SimpleHttpCacheConfig
Cache-Control/Surrogate-Control Header Cache Policies
We cache 5xx errors briefly via route/retry policy + local_rate_limit

Heders „სწრაფი“ ასეტებისთვის

Cache-Control: public, max-age=31536000, immutable
ETag: "hash"
Content-Encoding: br

Heders ნახევრად დინამიკისთვის (კატალოგები)

Cache-Control: public, s-maxage=600, max-age=120, stale-while-revalidate=1800, stale-if-error=86400
Vary: Accept-Encoding, Accept

FinOps: როგორ დაზოგავს ქეში ფულს

Egress origin არის, ვიდრე CPU/DB დატვირთვა უფრო დაბალია, ვიდრე ინფრასტრუქტურული ხარჯები.
ნაკლები მოთხოვნა ფასიანი ზურგჩანთებისთვის (search/index/images).
სამიზნე მეტრი: $/შემცირება p95 აშშ დოლარი და/egress შემცირება 1 GB- ზე - დააკვირდით შემდგომი გაშვების ეფექტს.

სპეციფიკა iGaming/fintech

პროვაიდერების/ასეტების კატალოგები: ვერსირებული ბილიკები + ერთწლიანი TTL.
ღონისძიებების/ტურნირების ლენდინგი: 1-5 წუთი-მაღაროს '+' SWR '10-30 წუთის განმავლობაში; განახლებისას tag-purge.
Live გვერდები (კოეფიციენტები/ცხრილები): ნაწილობრივი JSON ბლოკის ქეში, მოკლე TTL (5-30 წმ), პირადი ბლოკებისთვის - კლიენტის რენდერი.
PSP/გადახდის endpoints: ჩვენ არ ვხდებით, მკაცრი 'no-store'; მხოლოდ დირექტორიების ქეშირება (BIN ცხრილები, სტატუსები).
ანტიბოტი: სტატიკური ქეშირება/GET, „ნაცრისფერი“ მარშრუტები საეჭვო ASN- სთვის; ნუ დაუშვებთ 'Vary' ხმაურიან სათაურებში.

ჩეკის განხორციელების სია

• აღწერილია ქეშის გასაღები: URL- ის ნორმალიზაცია, ნებადართული query ჩამონათვალი, 'Vary' მხოლოდ საჭირო გზით.
• დაყოფილია საჯარო/პირადი გზები; პირადი - 'no-store' და bypass CDN.
• დაინერგა შინაარსის ტიპის TTL კიბეები; მორგებულია 'SWR/if-error'.
• tiered-cache + origin-shield; შედის negative-cache 5xx (მოკლე).
• არის tag/URLpurge, რბილი purge; ინტეგრაცია CI/CD- სთან.
• ჩართულია შეკუმშვა (br/gzip), სურათების ვებ ფორმატები და range პასუხები.
• მეტრიკა: hit-ratio by layer, p95 TTFB, 304 რატი, origin egress; ალერტები წარუმატებლობისკენ.
• Playbooks: თბება ქეში მწვერვალების წინ, გადაუდებელი purge, origin დეგრადაცია.

ტიპიური შეცდომები

დიდი TTL- ის ასეტის გარეშე, მომხმარებლებისგან „ჩაძირული“ ბანდებია.
გადაჭარბებული 'Vary' ('User-Agent- ის მიხედვით, ყველა სათაურით) არის რადიკალური აფეთქება და დაბალი hit-ratio.
4xx/401/403/პირადი შინაარსის ქეშირება.
negative-cache- ის არარსებობა არის დეგრადირებული origin- ის მოთხოვნის ზვავი.
არ არსებობს tag-purge - მასიური წერტილოვანი purge და „ქარიშხალი“ re-fill.
ქეშის გასაღები მოიცავს „ხმაურიან“ UTM/რეფ პარამეტრებს.
ძალიან მოკლე TTL სტატიკისთვის - ზედმეტი დატვირთვა CDN და Origin.

მინი ფლეიბუკები

1) ქეში გაათბეთ ღონისძიებამდე

1. ტოპ N URL- ის შეგროვება ლოგოების მიხედვით - 2) პარალელური პრეფექტურა რეგიონებისთვის - 3) შემოწმება hit-ratio - და p95.

2) გადაუდებელი რბილი კატოლოგები

1. 'PURGE '/tag-clear (2) გაგზავნა CDN აძლევს სტილს და ფონი აძლიერებს ახალს, 3) შეამოწმეთ ხერხემლის ნაკლებობა origin- ზე.

3) ორიგინის უარყოფა

1. 'stale-if-error' ასახელებს X საათს (2) ბანერს „ტექნიკური სამუშაოები“ edge-3) აღდგენისთვის - მიზნობრივი warm-up.

შედეგი

ძლიერი CDN სტრატეგია = სწორი ქეში + მნიშვნელოვანი TTL ღილაკი SWR/if-error + კონტროლირებადი ინვალიდობა + tiered/shield + დაკვირვება. დააფიქსირეთ პოლიტიკა კედლებში და IaC, გაზომეთ hit-ratio და p95, დაგეგმეთ მწვერვალების დათბობა - და მომხმარებლები ყოველთვის მიიღებენ სწრაფ პასუხს, ხოლო origin ცოცხალი დარჩება თუნდაც ყველაზე ცხელ საათში.