Chapter 9: Factor IX — Disposability

Tăng độ bền của hệ thống bằng cách khởi động nhanh và tắt êm

  • Theo Twelve-Factor, process của ứng dụng phải có thể bị khởi động hoặc dừng gần như bất cứ lúc nào. Tài liệu gốc gọi đó là disposable. Mục tiêu là hỗ trợ scale đàn hồi nhanh, deploy code/config nhanh, và làm production bền hơn khi platform cần thay process.
  • Factor IX có 2 vế cốt lõi: fast startup và graceful shutdown. Process nên sẵn sàng nhận traffic hoặc job chỉ sau vài giây, và khi nhận SIGTERM thì phải ngừng nhận việc mới, hoàn tất việc đang làm dở một cách hợp lý, rồi thoát ra sạch sẽ.
  • Với web process, graceful shutdown nghĩa là ngừng lắng nghe port, để request đang xử lý chạy nốt, rồi thoát. Với worker process, graceful shutdown thường là đưa job hiện tại trả lại queue hoặc nhả lock đúng cách để worker khác xử lý tiếp.
  • Trong thực tế hiện đại, Heroku gửi SIGTERM rồi chờ tối đa 30 giây trước khi SIGKILL; Kubernetes cũng có cơ chế graceful termination với mặc định 30 giây, readiness probes, startup probes và hướng dẫn rõ về connection draining khi Pod bị terminate.

1) Mở bài: vì sao factor này rất “đời thực”?

Nhiều hệ thống chạy ổn trong ngày thường, nhưng cứ đến lúc deploy, scale up, scale down, restart process, hoặc node bị thay là bắt đầu xuất hiện lỗi lạ: request đang chạy bị rơi giữa chừng, worker đang xử lý job thì mất hút, upload dở bị lỗi, hoặc app mới lên quá chậm nên bị health check đá liên tục. Factor IX được sinh ra để xử lý đúng nhóm vấn đề đó: hãy thiết kế app để platform có thể thay process bất cứ lúc nào mà hệ thống vẫn khỏe.

2) Định nghĩa gốc của Factor IX

Tên chính thức của factor này là:

“Disposability — Maximize robustness with fast startup and graceful shutdown.”

Tài liệu gốc nói rất rõ: process của Twelve-Factor app là disposable, nghĩa là có thể được start hoặc stop ngay khi cần. Điều này giúp scale đàn hồi nhanh hơn, deploy code/config nhanh hơn, và tăng độ chắc của production deploys.

Diễn giải thật dễ hiểu cho junior:

App của bạn không nên cư xử như một cỗ máy “rất khó bật lên và rất khó tắt đi”. Nó nên giống một process có thể được thay thế nhanh, lên nhanh, xuống êm, và không làm hệ thống rối tung.

3) “Disposable” không có nghĩa là “vô trách nhiệm”

Đây là chỗ rất dễ hiểu sai. “Disposable” không có nghĩa là process muốn chết lúc nào cũng được mà không cần quan tâm hậu quả. Ngược lại, Twelve-Factor muốn process được thiết kế để việc bị thay thế là chuyện bình thường, nên app phải có startup nhanh, shutdown tử tế, và chịu được cả trường hợp chết đột ngột. Tài liệu gốc còn nói thẳng rằng ngoài graceful shutdown bằng SIGTERM, app cũng phải đủ robust trước những cái chết đột ngột do lỗi phần cứng hoặc sự cố hạ tầng.

Nói ngắn gọn:

  • Dễ thay không phải là cẩu thả.
  • Dễ restart không phải là không cần giữ đúng nghiệp vụ.
  • Disposable là một tiêu chuẩn thiết kế để hệ thống sống khỏe trong môi trường hiện đại.

4) Vế thứ nhất: khởi động nhanh

Twelve-Factor nói process nên cố gắng giảm tối đa startup time. Lý tưởng nhất, từ lúc chạy lệnh launch đến lúc process sẵn sàng nhận request hoặc job chỉ mất vài giây. Startup ngắn giúp release linh hoạt hơn, scale up nhanh hơn, và giúp process manager dễ dời process sang máy vật lý khác khi cần.

