Kiến trúc Cloud Native (điện toán đám mây gốc)

1. Tổng quan

Định nghĩa: Cloud Native không phải là việc sử dụng một sản phẩm đám mây cụ thể, mà là cách tiếp cận thiết kế ứng dụng và phương thức vận hành bằng cách kết hợp container, microservices, API khai báo, tự động hóa, khả năng quan sát (observability) và tính đàn hồi để ứng phó với thay đổi một cách nhanh chóng và có thể lặp lại.

Cốt lõi của Cloud Native nằm ở việc phân biệt giữa đưa ứng dụng lên đám mây và thiết kế ứng dụng theo phương thức Cloud Native. Lift and shift — đóng gói hệ thống hiện có thành image máy ảo rồi chuyển lên đám mây công cộng — là sử dụng đám mây, nhưng chỉ riêng điều đó chưa làm cho hệ thống trở thành Cloud Native. Cloud Native coi các tình huống sự cố xảy ra, nhu cầu biến động và mã nguồn thay đổi thường xuyên là điều kiện vận hành bình thường, và thay đổi cấu trúc lẫn quy trình để hệ thống tự phục hồi và tự mở rộng trong các điều kiện đó.

Các ứng dụng truyền thống thường được thiết kế xoay quanh một máy chủ và một đơn vị triển khai. Trong cấu trúc này, phạm vi kiểm thử hồi quy trước triển khai trở nên lớn, và ngay cả khi thay đổi một phần chức năng cũng phải dừng toàn bộ hệ thống hoặc dành ra một cửa sổ phát hành lớn. Ngoài ra, nếu trạng thái máy chủ còn lưu trên đĩa cục bộ và bộ nhớ thì việc khôi phục sự cố hay mở rộng theo chiều ngang trở nên khó khăn, và người vận hành phải trực tiếp quản lý trạng thái của từng máy chủ.

Để giảm sự ràng buộc này, Cloud Native chia ứng dụng thành các đơn vị thay đổi nhỏ và ngoại hóa trạng thái cũng như môi trường thực thi ở mức tối đa có thể. Container image di chuyển cùng một đơn vị thực thi qua các môi trường phát triển, kiểm thử và vận hành, còn bộ điều phối (orchestrator) liên tục điều chỉnh chênh lệch giữa trạng thái mong muốn và trạng thái thực tế. Pipeline tự động hóa quy trình build và kiểm chứng mã nguồn, còn khả năng quan sát cung cấp tín hiệu để người vận hành phán đoán dịch vụ có bình thường hay không và sự cố bắt đầu từ đâu.

Tuy nhiên, chỉ tạo thật nhiều microservice hay cài đặt Kubernetes thì không thể đạt được mục tiêu. Nếu ranh giới dịch vụ sai, các lời gọi mạng và giao dịch phân tán sẽ tăng lên, chi phí điều phối giữa các nhóm và độ khó gỡ lỗi cũng tăng theo. Nếu tự động hóa thiếu chính xác, triển khai nhanh có thể biến thành lan truyền sự cố nhanh, và tính đàn hồi của tài nguyên đám mây có thể dẫn đến bùng nổ chi phí. Vì vậy, trong bài làm của Kỹ sư chuyên nghiệp (Professional Engineer), thay vì liệt kê các yếu tố công nghệ, cần giải thích mối quan hệ nhân quả giữa các mục tiêu — khả năng ứng phó thay đổi, khả năng phục hồi, tự động hóa vận hành, bảo mật, chi phí — và các lựa chọn thiết kế.

1.1 Bối cảnh xuất hiện và sự cần thiết

Thứ nhất, tốc độ thay đổi của các dịch vụ số đã tăng nhanh. Các dịch vụ di động và trực tuyến phải cung cấp cải tiến chức năng và thay đổi chính sách theo chu kỳ ngắn, và chỉ với triển khai hàng loạt quy mô lớn thì khó theo kịp tốc độ cạnh tranh cũng như phản hồi của người dùng. Để triển khai thường xuyên các thay đổi nhỏ, cần một luồng chuyển giao tự động kết nối kho mã nguồn, build, kiểm thử, triển khai và rollback.

Thứ hai, tính biến động của nhu cầu và sự cố ngày càng lớn. Với các dịch vụ có yêu cầu tăng đột biến vào khung giờ nhất định như sự kiện mua sắm hay tiếp nhận hồ sơ công, nếu cố định máy chủ theo tải trung bình thì chi phí nhàn rỗi lớn, còn nếu theo tải đỉnh thì chi phí thường ngày lớn. Tổ hợp như mở rộng ngang các thành phần phi trạng thái, đệm dựa trên hàng đợi, auto scaling và cache có thể hấp thụ biến động, nhưng không tự động giải quyết được nút thắt ở cơ sở dữ liệu và các liên kết bên ngoài.

Thứ ba, tổ chức ngày càng phân tán và nền tảng ngày càng phức tạp. Khi các nhóm phát triển, vận hành, bảo mật và dữ liệu hoạt động riêng rẽ, việc bàn giao và chờ phê duyệt trở thành nút thắt. Nếu các nhóm sản phẩm sử dụng nền tảng chung theo hình thức tự phục vụ và áp dụng chính sách dưới dạng mã (policy as code), có thể nâng cao tính tự chủ của nhóm mà vẫn duy trì kiểm soát cơ bản của tổ chức.

