The Content Delivery Network (CDN)

Problem statement

Nếu hàng triệu người dùng sử dụng app nặng về dữ liệu của ta, và ta chỉ deploy dịch vụ lên 1 data center tập trung để phục vụ user request, những vấn đề nào sẽ bị nảy sinh?

How will we design a CDN?

Ta sẽ chia việc thiết kế hệ thống CDN này ra 4 sections:

Introduction to a CDN

Proposed Solution

CDN - giải pháp nghe như sấm bên tai rồi.

Đây là 1 nhóm các proxy servers phân tán theo vị trí địa lý.

1 proxy server là 1 server trung gian nằm giữa client và server gốc. Các proxy servers được đặt trong network edge - 1 vùng mà tại đó kết nối mạng nội bộ hoặc thiết bị tới Internet.

Vì network edge ở gần với end users, việc đặt các proxy servers ở đây giúp phân phối nội dung tới ng dùng 1 các nhanh chóng với việc giảm độ trễ và băng thông.

Ở đây, ta có thể đưa dữ liệu tới gần người dùng hơn bằng cách đặt 1 data center nhỏ gần họ và lưu trữ bản copy của dữ liệu ở trong data center này. CDN chủ yếu lưu trữ 2 loại dữ liệu: tĩnh (có thể tồn tại trong thời gian dài như ảnh ọt) và động (có thể bị thay đổi liên tục như ads, live video).

Từ những vấn đề đc nêu ra ở problem statement, CDN có thể giải quyết ntn:

1 số nhà cung cấp CDN phổ biến:

Requirements

Functional requirements

Non-functional requirements

Building blocks we will use

1 combo default luôn song hành cùng nhau, đó là:

Design a CDN

CDN overview

Ta sẽ đi 1 lượt về thiết kế của CDN trong 2 phases:

  1. Phase thứ nhất bao gồm các components tạo nên 1 hệ thống CDN.

  2. Phase thứ hai sẽ khám phá các workflow bằng cách giải thích cách mỗi components tương tác với components khác để phát triển nên CDN đầy đủ tính năng.

CDN Components

CDN components

Workflow

  1. Server gốc cung cấp URI namespace tới tất cả object được cached trong CDN tới hệ thống request routing.

  2. Server gốc gửi nội dung tới hệ thống chịu trách nhiệm phân tán nội dung qua các edge proxy servers.

  3. Hệ thống phân tán nội dung gửi nội dung tới các proxy servers và gửi feedback lại hệ thống request routing. Các feedback này sẽ hữu dụng trong việc tối ưu lựa chọn proxy gần nhất tới request client.

  4. Client yêu cầu hệ thống routing địa chỉ IP của proxy server phù hợp.

  5. Hệ thống request routing trả về địa chỉ IP của proxy server phù hợp.

  6. Request của client đc được route qua các scrubber servers để đảm bảo bảo mật.

  7. Scrubber servers forward các traffic an toàn tới edge proxy servers.

  8. Edge proxy servers phục vụ nội dung theo client request.

API Design

Retrieve (proxy server to origin server)

Proxy server yêu cầu content từ origin server với GET method như sau:

GET /retrieve
retrieveContent(proxy_server_id, content_type, content_version, description)

Deliver (origin server to proxy servers)

Server gốc dùng API này để gửi các nội dung cụ thể tới proxy servers.

/deliver
deliverContent(origin_id, server_list, content_type, content_version, description)

Request (clients to proxy servers)

Người dùng sử dụng API này để yêu cầu content từ proxy servers.

/request_content
requestContent(user_id, content_type, description)

Search (proxy server to peer proxy servers)

Proxy server sử dụng API này để có thể tìm kiếm content từ các peer proxy servers khác, từ đó giảm tải hơn nữa lượng tải tới server gốc.

/search
searchContent(proxy_server_id, content_type, description)

Update (proxy server to peer proxy servers)

Proxy server sử dụng API này để cập nhật nội dung lấy từ peer proxy servers POP.

/update
updateContent(proxy_server_id, content_type, description)

In-depth Investigation of CDN

Content caching strategies in CDN

Push CDN

Push CDN illustration

Trong push CDN model, nội dung được gửi tự động từ origin server tới proxy servers. Nhà cung cấp nội dung sẽ chịu trách nhiệm trong việc chuyển giao nội dung tới các CDN proxy servers.

Thích hợp với static content delivery, tại đó origin server quyết định nội dung nào được đưa tới người dùng qua CDN. Nội dung được đẩy lên proxy servers ở các đa dạng vị trí địa lý tùy thuộc theo độ phổ biến ở đó.

Nếu nội dung liên tục thay đổi, mô hình này có thể gặp khó khăn để theo kịp sự thay đổi với rất nhiều content push dư thừa.

