Ứng dụng AI: Lời khuyên về kiến trúc nâng cao (AKA AAAA!)

Sự ngạc nhiên! Đây là một bài đăng blog bổ sung cho loạt bài AI dành cho Nhà phát triển Web mà tôi vừa mới kết thúc. Nếu bạn chưa đọc bộ truyện đó, tôi khuyến khích bạn nên đọc kiểm tra nó .

Bài đăng này sẽ xem xét kiến trúc dự án hiện có và những cách chúng tôi có thể cải thiện nó cho cả nhà phát triển ứng dụng và người dùng cuối.

Tôi sẽ thảo luận về một số khái niệm chung và sử dụng các sản phẩm cụ thể của Akamai trong các ví dụ của mình.

Kiến trúc ứng dụng cơ bản

Ứng dụng hiện tại khá cơ bản. Một người dùng gửi hai đối thủ, sau đó ứng dụng sẽ truyền lại phản hồi do AI tạo ra về ai sẽ thắng trong một cuộc chiến.

Kiến trúc cũng đơn giản:

1. Máy khách gửi yêu cầu đến máy chủ.

   
   

2. Máy chủ xây dựng lời nhắc và chuyển tiếp lời nhắc tới OpenAI.

   
   

3. OpenAI trả về phản hồi phát trực tuyến tới máy chủ.

   
   

4. Máy chủ thực hiện mọi điều chỉnh cần thiết và chuyển tiếp phản hồi phát trực tuyến tới máy khách.

Tôi đã sử dụng dịch vụ điện toán đám mây của Akamai (trước đây Linode ), nhưng điều này thực sự giống nhau đối với bất kỳ dịch vụ lưu trữ nào.

🤵 trông giống như người phục vụ tại một nhà hàng sang trọng và 👁️‍🗨️ là “con mắt”, hay AI. cười lớn

Về mặt kỹ thuật, điều này hoạt động tốt nhưng có một số vấn đề, đặc biệt khi người dùng thực hiện các yêu cầu trùng lặp. Việc lưu trữ phản hồi trên máy chủ của chúng tôi có thể nhanh hơn và tiết kiệm chi phí hơn và chỉ truy cập OpenAI cho các yêu cầu duy nhất.

Điều này giả định rằng chúng ta không cần mọi yêu cầu đều không xác định (cùng một đầu vào sẽ tạo ra một đầu ra khác nhau). Giả sử rằng cùng một đầu vào tạo ra cùng một đầu ra là được. Suy cho cùng, dự đoán ai sẽ thắng trong một trận chiến sẽ không thay đổi.

Thêm kiến trúc cơ sở dữ liệu

Nếu chúng ta muốn lưu trữ các phản hồi từ OpenAI, một nơi thực tế để đặt chúng là trong một loại cơ sở dữ liệu nào đó cho phép tra cứu nhanh chóng và dễ dàng bằng cách sử dụng hai đối thủ. Bằng cách này, khi yêu cầu được thực hiện, chúng ta có thể kiểm tra cơ sở dữ liệu trước:

1. Máy khách gửi yêu cầu đến máy chủ.

   
   

2. Máy chủ kiểm tra mục nhập hiện có trong cơ sở dữ liệu phù hợp với thông tin đầu vào của người dùng.

   
   

3. Nếu bản ghi trước đó tồn tại, máy chủ sẽ phản hồi với dữ liệu đó và yêu cầu sẽ hoàn tất. Bỏ qua các bước sau.

   
   

4. Nếu không, máy chủ sẽ thực hiện theo bước ba trong quy trình trước đó.

   
   

5. Trước khi đóng phản hồi, máy chủ sẽ lưu kết quả OpenAI vào cơ sở dữ liệu.

Các đường chấm chấm thể hiện các yêu cầu tùy chọn và loại 💽 trông giống như một chiếc đĩa cứng.

Với thiết lập này, mọi yêu cầu trùng lặp sẽ được cơ sở dữ liệu xử lý. Bằng cách đặt một số yêu cầu OpenAI thành tùy chọn, chúng tôi có thể giảm độ trễ trải nghiệm của người dùng, đồng thời tiết kiệm tiền bằng cách giảm số lượng yêu cầu API.