1.2 Mục tiêu và phạm vi áp dụng

Mục tiêu đầu tiên của thiết kế Cloud Native là khả năng thay đổi (changeability). Phải có thể sửa đổi chức năng theo đơn vị nhỏ và triển khai độc lập, và thất bại khi thay đổi không được lan rộng thành gián đoạn toàn bộ dịch vụ. Để làm được điều này, cần xác định đồng thời đơn vị triển khai, quyền sở hữu dữ liệu, hợp đồng API, khả năng tương thích phiên bản và ranh giới rollback.

Mục tiêu thứ hai là tính đàn hồi (elasticity). Tính đàn hồi không đơn thuần là chức năng tăng số lượng máy chủ, mà là năng lực điều chỉnh tài nguyên theo tải và thu hồi khi tải biến mất. Để áp dụng mở rộng ngang, các instance không được phụ thuộc vào trạng thái cục bộ, và phải tách session, tệp tin, hàng đợi công việc ra kho lưu trữ bên ngoài hoặc dịch vụ chuyên dụng.

Mục tiêu thứ ba là khả năng phục hồi (resilience). Khả năng phục hồi không có nghĩa là hoàn toàn không xảy ra sự cố, mà là năng lực cô lập sự cố cục bộ, duy trì dịch vụ với chức năng hạn chế và khôi phục trong thời gian đã định. Timeout, retry, circuit breaker, bulkhead và nhiều vùng sẵn sàng (availability zone) xử lý các chế độ lỗi khác nhau, nên cần phân biệt mục đích khi áp dụng.

Mục tiêu thứ tư là khả năng quan sát và tự động hóa vận hành. Metric, log và trace phải giải thích được trạng thái của dịch vụ và hạ tầng, và các thay đổi triển khai lẫn chính sách phải được lưu lại dưới dạng mã có thể tái lập. Không có dữ liệu quan sát thì khó kiểm chứng kết quả của tự động hóa, còn không có tự động hóa thì con người phải xử lý từng tín hiệu quan sát, nên hai yếu tố này được thiết kế cùng nhau.

2. Cấu trúc tổng thể và nguyên lý cốt lõi của Cloud Native

Cloud Native là một mô hình vận hành kết hợp ứng dụng, nền tảng, hạ tầng và quy trình tổ chức. Lớp ứng dụng cung cấp chức năng nghiệp vụ và API, còn lớp nền tảng cung cấp triển khai, khám phá dịch vụ, quản lý bí mật, quan sát và chính sách như các chức năng dùng chung. Lớp hạ tầng trừu tượng hóa tài nguyên tính toán, mạng và lưu trữ, còn lớp quản trị xác định ranh giới về bảo mật, chi phí và tuân thủ quy định.

flowchart TB
    U[Người dùng·Đối tác·Thiết bị] --> G[API Gateway / Ingress]
    G --> S1[Dịch vụ A]
    G --> S2[Dịch vụ B]
    S1 --> DB1[(Kho dữ liệu dịch vụ A)]
    S2 --> DB2[(Kho dữ liệu dịch vụ B)]
    S1 --> Q[Message broker]
    Q --> S2
    S1 --> O[Lớp thu thập quan sát]
    S2 --> O
    O --> M[Backend metric·log·trace]
    P[CI/CD·GitOps] --> K[Bộ điều phối container]
    K --> S1
    K --> S2
    K --> R[Registry·Chính sách·Quản lý bí mật]
    R --> K

Trong cấu trúc này, API Gateway sắp xếp ranh giới bên ngoài nhưng không được trở thành nút thắt trung tâm gom mọi quy tắc nghiệp vụ về một chỗ. Mỗi dịch vụ có trách nhiệm và quyền sở hữu dữ liệu riêng, và giao tiếp với các dịch vụ khác qua giao diện đã được thỏa thuận. Bộ điều phối vừa là công cụ chạy container, vừa là vòng lặp điều khiển phản ánh số bản sao, chính sách mạng và phiên bản triển khai đã khai báo vào môi trường thực tế.

2.1 Hạ tầng bất biến và quản lý khai báo

Hạ tầng bất biến (immutable infrastructure) là nguyên lý: thay vì sửa dần máy chủ đang vận hành bằng lệnh của quản trị viên, ta định nghĩa cấu hình mong muốn bằng mã và image, rồi khi thay đổi thì tạo đơn vị thực thi mới để thay thế. Cách này giảm trạng thái ẩn kiểu “máy chủ hiện tại đã trải qua những thay đổi thủ công nào” và thu hẹp khác biệt giữa các môi trường. Đặc biệt khi xảy ra sự cố, tái tạo instance mới với cùng image và cấu hình dễ tự động hóa quy trình khôi phục hơn là sửa máy chủ hiện tại.

Quản lý khai báo là cách mô tả trạng thái mong muốn và giao cho hệ thống tự đạt tới trạng thái đó. Nếu script thủ tục chỉ định “trước tiên lệnh này, sau đó lệnh kia”, thì định nghĩa khai báo diễn đạt “phải tồn tại 10 pod và chính sách này”. Controller quan sát trạng thái thực tế để tạo tài nguyên còn thiếu, giảm tài nguyên thừa và phản ánh lại định nghĩa đã thay đổi.

