Categories
Dev's Corner

MLOps là gì? Tại sao MLOps lại quan trọng? Và cách triển khai nó

“Cái thứ MLOps này là gì?”

Đó là câu hỏi mà tôi trăn trở, nhưng cho đến gần đây, tôi mới chỉ nghe nói về MLOps một vài lần tại các hội nghị lớn về AI, tôi thấy một số đề cập trong các bài báo tôi đã đọc trong nhiều năm, nhưng tôi không biết bất cứ điều gì cụ thể.

Vào khoảng thời gian đó, tôi có cuộc trò chuyện với một người bạn làm Chuyên gia khai thác dữ liệu (Data Mining Specialist) ở Mozambique, Châu Phi. Gần đây, họ bắt đầu tạo quy trình Machine Learning (ML) nội bộ của mình, và tình cờ là tôi bắt đầu viết bài này khi đang tự nghiên cứu về lĩnh vực MLOps bí ẩn để quy mọi thứ về một mối.

Bên lề: Bạn có thể tham khảo video dưới đây để hiểu thêm về MLOps. Đây là video buổi chia sẻ tại Gambaru Technical Event #11 của anh Quân Đặng, Senior ML Engineer.

Chia sẻ chủ đề MLOps tại Technical Event #11

Trong lần trao đổi này, tôi biết thêm về những khó khăn mà cả các công ty cũ (và nhiều công ty công nghệ làm ML thương mại) mắc phải:

  • Di chuyển lên đám mây
  • Tạo và quản lý quy trình ML
  • Mở rộng quy mô
  • Xử lý dữ liệu nhạy cảm trên quy mô lớn
  • Và khoảng một triệu vấn đề khác

Và vì vậy, tôi có nhiệm vụ đi sâu và thực hiện các nghiên cứu sâu rộng và học hỏi nhiều nhất có thể khi tôi viết ra các ghi chú và ý tưởng của riêng mình.

Kết quả là bài viết này.

Nhưng tại sao tôi lại nghiên cứu về MLOps?

Theo techjury, mỗi người tạo ra ít nhất 1,7 MB dữ liệu mỗi giây vào năm 2020. Đối với các nhà khoa học dữ liệu, điều đó giống như Giáng sinh sớm vì có rất nhiều lý thuyết / ý tưởng để khám phá, thử nghiệm và nhiều khám phá được thực hiện và các mô hình được phát triển.

Nhưng nếu chúng ta trở nên nghiêm túc và thực sự để những mô hình đó chạm đến các vấn đề kinh doanh trong đời thực và con người thực, chúng ta phải giải quyết các yếu tố cần thiết như:

  • thu thập & làm sạch một lượng lớn dữ liệu
  • thiết lập theo dõi và lập phiên bản cho các thử nghiệm và chạy huấn luyện mô hình
  • thiết lập các quy trình triển khai và giám sát cho các mô hình đi vào sản xuất.

Và chúng ta cần tìm cách mở rộng quy mô hoạt động ML của mình theo nhu cầu của doanh nghiệp và / hoặc người dùng các mô hình ML.

Trước đây cũng có những vấn đề tương tự khi chúng tôi cần mở rộng các hệ thống phần mềm thông thường để nhiều người có thể sử dụng chúng hơn.

Giải pháp của DevOps là một tập hợp các phương pháp phát triển, thử nghiệm, triển khai và vận hành các hệ thống phần mềm quy mô lớn. Với DevOps, chu kỳ phát triển trở nên ngắn hơn, tốc độ triển khai tăng lên và các bản phát hành hệ thống trở nên dễ kiểm soát và đáng tin cậy.

Điều đó đưa chúng ta đến MLOps. Nó được sinh ra tại nơi giao thoa của DevOps, Data Engineering và Machine Learning và nó có khái niệm tương tự như DevOps, nhưng cách thực thi thì khác.

Các hệ thống ML có bản chất là thử nghiệm và có nhiều thành phần rất phức tạp để xây dựng và vận hành.

Nào, cùng nói sâu hơn!

MLOps là gì?

MLOps là một tập hợp các phương pháp để hợp tác và giao tiếp giữa các nhà khoa học dữ liệu và các chuyên gia vận hành.

Việc áp dụng các thực hành này sẽ làm tăng chất lượng, đơn giản hóa quy trình quản lý và tự động hóa việc triển khai các mô hình Machine Learning và Deep Learning trong môi trường sản xuất quy mô lớn. Liên kết các mô hình với nhu cầu kinh doanh cũng như các quy định bắt buộc cũng dễ dàng hơn.

Chu trình MLOps
Chu trình MLOps

MLOps đang dần phát triển thành một phương pháp độc lập để quản lý vòng đời ML. Nó áp dụng cho toàn bộ vòng đời – thu thập dữ liệu, tạo mô hình (vòng đời phát triển phần mềm, CI/CD), điều phối, triển khai, sức khỏe, chẩn đoán, quản trị và các chỉ số kinh doanh.

Các giai đoạn chính của MLOps là:

  • Thu thập dữ liệu
  • Phân tích dữ liệu
  • Chuyển đổi / chuẩn bị dữ liệu
  • Huấn luyện & phát triển mô hình
  • Đánh giá mô hình 
  • Dịch vụ hóa mô hình
  • Giám sát mô hình
  • Huấn luyện lại mô hình.

DevOps vs. MLOps

DevOps và MLOps có những điểm tương đồng cơ bản vì MLOps được bắt nguồn từ các nguyên tắc của DevOps. Nhưng chúng khá khác nhau về cách thực hiện:

1. Không giống như DevOps, MLOps mang bản chất thử nghiệm hơn

Các nhà khoa học dữ liệu (data scientist) và kỹ sư ML/DL (Machine Learning/Data Labeling) phải tinh chỉnh các tính năng khác nhau – siêu tham số, thông số và mô hình – đồng thời theo dõi và quản lý dữ liệu cũng như cơ sở mã (code base) để có kết quả có thể phục dựng được.

