Mở đầu câu chuyện

Mọi thứ bắt đầu khi tôi được giao một task yêu cầu phải migrate tất cả function lambda của hệ thống từ Python 3.8 lên một phiên bản mới hơn do Python 3.8 sẽ kết thúc vòng đời (EOL) vào 10/2024. Sau một hồi cân nhắc thì tôi quyết định update lên 3.10. Mọi người có thể hỏi vì sao không update thằng lên 3.11+, câu trả lời đơn giản là vì nhiều thư viện Python hiện tại chưa support các bản mới như vậy, điển hình là PyTorch. Hơn nữa, các phiên bản mới có nhiều tính năng mới không dùng và có thể gây ra bug tiềm tàng. Dùng bản cũ ít tính năng thì sẽ bớt entropy để gây ra lỗi.

Đặt vấn đề

Sau một thời gian dài, rất dài làm việc với AWS, Azure, Oracle Cloud, tôi chợt nhận ra tất cả những nhà cung cấp trên có một đặc điểm chung như sau:

• Khá rẻ khi đang dev
• Giá tăng theo cấp số nhân khi bắt đầu có khách sử dụng, do thiết kế phải sử dụng rất nhiều các dịch vụ built in của nền tảng
• Vẫn còn gồng được được khi bắt đầu serve lượng nhỏ người dùng nhưng khi phải gánh một hệ thống khủng để gánh một lượng lớn khách thì giá sẽ cao vọt lên.

Với một người có kinh tế eo hẹp, không được funding vốn từ bất kì đối tượng nào mà phải tự gồng gánh từ hạ tầng đến lương nhân viên, thì việc vỡ nợ trước khi sản phẩm ra tiền là viễn cảnh không hề xa.

Đặt vấn đề

Một trong những việc quan trọng nhất khi lưu dữ liệu xuống bất kì đâu chính là đặt cho chúng một cái tên. Theo tôi một cách đặt tên được gọi là tốt cần phải thoả mãn các điều kiện sau:

1. Đảm bảo tính độc lập và duy nhất. Nhập nhằng về tên sẽ khiến việc truy xuất dữ liệu khó hơn rất nhiều
2. Kích thước không quá lớn vì tên quá lớn khi lưu vào, tìm kiếm và lấy ra sẽ mất nhiều thời gian
3. Cách đặt tên đơn giản. Quy tắc đặt tên quá phức tạp khi gặp lỗi sẽ rất khó sửa, cũng như khó bảo trì

Nhưng để một cách đặt tên được gọi là tốt để làm UID trong CSDL nên có thêm các yếu tố sau:

Mở đầu

Một trong những xu hướng mà tôi được tiếp cận khi sang làm DevOps ở một division trong Caterpillar chính là công nghệ Serverless. Project đầu tiên mà tôi nhận được chính là migrate hệ thống từ sử dụng server vật lý cổ điển lên sử dụng AWS Lambda. Đây là một trải nghiệm vô cùng thú vị khi tôi có cơ hội rất tốt để có thêm một mindset mới để thiết kế một hệ thống dựa hoàn toàn vào một nhà cung cấp hạ tầng và không phải lo lắng về những lỗi về server cổ điển như trước. Tất nhiên, không có bữa trưa nào là miễn phí, việc chuyển giao không chỉ đơn giản là port các method trong code cũ thành các function và cứ thế mà nó chạy, tôi đã tốn khá nhiều thời gian để re-engineer lại hệ thống để đảm bảo chi phí tiết kiệm và tốc độ được cải thiện. Dưới đây là một vài kinh nghiệm tôi thu thập được trong quá trình chuyển giao.

Đặt vấn đề

Một trong những thiếu sót khi sử dụng k8s trong môi trường production là không thiết đặt giới hạn tài nguyên cho hệ thống. Khi bạn không giới hạn tài nguyên cho các pod trong k8s, không sớm thì muộn sẽ có một thời điểm server của bạn sẽ hết sạch tài nguyên (điển hình là hết CPU và RAM). Việc này rất dễ xảy ra chạy các workload nặng trên nhiều node có cấu hình khác nhau. Cuối cùng server của bạn sẽ crash, hoặc là chạy rất chậm, khiến hệ thống trở nên kém ổn định, thậm chí là mất mát dữ liệu, gây tổn thất về uy tín và tiền bạc. Vậy một trong những việc đầu tiên khi một đưa bất kì thứ gì lên k8s là phải thiết đặt tài nguyên cho nó.