Định nghĩa khai báo cũng không phải lúc nào cũng an toàn. Nếu khai báo sai tag image hoặc số bản sao quá lớn, bộ điều chỉnh tự động có thể khuếch đại lỗi rất nhanh. Vì vậy cần đưa phê duyệt thay đổi, kiểm chứng chính sách, phân tích tĩnh, triển khai dần dần và rollback tự động vào pipeline để phân biệt “tự động” với “không kiểm soát”.

2.2 Container và image

Container là công nghệ đóng gói ứng dụng và các phụ thuộc thành image, chạy như tiến trình được cô lập trong khi dùng chung kernel của hệ điều hành máy chủ. Nói chung nó cung cấp đơn vị thực thi nhẹ hơn máy ảo, nhưng việc dùng chung kernel không đồng nghĩa với bảo mật hoàn toàn. Cần kiểm soát riêng các thư viện có lỗ hổng trong image, quyền hạn quá mức, việc mount đường dẫn của máy chủ và việc chứa thông tin bí mật.

Image được xử lý như artifact bất biến, liên kết với commit mã nguồn, công cụ build, phụ thuộc, chữ ký và kết quả quét lỗ hổng. Nếu cài gói thủ công vào container đang chạy trong môi trường vận hành, tính tái lập bị phá vỡ và thay đổi có thể biến mất ở lần triển khai kế tiếp. Cách làm đúng là sửa đổi trong Dockerfile, cấu hình build, kho cấu hình, rồi thăng cấp (promote) digest của image đã được kiểm chứng.

Tối ưu image không đơn thuần là vấn đề giảm kích thước. Image nhỏ có ưu điểm giảm bề mặt tấn công và thời gian truyền, nhưng nếu loại bỏ hết công cụ gỡ lỗi thì khả năng phân tích sự cố có thể giảm. Cần tách quyền sử dụng giữa image vận hành và công cụ chẩn đoán tạm thời, đồng thời kết hợp người dùng thực thi tối thiểu, hệ thống tệp chỉ đọc và hạn chế system call.

2.3 Điều phối (orchestration) và nền tảng

Bộ điều phối bố trí container lên các node và xử lý theo cách chung các việc như khám phá dịch vụ, health check, rolling update, chèn secret và giới hạn tài nguyên. Người vận hành không tạo quy trình truy cập máy chủ cho từng ứng dụng, mà quản lý triển khai và trạng thái qua API và tệp khai báo của nền tảng. Sự trừu tượng hóa này nâng cao năng suất, nhưng nếu không hiểu hành vi thực tế của mạng, lưu trữ và lập lịch thì có thể bỏ sót nguyên nhân sự cố.

Yêu cầu tài nguyên (request) và giới hạn (limit) là cơ sở cho lập lịch và độ ổn định. Đặt request quá thấp thì node bị bố trí quá tải, đặt limit quá thấp thì tiến trình có thể bị kết thúc ở mức đỉnh bình thường. Ngược lại, nếu đặt limit quá cao thì lượng tài nguyên đặt trước tăng lên bất kể mức sử dụng thực tế, ảnh hưởng đến việc bố trí và chi phí của các dịch vụ khác. Cần đo tải cơ sở và mức sử dụng p95·p99 của từng dịch vụ để điều chỉnh các giá trị này định kỳ.

Health check cần phân biệt liveness — kiểm tra tiến trình còn sống hay không — và readiness — kiểm tra đã sẵn sàng nhận yêu cầu hay chưa. Thất bại readiness có nghĩa là tạm thời loại khỏi luồng lưu lượng, còn thất bại liveness có thể gây khởi động lại, nên không được đặt hai kiểm tra với cùng điều kiện. Với dịch vụ khởi tạo lâu, cần đặt kiểm tra startup để tiến trình đang khởi động không bị khởi động lại sớm.

2.4 Vòng lặp chuyển giao Cloud Native

Giá trị vận hành của Cloud Native đến từ việc tạo ra một vòng phản hồi duy nhất từ giai đoạn phát triển đến giai đoạn vận hành. Thay đổi được ghi lại trong Git, pipeline thực hiện kiểm thử, kiểm tra bảo mật và chính sách rồi tạo ra artifact. Sau triển khai, tín hiệu quan sát được so sánh với mục tiêu mức dịch vụ, và nếu phát hiện bất thường thì quay lại công việc rollback, giảm thiểu và cải tiến.

flowchart LR
    A[Yêu cầu·Backlog] --> B[Thay đổi mã·hạ tầng·chính sách]
    B --> C[Build·Kiểm thử đơn vị/tích hợp]
    C --> D[Cổng bảo mật·chất lượng]
    D --> E[Artifact trên registry]
    E --> F[Triển khai dần dần]
    F --> G[Metric·log·trace lúc chạy]
    G --> H{Đạt tiêu chí SLO·chính sách?}
    H -->|Có| I[Mở rộng·chuẩn hóa·học hỏi]
    H -->|Không| J[Rollback·giảm thiểu·phân tích nguyên nhân]
    J --> B
    I --> A

Trong vòng lặp này, triển khai thành công và dịch vụ thành công có thể khác nhau. Dù image chạy bình thường, độ trễ người dùng, tỷ lệ lỗi nghiệp vụ, chi phí và sự kiện bảo mật vẫn có thể xấu đi, nên kết quả lúc chạy phải được đưa vào quyết định triển khai. Ngoài ra, tiêu chí rollback tự động nên là các tín hiệu gần với tác động nghiệp vụ như mức tiêu hao error budget, tỷ lệ thành công của hành trình người dùng cốt lõi, tính toàn vẹn dữ liệu, thay vì chỉ mức sử dụng CPU đơn lẻ.