Bên cạnh những nỗ lực và công cụ, ngành ML/DL vẫn phải vật lộn với khả năng phục dựng lại các thí nghiệm.

2. Đội nhóm hỗn hợp

Đội nhóm cần để xây dựng và triển khai các mô hình vào sản xuất không chỉ gồm các kỹ sư phần mềm (software engineer).

Trong dự án ML, đội nhóm thường gồm các nhà khoa học dữ liệu hoặc nhà nghiên cứu ML (Machine learning researcher), những người tập trung vào phân tích dữ liệu khám phá, phát triển mô hình và thử nghiệm.

Họ không nhất thiết phải là những kỹ sư phần mềm giàu kinh nghiệm để có thể xây dựng các dịch vụ ở cấp sản xuất.

3. Kiểm thử

Kiểm thử một hệ thống ML bao gồm đánh giá mô hình, huấn luyện mô hình,… ngoài các kiểm thử thông thường, chẳng hạn như kiểm thử đơn vị và kiểm thử tích hợp.

4. Triển khai tự động

Bạn không thể chỉ triển khai mô hình ML được huấn luyện ngoại tuyến (offline-trained ML model) như một dịch vụ dự đoán (prediction service). Bạn sẽ cần quy trình gồm nhiều bước để tự động huấn luyện lại và triển khai mô hình.

Quy trình tăng tính phức tạp vì bạn cần tự động hóa các bước mà các nhà khoa học dữ liệu thực hiện thủ công trước khi triển khai huấn luyện và đánh giá các mô hình mới.

5. Sự suy giảm kết quả trong môi trường sản xuất của hệ thống do hồ sơ dữ liệu thay đổi hay đơn giản là Chênh lệch Huấn luyện – Thực tế (Training – Serving Skew).

Các mô hình ML trong môi trường sản xuất có thể bị giảm hiệu suất không chỉ do việc lập trình không tối ưu mà còn do hồ sơ dữ liệu liên tục thay đổi.

Các mô hình có thể phân rã theo nhiều cách hơn so với các hệ thống phần mềm thông thường và bạn cần phải lên kế hoạch cho nó. 

Điều này có thể xảy ra bởi:

  • Sự khác biệt giữa cách bạn xử lý dữ liệu trong quy trình huấn luyện và chạy thực tế.
  • Sự thay đổi dữ liệu giữa khi bạn huấn luyện và khi bạn chạy thực tế.
  • Vòng lặp phản hồi – khi bạn chọn sai giả thuyết để tối ưu, điều này khiến bạn thu thập dữ liệu sai lệch khi huấn luyện mô hình của mình. Sau đó, không hề hay biết, bạn thu thập các điểm dữ liệu mới hơn bằng cách sử dụng giả thuyết này, nó được phản hồi để huấn luyện lại / tinh chỉnh các phiên bản mô hình trong tương lai, làm cho mô hình trở nên sai lệch hơn và hiệu ứng hòn tuyết lăn xảy ra.

6. Giám sát

Các mô hình trong môi trường sản xuất cần được giám sát. Tương tự, cần theo dõi các thống kê tóm tắt dữ liệu đã xây dựng mô hình để làm mới mô hình khi cần.

Các thống kê này có thể và sẽ thay đổi theo thời gian, bạn cần thông báo hoặc một quy trình khôi phục khi các giá trị đi chệch hướng so với mong đợi.

MLOps và DevOps tương tự nhau khi nói tới việc tích hợp liên tục kiểm soát nguồn, kiểm thử đơn vị, kiểm thử tích hợp và phân phối liên tục mô-đun hoặc gói phần mềm.

Tuy nhiên, trong ML có một số điểm khác biệt đáng chú ý:

  • Tích hợp liên tục (CI) không còn là về kiểm thử và đánh giá code và các thành phần, mà còn kiểm thử và thẩm định dữ liệu, lược đồ CSDL và mô hình.
  • Triển khai liên tục (CD) không còn là về một gói phần mềm hoặc dịch vụ đơn lẻ, mà là một hệ thống (quy trình huấn luyện ML) sẽ tự động triển khai một dịch vụ khác (dịch vụ dự đoán mô hình) hoặc khôi phục các thay đổi từ một mô hình.
  • Kiểm thử liên tục (CT) là một thuộc tính mới, duy nhất đối với các hệ thống ML, liên quan đến việc tự động huấn luyện lại và chạy thực tế mô hình.
Nền tảng Machine Learning End-to-End
Nền tảng Machine Learning End-to-End

MLOps vs. Theo dõi thử nghiệm vs. Quản lý mô hình ML

Chúng ta đã định nghĩa MLOps là gì, còn theo dõi thử nghiệm và quản lý mô hình ML thì sao?

Theo dõi thử nghiệm (Experiment tracking)

Theo dõi thử nghiệm là một phần (hoặc một quy trình) của MLOps, tập trung vào việc thu thập, tổ chức và theo dõi thông tin huấn luyện mô hình qua nhiều lần chạy với các cấu hình khác nhau (siêu tham số, quy mô mô hình, phân tách dữ liệu, tham số, v.v.).

Như đã đề cập trước đó, vì ML/DL có bản chất là thử nghiệm, chúng ta sẽ sử dụng các công cụ theo dõi thử nghiệm để so sánh các mô hình khác nhau được tạo bởi các công ty, đội nhóm hoặc thành viên khác nhau.

Quản lý mô hình

Để đảm bảo rằng các mô hình ML nhất quán và tất cả các yêu cầu kinh doanh được đáp ứng ở quy mô lớn, một chính sách hợp lý, dễ thực hiện đối với Quản lý mô hình là điều cần thiết.

Phương pháp luận MLOps bao gồm một quy trình để phối hợp việc huấn luyện mô hình, đóng gói, thẩm định, triển khai và giám sát. Bằng cách này, bạn có thể chạy các dự án ML một cách nhất quán từ đầu đến cuối.