Đây là một khởi đầu tốt, đặc biệt nếu máy chủ và cơ sở dữ liệu tồn tại trong cùng một khu vực. Nó sẽ giúp thời gian phản hồi nhanh hơn nhiều so với việc truy cập vào máy chủ của OpenAI.

Tuy nhiên, khi ứng dụng của chúng tôi trở nên phổ biến hơn, chúng tôi có thể bắt đầu thu hút người dùng từ khắp nơi trên thế giới. Tra cứu cơ sở dữ liệu nhanh hơn là điều tuyệt vời, nhưng điều gì sẽ xảy ra nếu nút thắt cổ chai là độ trễ so với thời gian bay?

Chúng tôi có thể giải quyết mối lo ngại đó bằng cách đưa mọi thứ đến gần hơn với người dùng.

Đưa tính toán biên vào

Nếu bạn chưa quen với thuật ngữ “cạnh”, phần này có thể gây nhầm lẫn, nhưng tôi sẽ cố gắng giải thích nó một cách đơn giản. Edge đề cập đến nội dung càng gần gũi với người dùng càng tốt. Đối với một số người, điều đó có thể có nghĩa là các thiết bị IoT hoặc tháp điện thoại di động, nhưng trong trường hợp của web, ví dụ điển hình là một Mạng phân phối nội dung (CDN) .

Tôi sẽ cung cấp cho bạn thông tin chi tiết, nhưng CDN là một mạng gồm các máy tính được phân phối toàn cầu có thể đáp ứng yêu cầu của người dùng từ nút gần nhất trong mạng ( một cái gì đó tôi đã viết về trong quá khứ ). Mặc dù theo truyền thống, chúng được thiết kế cho các nội dung tĩnh, nhưng trong những năm gần đây, chúng bắt đầu hỗ trợ tính toán biên ( cũng là điều tôi đã viết trước đây ).

Với tính toán biên, chúng tôi có thể di chuyển nhiều logic phụ trợ đến gần người dùng hơn và không dừng lại ở việc tính toán. Hầu hết các nhà cung cấp điện toán biên cũng cung cấp một số loại kho lưu trữ khóa-giá trị nhất quán cuối cùng trong cùng các nút biên.

Điều đó có thể ảnh hưởng đến ứng dụng của chúng tôi như thế nào?

1. Khách hàng gửi yêu cầu đến chương trình phụ trợ của chúng tôi.

   
   

2. Mạng điện toán biên định tuyến yêu cầu đến nút biên gần nhất.

   
   

3. Nút cạnh kiểm tra mục nhập hiện có trong kho khóa-giá trị khớp với đầu vào của người dùng.

   
   

4. Nếu bản ghi trước đó tồn tại, nút cạnh sẽ phản hồi với dữ liệu đó và yêu cầu hoàn tất. Bỏ qua các bước sau.

   
   

5. Nếu không, nút biên sẽ chuyển tiếp yêu cầu đến máy chủ gốc, máy chủ gốc sẽ chuyển yêu cầu đó đến OpenAI và yadda yadda yadda.

   
   

6. Trước khi đóng phản hồi, máy chủ lưu trữ kết quả OpenAI trong kho khóa-giá trị cạnh.

Nút cạnh là hộp màu xanh lam và được biểu thị bằng 🔪 vì nó có cạnh, EdgeWorker là sản phẩm điện toán biên của Akamai được đại diện bởi 🧑‍🏭 và EdgeKV là kho lưu trữ khóa-giá trị của Akamai được đại diện bởi 🔑🤑🏪. Hộp cạnh gần máy khách hơn máy chủ gốc trên đám mây để thể hiện khoảng cách vật lý.

Máy chủ gốc có thể không thực sự cần thiết ở đây, nhưng tôi nghĩ nó có nhiều khả năng ở đó hơn. Vì lợi ích của dữ liệu, tính toán và luồng logic, kiến trúc này hầu như giống với kiến trúc trước đó. Sự khác biệt chính là các kết quả được lưu trữ trước đó hiện tồn tại rất gần với người dùng và có thể được trả về gần như ngay lập tức.