3. Thiết kế ứng dụng, dữ liệu và nền tảng

3.1 Microservices và ranh giới dịch vụ

Cốt lõi của microservices không phải là số lượng tiến trình nhỏ, mà là có thể vận hành độc lập các ranh giới về thay đổi, triển khai, sự cố và sở hữu dữ liệu hay không. Một dịch vụ phải chịu trách nhiệm cho một năng lực nghiệp vụ gắn kết chứ không phải một chức năng kỹ thuật, và từ bên ngoài chức năng được sử dụng qua API và sự kiện đã được đặc tả. Nếu xác định ranh giới tốt, các nhóm có thể phát hành độc lập, còn nếu sai thì hệ thống trở thành distributed monolith (khối nguyên khối phân tán).

Khi chia dịch vụ, cần phân tích đồng thời thuật ngữ miền, tần suất thay đổi, ranh giới giao dịch, trách nhiệm nhóm, ranh giới bảo mật và đặc tính hiệu năng. Tách hai module luôn thay đổi cùng thời điểm có thể chỉ làm tăng lời gọi mạng, còn gộp các quy tắc nghiệp vụ khác nhau vào một dịch vụ thì xung đột triển khai sẽ tiếp diễn. Chiến lược ban đầu dùng modular monolith để kiểm chứng ranh giới miền, rồi tách dần khi đã xác nhận được nút thắt thực tế và cấu trúc nhóm, cũng là một chiến lược hữu hiệu.

3.2 Giao tiếp dựa trên API và sự kiện

Lời gọi API đồng bộ phù hợp với truy vấn hoặc lệnh cần phản hồi tức thì, nhưng nếu đối tượng được gọi bị trễ hoặc lỗi thì bên gọi cũng có thể phải chờ. Timeout ngăn chờ vô hạn, nhưng bản thân timeout không đảm bảo hủy công việc, nên cần xem xét việc thực thi trùng lặp phía máy chủ và xử lý bù trừ. Retry có thể hấp thụ lỗi tạm thời, nhưng nếu retry mọi lỗi thì sẽ xảy ra retry storm, tăng thêm tải lên đối tượng đang gặp sự cố.

Giao tiếp dựa trên sự kiện để bên sản xuất phát hành sự kiện (fact) và bên tiêu thụ xử lý bất đồng bộ, qua đó giảm ràng buộc về thời gian. Tuy nhiên sẽ phát sinh các vấn đề trùng lặp thông điệp, thay đổi thứ tự, trễ, bên tiêu thụ xử lý lại và tương thích schema, nên cần thiết kế khóa idempotency và chính sách xử lý lại. Việc phát hành sự kiện cũng không có nghĩa là giao dịch cơ sở dữ liệu và việc phát hành thông điệp luôn được commit đồng thời, nên có thể dùng outbox pattern hoặc change data capture (CDC).

3.3 Quản lý trạng thái và dữ liệu

Trong Cloud Native, “phi trạng thái” không có nghĩa là không có dữ liệu, mà là tách vòng đời của từng instance khỏi vòng đời của dữ liệu nghiệp vụ. Chuyển session xác thực sang kho session bên ngoài hoặc token, tệp tin sang object storage, công việc sang hàng đợi bền vững thì có thể tự do thay thế instance. Tuy nhiên, càng nhiều kho lưu trữ bên ngoài thì độ trễ mạng, tính nhất quán, chi phí và miền sự cố cũng tăng theo, nên cần đo lường các mẫu truy cập dữ liệu.

Việc mỗi dịch vụ sở hữu cơ sở dữ liệu riêng nâng cao tính độc lập, nhưng có thể xung đột với yêu cầu join nhiều cơ sở dữ liệu cho báo cáo toàn doanh nghiệp. Nếu cho phép join trực tiếp cơ sở dữ liệu vận hành, ranh giới dịch vụ sụp đổ và thay đổi schema sẽ chặn việc triển khai của nhóm khác. Thay vào đó, tạo riêng mô hình phân tích thông qua sự kiện, CDC, kho dữ liệu (data warehouse), sản phẩm dữ liệu, và nêu rõ sự khác biệt giữa giao dịch nghiệp vụ thời gian thực và tính nhất quán phân tích.

3.4 Platform engineering và trải nghiệm nhà phát triển

Nhóm nền tảng không phải là nhóm vận hành trung tâm làm mọi việc thay nhà phát triển, mà cung cấp nền tảng nội bộ giúp các nhóm sản phẩm xây dựng dịch vụ với các giá trị mặc định an toàn. Khi template dịch vụ, pipeline chuẩn, kết nối log·trace, quản lý quyền và bí mật, dashboard chi phí được cung cấp dưới dạng tự phục vụ, sự lãng phí do mỗi nhóm lặp lại cùng công việc nền tảng sẽ giảm.

Thành công của nền tảng nội bộ được đo bằng trải nghiệm nhà phát triển và kết quả vận hành chứ không phải số lượng chức năng. Cần xem đồng thời thời gian từ dịch vụ mới đến lần triển khai đầu tiên, tỷ lệ sử dụng template chuẩn, tỷ lệ thay đổi thất bại, thời gian khôi phục và số trường hợp ngoại lệ chính sách. Nếu nền tảng áp đặt mọi lựa chọn thì có thể cản trở đổi mới của nhóm, vì vậy cần cung cấp đồng thời golden path an toàn và lộ trình phê duyệt ngoại lệ.