Pull CDN

Pull CDN illustration

CDN kéo các dữ liệu ko có sẵn từ origin server tới người dùng. Các proxy servers lưu trữ các files trong 1 thời gian nhất định rồi xóa nếu chúng ko còn được yêu cầu trong suốt thời gian đó để cân bằng dung lượng và chi phí.

Bản thân CDN chịu trách nhiệm trong việc kéo nội dung được yêu cầu từ origin server và deliver cho người dùng. Mô hình này thích hợp nhất với các dynamic content và lượng traffic tải cao.

  • Hầu hết nhà cung cấp nội dung áp dụng cả 2 mô hình để tận dụng được lợi thế cả 2.

  • Vì static content hướng tới tệp người dùng rộng lớn hơn dynamic content, push CDN sẽ yêu cầu nhiều replicas hơn pull CDN để đáp ứng tính sẵn sàng cao nhất.

Dynamic content caching optimization

1 số việc tạo dynamic content yêu cầu phải thực thi các đoạn scripts ở proxy server thay vì origin server. Chẳng hạn, ta có thể có những trường hợp cần generate dynamic content dựa trên vị trí người dùng, thời gian theo vùng, APIs cụ thể cho từng vùng, etc...

Để giảm thiểu lưu lượng dữ liệu giữa server gốc và các proxy servers, cùng với giới hạn về storage ở proxy servers, ta có thể áp dụng giải pháp nén dữ liệu lại. Ví dụ, Cloudflare sử dụng Railgun để nén dynamic content.

Multi-tier CDN architecture

Multi-tier CDN architecture illustration

CDN tuân theo kiến trúc dạng cây để giảm bớt gánh nặng phân tán dữ liệu cho server gốc.

Cấu trúc dạng cây này giúp ta scale hệ thống dễ dàng hơn. Khi lượng người dùng truy cập tăng cao, ta chỉ cần thêm các server nodes ở nhánh cây.

Với 1 2 tầng proxy servers (caches), lượng tải tới server gốc cũng được giảm tải đáng kể xuống còn 1 nửa

Find the nearest proxy server to fetch data

Important factors that affect the proximity of the proxy server

DNS redirection

DNS có thể trả về client 1 URI thay vì 1 IP

DNS redirection illustration

Cách tiếp cận bằng DNS redirection này bao gồm 2 bước:

  1. Map clients với vị trí network thích hợp.

  2. Phân tán tải qua các proxy servers trong vị trí đó để cân bằng tải.

Anycast

Anycast là 1 phương pháp routing mà tại đó tất cả edge servers trong nhiều địa điểm chia sẻ chung 1 địa chỉ IP. Chúng sử dụng Border Gateway Protocol (BGP) để route clients dựa trên Internet.

Client multiplexing

Client multiplexing gửi cho clients 1 list các servers ứng viên. Client chọn ra 1 server trong list đó để gửi request tới.

HTTP redirecting

Đây là cách dễ nhất. Clients sẽ gửi yêu cầu nội dung tới server gốc. Server gốc sẽ phản hồi với 1 HTTP protocol để chuyển hướng người dùng thông qua URL của nội dung.

Dưới đây là 1 đoạn HTML snippet của Facebook. Ta có thể để ý từ thẻ <img></img>, người dùng sẽ được chuyển hướng tới CDN cho Facebook logo.

<!––  The code below is taken from Facebook. -->
<div class="fb_content clearfix " id="content" role="main">
  <div>
    <div class="_8esj _95k9 _8esf _8opv _8f3m _8ilg _8icx _8op_ _95ka">
      <div class="_8esk">
        <div class="_8esl">
          <div class="_8ice">
            <img class="fb_logo" src="https://static.xx.fbcdn.net/rsrc.php/y8/r/dF5SId3UHWd.svg" />
          </div>
          <h2 class="_8eso">Facebook helps you connect and share with the people in your life.</h2>
        </div>
      </div>
    </div>
  </div>
</div>

Content consistency in CDN

Dữ liệu trong proxy servers nên được thống nhất với dữ liệu trong server gốc, nhưng cũng ko lại trừ nguy cơ dữ liệu ở 2 bên bị lệch nhau. Điều này khiến cho người dùng có thể truy cập tới nội dung bị chậm cập nhật.

Ta có thể áp dụng nhiều cơ chế khác nhau để củng cố tính thống nhất của dữ liệu, tùy vào model pull CDN hay push CDN.

Periodic polling

Được sử dụng cho pull model. Proxy servers yêu cầu server gốc cập nhật dữ liệu và thay cached content định kỳ. Periodic polling sử dụng time-to-refresh (TTR) để đặt thời gian yêu cầu cập nhật dữ liệu.

