Phân tích Kiến trúc Microservices trên Cloud của Netflix

1. Giới thiệu về Netflix

Netflix là một trong số các dịch vụ streaming dựa trên lượt đăng ký tốt nhất trên thế giới, chiếm hơn 15% dung lượng băng thông Internet toàn cầu. Vào năm 2019, Netflix đã có hơn 167 triệu người đăng ký, trong đó có hơn 5 triệu người đăng ký mới mỗi quý và hoạt động tại hơn 200 quốc gia. Cụ thể, người dùng Netflix dành hơn 165 triệu giờ để xem hơn 4.000 bộ phim và 47.000 tập mỗi ngày. Những số liệu thống kê ấn tượng này cho ta thấy, từ góc độ kỹ thuật, các nhóm kỹ thuật của Netflix đã thiết kế một hệ thống phát video trực tuyến tuyệt vời với tính khả dụng và khả năng mở rộng rất cao để phục vụ khách hàng của họ dù ở bất cứ đâu trên thế giới.

Đội ngũ kỹ thuật Netflix đã mất hơn 8 năm để xây dựng hệ thống CNTT như bây giờ. Trên thực tế, quá trình chuyển đổi cơ sở hạ tầng tại Netflix bắt đầu từ tháng 8 năm 2008, sau khi họ ngừng dịch vụ tại các trung tâm dữ liệu của chính hãng, đóng toàn bộ dịch vụ cho thuê DVD trong ba ngày. Netflix nhận ra rằng họ cần một cơ sở hạ tầng đáng tin cậy hơn và hạn chế tối đa điểm lỗi. Do đó, họ đã đưa ra hai quyết định quan trọng: Chuyển cơ sở hạ tầng từ các trung tâm dữ liệu của mình sang 1 public cloud, thay thế các chương trình monolithic (nguyên khối) bằng kiến trúc microservices. Cả hai quyết định này đã trực tiếp định hình thành công ngày nay của Netflix.

Netflix đã chọn cloud AWS để dịch chuyển hạ tầng. AWS có thể cung cấp cơ sở dữ liệu (CSDL) có độ tin cậy cao, lưu trữ cloud quy mô lớn và có nhiều trung tâm dữ liệu trên toàn cầu. Bằng cách sử dụng hạ tầng đám mây do AWS xây dựng và duy trì, Netflix không cần thực hiện công việc đơn lẻ, tốn kém như xây dựng trung tâm dữ liệu vật lý. Họ tập trung nhiều hơn vào hoạt động kinh doanh cốt lõi của mình là cung cấp trải nghiệm người dùng khi xem video trực tuyến chất lượng cao. Mặc dù phải xây dựng lại toàn bộ công nghệ để có thể chạy trơn tru trên cloud AWS, nhưng bù lại, việc cải thiện khả năng mở rộng và tính khả dụng của dịch vụ, Netflix đã thu được lợi nhuận đáng kể.

Netflix cũng là một trong những công ty đầu tiên sử dụng thành công kiến trúc microservices. Microservices nhắm vào các vấn đề của thiết kế phần mềm nguyên khối bằng phương pháp “separation of concerns” trong đó các chương trình lớn được chia thành các thành phần mềm nhỏ hơn theo mô đun, với việc tự đóng gói dữ liệu. Microservices cũng giúp tăng khả năng mở rộng thông qua chia tỷ lệ theo chiều ngang và phân vùng khối lượng công việc. Bằng cách áp dụng microservices, các kỹ sư của Netflix dễ dàng thay đổi các dịch vụ giúp triển khai nhanh hơn. Ngoài ra, họ có thể theo dõi hiệu suất của từng dịch vụ và nhanh chóng giải quyết, cô lập các vấn đề dịch vụ đó với các dịch vụ đang chạy khác.