4. Bảo mật, khả năng quan sát và tự động hóa vận hành

4.1 DevSecOps và bảo mật chuỗi cung ứng

Trong môi trường Cloud Native, mã nguồn được chuyển hóa nhanh chóng thành image và cấu hình triển khai, nên không thể chỉ đặt kiểm tra bảo mật ở bước phê duyệt cuối cùng ngay trước khi vận hành. Cần kết nối phát hiện bí mật trong kho mã nguồn, kiểm tra lỗ hổng phụ thuộc, quét image, xác minh chữ ký và kiểm soát quyền triển khai vào luồng phát triển, build và triển khai. Tách quyền của hệ thống build và registry, đồng thời giới hạn bằng chính sách các bên ký được tin cậy và registry được phép đối với cụm vận hành.

Bảo mật không chỉ là trách nhiệm của nhóm nền tảng mà được chia sẻ giữa các chủ sở hữu mã dịch vụ, image, mã hạ tầng và mã chính sách. Tuy nhiên, nếu phân tán cả tiêu chuẩn kiểm soát khi phân tán trách nhiệm thì chênh lệch mức độ giữa các nhóm sẽ lớn, nên cần xác định tiêu chuẩn chung của tổ chức và cổng chính sách tự động. Thông tin bí mật không được lưu dạng văn bản thuần trong biến môi trường mà dùng hệ thống quản lý bí mật chuyên dụng cùng chính sách thời hạn ngắn và luân chuyển (rotation).

4.2 Ba tín hiệu của khả năng quan sát

Khả năng quan sát là mức độ có thể suy luận trạng thái nội bộ từ đầu ra bên ngoài khi không thể nhìn trực tiếp vào trạng thái đó. Metric cho thấy các giá trị số và xu hướng theo thời gian, log cung cấp ngữ cảnh của một sự kiện cụ thể, còn trace cho thấy đường đi và độ trễ của một yêu cầu khi đi qua nhiều dịch vụ. Mục đích không phải là thu thập thật nhiều cả ba tín hiệu, mà là thiết kế mối tương quan để trả lời được các câu hỏi về tác động người dùng và phân tích nguyên nhân.

Chuẩn hóa các thuộc tính chung như tên dịch vụ, môi trường, phiên bản, instance, ID yêu cầu giúp dễ liên kết các tín hiệu với nhau. Tuy nhiên, nếu đưa nguyên các giá trị chứa thông tin cá nhân hoặc có cardinality cao như ID người dùng hay yêu cầu gốc vào tag thì chi phí lưu trữ và rủi ro lộ thông tin tăng lên. Cần đưa phân loại trường, masking, sampling, thời hạn lưu giữ và quyền truy cập vào thiết kế khả năng quan sát.

4.3 Các mẫu tin cậy và cô lập sự cố

Timeout xác định thời gian chờ tối đa của lời gọi để ngăn tài nguyên bị giữ lại. Retry dùng exponential backoff và jitter để phân tán các lời gọi lại đồng thời, và phân biệt lỗi có thể retry với lỗi không thể retry. Circuit breaker nhanh chóng từ chối lời gọi khi tỷ lệ lỗi hoặc độ trễ vượt ngưỡng để ngăn lan truyền sự cố, nhưng cần định nghĩa phản hồi thay thế và cách dò phục hồi trong thời gian mạch mở.

Bulkhead tách biệt pool tài nguyên, thread, mức đồng thời và hàng đợi để sự bùng nổ của một chức năng không làm cạn kiệt chức năng khác. Nếu ranh giới cô lập quá nhỏ thì hiệu suất sử dụng tài nguyên thấp, còn quá lớn thì không ngăn được lan truyền sự cố. Để khắc phục thảm họa, cần giả định không chỉ sự cố một node mà cả sự cố của region, kho dữ liệu, liên kết thanh toán bên ngoài, hệ thống xác thực, rồi xác định thứ tự ưu tiên và mục tiêu khôi phục của từng dịch vụ.

4.4 GitOps và vận hành liên tục

GitOps là phương thức vận hành khai báo trạng thái mong muốn của ứng dụng và hạ tầng trong Git, và agent tự động đưa trạng thái thực tế của cụm hội tụ về trạng thái mong muốn. Vì lịch sử thay đổi được lưu qua code review và commit, có thể truy vết ai đã thay đổi gì và vì sao, đồng thời quy trình quay về phiên bản trước cũng trở nên rõ ràng.

Ưu điểm của GitOps là phê duyệt và tính tái lập, không có nghĩa là mọi vấn đề vận hành đều được giải quyết bằng commit Git. Ứng phó sự cố khẩn cấp, thông tin bí mật, thay đổi dữ liệu quy mô lớn và cấu hình hệ thống bên ngoài cần kiểm soát và ghi nhận riêng. Khi trạng thái thực tế khác với trạng thái trong Git, việc tự động ghi đè có thể khôi phục sự cố nhưng cũng có thể đảo ngược các biện pháp giảm thiểu thủ công, nên cần chuẩn bị quy trình tạm dừng và điều chỉnh.

5. So sánh và các trường hợp áp dụng