(Lưu ý: mặc dù dữ liệu đang được lưu vào bộ đệm ở biên nhưng phản hồi vẫn được tạo động. Nếu bạn không cần phản hồi động, có thể đơn giản hơn khi sử dụng CDN ở phía trước máy chủ gốc và đặt tiêu đề HTTP chính xác thành lưu vào bộ nhớ đệm câu trả lời. Ở đây có rất nhiều sắc thái và tôi có thể nói nhiều hơn nhưng…chà, tôi mệt và không thực sự muốn. Vui lòng liên hệ nếu bạn có bất kỳ câu hỏi nào.)

Bây giờ chúng ta đang nấu ăn! Mọi yêu cầu trùng lặp sẽ được phản hồi gần như ngay lập tức, đồng thời giúp chúng tôi lưu lại các yêu cầu API không cần thiết.

Điều này sắp xếp cấu trúc cho các phản hồi bằng văn bản nhưng chúng tôi cũng có hình ảnh do AI tạo ra.

Lưu những hình ảnh đó vào bộ nhớ đệm

Điều cuối cùng chúng ta xem xét hôm nay là hình ảnh. Khi xử lý hình ảnh, chúng ta cần nghĩ đến việc phân phối và lưu trữ. Tôi chắc chắn rằng những người ở OpenAI có giải pháp riêng của họ, nhưng một số tổ chức muốn sở hữu toàn bộ cơ sở hạ tầng vì lý do bảo mật, tuân thủ hoặc độ tin cậy. Một số thậm chí có thể chạy các dịch vụ tạo hình ảnh của riêng họ thay vì sử dụng OpenAI.

Trong quy trình làm việc hiện tại, người dùng đưa ra yêu cầu và cuối cùng sẽ chuyển đến OpenAI. OpenAI tạo hình ảnh nhưng không trả lại hình ảnh đó. Thay vào đó, chúng trả về phản hồi JSON kèm theo URL cho hình ảnh, được lưu trữ trên cơ sở hạ tầng của OpenAI.

Với phản hồi này, thẻ <img> có thể được thêm vào trang bằng URL, điều này sẽ khởi động một yêu cầu khác về hình ảnh thực tế.

Nếu chúng ta muốn lưu trữ hình ảnh trên cơ sở hạ tầng của riêng mình, chúng ta cần một nơi để lưu trữ nó. Chúng tôi có thể ghi hình ảnh vào đĩa của máy chủ gốc, nhưng điều đó có thể nhanh chóng sử dụng hết dung lượng ổ đĩa và chúng tôi sẽ phải nâng cấp máy chủ của mình, việc này có thể tốn kém.

Lưu trữ đối tượng là một giải pháp rẻ hơn nhiều ( Tôi cũng đã viết về điều này ). Thay vì sử dụng URL OpenAI cho hình ảnh, chúng tôi có thể tải nó lên phiên bản lưu trữ đối tượng của riêng mình và thay vào đó sử dụng URL đó.

Điều đó giải quyết được câu hỏi về lưu trữ, nhưng các nhóm lưu trữ đối tượng thường được triển khai cho một vùng duy nhất. Điều này lặp lại vấn đề chúng tôi gặp phải khi lưu trữ văn bản trong cơ sở dữ liệu. Một khu vực có thể ở xa người dùng, điều này có thể gây ra nhiều độ trễ.

Đã giới thiệu tính năng này rồi, việc thêm các tính năng CDN chỉ cho các nội dung tĩnh là điều khá đơn giản (thành thật mà nói, mọi trang web đều phải có CDN). Sau khi được định cấu hình, CDN sẽ lấy hình ảnh từ bộ lưu trữ đối tượng theo yêu cầu ban đầu và lưu chúng vào bộ nhớ đệm cho mọi yêu cầu trong tương lai từ khách truy cập trong cùng khu vực.

Đây là cách luồng hình ảnh của chúng tôi sẽ trông như thế nào:

1. Một khách hàng gửi yêu cầu tạo một hình ảnh dựa trên đối thủ của họ.

   
   

2. Tính toán biên kiểm tra xem dữ liệu hình ảnh cho yêu cầu đó đã tồn tại chưa. Nếu vậy, nó sẽ trả về URL.

   
   

3. Hình ảnh được thêm vào trang có URL và trình duyệt yêu cầu hình ảnh.

   
   