Đây là một ý cực kỳ thực chiến. Nếu app mất quá lâu để lên:

  • autoscaling phản ứng chậm,
  • deploy rolling chậm,
  • recovery sau crash chậm,
  • platform dễ nhầm rằng container “chết” trong khi thật ra chỉ đang khởi động chậm. Kubernetes vì vậy có startup probes để bảo vệ các container khởi động chậm, và chỉ bắt đầu liveness/readiness sau khi startup probe thành công.

5) Vế thứ hai: tắt êm

Twelve-Factor nói process phải shutdown gracefully khi nhận SIGTERM từ process manager. Với web process, graceful shutdown được mô tả rất cụ thể: ngừng lắng nghe trên service port để từ chối request mới, cho các request hiện tại chạy xong, rồi thoát. Tài liệu gốc cũng ngầm giả định rằng request HTTP nên ngắn, chỉ vài giây; còn nếu dùng long polling thì client nên tự reconnect mượt khi connection bị mất.

Với worker process, graceful shutdown là trả job hiện tại về queue hoặc nhả lock đúng cách. Tài liệu gốc nêu ví dụ RabbitMQ có thể NACK, Beanstalkd tự đưa job về queue khi worker disconnect, còn các hệ lock-based như Delayed Job phải đảm bảo release lock trên job record.

Nói dễ hiểu:

  • web process phải đóng cửa lịch sự,
  • worker process phải bàn giao việc lịch sự.

6) Ví dụ đời thường cực dễ hiểu

Hãy tưởng tượng app của bạn là một ca làm việc trong nhà hàng.

  • Fast startup giống như nhân viên mới vào ca là có thể bắt đầu nhận khách gần như ngay, không mất 20 phút loay hoay tìm sổ, tìm bút, tìm bàn.
  • Graceful shutdown giống như khi hết ca, nhân viên không bỏ đi ngang lúc đang cầm order. Họ ngừng nhận khách mới, bàn giao đơn đang xử lý, dọn nốt phần việc của mình, rồi mới rời đi.

Nếu một quán vận hành theo kiểu “nhân viên thích nghỉ ngang thì nghỉ”, hoặc “nhân viên mới vào mất nửa tiếng mới làm được việc”, quán đó rất khó scale và rất dễ loạn. Factor IX muốn process của bạn đừng vận hành như vậy. Ý này là diễn giải đời thường từ hai yêu cầu gốc: startup nhanh và shutdown êm.

7) Ví dụ xuyên suốt với ứng dụng mẫu TaskFlow

Ta tiếp tục dùng ứng dụng mẫu TaskFlow.

TaskFlow có:

  • web process để nhận HTTP request,
  • worker process để gửi email, tạo báo cáo, đồng bộ dữ liệu,
  • có thể thêm clock hoặc scheduler process cho việc định kỳ. Cách chia theo process type này nhất quán với Twelve-Factor.

Cách làm đúng

Khi TaskFlow khởi động:

  • app load config nhanh,
  • mở kết nối cần thiết vừa đủ,
  • bind port,
  • chỉ khi thật sự sẵn sàng mới nhận traffic hoặc job.

Khi TaskFlow nhận tín hiệu dừng:

  • web process ngừng nhận request mới,
  • request đang chạy được hoàn tất trong cửa sổ hợp lý,
  • worker process đánh dấu job hiện tại theo cách queue có thể tiếp tục xử lý,
  • rồi process thoát sạch. Tất cả các bước này đều đúng tinh thần gốc của Twelve-Factor và khớp với readiness/termination flow của Kubernetes.

Cách làm sai

  • App khởi động 1–2 phút vì làm quá nhiều việc nặng ở startup.
  • web process nhận SIGTERM nhưng vẫn nhận thêm request mới.
  • worker process chết giữa chừng mà job không được trả lại queue.
  • Khi Pod hoặc dyno bị thay, người dùng bị rớt request hàng loạt hoặc job “bốc hơi”.

Đó chính là kiểu hệ thống thiếu disposability mà Factor IX muốn ngăn.

8) Case thực tế đã được xác minh: Heroku shutdown behavior

Heroku là ví dụ rất rõ của disposability ngoài đời thật. Tài liệu chính thức nói khi dyno manager restart một dyno, nó gửi SIGTERM tới tất cả process trong dyno. Các process có 30 giây để shutdown sạch; sau thời gian đó, nếu vẫn còn process sống, dyno manager sẽ force kill bằng SIGKILL. Heroku còn khuyên process nên ngừng nhận request/job mới, hoàn tất phần đang xử lý, hoặc đưa job trở lại queue cho process khác.