5.1 So sánh với phương thức máy ảo truyền thống

Hệ thống lấy máy ảo làm trung tâm cung cấp cô lập mạnh ở mức hệ điều hành và phương thức quản lý quen thuộc. Đây có thể là lựa chọn ổn định cho các gói thương mại kế thừa hoặc hệ thống phụ thuộc nhiều vào kernel, nhưng image lớn, thời gian khởi động dài và dễ phát sinh khác biệt cấu hình giữa các máy chủ. Container và điều phối cung cấp đơn vị triển khai nhỏ hơn và điều chỉnh tự động, nhưng bổ sung độ phức tạp về giao tiếp, quan sát và bảo mật của hệ thống phân tán.

Hạng mục	Lấy máy ảo làm trung tâm	Container·Cloud Native	Hàm ý thực tiễn
Đơn vị triển khai	Image hệ điều hành	Image ứng dụng	So sánh phạm vi thay đổi và thời gian khởi động
Mở rộng	Tạo VM·scale set	Pod·Service·Auto scaling	Kiểm chứng riêng nút thắt ở kho trạng thái
Quản lý trạng thái	Có thể phụ thuộc đĩa cục bộ	Ưu tiên ngoại hóa trạng thái	Tính nhất quán dữ liệu và chi phí là quan trọng
Phương thức vận hành	Quản lý máy chủ theo thủ tục	Quản lý khai báo·tự động hóa	Kiểm soát mức ảnh hưởng của lỗi tự động hóa
Ứng phó sự cố	Khôi phục·thay thế máy chủ	Tái tạo·cô lập instance	Thiết kế đồng thời tự động khôi phục và bằng chứng
Đối tượng phù hợp	Kế thừa·OS đặc thù·cô lập mạnh	Web·API·batch thay đổi thường xuyên	Chiến lược kết hợp theo workload là thực tế

Sự khác biệt không phải là hơn kém mà phát sinh từ mức độ ràng buộc và mục đích vận hành. Nếu cố phân tách hệ thống kế thừa khó container hóa, chi phí kiểm thử và chuyển đổi dữ liệu có thể tăng lên. Ngược lại, nếu chỉ quản lý lớp API thay đổi thường xuyên bằng image VM lớn thì sẽ mất cơ hội về tốc độ triển khai và cô lập sự cố. Do đó, cần phân tích danh mục ứng dụng để phân chia các chiến lược rehost, replatform, refactor, loại bỏ (retire) và giữ nguyên (retain).

5.2 Trường hợp 1: Dịch vụ đặt hàng trực tuyến

Giả sử một dịch vụ đặt hàng trực tuyến có yêu cầu tăng từ 500 lên 5,000 yêu cầu mỗi giây ngay khi sự kiện khuyến mãi bắt đầu. Dịch vụ web và tra cứu sản phẩm có thể mở rộng ngang bằng container phi trạng thái, còn hình ảnh và thông tin sản phẩm được tra cứu thường xuyên có thể phân tán qua CDN và cache. Tiếp nhận đơn hàng được đệm bằng hàng đợi để tách các công việc thanh toán, tồn kho và thông báo, đồng thời dùng mã đơn hàng và khóa idempotency để dù bên tiêu thụ xử lý cùng thông điệp hai lần cũng không xảy ra thanh toán trùng.

Auto scaling có thể tăng số pod web, nhưng không tự động giải quyết được số kết nối cơ sở dữ liệu và khóa hàng (row lock) tồn kho. Vì vậy cần thiết kế đồng thời giới hạn connection pool, mô hình đặt trước tồn kho, bản sao chỉ đọc, tính nhất quán cache và backpressure. Người vận hành quản lý như các chỉ số mức dịch vụ không chỉ tốc độ yêu cầu, tỷ lệ lỗi, độ trễ p99 mà cả lượng tồn đọng hàng đợi, tỷ lệ thanh toán thành công, sai lệch tồn kho và chi phí.

5.3 Trường hợp 2: Dịch vụ dân sự công

Dịch vụ dân sự công đòi hỏi đồng thời không chỉ khả năng chịu tăng đột biến hồ sơ tạm thời mà còn bảo vệ thông tin cá nhân, truy vết kiểm toán và lưu giữ dữ liệu dài hạn. Lớp web được mở rộng đàn hồi, trong khi thông tin định danh công dân áp dụng chính sách thu thập tối thiểu, mã hóa, quyền truy cập, thời hạn lưu giữ, và áp dụng masking theo trường để thông tin cá nhân gốc không lưu lại trong log. Dù đưa vào service mesh hay API Gateway, cũng không được giả định rằng trách nhiệm cuối cùng về xác thực và phân quyền chỉ nằm ở cấu hình hạ tầng.

Nếu việc tiếp nhận hồ sơ và phân công bộ phận phụ trách diễn ra bất đồng bộ, có thể phản hồi tiếp nhận nhanh, nhưng cần mô hình tra cứu hiển thị chính xác trạng thái hiện tại cho công dân. Thông điệp xử lý thất bại được gửi đến hàng đợi xử lý lại và luồng phê duyệt của người vận hành, và thay vì xóa tùy ý thì bảo toàn lịch sử sự kiện và thay đổi. Triển khai theo phương thức canary áp dụng trước cho một phần lưu lượng, và nếu tỷ lệ lỗi hay tỷ lệ xử lý hồ sơ thành công vượt ngoài tiêu chuẩn thì quay về phiên bản trước.