Trong bài viết này, ta sẽ tìm hiểu kiến trúc cloud của Netflix và hiệu suất của nó trong các khối lượng công việc và giới hạn mạng khác nhau. Cụ thể, bài viết sẽ phân tích thiết kế hệ thống về tính khả dụng, độ trễ, khả năng mở rộng và khả năng phục hồi đối với sự cố mạng hoặc sự cố hệ thống. Nội dung chính cuẩ các phần như sau:

Phần 2 sẽ mô tả một kiến trúc hệ thống Netflix khả thi được học từ nhiều nguồn trực tuyến khác nhau.
Phần 3 sẽ thảo luận về các thành phần hệ thống chi tiết hơn.
Phần 4, 5, 6, 7 sẽ phân tích hệ thống theo các mục tiêu chi tiết ở trên.
Kết luận những gì đã học được từ phân tích này và các bước tiếp theo có thể cần áp dụng để cải thiện.

2. Kiến trúc Cloud của Netflix

Netflix hoạt động dựa trên các dịch vụ điện toán đám mây của Amazon (AWS) và Open Connect – mạng phân phối nội dung nội bộ của AWS. Cả hai hệ thống phải hoạt động liền mạch với nhau để cung cấp dịch vụ streaming chất lượng cao trên toàn cầu. Từ góc độ kiến trúc phần mềm, Netflix được cấu tạo bởi ba phần chính: Client, Backend và Content Delivery Network (CDN).

Client là bất kỳ trình duyệt nào được hỗ trợ trên máy tính xách tay, máy tính để bàn hoặc ứng dụng Netflix trên điện thoại thông minh, TV thông minh. Netflix phát triển ứng dụng iOS và Android của riêng mình để cung cấp trải nghiệm xem tốt nhất cho từng khách hàng và thiết bị. Bằng cách kiểm soát các ứng dụng và các thiết bị khác của họ thông qua SDK, Netflix có thể điều chỉnh các dịch vụ phát trực tuyến của mình một cách minh bạch trong một số trường hợp nhất định như mạng chậm hoặc máy chủ quá tải.

Backend bao gồm các dịch vụ, CSDL, kho lưu trữ chạy hoàn toàn trên đám mây AWS. Backend về cơ bản xử lý mọi thứ không liên quan đến streaming. Một số thành phần của Backend với các dịch vụ AWS tương ứng của chúng được liệt kê như sau:

Scalable computing instances (AWS EC2)
Scalable storage (AWS S3)
Business logic microservices (các khuôn khổ được xây dựng có mục đích bởi Netflix)
Scalable distributed databases (AWS DynamoDB, Cassandra)
Các công việc phân tích và xử lý Big data (AWS EMR, Hadoop, Spark, Flink, Kafka và các công cụ do Netflix xây dựng cho mục đích khác)
Xử lý và chuyển mã video (các công cụ được xây dựng theo mục đích của Netflix)

Open Connect CDN là một mạng lưới các server gọi là Open Connect Appliances (OCAs), được tối ưu hóa để lưu trữ và phát trực tuyến các video dung lượng lớn. Các máy chủ OCA được đặt bên trong nhà cung cấp dịch vụ internet (ISP) và các mạng lưới địa điểm trao đổi internet (IXP) trên khắp thế giới. OCA chịu trách nhiệm streaming tới khách hàng.

Trong các phần tiếp theo, tôi sẽ mô tả một tham chiếu về kiến trúc đám mây Netflix bao gồm 3 phần trên. Trong phần 2.1, một kiến trúc tổng thể có khả năng phát trực tuyến video, được gọi là kiến trúc Playback, sau khi người đăng ký nhấp vào nút Play trên ứng dụng của họ. Sau đó, trong phần 2.2, một kiến trúc microservices chi tiết hơn của Backend sẽ được mô tả để chứng minh cách Netflix xử lý tính khả dụng và khả năng mở rộng ở quy mô toàn cầu.

2.1 Kiến trúc Playback

