Tại sao WebAssembly là tương lai của điện toán biên

Mô hình điện toán biên (edge computing) đã phát triển nhanh chóng trong vài năm qua, chuyển đổi từ một lớp bộ nhớ đệm CDN đơn thuần thành một môi trường tính toán đầy đủ, chạy các ứng dụng serverless toàn cầu. Khi nhu cầu về độ trễ cực thấp và khối lượng công việc serverless có khả năng mở rộng tăng vọt, các công nghệ nền tảng cung cấp năng lượng cho biên đã phải thích nghi. WebAssembly (Wasm) xuất hiện — ban đầu được thiết kế cho trình duyệt, định dạng hướng dẫn nhị phân này đã âm thầm trở thành nền tảng của các kiến trúc điện toán biên hiện đại.

Trong bài viết khám phá toàn diện này, chúng ta sẽ đi sâu vào lý do tại sao WebAssembly hoàn toàn phù hợp với biên, cách nó giải quyết vấn đề "khởi động nguội" khét tiếng, và tại sao các nhà cung cấp đám mây lớn và mạng biên đang đặt cược lớn vào Wasm để cung cấp năng lượng cho thế hệ tính toán serverless tiếp theo.

Lịch sử tóm tắt: Từ trình duyệt đến backend

WebAssembly được tạo ra với một mục tiêu rõ ràng: cho phép các ứng dụng hiệu suất cao chạy trên các trang web mà không ảnh hưởng đến bảo mật hoặc khả năng di động. Nó cho phép các nhà phát triển viết mã bằng các ngôn ngữ như C, C++ và Rust, biên dịch nó thành một định dạng nhị phân được tối ưu hóa cao và thực thi nó với tốc độ gần như gốc trực tiếp trong trình duyệt.

Tuy nhiên, các đặc điểm nổi bật của WebAssembly — hộp cát bảo mật, khả năng thực thi cực nhanh, độc lập với phần cứng và dung lượng nhẹ — đã khiến nó trở nên rất hấp dẫn đối với các môi trường ngoài trình duyệt. Việc giới thiệu Giao diện Hệ thống WebAssembly (WASI) đã cung cấp một cách tiêu chuẩn hóa để các mô-đun Wasm tương tác với hệ điều hành cơ bản (chẳng hạn như đọc tệp hoặc mở kết nối mạng), từ đó giải phóng WebAssembly khỏi web và đưa nó đến máy chủ.

Thách thức của điện toán biên

Điện toán biên phân phối logic ứng dụng gần hơn với người dùng cuối bằng cách triển khai mã đến các máy chủ đặt tại "biên" của mạng, thường là trong các điểm hiện diện (PoP) của CDN. Kiến trúc này giảm đáng kể độ trễ và cải thiện hiệu suất tổng thể.

Tuy nhiên, việc chạy tính toán ở biên đặt ra những thách thức riêng:

1. Hạn chế về tài nguyên: Các nút biên phải xử lý hàng chục nghìn yêu cầu đồng thời trên hàng trăm đối tượng thuê khác nhau. Chạy một máy ảo (VM) đầy đủ hoặc thậm chí một vùng chứa Docker tiêu chuẩn cho mỗi yêu cầu là cực kỳ không hiệu quả và tốn nhiều tài nguyên.
2. Khởi động nguội: Các kiến trúc serverless truyền thống (như AWS Lambda) thường dựa vào microVM hoặc vùng chứa. Khi một hàm không được gọi trong một thời gian, việc khởi động một vùng chứa mới sẽ gây ra độ trễ đáng chú ý, thường được gọi là "khởi động nguội". Ở biên, nơi toàn bộ mục đích là độ trễ thấp, khởi động nguội 500ms là không thể chấp nhận được.
3. Bảo mật và cách ly: Các nút biên đa đối tượng thuê chạy mã từ nhiều khách hàng không đáng tin cậy. Đảm bảo cách ly nghiêm ngặt giữa các khối lượng công việc này là điều không thể thương lượng.

WebAssembly giải quyết tình thế khó xử của điện toán biên như thế nào

WebAssembly giải quyết một cách khéo léo tất cả các thách thức liên quan đến điện toán biên, biến nó thành thời gian chạy lý tưởng cho môi trường đòi hỏi khắt khe này.

1. Khởi động nguội gần như tức thì

Tác động sâu sắc nhất của WebAssembly ở biên là việc loại bỏ vấn đề khởi động nguội. Không giống như các vùng chứa Docker, yêu cầu khởi động toàn bộ môi trường hệ điều hành, hoặc microVM yêu cầu khởi động một hạt nhân nhẹ, một mô-đun WebAssembly chỉ đơn giản là một tệp nhị phân đã biên dịch.

Các thời gian chạy Wasm, chẳng hạn như Wasmtime hoặc Lucet, có thể khởi tạo một mô-đun WebAssembly mới trong vòng vài micro giây — thường dưới 1 mili giây. Điều này có nghĩa là các hàm biên có thể được khởi động hoàn toàn theo yêu cầu cho mỗi yêu cầu, loại bỏ nhu cầu giữ các phiên bản nhàn rỗi ở trạng thái sẵn sàng và đảm bảo độ trễ cực thấp nhất quán cho người dùng cuối.