Bằng cách thiết lập một phương pháp luận Quản lý mô hình rõ ràng, nhất quán, các tổ chức có thể:

  • Chủ động giải quyết các mối quan tâm kinh doanh chung (chẳng hạn như tuân thủ quy định);
  • Cho phép các mô hình có thể tái tạo bằng cách theo dõi dữ liệu, mô hình, mã và lập phiên bản mô hình;
  • Đóng gói và cung cấp các mô hình theo cấu hình có thể lặp lại để hỗ trợ khả năng tái sử dụng.

Tại sao MLOps lại quan trọng?

MLOps là nền tảng. Machine Learning giúp các cá nhân và doanh nghiệp triển khai các giải pháp giúp mở khóa những nguồn doanh thu chưa khai thác, tiết kiệm thời gian và giảm chi phí bằng cách tạo quy trình làm việc hiệu quả hơn, tận dụng phân tích dữ liệu để ra quyết định và cải thiện trải nghiệm khách hàng.

Những mục tiêu này khó có thể hoàn thành nếu không có một khuôn khổ vững chắc để tuân theo. Tự động hóa việc phát triển và triển khai mô hình với MLOps có nghĩa là thời gian thâm nhập thị trường nhanh hơn và chi phí vận hành thấp hơn. Nó giúp các nhà quản lý và nhà phát triển trở nên linh hoạt và có tính chiến lược hơn trong các quyết định.

MLOps đóng vai trò như bản đồ hướng dẫn các cá nhân, nhóm nhỏ và thậm chí cả doanh nghiệp đạt được mục tiêu của họ bất kể các ràng buộc như dữ liệu nhạy cảm, ít tài nguyên, ngân sách nhỏ…

Bạn quyết định bản đồ của mình sẽ lớn tới mức nào vì MLOps không phải là những thực tiễn cứng nhắc. Bạn có thể thử nghiệm với các thiết lập khác nhau và chỉ giữ lại những gì hiệu quả.

Các thực hành  MLOps tốt nhất

Lúc đầu, tôi chỉ muốn liệt kê 10 thực hành tốt nhất, nhưng sau một số nghiên cứu, tôi đã đi đến kết luận rằng tốt nhất nên đưa vào các thực hành tốt nhất cho các thành phần khác nhau của một quy trình ML, đó là: Đội nhóm, Dữ liệu, Mục tiêu, Mô hình, Mã và Triển khai.

Đội nhóm

Dữ liệu 

Mục tiêu (Thang đo và KPI)

Model 

Code

Triển khai

Các thực hành tốt nhất này sẽ đóng vai trò nền tảng để bạn xây dựng các giải pháp MLOps.

Cách triển khai MLOps

Có 3 cách triển khai MLOps:

  • MLOps cấp 0 (Quy trình thủ công)
  • MLOps cấp 1 (tự động hóa quy trình ML)
  • MLOps cấp 2 (tự động hóa quy trình CI / CD)

MLOps cấp 0

Điển hình cho các công ty mới bắt đầu với ML. Quy trình ML hoàn toàn thủ công và quy trình dựa trên nhà khoa học dữ liệu là đủ nếu các mô hình hiếm khi được thay đổi hoặc huấn luyện.

Đặc trưng

  • Quy trình thủ công, theo hướng kịch bản và tương tác: mọi bước đều thủ công, bao gồm phân tích dữ liệu, chuẩn bị dữ liệu, huấn luyện mô hình và đánh giá. Yêu cầu thực hiện thủ công từng bước và chuyển đổi thủ công từ bước này sang bước khác.
  • Không kết nối giữa ML và các hoạt động: quy trình tách biệt giữa các nhà khoa học dữ liệu tạo ra mô hình với các kỹ sư chạy thực tế mô hình. Các nhà khoa học dữ liệu chuyển giao một mô hình đã huấn luyện như một tạo tác (artifact) để nhóm kỹ sư triển khai trên cơ sở hạ tầng API của mình.
  • Phát hành không thường xuyên: giả định ở đây là nhóm khoa học dữ liệu quản lý một số mô hình không thường xuyên thay đổi (triển khai mô hình hoặc huấn luyện lại mô hình bằng dữ liệu mới). Một phiên bản mô hình mới chỉ được triển khai một vài lần mỗi năm.
  • Không tích hợp liên tục (CI): vì có ít thay đổi trong triển khai, nên bỏ qua CI. Thông thường, kiểm thử là một phần trong việc thực thi kịch bản.
  • Không triển khai liên tục (CD): vì không có triển khai phiên bản mô hình thường xuyên, nên CD không được cân nhắc.
  • Triển khai liên quan đến dịch vụ dự đoán (tức là một microservice với REST API)
  • Thiếu chủ động giám sát hiệu suất: quy trình không theo dõi hoặc ghi lại các dự đoán và hành động của mô hình.

Đội ngũ kỹ sư có thể có thiết lập phức tạp khi cấu hình API, kiểm thử và triển khai, bao gồm bảo mật, hồi quy và thử nghiệm tải + canary.

Các thách thức

Trong thực tế, các mô hình thường bị hỏng khi chúng được triển khai trong thế giới thực. Mô hình không thích ứng với những thay đổi của môi trường hoặc trong dữ liệu mô tả môi trường.

Để giải quyết những thách thức của quy trình thủ công này, bạn nên sử dụng các phương pháp MLOps cho CI / CD và CT. Bằng cách triển khai quy trình huấn luyện ML, bạn có thể kích hoạt CT và có thể thiết lập hệ thống CI / CD để kiểm thử, xây dựng và thực thi các triển khai mới của quy trình ML một cách nhanh chóng.

MLOps cấp độ 1

Mục tiêu của MLOps cấp 1 là thực hiện huấn luyện liên tục (CT) mô hình bằng cách tự động hóa quy trình ML. Bằng cách này, bạn có thể cung cấp liên tục dịch vụ dự đoán mô hình.