Khi người đăng ký nhấp vào nút Play trên ứng dụng hoặc thiết bị của họ, cả Backend trên AWS và OCA trên Netflix CDN sẽ cùng hoạt động để phát video trực tuyến. Sơ đồ sau minh họa cách thức hoạt động của quá trình phát lại:

Các OCA liên tục gửi báo cáo tình trạng về trạng thái khối lượng công việc, khả năng định tuyến và các video có sẵn tới Cache Control đang chạy trong AWS EC2 để Playback Apps cập nhật các OCA lành mạnh mới nhất cho Client.
Yêu cầu Phát được gửi từ thiết bị của người dùng tới dịch vụ Playback Apps của Netflix đang chạy trên AWS EC2 để lấy URL cho video phát trực tuyến.
Playback Apps phải xác định rằng yêu cầu Phát sẽ hợp lệ để xem video cụ thể. Việc xác thực như vậy sẽ kiểm tra gói của người đăng ký, việc cấp phép video ở các quốc gia khác nhau, v.v.
Playback Apps trao đổi với Steering service cũng đang chạy trong AWS EC2 để nhận danh sách các máy chủ OCAs thích hợp của video được yêu cầu. Steering service sử dụng địa chỉ IP của Client và thông tin ISP để xác định một tập hợp các OCA phù hợp hoạt động tốt nhất cho Client đó.
Từ danh sách 10 máy chủ OCA khác nhau do Playback Apps trả về, Client sẽ kiểm tra chất lượng kết nối mạng với các OCA này và chọn OCA nhanh nhất, đáng tin cậy nhất để yêu cầu phát tệp video.
Máy chủ OCA đã chọn chấp nhận các yêu cầu từ Client và bắt đầu phát trực tuyến video.

Trong sơ đồ trên, Steering service, Playback Apps và Cache Control service chạy hoàn toàn trong đám mây AWS dựa trên kiến trúc microservices. Trong phần tiếp theo, tôi sẽ mô tả một tham chiếu về kiến trúc microservices Netflix Backend giúp tăng tính khả dụng và khả năng mở rộng của các dịch vụ đang chạy

2.2 Kiến trúc Backend

Như đã đề cập trong phần trước, Backend xử lý hầu hết mọi thứ, từ đăng ký, đăng nhập, thanh toán đến các tác vụ xử lý phức tạp hơn như chuyển mã video và đề xuất được cá nhân hóa. Để hỗ trợ cả khối lượng công việc nhẹ và nặng chạy trên cùng một hạ tầng cơ bản, Netflix đã chọn kiến trúc microservices cho hệ thống dựa trên đám mây của họ. Sơ đồ dưới đây đại diện cho một kiến trúc microservices có thể có tại Netflix mà tôi đã lấy từ một số nguồn trực tuyến:

Hình 2 . Tham khảo kiến trúc phụ trợ dựa trên nhiều nguồn khác nhau

