Tweet
DevSecOps (Phần 10): Stateless Processes – Vì sao ứng dụng Cloud Native không được "nhớ" dữ liệu trong RAM?
Một người dùng đăng nhập vào website.
Lần đầu, yêu cầu được xử lý bởi Server A.
Lần tiếp theo, Load Balancer chuyển yêu cầu sang Server B.
Nếu Server B không biết người dùng vừa đăng nhập, phiên làm việc (Session) sẽ bị mất.
Đây là vấn đề rất phổ biến ở các ứng dụng truyền thống và cũng là lý do Yếu tố thứ 6 của 12-Factor App yêu cầu:
Hay nói cách khác:
Stateless Process là gì?
Một ứng dụng khi chạy sẽ tạo ra một hoặc nhiều Process.
Ví dụ đơn giản với Python:
python app.py
Có thể chỉ tạo một process.
Nhưng với các hệ thống Web hiện đại như Nginx, Gunicorn hay Kubernetes, một ứng dụng thường chạy nhiều process hoặc nhiều container đồng thời để phục vụ hàng nghìn người dùng.
Vì vậy, bạn không thể giả định rằng hai yêu cầu liên tiếp sẽ luôn được xử lý bởi cùng một process.
Vì sao không được lưu trạng thái trong RAM?
Giả sử ứng dụng lưu Session của người dùng trực tiếp trong bộ nhớ:
Process A
├── User A Session
├── User B Session
└── Cache
Mọi thứ có vẻ ổn...
Cho đến khi:
Khi đó toàn bộ dữ liệu trong RAM sẽ biến mất.
Ứng dụng không được phép giả định rằng dữ liệu vẫn còn tồn tại sau mỗi request.
Đây chính là ý nghĩa của Stateless.
Hệ điều hành có thể dừng Process bất cứ lúc nào
Một Process không tồn tại mãi mãi.
Hệ điều hành hoặc nền tảng Cloud có thể:
Điều này hoàn toàn bình thường trong các hệ thống hiện đại.
Do đó, ứng dụng phải được thiết kế sao cho mỗi request đều có thể được xử lý độc lập, kể cả khi nó được chuyển đến một process hoàn toàn mới.
RAM chỉ nên là bộ nhớ tạm
12-Factor App không cấm sử dụng RAM.
RAM vẫn có thể được dùng làm:
Ví dụ:
API Request
│
▼
Đọc dữ liệu từ Database
│
▼
Xử lý trong RAM
│
▼
Lưu kết quả xuống Database
│
▼
Giải phóng bộ nhớ
Sau khi request hoàn thành, ứng dụng không được giả định rằng dữ liệu đó vẫn còn trong RAM hoặc trên đĩa cục bộ.
Nếu cần chia sẻ dữ liệu thì sao?
Nếu nhiều Process cần cùng sử dụng một trạng thái hoặc dữ liệu, 12-Factor App khuyến nghị sử dụng Backing Services thay vì bộ nhớ cục bộ.
Một số lựa chọn phổ biến:
Ví dụ:
Application A
│
├────────────┐
│ │
Application B │
│ │
└──────┬─────┘
▼
Redis
Dù request được xử lý bởi Process A hay Process B, cả hai đều truy cập cùng một dữ liệu trong Redis. Điều này giúp ứng dụng hoạt động nhất quán ngay cả khi có nhiều instance chạy song song.
Session trong RAM là một sai lầm phổ biến
Một lỗi thường gặp ở các ứng dụng web truyền thống là lưu Session trực tiếp trong bộ nhớ của ứng dụng.
Browser
│
▼
Server A
│
Session in RAM
Nếu yêu cầu tiếp theo được chuyển sang:
Browser
│
▼
Server B
Server B sẽ không có Session của người dùng.
Kết quả:
Đây là lý do các hệ thống hiện đại thường lưu Session trong Redis hoặc Memcached, để mọi process đều có thể truy cập cùng một trạng thái.
Stateless là nền tảng của Kubernetes và Cloud Native
Kiến trúc Stateless mang lại nhiều lợi ích quan trọng:
Đó cũng là lý do phần lớn các ứng dụng Cloud Native hiện nay đều được thiết kế theo mô hình Stateless.
DevSecOps và Stateless
Stateless không chỉ là một nguyên tắc thiết kế, mà còn là nền tảng để xây dựng các hệ thống có khả năng mở rộng và tự phục hồi.
Khi ứng dụng không phụ thuộc vào dữ liệu trong RAM hay bộ nhớ cục bộ, doanh nghiệp có thể:
Đây là một trong những nguyên tắc quan trọng giúp các nền tảng như Docker, Kubernetes và các dịch vụ Cloud vận hành hàng nghìn ứng dụng với tính sẵn sàng và khả năng mở rộng rất cao.
Một người dùng đăng nhập vào website.
Lần đầu, yêu cầu được xử lý bởi Server A.
Lần tiếp theo, Load Balancer chuyển yêu cầu sang Server B.
Nếu Server B không biết người dùng vừa đăng nhập, phiên làm việc (Session) sẽ bị mất.
Đây là vấn đề rất phổ biến ở các ứng dụng truyền thống và cũng là lý do Yếu tố thứ 6 của 12-Factor App yêu cầu:
Processes must be stateless.
Hay nói cách khác:
Mỗi tiến trình phải hoạt động độc lập và không được phụ thuộc vào dữ liệu còn lưu trong bộ nhớ của chính nó.
Stateless Process là gì?
Một ứng dụng khi chạy sẽ tạo ra một hoặc nhiều Process.
Ví dụ đơn giản với Python:
python app.py
Có thể chỉ tạo một process.
Nhưng với các hệ thống Web hiện đại như Nginx, Gunicorn hay Kubernetes, một ứng dụng thường chạy nhiều process hoặc nhiều container đồng thời để phục vụ hàng nghìn người dùng.
Vì vậy, bạn không thể giả định rằng hai yêu cầu liên tiếp sẽ luôn được xử lý bởi cùng một process.
Vì sao không được lưu trạng thái trong RAM?
Giả sử ứng dụng lưu Session của người dùng trực tiếp trong bộ nhớ:
Process A
├── User A Session
├── User B Session
└── Cache
Mọi thứ có vẻ ổn...
Cho đến khi:
- Process bị restart.
- Container bị thay thế.
- Kubernetes chuyển Pod sang Node khác.
- Auto Scaling tạo thêm instance mới.
Khi đó toàn bộ dữ liệu trong RAM sẽ biến mất.
Ứng dụng không được phép giả định rằng dữ liệu vẫn còn tồn tại sau mỗi request.
Đây chính là ý nghĩa của Stateless.
Hệ điều hành có thể dừng Process bất cứ lúc nào
Một Process không tồn tại mãi mãi.
Hệ điều hành hoặc nền tảng Cloud có thể:
- Restart Process.
- Kill Process.
- Scale Out.
- Scale In.
- Chuyển Container sang máy chủ khác.
Điều này hoàn toàn bình thường trong các hệ thống hiện đại.
Do đó, ứng dụng phải được thiết kế sao cho mỗi request đều có thể được xử lý độc lập, kể cả khi nó được chuyển đến một process hoàn toàn mới.
RAM chỉ nên là bộ nhớ tạm
12-Factor App không cấm sử dụng RAM.
RAM vẫn có thể được dùng làm:
- Cache tạm thời.
- Buffer.
- Dữ liệu trung gian trong quá trình xử lý.
Ví dụ:
API Request
│
▼
Đọc dữ liệu từ Database
│
▼
Xử lý trong RAM
│
▼
Lưu kết quả xuống Database
│
▼
Giải phóng bộ nhớ
Sau khi request hoàn thành, ứng dụng không được giả định rằng dữ liệu đó vẫn còn trong RAM hoặc trên đĩa cục bộ.
Nếu cần chia sẻ dữ liệu thì sao?
Nếu nhiều Process cần cùng sử dụng một trạng thái hoặc dữ liệu, 12-Factor App khuyến nghị sử dụng Backing Services thay vì bộ nhớ cục bộ.
Một số lựa chọn phổ biến:
- Redis
- Memcached
- Database
- Distributed Cache
Ví dụ:
Application A
│
├────────────┐
│ │
Application B │
│ │
└──────┬─────┘
▼
Redis
Dù request được xử lý bởi Process A hay Process B, cả hai đều truy cập cùng một dữ liệu trong Redis. Điều này giúp ứng dụng hoạt động nhất quán ngay cả khi có nhiều instance chạy song song.
Session trong RAM là một sai lầm phổ biến
Một lỗi thường gặp ở các ứng dụng web truyền thống là lưu Session trực tiếp trong bộ nhớ của ứng dụng.
Browser
│
▼
Server A
│
Session in RAM
Nếu yêu cầu tiếp theo được chuyển sang:
Browser
│
▼
Server B
Server B sẽ không có Session của người dùng.
Kết quả:
- Người dùng bị đăng xuất.
- Phiên làm việc bị mất.
- Ứng dụng hoạt động không ổn định khi triển khai nhiều máy chủ.
Đây là lý do các hệ thống hiện đại thường lưu Session trong Redis hoặc Memcached, để mọi process đều có thể truy cập cùng một trạng thái.
Stateless là nền tảng của Kubernetes và Cloud Native
Kiến trúc Stateless mang lại nhiều lợi ích quan trọng:
- Dễ mở rộng bằng cách thêm nhiều Pod hoặc Container.
- Thay thế instance bị lỗi mà không ảnh hưởng đến người dùng.
- Hỗ trợ Auto Scaling hiệu quả.
- Tăng khả năng chịu lỗi khi một process hoặc máy chủ gặp sự cố.
- Giúp Load Balancer phân phối yêu cầu đến bất kỳ instance nào mà không cần quan tâm đến trạng thái trước đó.
Đó cũng là lý do phần lớn các ứng dụng Cloud Native hiện nay đều được thiết kế theo mô hình Stateless.
DevSecOps và Stateless
Stateless không chỉ là một nguyên tắc thiết kế, mà còn là nền tảng để xây dựng các hệ thống có khả năng mở rộng và tự phục hồi.
Khi ứng dụng không phụ thuộc vào dữ liệu trong RAM hay bộ nhớ cục bộ, doanh nghiệp có thể:
- Triển khai nhiều instance cùng lúc.
- Tự động thay thế các instance gặp lỗi.
- Mở rộng hoặc thu hẹp tài nguyên theo nhu cầu mà không làm gián đoạn dịch vụ.
- Kết hợp hiệu quả với CI/CD Pipeline và hạ tầng Cloud Native.
Đây là một trong những nguyên tắc quan trọng giúp các nền tảng như Docker, Kubernetes và các dịch vụ Cloud vận hành hàng nghìn ứng dụng với tính sẵn sàng và khả năng mở rộng rất cao.
Attached Files