5.4 Trường hợp 3: Bảo trì dự đoán thiết bị sản xuất

Dữ liệu cảm biến của thiết bị sản xuất có thể bị gián đoạn hoặc trễ do mạng hiện trường, nên nếu phụ thuộc toàn bộ xử lý vào đám mây trung tâm thì cảnh báo và điều khiển có thể bị chậm. Cấu trúc lai (hybrid) có thể phù hợp: thiết bị biên (edge) thực hiện phát hiện theo ngưỡng và đệm tạm thời, còn đám mây thực hiện phân tích dài hạn, tái huấn luyện mô hình và so sánh giữa các thiết bị.

Triển khai biên dựa trên container thuận lợi cho việc triển khai lặp lại cùng một module phân tích tại nhiều nhà máy, nhưng phải xem xét các ràng buộc về tài nguyên thiết bị, mạng, nhiệt độ và thao tác tại hiện trường. Quản lý đồng thời phiên bản của mô hình và cấu hình, và đặt cơ chế an toàn hạ độ tin cậy của kết quả suy luận hoặc yêu cầu con người xác nhận khi chất lượng cảm biến thấp. Trường hợp này cho thấy Cloud Native không chỉ có nghĩa là đám mây công cộng trung tâm, mà là cách tiếp cận áp dụng nguyên lý triển khai khai báo, tự động hóa, quan sát và phục hồi tại nhiều vị trí.

6. Chuyên sâu — Định nghĩa theo góc nhìn CNCF và thay đổi tổ chức

Định nghĩa Cloud Native của CNCF tập trung vào cách tổ chức phát triển, build và triển khai workload một cách có thể lặp lại và bằng lập trình ở quy mô phù hợp, hơn là danh sách công nghệ. Vì vậy, serverless hay dịch vụ được quản lý không dùng container cũng có thể là một phần của chiến lược Cloud Native nếu đáp ứng cùng nguyên lý và kiểm soát vận hành. Ngược lại, dù dùng container, nếu vẫn tiếp tục truy cập máy chủ thủ công, triển khai không rõ ràng, thiếu quan sát và quy trình khôi phục chưa được kiểm chứng thì khó có thể xem là đã đạt mục tiêu cốt lõi.

Các hướng dẫn liên quan đến microservices và DevSecOps của NIST đưa ra quan điểm quản lý đồng thời không chỉ mã ứng dụng mà cả mã dịch vụ ứng dụng, mã hạ tầng, mã chính sách và mã quan sát. Quan điểm này mở rộng vận hành Cloud Native từ công việc container đơn thuần của nhóm phát triển thành vấn đề chuỗi cung ứng và chính sách toàn doanh nghiệp. Để xác minh sự tin cậy giữa sản phẩm build và môi trường triển khai, cần kết nối SBOM, chữ ký image, chính sách triển khai và quan sát lúc chạy.

Platform engineering gần đây là phương tiện thực tế để lan tỏa Cloud Native trong tổ chức. Nền tảng chung cung cấp các chức năng bảo mật, quan sát và triển khai chuẩn, còn nhóm sản phẩm tập trung vào chức năng nghiệp vụ và giá trị người dùng. Tuy nhiên, nếu nhóm nền tảng chỉ triển khai công cụ mà không lắng nghe yêu cầu của khách hàng nội bộ thì nền tảng sẽ trở thành thêm một tổ chức chờ ticket. Lộ trình của sản phẩm nền tảng cần được đánh giá bằng trải nghiệm nhà phát triển, độ tin cậy dịch vụ, hiệu quả chi phí và kết quả bảo mật.

Trong bài làm của Kỹ sư chuyên nghiệp, cần vượt qua công thức học thuộc “Cloud Native = MSA + container + Kubernetes”. Điểm cao nằm ở việc liên kết định nghĩa và nguyên lý cốt lõi, thiết kế theo lớp, bảo mật và vận hành, so sánh với phương thức cũ, các trường hợp thực tế, rồi đưa ra tiêu chí đánh giá tính phù hợp nghiệp vụ và rủi ro chuyển đổi. Đặc biệt, cần trình bày cả phản biện rằng nếu đưa công nghệ vào trước khi năng lực tổ chức và kiến trúc dữ liệu sẵn sàng thì độ phức tạp và chi phí sẽ tăng, như vậy bài làm mới cân bằng.

7. Các điểm cần lưu ý và hàm ý

Thứ nhất, điểm xuất phát của chuyển đổi phải được xác định bằng thay đổi nghiệp vụ và mức dịch vụ, không phải bằng công nghệ. Khảo sát tần suất triển khai, thời gian gián đoạn cho phép, biến động lưu lượng, tính nhất quán dữ liệu, quy định và cấu trúc nhóm rồi mới xác định phạm vi áp dụng Cloud Native. Với batch hầu như không thay đổi hoặc hệ thống gắn chặt với phần cứng, môi trường thực thi đơn nhất ổn định có thể phù hợp hơn microservices gượng ép.

Thứ hai, phải tính toán đồng thời tính độc lập đạt được nhờ phân tán và độ phức tạp phát sinh do phân tán. Khi số dịch vụ tăng, có lợi ích về triển khai độc lập và cô lập sự cố, nhưng chi phí cho lời gọi mạng, hợp đồng, quan sát, kiểm thử và tương thích phiên bản cũng tăng. Trước khi tách dịch vụ, kiểm chứng ranh giới module và trách nhiệm nhóm; sau khi tách, đo lường xem độ trễ, lỗi, ticket vận hành và hiệu quả triển khai có thực sự cải thiện hay không.