Client gửi yêu cầu Play tới Backend đang chạy trên AWS. Yêu cầu đó được xử lý bởi AWS Load balancer (ELB)
AWS ELB sẽ chuyển tiếp yêu cầu đó tới API Gateway Service chạy trên các phiên bản AWS EC2. Thành phần này tên là Zuul, được xây dựng bởi Netflix cho phép định tuyến động, giám sát lưu lượng và bảo mật, khả năng phục hồi đối với các lỗi khi triển khai đám mây. Yêu cầu sẽ được áp dụng cho một số bộ lọc được xác định trước tương ứng với lôgic kinh doanh, sau đó được chuyển tiếp đến Application API để xử lý thêm.
Application API là logic cốt lõi đằng sau các hoạt động của Netflix. Có một số loại API tương ứng với các hoạt động khác nhau của người dùng như API đăng ký, API đề xuất để truy xuất đề xuất video. Trong trường hợp này, yêu cầu được chuyển tiếp từ API Gateway Service được Play API xử lý.
Play API sẽ gọi một microservice hoặc một chuỗi microservice để đáp ứng yêu cầu. Dịch vụ Playback Apps, dịch vụ Chỉ đạo và dịch vụ Kiểm soát bộ nhớ cache trong Hình 1 có thể được xem như một dịch vụ nhỏ trong sơ đồ này.
Microservices hầu hết là các chương trình nhỏ không trạng thái và có thể gọi lẫn nhau.Để kiểm soát cascading failure and enable resilience,mỗi microservice được cách ly khỏi các quy trình của người gọi bằng Hystrix. Kết quả của nó sau khi chạy có thể được lưu vào bộ nhớ đệm dựa trên bộ nhớ để cho phép truy cập nhanh hơn cho các yêu cầu độ trễ thấp quan trọng đó.
Microservices có thể lưu vào hoặc lấy dữ liệu từ một kho dữ liệu trong suốt quá trình của nó.
Microservices có thể gửi các sự kiện để theo dõi hoạt động của người dùng hoặc dữ liệu khác tới Stream Processing Pipeline để xử lý theo thời gian thực đối với đề xuất được cá nhân hóa hoặc xử lý hàng loạt các nhiệm vụ kinh doanh thông minh.
Dữ liệu đi ra từ Stream Processing Pipeline có thể được lưu trữ liên tục đến các kho dữ liệu khác như AWS S3, Hadoop HDFS, Cassandra, v.v.

Các kiến trúc được mô tả giúp ta hiểu về cách các phần khác nhau sắp xếp và hoạt động cùng nhau để streaming. Tuy nhiên, để phân tích tính khả dụng và khả năng mở rộng của kiến trúc, ta cần đi sâu hơn vào từng thành phần quan trọng để xem nó hoạt động như thế nào trong các khối lượng công việc khác nhau.

3. Thành phần

Trong phần này, ta sẽ xem xét các thành phần đã được xác định tại Mục 2, để phân tích tính khả dụng và khả năng mở rộng của nó. Khi miêu tả mỗi thành phần, tôi sẽ đồng thời miêu tả cách nó đáp ứng các mục tiêu thiết kế này. Phân tích thiết kế chuyên sâu hơn cũng sẽ được đề cập trong các phần tiếp theo liên quan tới toàn bộ hệ thống.

3.1 Khách hàng

Đội ngũ kỹ thuật của Netflix đã rất nỗ lực trong việc phát triển các ứng dụng chạy nhanh hơn và thông minh hơn trên laptop, máy tính bàn hoặc các thiết bị di động. Ngay cả trên một số TV thông minh mà Netflix không xây dựng ứng dụng dành cho khách chuyên biệt, Netflix vẫn kiểm soát hiệu suất của nó thông qua SDK được cung cấp. Trên thực tế, bất kỳ môi trường thiết bị nào cũng cần cài đặt Netflix Ready Devive Platform (NRDP) để mang lại trải nghiệm xem Netflix tốt nhất có thể. Một thành phần cấu trúc khách hàng điển hình ([11]) được minh họa trong Hình 3.

Hình 3. Client App Component

Các Ứng dụng Khách tách biệt 2 loại kết nối với Backend để khám phá và phát lại nội dung. Ứng dụng khách sử dụng giao thức NTBA cho các yêu cầu Phát lại để đảm bảo bảo mật hơn đối với các vị trí máy chủ OCA của nó và để loại bỏ SSL/TLS handshake cho các kết nối mới.
Trong khi streaming videos, Ứng dụng Khách sẽ giảm chất lượng video một cách thông minh hoặc chuyển sang các máy chủ OCA khác nhau nếu kết nối mạng bị quá tải hoặc lỗi. Ngay cả khi OCA được kết nối bị quá tải hoặc bị lỗi, Ứng dụng Khách có thể dễ dàng thay đổi sang máy chủ OCA khác để có trải nghiệm xem tốt hơn. Tất cả điều này có thể đạt được là nhờ Netflix Platform SDK trên Ứng dụng Khách luôn theo dõi các OCA lành mạnh mới nhất được truy xuất từ dịch vụ Ứng dụng phát lại (Hình 1)