4. Nếu hình ảnh trước đó đã được lưu vào bộ nhớ đệm trong CDN thì trình duyệt sẽ tải nó gần như ngay lập tức. Đây là điểm cuối của dòng chảy.

   
   

5. Nếu hình ảnh chưa được lưu vào bộ đệm trước đó, CDN sẽ lấy hình ảnh từ vị trí lưu trữ đối tượng, lưu vào bộ đệm một bản sao của nó cho các yêu cầu trong tương lai và trả lại hình ảnh cho máy khách. Đây là một đầu khác của dòng chảy.

   
   

6. Nếu dữ liệu hình ảnh không có trong kho lưu trữ khóa-giá trị cạnh, yêu cầu tạo hình ảnh sẽ được chuyển đến máy chủ và chuyển đến OpenAI, máy chủ này sẽ tạo hình ảnh và trả về thông tin URL. Máy chủ bắt đầu thực hiện tác vụ lưu hình ảnh vào nhóm lưu trữ đối tượng, lưu trữ dữ liệu hình ảnh trong kho lưu trữ khóa-giá trị cạnh và trả dữ liệu hình ảnh về điện toán biên.

   
   

7. Với dữ liệu hình ảnh mới, khách hàng sẽ tạo hình ảnh để tạo yêu cầu mới và tiếp tục từ bước năm ở trên.

Mạng phân phối nội dung được biểu thị bằng xe tải giao hàng (🚚) và tín hiệu mạng (📶), còn việc lưu trữ đồ vật được biểu thị bằng những chiếc tất trong hộp (🧦📦) hoặc đồ vật trong kho. Chú thích này có lẽ không cần thiết vì tôi nghĩ những điều này đã rõ ràng nhưng tôi quá tự hào về trò chơi biểu tượng cảm xúc của mình và yêu cầu xác thực. Cảm ơn bạn đã chiều chuộng tôi. Tiếp tục.

Phải thừa nhận rằng kiến trúc cuối cùng này phức tạp hơn một chút, nhưng nếu ứng dụng của bạn sắp xử lý lưu lượng truy cập nghiêm trọng thì nó đáng được xem xét.

Thì đấy

Đúng rồi! Với tất cả những thay đổi đó, chúng tôi đã tạo văn bản và hình ảnh do AI tạo ra cho các yêu cầu riêng biệt và phân phát nội dung được lưu trong bộ nhớ đệm từ biên cho các yêu cầu trùng lặp. Kết quả là thời gian phản hồi nhanh hơn và trải nghiệm người dùng tốt hơn nhiều (ngoài số lệnh gọi API ít hơn).

Tôi đã cố ý giữ các sơ đồ kiến trúc này có thể áp dụng được trên nhiều cơ sở dữ liệu, điện toán biên, lưu trữ đối tượng và nhà cung cấp CDN. Tôi thích nội dung của tôi có thể áp dụng rộng rãi. Nhưng điều đáng nói là việc tích hợp lợi thế không chỉ là hiệu suất. Có rất nhiều tính năng bảo mật thực sự thú vị mà bạn có thể kích hoạt.

Ví dụ: trên mạng của Akamai, bạn có thể truy cập vào những thứ như tường lửa ứng dụng web (WAF) , Bảo vệ từ chối dịch vụ phân tán (DDoS) , phát hiện bot thông minh , và hơn thế nữa. Tuy nhiên, đó là tất cả nằm ngoài phạm vi của bài viết ngày hôm nay.

Vì vậy, bây giờ, tôi sẽ để lại cho bạn lời “cảm ơn” sâu sắc vì đã đọc. Tôi hy vọng bạn đã học được điều gì đó. Và như mọi khi, vui lòng liên hệ bất cứ lúc nào nếu có nhận xét, câu hỏi hoặc mối quan tâm.

Cảm ơn bạn rất nhiều vì đã đọc. Nếu bạn thích bài viết này và muốn ủng hộ tôi, cách tốt nhất để làm điều đó là chia sẻ nó , Hãy đăng ký để nhận thư mới từ tôi , Và theo dõi tôi trên Twitter .

Được xuất bản lần đầu vào austingil.com .