Thứ ba, đặt tính nhất quán và khả năng khôi phục của dữ liệu ở trung tâm kiến trúc. Nếu chỉ nhấn mạnh ứng dụng phi trạng thái mà để kho dữ liệu là nút thắt duy nhất thì dịch vụ sẽ thất bại dưới tải đỉnh. Xác định quyền sở hữu dữ liệu, xử lý đồng bộ/bất đồng bộ, idempotency, giao dịch bù trừ, thử nghiệm sao lưu·khôi phục, RPO·RTO theo mức độ quan trọng nghiệp vụ.

Thứ tư, nhúng bảo mật và tuân thủ quy định vào pipeline và lúc chạy. Chỉ kiểm tra lỗ hổng image và mã thì không ngăn được lạm dụng quyền, lộ bí mật hay thoát khỏi môi trường chạy (runtime escape). Kết nối đặc quyền tối thiểu, phân đoạn mạng, xác minh chữ ký, mã chính sách, phát hiện lúc chạy, log kiểm toán và diễn tập ứng phó sự cố từ phát triển đến vận hành.

Thứ năm, khả năng quan sát được đánh giá bằng chất lượng ra quyết định, không phải lượng dữ liệu thu thập. Xác định hành trình người dùng cốt lõi và SLO của từng dịch vụ, rồi ưu tiên thu thập các metric, log, trace có thể phát hiện vi phạm SLO đó và khoanh vùng nguyên nhân. Nếu không kiểm soát vấn đề thông tin cá nhân và cardinality cao, dữ liệu quan sát sẽ trở thành rủi ro bảo mật và chi phí mới, nên cần vận hành đồng thời chính sách lưu giữ và truy cập.

Thứ sáu, đưa đường dừng an toàn và khôi phục vào tự động hóa. Giới hạn thất bại của tự động hóa thông qua triển khai dần dần, thay đổi được phê duyệt, kiểm chứng chính sách, rollback tự động, dừng thủ công khi sự cố và diễn tập khôi phục. Triển khai tự động thành công không có nghĩa là quy trình đã kết thúc; cần xác nhận các chỉ số người dùng thực tế và chỉ số kinh doanh có ổn định hay không.

Thứ bảy, đưa chi phí và tính bền vững vào mục tiêu thiết kế. Auto scaling và dịch vụ chia nhỏ có thể giảm chi phí theo mức sử dụng, nhưng môi trường phát triển luôn bật, log quá mức, metric cardinality cao và truyền mạng không cần thiết sẽ làm tăng chi phí. Đưa khả năng hiển thị chi phí theo nhóm, cảnh báo ngân sách, TTL tài nguyên, tiêu chí sử dụng reserved/spot, chỉ số carbon·năng lượng vào vận hành.

Thứ tám, song hành thay đổi về tổ chức và năng lực. DevOps và platform engineering không phải là dự án đổi tên nhóm, mà là phương thức vận hành trong đó phát triển, vận hành và bảo mật cùng chịu trách nhiệm về kết quả dịch vụ. Nâng cao tính tự chủ của nhóm sản phẩm đồng thời cung cấp nền tảng chung và rào chắn (guardrail), và biến việc ngăn tái diễn và học hỏi thành tài sản của tổ chức thay vì đổ lỗi sự cố cho cá nhân.

Tổng hợp lại, Cloud Native không phải là tập hợp công nghệ sử dụng đám mây, mà là chiến lược kiến trúc làm cho hệ thống và tổ chức có thể lặp lại được trên tiền đề thay đổi, sự cố và biến động nhu cầu. Kỹ sư chuyên nghiệp cần đánh giá đồng thời tính phù hợp nghiệp vụ, hiệu quả thực của tính độc lập, tính nhất quán dữ liệu, bảo mật, chi phí và năng lực vận hành hơn là độ mới của công nghệ được áp dụng, để đưa ra lộ trình chuyển đổi theo từng giai đoạn.

Tài liệu tham khảo

Cloud Native Computing Foundation, "Cloud Native Definition": https://github.com/cncf/toc/blob/main/DEFINITION.md
Cloud Native Computing Foundation, "Cloud Native Security Whitepaper": https://www.cncf.io/wp-content/uploads/2022/06/CNCF_cloud-native-security-whitepaper-May2022-v2.pdf
NIST, "SP 800-204: Security Strategies for Microservices-based Application Systems": https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-204.pdf
NIST, "NIST Publishes SP 800-204C": https://csrc.nist.gov/news/2022/nist-publishes-sp-800-204c
Kubernetes Documentation, "Declarative Management of Kubernetes Objects": https://kubernetes.io/docs/concepts/overview/working-with-objects/declarative-management/
OpenTelemetry Documentation, "Observability Primer": https://opentelemetry.io/docs/concepts/observability-primer/

Tóm tắt một câu: Cloud Native không phải là bản thân container, mà là chiến lược vận hành ứng dụng, nền tảng và tổ chức kết hợp quản lý khai báo, tự động hóa, tính đàn hồi, khả năng phục hồi, khả năng quan sát và bảo mật để ứng phó lặp lại được với thay đổi và sự cố.