3.2 Backend

3.2.1 API Gateway Service

Thành phần API Gateway Service kết nối với AWS Load Balancers để giải quyết tất cả các yêu cầu của khách hàng. Thành phần này có thể được triển khai cho nhiều AWS EC2 instances trên các khu vực khác nhau để tăng tính khả dụng của dịch vụ Netflix. Sơ đồ trong Hình 4 đại diện cho một Zuul nguồn mở, một triển khai của API Gateway do nhóm Netflix tạo ra.

Hình 4. Zuul Gateway Service Component

Inbound Filters có thể được sử dụng để xác thực, định tuyến và bổ sung cho yêu cầu.
Endpoint Filter có thể được sử dụng để trả về tài nguyên tĩnh hoặc định tuyến yêu cầu đến API gốc hoặc ứng dụng thích hợp để xử lý thêm.
Outbound Filters có thể được sử dụng để theo dõi số liệu, phản hồi cho người dùng hoặc thêm tiêu đề tùy chỉnh.
Zuul có thể khám phá API ứng dụng mới bằng cách tích hợp với Eureka khám phá dịch vụ.
Zuul được sử dụng rộng rãi để định tuyến lưu lượng truy cập cho các mục đích khác nhau như tích hợp API ứng dụng mới, kiểm tra tải, định tuyến đến các endpoints dịch vụ khác nhau với khối lượng công việc lớn.

3.2.2 API Ứng dụng

API ứng dụng đóng vai trò của một lớp điều phối đối với các dịch vụ vi mô của Netflix. API cung cấp một logic tạo các yêu cầu tới các dịch vụ vi mô cơ bản theo thứ tự cần thiết, với dữ liệu bổ sung từ các kho dữ liệu khác để tạo ra các phản hồi thích hợp. Đội ngũ Netflix đã dành rất nhiều thời gian để thiết kế thành phần API ứng dụng vì nó tương thích với các chức năng kinh doanh cốt lõi của Netflix. Nó cũng cần có khả năng mở rộng, khả dụng cao với khối lượng yêu cầu lớn. Hiện tại, API ứng dụng được xác định theo ba danh mục: Signup API cho các yêu cầu không phải thành viên như đăng ký, thanh toán, dùng thử miễn phí, v.v., Discovery API để tìm kiếm, yêu cầu đề xuất và Play API để phát trực tuyến, xem yêu cầu cấp phép. Sơ đồ thành phần cấu trúc chi tiết của API Ứng dụng được cung cấp trong Hình 5.

Hình 5. Separation of Play and Discovery Application API

Trong bản cập nhật triển khai Play API gần đây, giao thức mạng giữa Play API và vi dịch vụ là gRPC/HTTP2 “cho phép các phương thức và thực thể RPC được xác định thông qua Protocol Buffers và các thư viện/SDK ứng dụng được tạo tự động bằng nhiều ngôn ngữ khác nhau”. Thay đổi cho phép API ứng dụng tích hợp thích hợp với các máy khách được tạo tự động thông qua giao tiếp hai chiều và để “giảm thiểu việc sử dụng lại code trên các service boundaries”.
API Ứng dụng cũng cung cấp một cơ chế phục hồi chung dựa trên các lệnh Hystrix để bảo vệ các dịch vụ vi mô cơ bản của nó.

Vì API Ứng dụng phải xử lý khối lượng yêu cầu khổng lồ và xây dựng các phản hồi thích hợp, nên quá trình xử lý nội bộ của nó cần phải chạy song song. Đội ngũ Netflix đã tìm thấy sự kết hợp giữa thực thi đồng bộ và I/O không đồng bộ là cách tiếp cận phù hợp.

Hình 6. Synchronous Execution & Asynchronous I/O of Application API