Kịch bản này có thể hữu ích cho các giải pháp hoạt động trong môi trường thay đổi liên tục và cần chủ động giải quyết những thay đổi trong hành vi của khách hàng, tỷ giá và các chỉ số khác.

Đặc trưng

  • Thử nghiệm nhanh: Các bước thử nghiệm ML được sắp xếp và thực hiện tự động.
  • CT của mô hình trong môi trường sản xuất: mô hình được huấn luyện tự động trong môi trường sản xuất, sử dụng dữ liệu mới dựa trên các live pipeline trigger.
  • Cân xứng giữa vận hành – thử nghiệm: triển khai quy trình được sử dụng trong môi trường phát triển hoặc thử nghiệm được sử dụng trong môi trường tiền sản xuất và sản xuất, đây là một khía cạnh chính của thực hành MLOps để thống nhất DevOps.
  • Mã được mô-đun hóa cho các thành phần và quy trình: để xây dựng quy trình ML, các thành phần cần phải tái sử dụng được, kết hợp được và chia sẻ được ở các quy trình ML (tức là sử dụng các container).
  • Phân phối liên tục các mô hình: tự động hóa bước triển khai mô hình, tức là chạy thực tế mô hình đã được huấn luyện và công nhận như một dịch vụ dự đoán cho các dự đoán online.
  • Triển khai quy trình: ở cấp độ 0, bạn triển khai một mô hình được huấn luyện như một dịch vụ dự đoán vào môi trường sản xuất. Đối với cấp độ 1, bạn triển khai quy trình huấn luyện tổng thể (một cách tự động và thường xuyên) để chạy thực tế mô hình đã được huấn luyện như một dịch vụ dự đoán.

Các thành phần bổ sung

  • Xác thực dữ liệu và mô hình: quy trình kỳ vọng dữ liệu sống, mới nhằm tạo ra một phiên bản mô hình mới được huấn luyện dựa trên dữ liệu mới. Do đó, các bước xác thực dữ liệu và xác thực mô hình tự độnglà bắt buộc trong quy trình sản xuất.
  • Kho tính năng: kho tính năng là một kho lưu trữ tập trung, nơi chuẩn hóa định nghĩa, lưu trữ và truy cập của các tính năng để huấn luyện và phục vụ.
  • Quản lý metadata: thông tin về mỗi lần thực thi quy trình ML được ghi lại, hữu ích cho dòng đời dữ liệu và tạo tác, khả năng tái tạo và so sánh. Nó cũng giúp bạn gỡ lỗi và các bất thường
  • Kích hoạt quy trình ML: bạn có thể tự động hóa quy trình sản xuất ML để huấn luyện lại các mô hình bằng dữ liệu mới, tùy thuộc vào tình huống của bạn:
    • Theo nhu cầu
    • Theo lịch trình
    • Theo tính sẵn có của dữ liệu huấn luyện mới
    • Theo sự suy giảm hiệu suất của mô hình
    • Theo những thay đổi đáng kể trong phân phối dữ liệu (hồ sơ dữ liệu đang thay đổi).

Những thách thức

Thiết lập này phù hợp khi bạn triển khai các mô hình mới dựa trên dữ liệu mới, thay vì dựa trên các ý tưởng ML mới.

Tuy nhiên, bạn cần thử các ý tưởng ML mới và nhanh chóng triển khai các thành phần ML. Nếu bạn quản lý nhiều quy trình ML trong môi trường sản xuất, bạn cần thiết lập CI / CD để tự động hóa việc xây dựng, kiểm tra và triển khai các quy trình ML.

MLOps cấp độ 2

Với 1 cập nhật nhanh chóng và đáng tin cậy các quy trình trong môi trường sản xuất, bạn cần có một hệ thống CI/CD tự động mạnh mẽ.

Với hệ thống CI/CD tự động này, các data scientist sẽ sớm khám phá nhiều ý tưởng mới quanh feature engineering (kỹ thuật loại bỏ thuộc tính dư thừa), kiến ​​trúc định hướng mô hình và siêu tham số.

Cấp độ này phù hợp với các công ty hoạt động trong lĩnh vực công nghệ phải huấn luyện lại mô hình của họ hàng ngày, thậm chí hàng giờ, cập nhật chúng trong vài phút và triển khai lại trên hàng nghìn máy chủ đồng thời.

Nếu không có chu trình MLOps từ đầu đến cuối, các tổ chức như vậy sẽ không tồn tại được.

Thiết lập MLOps này bao gồm các thành phần sau:

  • Kiểm soát nguồn
  • Dịch vụ kiểm thử và xây dựng 
  • Dịch vụ triển khai
  • Sổ đăng ký mô hình
  • Kho thuộc tính
  • Kho siêu dữ liệu ML
  • Bộ điều phối quy trình ML

Đặc trưng

  • Phát triển và thử nghiệm: bạn liên tục thử các thuật toán ML và mô hình mới, trong đó các bước thử nghiệm được điều phối. Đầu ra của giai đoạn này là mã nguồn của các bước quy trình ML, sau đó được đẩy đến một kho lưu trữ nguồn.
  • Tích hợp liên tục theo quy trình: bạn xây dựng mã nguồn và chạy các bài kiểm thử khác nhau. Đầu ra của giai đoạn này là các thành phần quy trình (gói, tệp thực thi và tạo tác) sẽ được triển khai trong giai đoạn sau.
  • Phân phối liên tục theo quy trình: bạn triển khai các tạo tác được tạo ra bởi giai đoạn CI tới môi trường mục tiêu. Đầu ra của giai đoạn này là một quy trình được triển khai với việc triển khai mô hình mới.
  • Kích hoạt tự động: quy trình được thực hiện tự động trong quá trình sản xuất dựa trên lịch trình hoặc phản ứng với trình kích hoạt. Đầu ra của giai đoạn này là một mô hình mới được huấn luyện được đẩy vào sổ đăng ký mô hình.
  • Phân phối liên tục mô hình: bạn chạy thực tế mô hình đã được huấn luyện như một dịch vụ dự đoán cho các dự đoán. Đầu ra của giai đoạn này là một dịch vụ dự đoán mô hình đã triển khai.
  • Giám sát: bạn thu thập thống kê hiệu suất của mô hình dựa trên dữ liệu sống. Đầu ra của giai đoạn này là một trigger để thực thi quy trình hoặc thực thi một chu kỳ thử nghiệm mới.