Điều này gần như là bản diễn giải vận hành thực tế của Twelve-Factor:

  • shutdown được yêu cầu bằng SIGTERM,
  • nếu app làm đúng thì hệ thống thay process êm,
  • nếu app làm sai thì sẽ bị kill cứng.

9) Case thực tế đã được xác minh: Kubernetes và graceful termination

Kubernetes cũng phản ánh rất rõ tinh thần của Factor IX. Tài liệu chính thức về Pod lifecycle nói Pod được cấp một graceful termination period mặc định là 30 giây trước khi bị force terminate. Đồng thời, readiness probes được kubelet dùng để xác định khi nào container đã sẵn sàng nhận traffic; khi Pod không ready, nó bị loại khỏi Service load balancers. Startup probes giúp tránh việc container khởi động chậm bị liveness/readiness “đánh chết” quá sớm.

Kubernetes còn có hẳn một tutorial về termination flow và endpoint removal, nhấn mạnh việc active connection draining để giữ availability tốt hơn khi Pod bị terminate vì upgrade hoặc scale down. Đây là một ví dụ hiện đại rất sát với ý “cease listening, finish current work, then exit” của Twelve-Factor.

10) Chết đột ngột vẫn phải chịu được

Đây là chỗ làm Twelve-Factor rất thực tế. Tài liệu gốc nói graceful shutdown bằng SIGTERM là trường hợp thường gặp hơn, nhưng app vẫn phải chịu được sudden death do lỗi phần cứng hoặc hạ tầng. Một hướng khuyến nghị là dùng queue backend đủ robust để job quay lại queue khi client disconnect hoặc timeout. Nói cách khác, app tốt không chỉ biết “tắt đẹp”, mà còn phải không sụp logic khi không kịp tắt đẹp.

Điều này nối thẳng với các factor trước:

  • Factor VI: process stateless nên dễ thay hơn.
  • Factor VIII: process model giúp scale và restart độc lập hơn.
  • Factor IX: disposability biến việc process bị thay trở thành chuyện bình thường.

11) Junior thường hiểu sai ở đâu?

Hiểu sai 1: “Disposability là tối ưu phụ thôi”

Không. Tài liệu gốc nói rất rõ nó giúp fast elastic scaling, rapid deploy và robustness của production deploys. Đây là năng lực vận hành cốt lõi, không phải đồ trang trí.

Hiểu sai 2: “Chỉ cần xử lý SIGTERM là xong”

Chưa đủ. Twelve-Factor còn yêu cầu app đủ robust trước cả non-graceful termination. Nếu process chết cứng mà job mất luôn, hệ thống vẫn chưa đạt tinh thần của factor này.

Hiểu sai 3: “Startup chậm không sao, miễn là chạy ổn”

Không đúng trong môi trường autoscaling, rolling deploy, self-healing. Tài liệu gốc muốn startup chỉ vài giây; Kubernetes cũng có startup probe chính vì startup behavior ảnh hưởng trực tiếp tới availability.

Hiểu sai 4: “Shutdown là chuyện của platform, app không cần quan tâm”

Platform chỉ gửi tín hiệu và cho grace period. App mới là thứ phải biết ngừng nhận việc mới, hoàn tất việc đang làm, trả job về queue, flush trạng thái cần thiết và thoát đúng cách. Heroku và Twelve-Factor đều nói rất rõ điều này.

12) Làm sai thì hậu quả gì?

  • Deploy dễ làm rơi request, vì app bị terminate trong lúc vẫn nhận traffic. Twelve-Factor yêu cầu web process ngừng lắng nghe port trước khi thoát; Kubernetes cũng nhấn mạnh readiness và connection draining để tránh đúng tình huống này.
  • Job bị mất hoặc chạy trùng, vì worker không bàn giao đúng khi shutdown hoặc sudden death. Twelve-Factor khuyên dùng queue backend đủ robust để job quay lại queue khi cần.
  • Autoscaling kém hiệu quả, vì app lên quá chậm nên platform mở thêm instance nhưng không phục vụ được sớm. Startup time ngắn là một lợi ích được Twelve-Factor nêu trực tiếp.
  • Khó vận hành trên platform hiện đại, vì cả Heroku lẫn Kubernetes đều giả định process/container/Pod có thể bị stop hoặc replace như một việc rất bình thường.