Mỗi yêu cầu từ Dịch vụ Cổng API sẽ được đưa vào Application API’s Network Event Loop để xử lý.
Mỗi yêu cầu sẽ bị chặn bởi một trình xử lý luồng chuyên dụng đặt các lệnh Hystrix như getCustomerInfo, getDeviceInfo, v.v. vào Outgoing Event Loop. Outgoing Event Loop được thiết lập cho mỗi máy khách và chạy với I/O không chặn. Sau khi các dịch vụ gọi điện kết thúc hoặc hết thời gian, chuỗi chuyên dụng sẽ tạo các phản hồi tương ứng.

3.2.3 Microservices

Theo định nghĩa của Martin Fowler, “Microservices là một tập hợp các dịch vụ nhỏ, mỗi dịch vụ chạy trong quy trình riêng và giao tiếp với các cơ chế nhẹ…”. Các chương trình nhỏ này có thể triển khai độc lập hoặc có thể nâng cấp đối với những chương trình khác và có dữ liệu được đóng gói riêng.

Việc triển khai thành phần microservice tại Netflix ([11]) được minh họa trong Hình 7.

Hình 7. Structural component of a microservice

Một microservice có thể tự hoạt động hoặc gọi các dịch vụ vi mô khác qua REST hoặc gRPC.
Việc triển khai microservice có thể tương tự Ứng dụng API như được mô tả trong Hình 6, trong đó các yêu cầu sẽ được đưa vào Network Event Loop và kết quả từ các dịch vụ vi mô khác được đặt vào hàng đợi kết quả trong non-blocking I/O.
Mỗi microservice có thể có kho dữ liệu riêng và một số kho lưu trữ bộ nhớ đệm trong bộ nhớ của các kết quả gần đây. EVCache là lựa chọn chính để lưu vào bộ nhớ đệm của các microservice tại Netflix.

3.2.4 Lưu trữ dữ liệu

Khi di chuyển cơ sở hạ tầng sang đám mây AWS, Netflix đã sử dụng các kho dữ liệu khác nhau (Hình 8), cả SQL và NoSQL, cho các mục đích khác nhau ([6]).

Fig 8. Netflix Data Stores deployed on AWS

MySQL được sử dụng cho mục đích quản lý tiêu đề phim và giao dịch/thanh toán.
Hadoop được sử dụng để xử lý dữ liệu lớn dựa trên nhật ký của người dùng.
ElasticSearch đã hỗ trợ tìm kiếm tiêu đề cho các ứng dụng Netflix.
Cassandra là một kho lưu trữ dữ liệu NoSQL dựa trên cột phân tán để xử lý số lượng lớn các yêu cầu đọc mà không có điểm lỗi nào. Để tối ưu hóa độ trễ so với các yêu cầu ghi lớn, Cassandra được sử dụng vì khả năng nhất quán cuối cùng của nó.

3.2.5 Stream Processing Pipeline

Stream Processing Data Pipeline ([14,3]) đã trở thành xương sống dữ liệu của Netflix trong các nhiệm vụ phân tích kinh doanh và đề xuất được cá nhân hóa. Nó chịu trách nhiệm sản xuất, thu thập, xử lý, tổng hợp và chuyển tất cả các sự kiện vi dịch vụ sang các bộ xử lý dữ liệu khác trong thời gian gần thực. Hình 9 cho thấy các phần khác nhau của nền tảng.

Hình 9. Keystone Stream Processing Platform at Netflix

Nền tảng xử lý luồng đã xử lý hàng nghìn tỷ sự kiện và petabyte dữ liệu mỗi ngày. Nó cũng sẽ tự động mở rộng quy mô khi số lượng người đăng ký tăng lên.
Mô-đun Bộ định tuyến cho phép định tuyến đến các bồn chứa dữ liệu hoặc ứng dụng khác nhau trong khi Kafka chịu trách nhiệm định tuyến các thông báo cũng như bộ đệm cho các hệ thống hạ lưu.
Stream Processing as a Service (SPaaS) cho phép các kỹ sư dữ liệu xây dựng và giám sát các ứng dụng xử lý luồng được quản lý tùy chỉnh của họ trong khi nền tảng sẽ quan tâm đến khả năng mở rộng và hoạt động.