Bước phân tích dữ liệu vẫn là một quy trình thủ công đối với các data scientist trước khi quy trình bắt đầu lặp lại thử nghiệm mới. Bước phân tích mô hình cũng là một quy trình thủ công.

Cơ sở hạ tầng MLOps: Xây dựng, mua hay kết hợp (hydrid)?

Các công ty điện toán đám mây đã đầu tư hàng trăm tỷ đô la vào cơ sở hạ tầng và quản lý.

Để cung cấp cho bạn một chút bối cảnh, một báo cáo của canalys nói rằng chi tiêu cho cơ sở hạ tầng đám mây công cộng đạt 77,8 tỷ đô vào năm 2018 và đã tăng lên 107 tỷ đô vào năm 2019.

Theo một nghiên cứu khác của IDC, với tốc độ tăng trưởng kép hàng năm (CAGR) là 22,3%, chi tiêu cho cơ sở hạ tầng đám mây ước tính sẽ tăng lên gần 500 tỷ đô vào năm 2023.

Chi tiêu cho các dịch vụ cơ sở hạ tầng đám mây đạt mức kỷ lục 30 tỷ đô trong quý 2 năm 2020, với Amazon Web Services (AWS), Microsoft và Google Cloud chiếm một nửa chi tiêu của khách hàng.

Từ góc độ nhà cung cấp, thị phần AWS vẫn ở mức “lâu đời” là khoảng 33% trong quý 2 năm 2020, tiếp theo là Microsoft với 18% và Google Cloud là 9%.

Trong khi đó, các nhà cung cấp đám mây Trung Quốc hiện chiếm hơn 12% thị trường toàn thế giới, dẫn đầu là Alibaba, Tencent và Baidu.

Các công ty này đầu tư vào nghiên cứu và phát triển phần cứng, phần mềm và các ứng dụng SaaS chuyên dụng, cũng như phần mềm MLOps. Hai ví dụ tuyệt vời xuất hiện trong tâm trí tôi:

  • AWS với Sagemaker, một nền tảng ML đám mây được quản lý từ đầu chí cuối, cho phép các nhà phát triển tạo, huấn luyện và triển khai các mô hình học máy trong đám mây, hệ thống nhúng và thiết bị tiên tiến.
  • Google với AI Platform Pipelines gần đây để xây dựng và quản lý các quy trình ML, tận dụng các thành phần và mẫu được tạo sẵn của TensorFlow (TFX’s) thực hiện rất nhiều công việc triển khai mô hình.

Vậy bạn nên xây dựng hay mua cơ sở hạ tầng hay kết hợp đây?

Các công ty công nghệ muốn tồn tại lâu dài thường có đội ngũ nội bộ và xây dựng các giải pháp tùy chỉnh. Nếu họ có kỹ năng, kiến ​​thức và công cụ để giải quyết các vấn đề phức tạp, thì không có gì sai với cách tiếp cận đó. Nhưng có những yếu tố khác đáng được tính đến, như:

  • thời gian và nỗ lực
  • nguồn nhân lực
  • thời gian để thu lợi nhuận
  • chi phí cơ hội.

Thời gian và nỗ lực

Theo một cuộc khảo sát của cnvrg.io, các data scientist thường dành thời gian xây dựng các giải pháp để bổ sung vào cơ sở hạ tầng hiện có của họ nhằm hoàn thành các dự án.

65% thời gian của họ dành cho các nhiệm vụ nặng về kỹ thuật, phi khoa học dữ liệu như theo dõi, giám sát, cấu hình, quản lý tài nguyên tính toán, cơ sở hạ tầng chạy thực tế, khai thác tính năng và triển khai mô hình.

Thời gian lãng phí này thường được gọi là “nợ kỹ thuật ẩn” và là một nút thắt cổ chai phổ biến đối với các đội nhóm machine learning.

Việc xây dựng một giải pháp nội bộ hoặc duy trì một giải pháp hoạt động kém hiệu quả có thể mất từ ​​6 tháng đến 1 năm.

Ngay cả khi bạn đã xây dựng cơ sở hạ tầng đang hoạt động, chỉ để duy trì cơ sở hạ tầng và cập nhật công nghệ mới nhất, bạn cần phải có quản lý vòng đời và một đội nhóm chuyên tâm.

Nguồn nhân lực

Việc vận hành machine learning đòi hỏi rất nhiều kỹ thuật. Để có một quy trình làm việc machine learning trôi chảy, mỗi đội nhóm data science phải có một nhóm vận hành hiểu được các yêu cầu riêng biệt của việc triển khai các mô hình machine learning.

Bằng việc đầu tư vào nền tảng MLOps end-to-end, các quy trình này có thể hoàn toàn tự động, sẽ giúp các nhóm vận hành tập trung vào việc tối ưu hóa cơ sở hạ tầng của họ dễ dàng hơn.

Phí tổn

Việc có một nhóm vận hành chuyên tâm để quản lý các mô hình có thể tốn kém. Nếu muốn mở rộng quy mô thử nghiệm và triển khai, bạn cần thuê thêm kỹ sư để quản lý quy trình này. Đó là một khoản đầu tư lớn và một quá trình chậm chạp để tìm được nhóm phù hợp.

Giải pháp MLOps có sẵn được xây dựng tính đến khả năng mở rộng, với chi phí thấp. Sau khi tính toán tất cả các chi phí khác nhau liên quan đến việc thuê và giới thiệu toàn bộ đội ngũ kỹ sư, lợi tức đầu tư của bạn giảm xuống, điều này đưa chúng ta đến yếu tố tiếp theo.

