Hội nghị Habr không phải là câu chuyện đầu tiên. Trước đây, chúng tôi đã tổ chức các sự kiện Toaster khá lớn cho 300-400 người, nhưng bây giờ chúng tôi quyết định rằng các cuộc họp theo chủ đề nhỏ sẽ phù hợp, chẳng hạn như hướng đi mà bạn có thể đặt ra trong phần nhận xét. Hội nghị đầu tiên theo hình thức này được tổ chức vào tháng XNUMX và dành riêng cho việc phát triển phụ trợ. Những người tham gia đã nghe các báo cáo về các tính năng của quá trình chuyển đổi từ chương trình phụ trợ sang ML và về thiết kế của dịch vụ Quadrupel trên cổng Dịch vụ Nhà nước, đồng thời tham gia vào một bàn tròn dành riêng cho Serverless. Đối với những người không thể trực tiếp tham dự sự kiện, trong bài đăng này, chúng tôi sẽ kể cho bạn những điều thú vị nhất.
Từ phát triển phụ trợ đến học máy
Kỹ sư dữ liệu làm gì trong ML? Nhiệm vụ của nhà phát triển phụ trợ và kỹ sư ML giống và khác nhau như thế nào? Bạn cần đi theo con đường nào để chuyển nghề đầu tiên sang nghề thứ hai? Điều này đã được kể bởi Alexander Parinov, người đã bước vào lĩnh vực học máy sau 10 năm làm công việc phụ trợ.
Alexander Parinov
Hiện nay, Alexander làm kiến trúc sư hệ thống thị giác máy tính tại Tập đoàn bán lẻ X5 và đóng góp cho các dự án Nguồn mở liên quan đến thị giác máy tính và học sâu (github.com/creafz). Kỹ năng của anh ấy được khẳng định khi anh ấy lọt vào top 100 bảng xếp hạng thế giới của Kaggle Master (kaggle.com/creafz), nền tảng phổ biến nhất cho các cuộc thi học máy.
Tại sao chuyển sang học máy
Một năm rưỡi trước, Jeff Dean, người đứng đầu Google Brain, dự án nghiên cứu trí tuệ nhân tạo dựa trên học tập sâu của Google, đã mô tả cách nửa triệu dòng mã trong Google Dịch đã được thay thế bằng mạng thần kinh Tensor Flow chỉ gồm 500 dòng. Sau khi đào tạo mạng, chất lượng dữ liệu tăng lên và cơ sở hạ tầng trở nên đơn giản hơn. Có vẻ như đây là tương lai tươi sáng của chúng ta: chúng ta không còn phải viết mã nữa, chỉ cần tạo ra các tế bào thần kinh và lấp đầy dữ liệu vào chúng là đủ. Nhưng trong thực tế mọi thứ phức tạp hơn nhiều.
Cơ sở hạ tầng ML tại Google
Mạng lưới thần kinh chỉ là một phần nhỏ của cơ sở hạ tầng (hình vuông nhỏ màu đen trong hình trên). Cần thêm nhiều hệ thống phụ trợ nữa để nhận dữ liệu, xử lý, lưu trữ, kiểm tra chất lượng, v.v., chúng ta cần cơ sở hạ tầng để đào tạo, triển khai mã machine learning trong sản xuất và thử nghiệm mã này. Tất cả các nhiệm vụ này hoàn toàn giống với những gì các nhà phát triển phụ trợ làm.
Quá trình học máy
Sự khác biệt giữa ML và phụ trợ là gì?
Trong lập trình cổ điển, chúng ta viết mã và điều này quyết định hành vi của chương trình. Trong ML, chúng tôi có một mã mô hình nhỏ và rất nhiều dữ liệu mà chúng tôi đưa vào mô hình. Dữ liệu trong ML rất quan trọng: cùng một mô hình được đào tạo trên các dữ liệu khác nhau có thể hiển thị các kết quả hoàn toàn khác nhau. Vấn đề là dữ liệu hầu như luôn nằm rải rác và được lưu trữ trong các hệ thống khác nhau (cơ sở dữ liệu quan hệ, cơ sở dữ liệu NoSQL, nhật ký, tệp).
Phiên bản dữ liệu
ML yêu cầu lập phiên bản không chỉ mã, như trong phát triển cổ điển, mà còn cả dữ liệu: cần phải hiểu rõ mô hình đã được đào tạo về cái gì. Để thực hiện việc này, bạn có thể sử dụng thư viện Kiểm soát phiên bản khoa học dữ liệu phổ biến (dvc.org).
Đánh dấu dữ liệu
Nhiệm vụ tiếp theo là ghi nhãn dữ liệu. Ví dụ: đánh dấu tất cả các đồ vật trong hình hoặc cho biết nó thuộc lớp nào. Điều này được thực hiện bởi các dịch vụ đặc biệt như Yandex.Toloka, công việc được đơn giản hóa rất nhiều nhờ sự hiện diện của API. Khó khăn nảy sinh do “yếu tố con người”: bạn có thể cải thiện chất lượng dữ liệu và giảm thiểu sai sót bằng cách giao cùng một nhiệm vụ cho một số người thực hiện.
Trực quan hóa trong Tensor Board
Việc ghi nhật ký các thử nghiệm là cần thiết để so sánh kết quả và chọn mô hình tốt nhất dựa trên một số số liệu. Có một bộ công cụ lớn để trực quan hóa - ví dụ: Tensor Board. Nhưng không có cách nào lý tưởng để lưu trữ thí nghiệm. Các công ty nhỏ thường sử dụng bảng tính Excel, trong khi các công ty lớn sử dụng các nền tảng đặc biệt để lưu trữ kết quả vào cơ sở dữ liệu.
Có nhiều nền tảng dành cho machine learning nhưng không có nền tảng nào đáp ứng được 70% nhu cầu
Vấn đề đầu tiên mà người ta phải đối mặt khi đưa một mô hình đã đào tạo vào sản xuất có liên quan đến công cụ yêu thích của các nhà khoa học dữ liệu - Jupyter Notebook. Không có tính mô-đun nào trong đó, nghĩa là đầu ra là một “chân vải” mã không được chia thành các phần logic - mô-đun. Mọi thứ đều bị xáo trộn: lớp, chức năng, cấu hình, v.v. Mã này rất khó để tạo phiên bản và kiểm tra.
Làm thế nào để đối phó với điều này? Bạn có thể tự từ chức, như Netflix và tạo nền tảng của riêng mình cho phép bạn khởi chạy những máy tính xách tay này trực tiếp trong quá trình sản xuất, truyền dữ liệu đến chúng làm đầu vào và nhận kết quả. Bạn có thể buộc các nhà phát triển đang đưa mô hình vào sản xuất viết lại mã một cách bình thường, chia nó thành các mô-đun. Nhưng với cách làm này rất dễ mắc sai lầm và mô hình sẽ không hoạt động như dự định. Do đó, lựa chọn lý tưởng là cấm sử dụng Jupyter Notebook cho mã model. Tất nhiên, nếu các nhà khoa học dữ liệu đồng ý với điều này.
Mô hình như một hộp đen
Cách dễ nhất để đưa mô hình vào sản xuất là sử dụng nó làm hộp đen. Bạn có một loại lớp mô hình nào đó, bạn được cung cấp các trọng số của mô hình (tham số của các nơ-ron của mạng được đào tạo) và nếu bạn khởi tạo lớp này (gọi phương thức dự đoán, cung cấp cho nó một hình ảnh), bạn sẽ nhận được một kết quả nhất định dự đoán như một đầu ra. Những gì xảy ra bên trong không quan trọng.
Quy trình máy chủ riêng biệt với mô hình
Bạn cũng có thể đưa ra một quy trình riêng biệt nhất định và gửi nó qua hàng đợi RPC (có hình ảnh hoặc dữ liệu nguồn khác. Ở đầu ra, chúng tôi sẽ nhận được dự đoán.
Một ví dụ về việc sử dụng mô hình trong Flask:
@app.route("/predict", methods=["POST"])
def predict():
image = flask.request.files["image"].read()
image = preprocess_image(image)
predictions = model.predict(image)
return jsonify_prediction(predictions)
Vấn đề với cách tiếp cận này là hạn chế về hiệu suất. Giả sử chúng ta có mã Phyton được viết bởi các nhà khoa học dữ liệu chậm và chúng ta muốn đạt được hiệu suất tối đa. Để thực hiện việc này, bạn có thể sử dụng các công cụ chuyển đổi mã thành mã gốc hoặc chuyển mã sang một khung khác được thiết kế riêng cho sản xuất. Có những công cụ như vậy cho mọi framework, nhưng không có công cụ nào lý tưởng; bạn sẽ phải tự thêm chúng.
Cơ sở hạ tầng trong ML giống như trong phần phụ trợ thông thường. Có Docker và Kubernetes, riêng với Docker bạn cần cài đặt thời gian chạy từ NVIDIA, cho phép các tiến trình bên trong container truy cập vào card màn hình trong máy chủ. Kubernetes cần một plugin để có thể quản lý máy chủ bằng card màn hình.
Không giống như lập trình cổ điển, trong trường hợp ML, có nhiều yếu tố chuyển động khác nhau trong cơ sở hạ tầng cần được kiểm tra và thử nghiệm - ví dụ: mã xử lý dữ liệu, quy trình đào tạo mô hình và quá trình sản xuất (xem sơ đồ ở trên). Điều quan trọng là phải kiểm tra mã kết nối các phần khác nhau của đường ống: có rất nhiều phần và các vấn đề thường phát sinh ở ranh giới mô-đun.
AutoML hoạt động như thế nào
Các dịch vụ AutoML hứa hẹn sẽ chọn mô hình tối ưu cho mục đích của bạn và đào tạo mô hình đó. Nhưng bạn cần hiểu: dữ liệu rất quan trọng trong ML, kết quả phụ thuộc vào sự chuẩn bị của nó. Việc đánh dấu được thực hiện bởi con người nên có nhiều sai sót. Nếu không kiểm soát chặt chẽ, kết quả có thể là rác thải và chưa thể tự động hóa quy trình, cần có sự xác minh của các chuyên gia - nhà khoa học dữ liệu -. Đây là nơi AutoML bị hỏng. Nhưng nó có thể hữu ích cho việc chọn kiến trúc - khi bạn đã chuẩn bị sẵn dữ liệu và muốn chạy một loạt thử nghiệm để tìm ra mô hình tốt nhất.
Làm thế nào để tham gia vào học máy
Cách dễ nhất để tiếp cận ML là nếu bạn phát triển bằng Python, vốn được sử dụng trong tất cả các khung học sâu (và các khung thông thường). Ngôn ngữ này thực tế là bắt buộc đối với lĩnh vực hoạt động này. C++ được sử dụng cho một số tác vụ thị giác máy tính, chẳng hạn như trong hệ thống điều khiển cho ô tô tự lái. JavaScript và Shell - để trực quan hóa và những thứ kỳ lạ như chạy nơ-ron trong trình duyệt. Java và Scala được sử dụng khi làm việc với Dữ liệu lớn và học máy. R và Julia được những người nghiên cứu thống kê toán học yêu thích.
Cách thuận tiện nhất để bắt đầu trải nghiệm thực tế là trên Kaggle; việc tham gia vào một trong các cuộc thi của nền tảng này sẽ mang lại hơn một năm nghiên cứu lý thuyết. Trên nền tảng này, bạn có thể lấy mã được đăng và nhận xét của người khác và cố gắng cải thiện nó, tối ưu hóa nó cho mục đích của bạn. Tiền thưởng - thứ hạng Kaggle của bạn ảnh hưởng đến mức lương của bạn.
Một lựa chọn khác là tham gia nhóm ML với tư cách là nhà phát triển phụ trợ. Có rất nhiều công ty khởi nghiệp về học máy nơi bạn có thể tích lũy kinh nghiệm bằng cách giúp đồng nghiệp giải quyết vấn đề của họ. Cuối cùng, bạn có thể tham gia một trong các cộng đồng nhà khoa học dữ liệu - Khoa học dữ liệu mở (ods.ai) và các cộng đồng khác.
Diễn giả đăng thêm thông tin về chủ đề tại link
"Quadrupel" - dịch vụ thông báo có mục tiêu của cổng thông tin "Dịch vụ Nhà nước"
Evgeny Smirnov
Diễn giả tiếp theo là trưởng bộ phận phát triển cơ sở hạ tầng chính phủ điện tử, Evgeny Smirnov, người đã nói về Quadruple. Đây là dịch vụ thông báo có mục tiêu dành cho cổng Gosuslugi (gosuslugi.ru), nguồn tài nguyên chính phủ được truy cập nhiều nhất trên Runet. Lượng khán giả hàng ngày là 2,6 triệu, tổng cộng có 90 triệu người dùng đã đăng ký trên trang này, trong đó 60 triệu đã được xác nhận. Tải trên API cổng thông tin là 30 nghìn RPS.
Các công nghệ được sử dụng trong phần phụ trợ của Dịch vụ Nhà nước
“Quadrupel” là một dịch vụ thông báo có mục tiêu, với sự trợ giúp của dịch vụ này, người dùng sẽ nhận được lời đề nghị sử dụng dịch vụ vào thời điểm phù hợp nhất với mình bằng cách thiết lập các quy tắc thông báo đặc biệt. Yêu cầu chính khi phát triển dịch vụ là cài đặt linh hoạt và thời gian thích hợp để gửi thư.
Quadrupel hoạt động như thế nào?
Sơ đồ trên thể hiện một trong những quy tắc hoạt động của Quadrupel bằng cách sử dụng ví dụ về tình huống cần phải thay bằng lái xe. Đầu tiên, dịch vụ tìm kiếm những người dùng có ngày hết hạn sau một tháng. Họ được hiển thị một biểu ngữ với lời đề nghị nhận dịch vụ phù hợp và một tin nhắn sẽ được gửi qua email. Đối với những người dùng đã hết thời hạn, biểu ngữ và email sẽ thay đổi. Sau khi trao đổi quyền thành công, người dùng sẽ nhận được các thông báo khác - kèm theo đề xuất cập nhật dữ liệu trong danh tính.
Từ quan điểm kỹ thuật, đây là những tập lệnh hấp dẫn trong đó mã được viết. Đầu vào là dữ liệu, đầu ra là đúng/sai, khớp/không khớp. Tổng cộng có hơn 50 quy tắc - từ việc xác định ngày sinh của người dùng (ngày hiện tại bằng ngày sinh của người dùng) cho đến các tình huống phức tạp. Mỗi ngày, những quy tắc này xác định khoảng một triệu trận đấu—những người cần được thông báo.
Kênh thông báo tăng gấp bốn lần
Dưới vỏ bọc của Quadrupel có một cơ sở dữ liệu trong đó dữ liệu người dùng được lưu trữ và ba ứng dụng:
- Công nhân nhằm mục đích cập nhật dữ liệu.
- API nghỉ ngơi tự mình nhận và chuyển các biểu ngữ đến cổng thông tin và ứng dụng di động.
- Scheduler triển khai công việc tính toán lại các biểu ngữ hoặc gửi thư hàng loạt.
Để cập nhật dữ liệu, phần phụ trợ được điều khiển theo sự kiện. Hai giao diện - phần còn lại hoặc JMS. Có rất nhiều sự kiện, trước khi lưu và xử lý, chúng được tổng hợp lại để không đưa ra những yêu cầu không cần thiết. Bản thân cơ sở dữ liệu, bảng trong đó dữ liệu được lưu trữ, trông giống như một kho lưu trữ giá trị khóa - khóa của người dùng và chính giá trị đó: các cờ cho biết sự hiện diện hay vắng mặt của các tài liệu liên quan, thời hạn hiệu lực của chúng, số liệu thống kê tổng hợp về thứ tự dịch vụ theo người dùng này, v.v.
Sau khi lưu dữ liệu, một tác vụ được đặt trong JMS để các biểu ngữ được tính toán lại ngay lập tức - điều này phải được hiển thị ngay trên web. Hệ thống bắt đầu vào ban đêm: các tác vụ được đưa vào JMS theo khoảng thời gian của người dùng, theo đó các quy tắc cần được tính toán lại. Điều này được thu thập bởi các bộ xử lý tham gia vào quá trình tính toán lại. Tiếp theo, kết quả xử lý sẽ chuyển sang hàng đợi tiếp theo, hàng đợi này sẽ lưu các biểu ngữ trong cơ sở dữ liệu hoặc gửi tác vụ thông báo của người dùng đến dịch vụ. Quá trình này mất 5-7 giờ, có thể dễ dàng mở rộng do thực tế là bạn luôn có thể thêm trình xử lý hoặc tăng phiên bản bằng trình xử lý mới.
Dịch vụ này hoạt động khá tốt. Nhưng khối lượng dữ liệu đang tăng lên khi có nhiều người dùng hơn. Điều này dẫn đến sự gia tăng tải trên cơ sở dữ liệu - thậm chí còn tính đến thực tế là Rest API xem xét bản sao. Điểm thứ hai là JMS, hóa ra là không phù hợp lắm do tiêu thụ nhiều bộ nhớ. Có nguy cơ tràn hàng đợi cao khiến JMS gặp sự cố và quá trình xử lý bị dừng. Không thể nâng cao JMS sau này nếu không xóa nhật ký.
Nó được lên kế hoạch để giải quyết các vấn đề bằng cách sử dụng sharding, điều này sẽ cho phép cân bằng tải trên cơ sở dữ liệu. Ngoài ra còn có kế hoạch thay đổi sơ đồ lưu trữ dữ liệu và thay đổi JMS thành Kafka - một giải pháp dễ chịu lỗi hơn sẽ giải quyết các vấn đề về bộ nhớ.
Phần cuối dưới dạng dịch vụ Vs. Không có máy chủ
Từ trái sang phải: Alexander Borgart, Andrey Tomilenko, Nikolay Markov, Ara Israelyan
Phần cuối là một dịch vụ hay giải pháp Serverless? Những người tham gia thảo luận về vấn đề cấp bách này tại bàn tròn là:
- Ara Israelyan, CTO CTO và người sáng lập Scorocode.
- Nikolay Markov, Kỹ sư dữ liệu cao cấp tại Nhóm nghiên cứu liên kết.
- Andrey Tomilenko, người đứng đầu bộ phận phát triển RUVDS.
Cuộc trò chuyện được kiểm duyệt bởi nhà phát triển cấp cao Alexander Borgart. Chúng tôi trình bày các cuộc tranh luận trong đó người nghe cũng tham gia bằng một phiên bản rút gọn.
— Serverless theo hiểu biết của bạn là gì?
Andrew: Đây là mô hình tính toán - hàm Lambda phải xử lý dữ liệu sao cho kết quả chỉ phụ thuộc vào dữ liệu. Thuật ngữ này đến từ Google hoặc từ Amazon và dịch vụ AWS Lambda của nó. Nhà cung cấp sẽ dễ dàng xử lý một chức năng như vậy hơn bằng cách phân bổ một nhóm công suất cho nó. Những người dùng khác nhau có thể được quản lý độc lập trên cùng một máy chủ.
Nicholas: Nói một cách đơn giản, chúng tôi đang chuyển một phần cơ sở hạ tầng CNTT và logic kinh doanh của mình sang đám mây, sang gia công phần mềm.
ara: Về phía các nhà phát triển - một nỗ lực tốt để tiết kiệm tài nguyên, về phía các nhà tiếp thị - để kiếm thêm tiền.
— Serverless có giống như microservice không?
Nicholas: Không, Serverless giống một tổ chức kiến trúc hơn. Một microservice là một đơn vị nguyên tử của một số logic. Serverless là một cách tiếp cận, không phải là một “thực thể riêng biệt”.
ara: Một hàm Serverless có thể được đóng gói thành một vi dịch vụ, nhưng hàm này sẽ không còn là Serverless nữa mà sẽ không còn là hàm Lambda nữa. Trong Serverless, một chức năng chỉ bắt đầu hoạt động vào thời điểm nó được yêu cầu.
Andrew: Họ khác nhau trong cuộc đời của họ. Chúng tôi đã khởi chạy hàm Lambda và quên mất nó. Nó hoạt động trong vài giây và máy khách tiếp theo có thể xử lý yêu cầu của nó trên một máy vật lý khác.
- Cân nào tốt hơn?
ara: Khi chia tỷ lệ theo chiều ngang, các hàm Lambda hoạt động giống hệt như vi dịch vụ.
Nicholas: Cho dù bạn đặt số lượng bản sao bao nhiêu thì cũng sẽ có bấy nhiêu bản sao; Serverless không gặp vấn đề gì với việc mở rộng quy mô. Tôi đã tạo một bộ bản sao trong Kubernetes, khởi chạy 20 phiên bản “ở đâu đó” và 20 liên kết ẩn danh đã được trả lại cho bạn. Phía trước!
— Có thể viết backend trên Serverless không?
Andrew: Về mặt lý thuyết, nhưng nó không có ý nghĩa. Các hàm Lambda sẽ dựa vào một kho lưu trữ duy nhất - chúng tôi cần đảm bảo sự đảm bảo. Ví dụ: nếu người dùng đã thực hiện một giao dịch nhất định thì lần liên hệ tiếp theo anh ta sẽ thấy: giao dịch đã được thực hiện, số tiền đã được ghi có. Tất cả các hàm Lambda sẽ chặn lệnh gọi này. Trên thực tế, một loạt chức năng Serverless sẽ biến thành một dịch vụ duy nhất với một điểm truy cập thắt cổ chai vào cơ sở dữ liệu.
— Việc sử dụng kiến trúc serverless trong những tình huống nào là hợp lý?
Andrew: Các tác vụ không yêu cầu bộ nhớ dùng chung - cùng loại khai thác, blockchain. Nơi bạn cần phải làm rất nhiều việc đếm. Nếu bạn có nhiều khả năng tính toán thì bạn có thể định nghĩa một hàm như “tính toán hàm băm của thứ gì đó ở đó…” Nhưng bạn có thể giải quyết vấn đề về lưu trữ dữ liệu bằng cách lấy, chẳng hạn như các hàm Lambda từ Amazon và bộ lưu trữ phân tán của họ . Và hóa ra bạn đang viết một dịch vụ thông thường. Các hàm Lambda sẽ truy cập vào bộ lưu trữ và cung cấp một số loại phản hồi cho người dùng.
Nicholas: Các vùng chứa chạy trong Serverless cực kỳ hạn chế về tài nguyên. Có rất ít bộ nhớ và mọi thứ khác. Nhưng nếu toàn bộ cơ sở hạ tầng của bạn được triển khai hoàn toàn trên một số đám mây - Google, Amazon - và bạn có hợp đồng lâu dài với họ, thì sẽ có ngân sách cho tất cả những điều này, thì đối với một số nhiệm vụ, bạn có thể sử dụng vùng chứa Serverless. Cần phải ở bên trong cơ sở hạ tầng này vì mọi thứ đều được thiết kế riêng để sử dụng trong một môi trường cụ thể. Nghĩa là, nếu bạn sẵn sàng gắn kết mọi thứ với cơ sở hạ tầng đám mây, bạn có thể thử nghiệm. Ưu điểm là bạn không phải quản lý cơ sở hạ tầng này.
ara: Việc Serverless không yêu cầu bạn quản lý Kubernetes, Docker, cài đặt Kafka, v.v. là sự tự lừa dối. Amazon và Google cũng đang cài đặt cái này. Một điều nữa là bạn có SLA. Bạn cũng có thể thuê ngoài mọi thứ thay vì tự mình viết mã.
Andrew: Bản thân Serverless không tốn kém, nhưng bạn phải trả rất nhiều tiền cho các dịch vụ khác của Amazon - ví dụ: cơ sở dữ liệu. Mọi người đã kiện họ vì họ đã tính những khoản tiền khổng lồ cho cổng API.
ara: Nếu chúng ta nói về tiền, thì bạn cần tính đến điểm này: bạn sẽ phải quay ngoắt 180 độ toàn bộ phương pháp phát triển trong công ty để chuyển tất cả mã sang Serverless. Việc này sẽ tốn rất nhiều thời gian và tiền bạc.
— Có lựa chọn thay thế xứng đáng nào cho Serverless trả phí từ Amazon và Google không?
Nicholas: Trong Kubernetes, bạn khởi chạy một số loại công việc, nó chạy và chết - điều này khá là Serverless theo quan điểm kiến trúc. Nếu bạn muốn tạo logic nghiệp vụ thực sự thú vị với hàng đợi và cơ sở dữ liệu, thì bạn cần suy nghĩ thêm một chút về nó. Tất cả điều này có thể được giải quyết mà không cần rời khỏi Kubernetes. Tôi sẽ không bận tâm đến việc triển khai bổ sung.
— Việc theo dõi những gì đang diễn ra trong Serverless quan trọng như thế nào?
ara: Phụ thuộc vào kiến trúc hệ thống và yêu cầu nghiệp vụ. Về cơ bản, nhà cung cấp phải cung cấp báo cáo để giúp nhóm phát triển hiểu được các vấn đề có thể xảy ra.
Nicholas: Amazon có CloudWatch, nơi tất cả nhật ký đều được truyền trực tuyến, bao gồm cả nhật ký từ Lambda. Tích hợp chuyển tiếp nhật ký và sử dụng một công cụ riêng để xem, cảnh báo, v.v. Bạn có thể nhét các tác nhân vào các thùng chứa mà bạn bắt đầu.
- Hãy tóm tắt lại.
Andrew: Suy nghĩ về các hàm Lambda rất hữu ích. Nếu bạn tự tạo một dịch vụ - không phải vi dịch vụ mà là dịch vụ ghi yêu cầu, truy cập cơ sở dữ liệu và gửi phản hồi - thì hàm Lambda sẽ giải quyết một số vấn đề: với đa luồng, khả năng mở rộng, v.v. Nếu logic của bạn được xây dựng theo cách này thì trong tương lai bạn sẽ có thể chuyển các Lambda này sang các vi dịch vụ hoặc sử dụng các dịch vụ của bên thứ ba như Amazon. Công nghệ này hữu ích, ý tưởng thật thú vị. Làm thế nào nó hợp lý cho doanh nghiệp vẫn là một câu hỏi mở.
Nikolay: Serverless được sử dụng tốt hơn cho các tác vụ vận hành hơn là tính toán một số logic nghiệp vụ. Tôi luôn nghĩ về nó như xử lý sự kiện. Nếu bạn có nó ở Amazon, nếu bạn ở Kubernetes, vâng. Nếu không, bạn sẽ phải nỗ lực khá nhiều để tự thiết lập và chạy Serverless. Cần phải xem xét một trường hợp kinh doanh cụ thể. Ví dụ, một trong những nhiệm vụ của tôi bây giờ là: khi các tệp xuất hiện trên đĩa ở một định dạng nhất định, tôi cần tải chúng lên Kafka. Tôi có thể sử dụng WatchDog hoặc Lambda. Từ quan điểm logic, cả hai tùy chọn đều phù hợp, nhưng về mặt triển khai, Serverless phức tạp hơn và tôi thích cách đơn giản hơn, không có Lambda.
ara: Serverless là một ý tưởng thú vị, có thể áp dụng và rất đẹp về mặt kỹ thuật. Sớm hay muộn, công nghệ sẽ đạt đến mức mà bất kỳ chức năng nào cũng sẽ được khởi chạy trong vòng chưa đầy 100 mili giây. Khi đó, về nguyên tắc, sẽ không còn nghi ngờ gì về việc liệu thời gian chờ đợi có quan trọng đối với người dùng hay không. Đồng thời, khả năng ứng dụng của Serverless, như các đồng nghiệp đã nói, hoàn toàn phụ thuộc vào vấn đề kinh doanh.
Chúng tôi cảm ơn các nhà tài trợ đã giúp đỡ chúng tôi rất nhiều:
- Không gian hội nghị CNTT «» cho địa điểm hội nghị.
- Lịch sự kiện CNTT và xuất bản"» để được hỗ trợ thông tin và tin tức.
- «"để nhận quà.
- để đồng sáng tạo.
- "Hiệp hội Truyền thông Điện tử" để tham gia và trải nghiệm.
- Nhà tài trợ chính - cho tất cả!
Nguồn: www.habr.com