3.3 Open Connect

Open Connect là mạng phân phối nội dung toàn cầu (CDN) chịu trách nhiệm lưu trữ và phân phối các chương trình truyền hình và phim Netflix cho người đăng ký trên toàn thế giới. Netflix đã xây dựng và vận hành Open Connect một cách hiệu quả bằng cách đưa nội dung mà mọi người muốn xem đến gần nơi họ muốn xem nhất có thể. Để bản địa hóa lưu lượng xem video Netflix vào mạng của khách hàng, Netflix đã hợp tác với Nhà cung cấp dịch vụ Internet (ISP) và Điểm trao đổi Internet (IX hoặc IXP) trên toàn thế giới để triển khai các thiết bị chuyên dụng có tên Open Connect Appliances (OCA) bên trong mạng của họ ([7]).

Hình 10. Deployment of OCAs to IXs or ISPs sites

OCA là các máy chủ được tối ưu hóa để lưu trữ và phát trực tuyến các tệp video lớn từ các trang web IX hoặc ISP trực tiếp đến trang chủ của người đăng ký. Các máy chủ này báo cáo định kỳ các tuyến đường tối ưu về chỉ số sức khỏe mà chúng học được từ mạng IXP/ISP và những video nào chúng lưu trữ trên đĩa SSD của mình cho các dịch vụ Open Connect Control Plane trên AWS. Đổi lại, các dịch vụ mặt phẳng điều khiển sẽ lấy dữ liệu đó để tự động hướng các thiết bị khách đến các OCA tối ưu nhất dựa trên tính khả dụng của tệp, tình trạng máy chủ và mức độ gần gũi của mạng với các máy khách.

Các dịch vụ máy bay điều khiển cũng kiểm soát hành vi điền của việc thêm tệp mới hoặc cập nhật tệp trên OCA hàng đêm. Các hành vi lấp đầy ([8,9]) được minh họa trong Hình 11.

Khi các tệp video mới đã được chuyển mã thành công và được lưu trữ trên AWS S3, các dịch vụ mặt phẳng điều khiển trên AWS sẽ chuyển các tệp này đến máy chủ OCAs trên các trang IXP. Các máy chủ OCAs này sẽ áp dụng tính năng lấp đầy bộ nhớ cache để chuyển các tệp này đến máy chủ OCAs trên các trang web ISP trong mạng con của chúng.
Khi một máy chủ OCA đã lưu trữ thành công các tệp video, nó sẽ có thể bắt đầu điền ngang hàng để sao chép các tệp này sang các máy chủ OCA khác trong cùng một trang web nếu cần.
Giữa 2 trang web khác nhau có thể nhìn thấy các địa chỉ IP của nhau, các OCA có thể áp dụng quy trình điền theo cấp thay vì lấp đầy bộ nhớ cache thông thường.

Về VTI Cloud

VTI Cloud tự hào là Advanced Consulting Partner của AWS và Gold Partner của Microsoft nhằm đem đến sức mạnh của Điện toán đám mây và các dịch vụ CNTT hàng đầu đến với các tổ chức, doanh nghiệp tại thị trường Việt Nam và Nhật Bản. VTI Cloud sở hũu đội ngũ hơn 50+ kỹ sư về giải pháp được chứng nhận bởi AWS, cùng đội ngũ giàu kinh nghiệm với hàng trăm dự án lớn. Xây dựng các kiến trúc an toàn, hiệu suất cao, linh hoạt, và tối ưu chi phí cho khách hàng là nhiệm vụ hàng đầu của VTI Cloud trong sứ mệnh công nghệ hóa doanh nghiệp.

Liên hệ với chúng tôi: Tại đây

Nguồn: Cao Duc Nguyen từ medium.com