Thời gian sinh lời

Có thể mất hơn một năm để xây dựng cơ sở hạ tầng machine learning hoạt động được. Có thể mất nhiều thời gian hơn nữa để xây dựng một quy trình dữ liệu có thể tạo ra giá trị cho tổ chức của bạn.

Các công ty như Uber, Netflix và Facebook đã dành nhiều năm và nỗ lực kỹ thuật lớn để mở rộng quy mô và duy trì nền tảng học máy của họ để duy trì tính cạnh tranh.

Đối với hầu hết các công ty, một khoản đầu tư như thế này là không thể, và cũng không cần thiết. Lĩnh vực machine learning đã phát triển kể từ khi Uber, Netflix và Facebook xây dựng các giải pháp nội bộ của họ.

Ngày càng nhiều giải pháp có sẵn cung cấp tất cả những gì bạn cần ngay lập tức, với chi phí thấp hơn.

Chi phí cơ hội

Như đã đề cập ở trên, một cuộc khảo sát cho thấy 65% ​​thời gian của một nhà khoa học dữ liệu được dành cho các nhiệm vụ không liên quan đến khoa học dữ liệu. Việc sử dụng nền tảng MLOps sẽ tự động hóa các tác vụ kỹ thuật và giảm tắc nghẽn DevOps.

Các nhà khoa học dữ liệu có thể dành thời gian làm nhiều việc hơn – cung cấp các mô hình có ý nghĩa – trong khi nhà cung cấp đám mây lo phần còn lại.

Việc áp dụng nền tảng MLOps end-to-end có một lợi thế cạnh tranh đáng kể cho phép sự phát triển machine learning của bạn mở rộng quy mô lớn.

Còn về cơ sở hạ tầng MLOps kết hợp?

Một số công ty được tin tưởng giao phó với dữ liệu riêng tư và nhạy cảm. Nó không thể rời khỏi máy chủ của họ vì nếu có một lỗ hổng nhỏ, hiệu ứng gợn sóng sẽ rất thảm khốc. Đây là lúc cơ sở hạ tầng đám mây MLOps kết hợp ra đời.

Hiện tại, cơ sở hạ tầng đám mây tồn tại song song với các hệ thống tại chỗ trong hầu hết các trường hợp.

Quản lý đám mây lai rất phức tạp, nhưng thường cần thiết. Theo báo cáo Cơ sở hạ tầng đám mây năm 2020 của Cloudcheckr, cơ sở hạ tầng ngày nay là sự kết hợp giữa đám mây và tại chỗ (cloud và on-premise)

Cơ sở hạ tầng đám mây ngày càng phổ biến, nhưng vẫn hiếm khi tìm thấy một công ty lớn từ bỏ hoàn toàn cơ sở hạ tầng tại chỗ (hầu hết đều vì những lý do rõ ràng, chẳng hạn như dữ liệu nhạy cảm).

Một nghiên cứu khác của RightScale cho thấy rằng tỷ lệ áp dụng đám mây lai đã tăng 58% vào năm 2019 từ 51% trong năm 2018. Điều này có thể hiểu được vì có nhiều lý do để tiếp tục duy trì cơ sở hạ tầng tại chỗ.

Nền tảng On-prem
Tại sao công ty của bạn tiếp tục duy trì cơ sở hạ tầng tại chỗ?

Quản lý cơ sở hạ tầng hydrid là một thách thức

Quản lý bất kỳ loại cơ sở hạ tầng công nghệ doanh nghiệp nào không phải việc dễ dàng. Luôn có những vấn đề liên quan đến bảo mật, hiệu suất, tính khả dụng, chi phí và nhiều vấn đề khác.

Môi trường đám mây lai tạo thêm một lớp phức tạp khiến việc quản lý CNTT thậm chí còn trở nên khó khăn hơn.

Phần lớn các bên liên quan đến đám mây (96%) phải đối mặt với những thách thức trong việc quản lý cả cơ sở hạ tầng tại chỗ và đám mây.

Thách thức nào trong việc quản lý cơ sở hạ tầng tại chỗ lẫn đám mây?

Thách thức trong quản lý hạ tầng on prem và cloud
Thách thức trong quản lý hạ tầng on prem và cloud

Các vấn đề “khác” được báo cáo bao gồm nhu cầu về một bộ kỹ năng hoàn toàn khác, thiếu khả năng tiếp cận với máy tính và lưu trữ chuyên dụng.

Ngoài ra, phải thay đổi vai trò của nhân viên hiện tại để giao cho họ quản lý các hệ thống tại chỗ và cuối cùng là giải quyết các vấn đề về độ tin cậy đang diễn ra (như Timeout, Thiếu tài nguyên dữ liệu, Thiếu tài nguyên máy tính, Lỗi phần mềm, Lỗi cơ sở dữ liệu, Lỗi phần cứng và Lỗi mạng)..

Việc xây dựng nền tảng và cơ sở hạ tầng của riêng bạn sẽ ngày càng chiếm nhiều sự tập trung và chú ý của bạn khi nhu cầu tăng lên.

Thời gian có thể dành cho R&D mô hình và thu thập dữ liệu sẽ do quản lý cơ sở hạ tầng đảm nhận. Điều này không hay chút nào trừ khi nó là một phần của hoạt động kinh doanh cốt lõi của bạn (nếu bạn là nhà cung cấp dịch vụ đám mây, PaaS hoặc IaaS).

Mua một nền tảng được quản lý hoàn toàn mang lại cho bạn tính linh hoạt và khả năng mở rộng cao, nhưng sau đó bạn phải đối mặt với các vấn đề về tuân thủ, quy định và bảo mật.

Cơ sở hạ tầng MLOps đám mây kết hợp là tốt nhất lúc này, nhưng nó đặt ra những thách thức riêng, vì vậy, bạn có thể quyết định xem nó có phù hợp với mô hình kinh doanh của mình hay không.

