Bài 6: CDN & Edge Caching

Bài 5 đặt cache cạnh app. Bài này đặt cache cạnh người dùng — và lý do phải làm vậy không phải là một quyết định kiến trúc, mà là một giới hạn vật lý không có đoạn code nào vượt qua được.

Lab của bài này dựng một tầng edge thật bằng nginx và đo được 25 lần throughput, với origin chỉ phải xử lý 4 request trong 208.173. Nhưng phát hiện đáng giá hơn là ở phép đo thứ hai: một lỗi cấu hình cache key rất phổ biến làm tải origin tăng 251 lần mà mọi số liệu phía client đều không đổi — cùng throughput, cùng p50, cùng p99. Nó hoàn toàn vô hình từ bên ngoài.

6.1 Giới hạn không code nào vượt được

Trong sợi quang, tín hiệu đi với tốc độ khoảng $200.000$ km/s — chậm hơn tốc độ ánh sáng trong chân không vì chiết suất của thuỷ tinh. Đổi đơn vị cho dễ dùng: 200 km mỗi millisecond. Một request phải đi và về, nên thời gian khứ hồi tối thiểu cho khoảng cách $d$ (km) là:

$$RTT_{min} = \frac{2d}{200} = \frac{d}{100} \text{ ms}$$

Tức là 1 ms cho mỗi 100 km khứ hồi, và đó là con số của một sợi quang thẳng, không thiết bị trung gian, không xếp hàng. Thực tế luôn xấu hơn 2–3 lần vì cáp không đi đường thẳng, vì mỗi router trên đường thêm một chút, và vì đường truyền có tải.

Bây giờ ghép với thứ đã đo ở Bài 4 mục 4.2: một kết nối HTTPS mới cần 1 RTT cho bắt tay TCP, cộng 1 RTT nữa cho bắt tay TLS 1.3. Với origin ở Virginia và RTT 250 ms, người dùng ở Hà Nội mất khoảng 500 ms trước khi request đầu tiên được gửi đi. Backend của bạn chưa nhận được gì cả.

6.2 Kiến trúc CDN, và tầng edge đo được bao nhiêu

CDN là một mạng gồm nhiều PoP (point of presence) đặt rải rác về mặt địa lý, mỗi PoP là một tầng cache đứng trước origin của bạn. Người dùng luôn nói chuyện với PoP gần nhất, và việc "gần nhất" được quyết định bằng anycast: cùng một địa chỉ IP được quảng bá từ nhiều nơi, định tuyến BGP (Border Gateway Protocol — giao thức các mạng lớn trên Internet dùng để trao đổi với nhau tuyến đường nào tới được đâu) tự đưa gói tin tới nơi gần nhất về mặt mạng, mà bạn không cần cấu hình gì thêm.

Lab dựng đúng tầng đầu tiên: một nginx thứ hai, nhưng khác hẳn lb.conf và gw.conf — nó lưu lại phản hồi thay vì chỉ chuyển tiếp. So sánh 32 kết nối, 10 giây, origin có độ trễ xử lý 30 ms:

Throughput gấp 25 lần, p50 giảm 27 lần. Nhưng cột cuối là cột đáng nhìn nhất: origin xử lý 4 request trong 208.173 — tức 0,002%. Toàn bộ phần còn lại được nginx trả từ cache của chính nó, và app hoàn toàn không biết chuyện gì đang diễn ra.

6.3 Header caching cho đúng

Tầng edge không tự đoán được nội dung nào cache được bao lâu — nó làm theo header mà origin phát ra. Đây là phần API duy nhất giữa app của bạn và CDN, và nó nhỏ hơn nhiều người tưởng.

Revalidation: ETag và 304

Khi TTL hết, tầng cache không nhất thiết phải tải lại toàn bộ. ETag là một chuỗi định danh cho một phiên bản nội dung cụ thể — trong lab nó là hash của chính body, nên nội dung không đổi thì ETag không đổi. Khi TTL hết, tầng cache gửi lại If-None-Match kèm ETag đã có; nếu ETag đó vẫn khớp (tức nội dung chưa đổi), origin trả 304 Not Modified không kèm body. Đo thật trên lab:

E=http://localhost:8082

etag=$(curl -s -D - -o /dev/null "$E/cacheable?key=b&ttl=60" \
  | grep -i '^etag:' | cut -d' ' -f2)
echo "ETag = $etag"                    # ETag = "7e9134f4"