Time-to-live (TTL)

Với TTR, proxy servers có thể yêu cầu cập nhật các dữ liệu vô dụng, nên có 1 cách khác tốt hơn có thể giảm tải số lượng request cập nhật lại, đó là time-to-live (TTL).

Mỗi object sẽ có 1 attribute TTL được gán bởi server gốc, tượng trưng cho thời gian mà object này sẽ hết hạn. Proxy server sẽ phục vụ phiên bản của object này cho đến khi chũng hết hạn.

Khi xác định được là dữ liệu đã hết hạn, proxy servers sẽ kiểm tra cập nhật từ server gốc. Nếu dữ liệu đã được thay đổi, proxy servers sẽ lấy phiên bản mới nhất của dữ liệu đó, còn ko thì chúng sẽ giữ nguyên dữ liệu và chỉ thay đổi TTL.

Leases

Ở kỹ thuật này, server gốc sẽ cho proxy server thuê, hoặc subscribe data.

Nghĩa là nếu proxy server yêu cầu 1 data object, server gốc sẽ gửi object đó đi kèm với thông tin cho thuê, bao gồm 1 giá trị time range. Giá trị quãng thời gian đó đóng vai trò xác định thời gian mà proxy server sẽ được server gốc thông báo nếu có sự thay đổi phiên bản của data object.

Như vậy, nếu ở server gốc có cập nhật nào với 1 data object, nó sẽ thông báo tới các proxy server đang subscribe object này, và cập nhật tới phiên bản mới nhất.

Deployment

Trước khi cài đặt các tiện nghi cho CDN, ta cần phải trả lời được 2 câu hỏi này trước:

Placement of CDN proxy servers

Các CDN proxy servers phải được đặt ở nơi có mạng lưới networks được kết nối tốt:

Hiện nay, việc lưu giữ 1 lượng lớn dữ liệu dạng video trong 1 cơ sở hạ tầng CDN mà đc đặt trong ISP là điều hoàn toàn khả thi.

Tuy vậy, với các dịch vụ như Zootube, lượng dữ liệu là quá lớn và ngày càng mở rộng thêm nên việc quyết định cho cái gì cần người dùng là 1 thử thách khó khăn.

Google sử dụng split TCP để giảm delay từ phía người dùng bằng cách giữ kết nối liên tục với các TCP windows khổng lồ từ cơ sở hạ tầng cấp IXP tới trung tâm dữ liệu ưu tiên của họ. Áp dụng cách này sẽ giúp cho Zootube tránh được việc phải khởi tạo 3-way handshake trong 1 TCP connection và tình trạng slow-start ở các host cách xa địa lý.

Akamai và Netflix đã phổ cập ý tưởng về giữ các CDN proxy servers của họ trong ISPs của clients. Mặt khác, Google cũng có cơ sở hạ tầng CDN riêng tư nhưng dựa vào các servers gần IXPs hơn, lý do chủ yếu đến từ việc lượng dữ liệu khổng lồ và việc thay đổi các patterns.

CDN as a service

Trước khi sử dụng các dịch vụ public CDN, các nhà cung cấp nội dung cần cân nhắc các điều kiện sau:

1 số công ty sẽ tự xây dựng CDN thay vì sử dụng các dịch vụ của nhà cung cấp CDN. Như Netflix họ tự build nên 1 hệ thống riêng gọi là Open Connect.

Specialized CDN

Trong trường hợp công ty tự xây dựng CDN, họ sẽ quan tâm tới những điểm sau:

Netflix's Open Connect Appliance (OCA) là 1 ví dụ điển hình. Các OCA servers ko lưu lại dữ liệu của người dùng, thay vào đó chúng đáp ứng đầy đủ các tasks sau:

Why Netflix built its CDN

Evaluation of CDN's Design

Để nhắc lại, requirements chính của ta là hiệu năng cao, tính sẵn sàng, tính scalability, độ tin cậy và an toàn bảo mật.

Performance

CDN đạt được hiệu năng cao nhờ tối ưu độ trễ. 1 số điểm đang chú ý như sau:

Availability

1 CDN có thể đối phó với lượng traffic khổng lồ nhờ đặc tính phân tán của nó.

Tính sẵn sàng đc đảm bảo thông qua việc content đc cached có thể đc tận dụng như backup trong trường hợp server gốc oẳng.

Edge proxy servers có thể đạt được tính sẵn sàng nhờ việc sao lưu dữ liệu tới nhiều proxy servers để tránh single point failure và thỏa mãn lượng tải yêu cầu.

Load balancer cũng đóng vai trò quan trọng trong việc phân tán request của người dùng tới các proxy servers.

Scalability

Reliability and Security