13) Áp dụng đúng trong team như thế nào?

Bước 1: Rà startup path

Hãy hỏi:

  • App đang làm gì trong startup?
  • Cái gì bắt buộc?
  • Cái gì có thể lùi sang background hoặc lazy load?

Twelve-Factor muốn process lên nhanh, lý tưởng là chỉ vài giây. Kubernetes startup probes cũng đặc biệt hữu ích nếu app có startup path phức tạp nhưng vẫn cần được bảo vệ khỏi restart quá sớm.

Bước 2: Xử lý tín hiệu dừng rõ ràng

App cần biết khi nhận SIGTERM thì phải làm gì:

  • web: dừng nhận request mới,
  • worker: dừng lấy job mới và bàn giao job đang chạy đúng cách,
  • mọi process: đóng kết nối, flush phần cần thiết, rồi thoát. Đây là mô hình gốc của Twelve-Factor và cũng là cách Heroku mong đợi app cư xử.

Bước 3: Thiết kế job processing đủ an toàn

Nếu worker có thể chết giữa chừng, queue backend hoặc job design phải chịu được chuyện đó. Twelve-Factor khuyến nghị queue đủ robust; về mặt thực hành, điều này thường kéo theo yêu cầu idempotency hoặc retry-safe behavior cho job. Phần idempotency là suy luận kỹ thuật từ nguyên lý sudden-death robustness.

Bước 4: Nối shutdown với traffic draining

Trong môi trường orchestration, đừng chỉ nghĩ “nhận SIGTERM rồi exit”. Bạn còn cần đảm bảo traffic mới không tiếp tục đổ vào process đang chuẩn bị tắt. Kubernetes readiness probes và tutorial về endpoint termination flow cho thấy đây là phần rất quan trọng của graceful shutdown.

Bước 5: Đừng biến startup thành nơi làm mọi thứ

Compile assets, chạy migration nặng, warming khối lượng lớn, hay sync dài hơi thường không nên bị nhét hết vào startup path của process web. Twelve-Factor muốn startup ngắn; phần việc nặng nên được đặt đúng stage hoặc đúng process type hơn. Đây là suy luận thực hành phù hợp với Build/Release/Run và Disposability.

14) Diễn giải trong bối cảnh hiện đại

Trong bối cảnh cloud-native, disposability gần như là một “ngôn ngữ chung” giữa app và platform. Platform muốn:

  • spin up instance mới nhanh,
  • cắt instance cũ êm,
  • thay node, scale down, rolling update mà ít ảnh hưởng người dùng.

Twelve-Factor từ sớm đã mô tả đúng tinh thần đó qua fast startup và graceful shutdown. Kubernetes hiện thực hóa bằng readiness, startup probes, grace period và termination flow; Heroku hiện thực hóa bằng SIGTERM, grace window và restart/replace dynos. Đây là các cách hiện đại hóa nguyên lý gốc, chứ không thay thế nội dung gốc của factor.

15) Checklist tự đánh giá

Hãy tự hỏi về ứng dụng của bạn:

  • Process của tôi có lên đủ nhanh để phục vụ scale hoặc restart không?
  • Khi nhận SIGTERM, app có thật sự ngừng nhận việc mới và thoát êm không?
  • Worker của tôi có trả job lại queue hoặc nhả lock đúng cách không?
  • Nếu process chết đột ngột, hệ thống có còn đúng không? Đây là câu hỏi thực hành bám thẳng vào yêu cầu “robust against sudden death”.
  • Nếu đang chạy trên Kubernetes, readiness/startup probes và termination flow của tôi có đang cấu hình hợp lý không?

Nếu bạn thấy 2–3 câu ở trên chưa trả lời chắc được, Factor IX của app đó đang cần chỉnh mạnh.

16) Tóm tắt nhanh

  • Disposability nghĩa là process có thể bị start/stop rất nhanh và rất thường xuyên mà hệ thống vẫn ổn.
  • Có hai yêu cầu lớn: startup nhanh và shutdown êm.
  • Web process cần ngừng nhận request mới rồi thoát; worker process cần bàn giao job đúng cách.
  • App cũng phải chịu được sudden death, không chỉ mỗi graceful shutdown.
  • Heroku và Kubernetes đều vận hành theo đúng giả định rằng process/container/Pod có thể bị thay rất thường xuyên.

17) Nguồn tham khảo