Kết

Giờ đây bạn đã xác định được công ty của mình đang ở cấp độ nào, bạn có thể sử dụng một trong hai giải pháp MLOps:

  • End-to-end
  • Giải pháp MLOps được xây dựng tùy chỉnh (hệ sinh thái các công cụ)

Giải pháp MLOps end-to-end

Đây là những dịch vụ được quản lý hoàn toàn cung cấp cho các nhà phát triển và nhà khoa học dữ liệu khả năng xây dựng, huấn luyện và triển khai các mô hình ML một cách nhanh chóng. Các giải pháp thương mại hàng đầu là:

  • Amazon Sagemaker, bộ công cụ để xây dựng, huấn luyện, triển khai và giám sát các mô hình học máy
  • Bộ Microsoft Azure MLOps:
    • Azure Machine Learning để xây dựng, huấn luyện và xác thực các quy trình ML có thể tái tạo
    • Azure Pipelines để tự động triển khai ML
    • Azure Monitor để theo dõi và phân tích các chỉ số
    • Dịch vụ Azure Kubernetes và các công cụ bổ sung khác.
  • Bộ MLOps của Google Cloud:
    • Luồng dữ liệu để trích xuất, xác thực và chuyển đổi dữ liệu cũng như để đánh giá các mô hình
    • AI Platform Notebook để phát triển và huấn luyện các mô hình
    • Cloud Build để xây dựng và kiểm tra các quy trình học máy
    • TFX để triển khai quy trình ML
    • Kubeflow Pipelines để sắp xếp triển khai ML trên Google Kubernetes Engine (GKE).

Giải pháp MLOps tùy chỉnh

Các giải pháp end-to-end là tuyệt vời, nhưng bạn cũng có thể tự xây dựng bằng các công cụ yêu thích của mình, bằng cách chia quy trình MLOps thành nhiều microservices.

Cách tiếp cận này có thể giúp bạn tránh một điểm lỗi duy nhất (SPOF) và giúp quy trình của bạn trở nên mạnh mẽ – điều này làm cho quy trình của bạn dễ kiểm tra, gỡ lỗi và tùy chỉnh hơn. Trong trường hợp nhà cung cấp microservice gặp sự cố, bạn có thể dễ dàng thay thế bằng một nhà cung cấp dịch vụ mới.

Ví dụ gần đây nhất về SPOF là AWS ngừng hoạt động, điều này rất hiếm nhưng có thể xảy ra. Ngay cả Goliath cũng có thể gục ngã.

Microservices đảm bảo rằng mỗi dịch vụ được kết nối với nhau thay vì nhúng với nhau. Ví dụ, bạn có thể có các công cụ riêng biệt để quản lý mô hình và theo dõi thử nghiệm.

Cuối cùng, có rất nhiều công cụ MLOps có sẵn, tôi xin đề xuất 7 lựa chọn hàng đầu của tôi:

  • Project Jupyter
  • Nbdev
  • Airflow
  • Kubeflow
  • MLflow
  • Optuna
  • Cortex
  • Neptune

Bằng cách tận dụng những công cụ này và nhiều công cụ khác, bạn có thể xây dựng một giải pháp end-to-end bằng cách kết hợp các microservice lại với nhau.

MLOps là một lĩnh vực mới đang phát triển nhanh chóng, với các công cụ và quy trình mới luôn ra đời. Nếu bạn tham gia chương trình đào tạo MLOps ngay bây giờ, bạn đang đạt được lợi thế cạnh tranh rất lớn.

Tham khảo: Neptune.ai

Categories
Dev's Corner

DevOps là gì? Cánh cửa tương lai của công việc DevOps

Công việc của DevOps được cho là mang lại rất nhiều lợi ích trong chu trình phát triển phần mềm.

Quá rõ ràng DevOps là sự kết hợp giữa công việc Development (phát triển) và Operations (Vận hành).

Thế nhưng, bạn có biết sự cộng tác này bắt nguồn từ đâu, tại sao lại có và cuộc hành trình DevOps hướng đến sẽ như thế nào không?

Cùng Gambaru tìm hiểu nhé.

Devops là gì? Sự tích DevOps

Ngày xửa ngày xưa, khi những chiếc máy tính đầu tiên được lưu hành, các nhà lập trình ngồi tại máy trạm, viết code, biên dịch và tiến hành kiểm tra trên cùng một thiết bị.

Quá trình “deploy” lúc bấy giờ đơn giản chỉ là sao chép vào hàng chục đĩa flop, lặp đi lặp lại.

Khi các “trung tâm hoạt động mạng” thô sơ đi vào hoạt động, các nhân viên Vận hành bắt đầu xuất hiện để quản lý cấu hình và uptime của mạng.

Ở giai đoạn Word Wide Web, quy mô hệ thống nhân lên, phát triển và vận hành CNTT tách biệt thành hai bộ phận độc lập.

Phát triển bao gồm phần việc của UI designer, developer, QA/QC… còn vận hành liên quan đến các công việc về quản lý, giám sát hệ thống.

DevOps là gì? Sự tích Devops
Công nghệ ngày càng tiên tiến và hiện đại, đòi hỏi cần có năng lực mới để đáp ứng

Sự bùng nổ của mạng Internet và công nghệ đi kèm với sự ra đời của thuật ngữ “Site Reliability Engineers” – kỹ sư ổn định hệ thống (SRE), chịu trách nhiệm giảm “downtime”, duy trì “uptime” cao, đảm bảo hoạt động liên tục không xảy ra gián đoạn để mang lại sự hài lòng cho khách hàng. SRE chính là tiền thân của DevOps Engineer sau này.

Cùng xem video buổi chia sẻ về SRE tại Technical Event #07 vừa qua:

Technical Event #07: Design for Failure – AWS Philosophy for Reliability

Lý do xuất hiện DevOps