2. Dung lượng cực kỳ nhẹ

Các mô-đun WebAssembly cực kỳ nhỏ. Một hàm biên điển hình được biên dịch thành Wasm có thể chỉ có vài kilobyte. Hơn nữa, vì các mô-đun Wasm không yêu cầu hệ điều hành riêng hoặc các thời gian chạy ngôn ngữ lớn (như Node.js hoặc Python), chúng tiêu thụ dung lượng bộ nhớ nhỏ hơn đáng kể so với các vùng chứa truyền thống.

Bản chất nhẹ này cho phép các nhà cung cấp biên đóng gói hàng nghìn hoặc thậm chí hàng chục nghìn mô-đun Wasm riêng biệt vào một máy chủ biên duy nhất, tối đa hóa việc sử dụng tài nguyên và làm cho điện toán biên khả thi về mặt kinh tế ở quy mô lớn.

3. Bảo mật và hộp cát không khoan nhượng

Bảo mật được tích hợp vào thiết kế cơ bản của WebAssembly. Các mô-đun Wasm thực thi trong một môi trường hộp cát, an toàn bộ nhớ. Thời gian chạy thực thi cách ly nghiêm ngặt; một mô-đun Wasm không thể truy cập bộ nhớ bên ngoài không gian bộ nhớ tuyến tính của chính nó, cũng như không thể tương tác với hệ điều hành máy chủ mà không có sự cho phép rõ ràng thông qua WASI.

Mô hình bảo mật từ chối mặc định này hoàn hảo cho các môi trường biên đa đối tượng thuê. Các nhà cung cấp biên có thể chạy mã từ các khách hàng hoàn toàn khác nhau một cách an toàn song song trong cùng một quy trình, tự tin rằng hộp cát Wasm sẽ ngăn chặn mọi sự can thiệp độc hại hoặc vô tình giữa các đối tượng thuê.

4. Độc lập ngôn ngữ và khả năng di động

WebAssembly là một mục tiêu thực thi, không phải là một ngôn ngữ lập trình. Ngày nay, các nhà phát triển có thể viết các hàm biên bằng Rust, C++, Go, AssemblyScript (một tập hợp con của TypeScript), Python và danh sách các ngôn ngữ khác ngày càng tăng.

Sau khi được biên dịch thành Wasm, tệp nhị phân kết quả hoàn toàn độc lập với nền tảng. Nó có thể chạy trên máy chủ x86, nút biên dựa trên ARM hoặc thậm chí trực tiếp trong trình duyệt của người dùng mà không yêu cầu bất kỳ sửa đổi nào. Khả năng "viết một lần, chạy mọi nơi" này đơn giản hóa đáng kể các quy trình triển khai và giảm sự phụ thuộc vào nhà cung cấp.

Hệ sinh thái đang trưởng thành nhanh chóng

Sự chuyển dịch sang WebAssembly ở biên không chỉ là lý thuyết; nó đang tích cực diễn ra ngay bây giờ. Các nền tảng lớn như Cloudflare Workers, Fastly Compute@Edge và Netlify Edge Functions hỗ trợ nguyên bản hoặc được xây dựng hoàn toàn dựa trên WebAssembly và V8 isolates (có chung các đặc điểm nhẹ tương tự).

Hơn nữa, CNCF (Cloud Native Computing Foundation) đã tích cực đón nhận WebAssembly, với các dự án như WasmEdge và Spin thúc đẩy các tiêu chuẩn hóa và công cụ để xây dựng và triển khai các ứng dụng Wasm dễ dàng hơn bao giờ hết. Mô hình thành phần (Component Model), một phát triển gần đây trong hệ sinh thái Wasm, hứa hẹn sẽ cho phép các mô-đun Wasm khác nhau được viết bằng các ngôn ngữ khác nhau giao tiếp liền mạch với nhau, mở đường cho các ứng dụng biên có tính mô-đun và khả năng kết hợp cao.

Điều gì tiếp theo?

Khi chúng ta nhìn về tương lai, vai trò của WebAssembly ở biên sẽ chỉ mở rộng. Chúng ta có thể sẽ thấy nhiều khối lượng công việc phức tạp hơn di chuyển đến biên, bao gồm suy luận AI thời gian thực, cơ sở dữ liệu phân tán cao và các ứng dụng có trạng thái phức tạp.

WebAssembly đang làm cho điện toán biên và serverless những gì Docker đã làm cho cơ sở hạ tầng đám mây. Bằng cách cung cấp một thời gian chạy an toàn, cực nhanh và cực kỳ nhẹ, WebAssembly đã chính thức mở khóa tiềm năng thực sự của biên. Đối với các nhà phát triển muốn xây dựng các ứng dụng toàn cầu, hiệu suất cao, việc hiểu và tận dụng WebAssembly không còn là tùy chọn nữa — đó là tiêu chuẩn mới.

Bạn cũng có thể thích

• Tương lai của WebAssembly trong điện toán biên
• Giới thiệu về WebAssembly
• WebAssembly với C++
• WebAssembly ngoài trình duyệt: Xây dựng các microservice hiệu suất cao