curl -s -o /dev/null -w '%{http_code} %{size_download} byte\n' \
  "$E/cacheable?key=b&ttl=60"
# 200 62 byte                          ← downloads the full body again

curl -s -o /dev/null -H "If-None-Match: $etag" \
  -w '%{http_code} %{size_download} byte\n' "$E/cacheable?key=b&ttl=60"
# 304 0 byte                           ← only confirms "still valid", downloads nothing

Với một payload 62 byte thì tiết kiệm này vô nghĩa. Với một file JavaScript 800 KB thì mỗi lần revalidate tiết kiệm đúng 800 KB. Đó là lý do proxy_cache_revalidate on nằm trong cấu hình edge của lab: nó biến "hết hạn" từ chuyện phải tải lại thành chuyện chỉ cần hỏi một câu.

Trả bản cũ khi origin sập — và giới hạn của nó

Nhánh STALE đáng được đo riêng, vì nó là thứ giữ cho site còn sống. Thí nghiệm: nạp cache với TTL 2 giây, rồi dừng toàn bộ ba app, chờ TTL hết, và gọi lại:

# 1) warm the cache with TTL 2s
curl -sI "$E/cacheable?key=stale&ttl=2"     # X-Cache=MISS  36.5 ms
curl -sI "$E/cacheable?key=stale&ttl=2"     # X-Cache=HIT    3.6 ms

# 2) stop the whole origin
docker compose stop app1 app2 app3
sleep 3                                      # let the TTL expire

# 3) TTL expired + origin down -> what does edge do?
curl -sI "$E/cacheable?key=stale&ttl=2"     # 200  X-Cache=STALE     2.4 ms
curl -sI "$E/cacheable?key=stale&ttl=2"     # 200  X-Cache=UPDATING  2.5 ms
curl -sI "$E/cacheable?key=stale&ttl=2"     # 200  X-Cache=UPDATING  2.5 ms

# 4) a URL that was NEVER cached, origin still down
curl -sI "$E/cacheable?key=never-cached"    # 504  X-Cache=MISS   6.03 SECONDS

Ba dòng ở bước 3 là kết quả tốt nhất có thể: origin đã chết hoàn toàn mà người dùng vẫn nhận 200 OK trong 2,4 ms. UPDATING nghĩa là nginx đang thử làm mới ở nền trong khi vẫn trả bản cũ cho người dùng — đúng tinh thần proxy_cache_background_update.

Nhưng bước 4 là dòng phải nhớ. Một URL chưa từng nằm trong cache thì edge không có gì để trả: 504 sau 6,03 giây. Và con số 6 giây đó không phải ngẫu nhiên — đó là 3 upstream × proxy_connect_timeout 2s, đúng cơ chế đã gặp ở Bài 3. Người dùng chờ 6 giây rồi nhận lỗi, tệ hơn nhiều so với nhận lỗi ngay.

6.4 Cache key và Vary — nơi hit ratio âm thầm về 0

Cache key quyết định hai phản hồi có được coi là "cùng một thứ" hay không. Nó gồm URL (mặc định của nginx là $scheme$proxy_host$request_uri, tức bao gồm toàn bộ query string) cộng với những header mà origin khai báo trong Vary.

Hai cơ chế này là hai cách phổ biến nhất để phá hit ratio, và cả hai đều không tạo ra lỗi nào — cấu hình nhìn vào vẫn thấy "đã bật cache".

Đo mức thiệt hại: 251 lần tải origin, và hoàn toàn vô hình

Kiểm chứng bằng số ở quy mô tải. Cùng một nội dung, nhưng bộ đo tải gắn thêm một tham số utm_source lấy ngẫu nhiên trong 1.000 giá trị — đúng như lưu lượng thật từ các chiến dịch quảng cáo. So hai cấu hình cache key, 32 kết nối, 10 giây:

Tải origin chênh 251 lần. Và ba cột trước đó — throughput, p50, p99 — giống nhau đến mức không phân biệt được. Từ phía client, hai cấu hình này là một. Không có dashboard latency nào, không có alert nào, không có lỗi nào cho bạn biết.

Con số 1.003 cũng đáng để đọc: 1.000 giá trị utm_source khác nhau tạo ra đúng 1.000 cache key khác nhau, mỗi key một lần MISS. Cache vẫn "hoạt động" — nó chỉ đang lưu 1.000 bản của cùng một nội dung và không bản nào được dùng lại.

Cấu hình tạo ra hai hành vi trên, khác nhau đúng một dòng:

location /cacheable {
    # RAW KEY: nginx's default, includes the ENTIRE query string.
    # ?utm_source=facebook => a separate cache entry for the exact same content.
    proxy_cache_key "$scheme$proxy_host$request_uri";
    proxy_pass http://edge_origin;
    include /etc/nginx/snippets/edge-common.conf;
}

location /norm/cacheable {
    # NORMALIZED KEY: only lists the parameters that ACTUALLY decide the content.
    # nginx has no loop, so this "allowlist" is spelling out every $arg_* we accept
    # by hand. Tracking params (utm_*, fbclid, gclid) are ignored simply because
    # they are NOT part of the key.
    proxy_cache_key "norm|$uri|key=$arg_key|ttl=$arg_ttl|vary=$arg_vary";
    proxy_pass http://edge_origin/cacheable$is_args$args;
    include /etc/nginx/snippets/edge-common.conf;
}

6.5 Purge, URL có version, và cách làm trắng trang toàn bộ người dùng

Khi nội dung đổi, có hai cách để người dùng thấy bản mới: xoá bản cũ khỏi cache (purge), hoặc đổi URL để bản mới nằm ở một địa chỉ khác. Cách thứ hai gần như luôn tốt hơn, và lý do rất thực dụng.

Từ đó ra một quy tắc rất gọn cho việc đặt header, chia theo loại tài nguyên:

Tự làm lại các phép đo

cd blog/sysdesign/sysdesign-lab
docker compose --profile edge up -d
E=http://localhost:8082
purge() { docker compose exec -T edge sh -c 'rm -rf /var/cache/nginx/edge/*'; }

# --- MISS then HIT ---
purge
for i in 1 2 3; do
  curl -s -o /dev/null -D /tmp/h -w "%{time_total}s " "$E/cacheable?key=a&ttl=60"
  grep -i '^x-cache:' /tmp/h
done

# --- Vary: Cookie fragments the cache ---
purge
for c in user1 user2 user3 user1; do
  curl -s -o /dev/null -D /tmp/h -H "Cookie: sid=$c" \
    "$E/cacheable?key=e&ttl=60&vary=cookie"
  echo "sid=$c -> $(grep -i '^x-cache:' /tmp/h)"
done

# --- Origin load: RAW key vs NORMALIZED key (1000 random utm_source values) ---
purge && ./tools/cache-stats.sh reset
docker compose run --rm loadgen loadgen.js \
  --url "http://edge:8082/cacheable?key=a&ttl=60" \
  -c 32 -d 10 -w 3 --key-space 1000 --key-param utm_source --json
./tools/cache-stats.sh          # see how many requests the origin actually processed

purge && ./tools/cache-stats.sh reset
docker compose run --rm loadgen loadgen.js \
  --url "http://edge:8082/norm/cacheable?key=a&ttl=60" \
  -c 32 -d 10 -w 3 --key-space 1000 --key-param utm_source --json
./tools/cache-stats.sh          # compare: 1,003 vs 4

Tóm lại

Khoảng cách địa lý là hằng số vật lý: 1 ms cho mỗi 100 km khứ hồi, và một kết nối HTTPS mới cần 2 RTT trước khi request được gửi đi. Không có cách nào sửa bằng code — chỉ có cách đặt dữ liệu gần hơn. Tầng edge trong lab cho 25 lần throughput và đẩy 99,998% request ra khỏi origin, chỉ bằng nginx với proxy_cache.

Ba điều dễ sai nhất đều nằm ở phần header và cache key, và không cái nào tạo ra lỗi: no-cache vẫn cache (muốn không lưu phải dùng no-store); ETag sinh từ thời điểm thay vì từ nội dung làm 304 không bao giờ xảy ra; và cache key chứa tham số theo dõi làm tải origin tăng 251 lần trong khi mọi số liệu phía client không đổi một chút nào.

Cuối cùng, proxy_cache_use_stale giữ được site sống khi origin sập — nhưng chỉ cho những URL đã ở trong cache. Điều đó biến độ phủ của cache thành một phần của kế hoạch chống sự cố, và biến "flush cache rồi deploy" thành một việc cần nghĩ lại.

Bài 7 rời tầng cache để xuống tầng dữ liệu: replication. Lab sẽ có PostgreSQL primary và replica thật, đo replication lag bằng pg_stat_replication, và tự tay tái tạo bug mà mọi hệ thống có replica đều gặp — người dùng đổi ảnh đại diện rồi reload và thấy ảnh cũ.