Trong khi Development thực hiện những thay đổi để sáng tạo ra tính năng mới thì Operations lại có nhiệm vụ đảm bảo duy trì sự ổn định.

Chính điều này đã gây ra mâu thuẫn giữa hai bên.

Để đáp ứng yêu cầu ngày càng gắt gao vừa tối ưu hóa sản phẩm vừa rút ngắn thời gian delivery nhưng vẫn giữ được tính ổn định, đòi hỏi Development và Operations phải xích lại gần nhau hơn.

Lý do xuất hiện DevOps
Dev và Ops cần tích cực phối hợp vì mục đích chung là tối ưu hóa và tiết kiệm thời gian

Khoảng cách giữa phát triển và vận hành mất đi, nhường chỗ cho sự giao tiếp hiệu quả cộng với khả năng làm việc cross-function giúp hạn chế rủi ro, giảm thiểu thất bại và đồng thời cải thiện khả năng cung cấp dịch vụ IT một cách đáng kể.

Công việc và yêu cầu với DevOps

DevOps được hiểu là một văn hóa, một phương thức làm việc đem lại sự thành công dựa vào sự cộng tác, liên tục thử nghiệm và cải tiến.

DevOps đóng vai trò quan trọng trong Software Development Life Cycle (SDLC) – Vòng đời phát triển sản phẩm phần mềm.

Ngoài việc hỗ trợ hoàn thiện quá trình chuyển đổi từ Waterfall sang Agile, nó còn giúp vận hành phần mềm chuyển sang phát triển liên tục.

Công việc của DevOps

Thông thường các công việc DevOps phụ trách xoay quanh những nội dung sau:

CI/CD (Continuous Integration/Continuous Deployment)

Bộ đôi công việc giúp tối ưu hóa thao tác test và build một phần mềm.

Quá trình tích hợp nhanh chóng hơn khi code cũng như thường xuyên cập nhập phiên bản mới.

Cùng xem video buổi chia sẻ về CI/CD trong chuỗi Technical Event của Gambaru:

Technical Event #03: CI/CD Practices & Monorepo

Xây dựng kiến trúc (Infrastructure as code)

IaC là một phần thiết yếu trong thực hành DevOps.

Các phiên bản cơ sở hạ tầng nhanh chóng được tạo ra và theo dõi, với mục đích tránh sự mâu thuẫn giữa các môi trường CNTT có thể gây ra các vấn đề nghiêm trọng trong quá trình triển khai.

Giao tiếp và cộng tác (Communication and collaboration)

Hai nhân tố then chốt góp phần xúc tiến việc phát triển diễn tra nhanh hơn, vận hành đạt hiệu quả hơn đồng thời cũng hỗ trợ cho các team khác cùng phát triển.

Yêu cầu đối với DevOps

Khả năng lập trình đem lại lợi thế cho công việc DevOpsKhả năng lập trình đem lại lợi thế cho công việc DevOps
Khả năng lập trình đem lại lợi thế cho công việc DevOps

Những yêu cầu để có thể đảm đương công việc DevOps:

  1. Về khía cạnh kỹ thuật, kỹ năng coding thật cứng là một trong những đòi hỏi đầu tiên. Có thể là bất cứ ngôn ngữ lập trình nào: Python, Ruby, Lua Scripting …
  2. Ngoài ra, thông thạo về hệ điều hành (Linux, Docker, …) cũng là một điểm mạnh. Không thể không kể đến những hiểu biết về các dịch vụ vận hành và hỗ trợ CNTT, xây dựng và phát hành (build and release), QA hoặc testing.
  3. Thêm vào đó, kỹ năng mềm cũng tạo điều kiện để DevOps có thể thực hiện tốt công việc của mình.
  4. Người làm công việc DevOps cần có kỹ năng nghiên cứu thật tốt để có thể nhanh chóng tìm ra cách giải quyết khi vấn đề phát sinh.
  5. Kèm theo đó, kỹ năng giao tiếp, phối hợp làm việc đội nhóm là không thể thiếu.
  6. Cẩn thận, tỉ mỉ và luôn đặt lợi ích tập thể lên hàng đầu là những tố chất gắn liền với công việc này.

Từ đó, chúng ta có thể nhìn nhận, DevOps không hẳn chỉ là một vị trí công việc.

Một team DevOps gồm những thành viên với kiến thức chuyên môn và kỹ năng đa dạng cùng nỗ lực phát triển không chỉ đem đến những sản phẩm chất lượng mà còn gia tăng sức cạnh tranh cho doanh nghiệp.

Tương lai của DevOps

Bạn có biết, công việc DevOps nhận được mức lương khá ấn tượng trong giới chuyên gia CNTT không?

Cũng dễ hiểu thôi! Nhu cầu DevOps tại các doanh nghiệp ngày càng tăng, và một phần nữa chính nhờ vào sự đa năng của người làm công việc này.

Không giới hạn bất kỳ công nghệ cụ thể nào, từ lập trình, xây dựng hạ tầng và cấu hình, đến thử nghiệm, xây dựng và phát hành.

DevOps liên tục tìm hiểu, làm việc để tích hợp và tự động hóa trên nhiều công nghệ khác nhau.

Định hướng tương lai của DevOps
DevOps đi cùng với thời đại tự động hóa Industry 4.0

Với sự phát triển không ngừng trong thời đại Công nghiệp 4.0, thời đại của tự động hóa, AI, IoT…, DevOps được dự đoán tiếp tục tồn tại mạnh mẽ.

Cho dù trong tương lai, sự xuất hiện của một số phương pháp mới hoặc công nghệ mới có khả năng làm lu mờ sự hiện diện của DevOps, nhưng tin chắc rằng với tư duy tìm tòi, học hỏi cùng với nền tảng kiến thức đa dạng, người làm DevOps sẽ luôn tìm được cho mình những vị trí vững chắc trong ngành CNTT.

Nguồn: Tổng hợp