Trước khi xây dựng CI/CD pipeline hay triển khai Kubernetes, cần nắm vững nền tảng hạ tầng
Nhiều người cho rằng con đường trở thành DevOps Engineer bắt đầu từ việc học Docker, Kubernetes hoặc xây dựng CI/CD pipeline. Tuy nhiên, điều thường bị bỏ qua là hiểu vì sao hạ tầng được thiết kế theo cách đó.
Trong phỏng vấn DevOps, bạn có thể được hỏi: “Tại sao cần load balancer khi đã có nhiều server?” hoặc “Scaling theo chiều dọc và chiều ngang khác nhau thế nào, khi nào nên dùng từng loại?” Nếu chỉ trả lời “để tăng tốc” hoặc “để tránh downtime”, có thể bạn mới nhớ thuật ngữ mà chưa hiểu bản chất.
DevOps Engineer giỏi không chỉ thành thạo automation script mà còn phải hiểu cách traffic di chuyển trong hệ thống, vì sao hệ thống quá tải khi lưu lượng tăng đột biến và cách scalability thực sự hoạt động. Thiếu nền tảng này, các công cụ dù mạnh đến đâu cũng chỉ là những câu lệnh học thuộc, thay vì kỹ năng có thể vận dụng và phân tích.
Bài viết giới thiệu 7 khái niệm hạ tầng cốt lõi dành cho người muốn theo đuổi DevOps, tập trung vào lý do mỗi khái niệm tồn tại, vấn đề cần giải quyết và những đánh đổi thực tế khi áp dụng.
1. Khả năng mở rộng (Scalability)
Khả năng mở rộng cho thấy năng lực xử lý của hệ thống dưới tăng trưởng mà không gặp sự cố gián đoạn. Sự tăng trưởng ở đây có thể gồm tăng số lượng người dùng, khối lượng dữ liệu, số lượng request, hoặc tăng thêm chi nhánh.
Có một điểm mà nhiều người thường bỏ sót: khả năng mở rộng không phải là đặc tính của riêng một thành phần đơn lẻ nào, mà là đặc tính của toàn bộ hệ thống. Bạn có thể scale các application servers lên gấp 10 lần, nhưng nếu database phía sau không scale tương ứng, thì nút thắt hệ thống (bottleneck) sẽ không biến mất; nó chỉ đơn thuần dịch chuyển sang vị trí khác mà thôi.
Một số điểm cần lưu ý về Scalability (Khả năng mở rộng):
- Hệ thống chỉ có thể mở rộng tốt bằng với layer yếu nhất, chứ không phải layer mạnh nhất.
- Scaling không đơn thuần là “thêm server” mà cần được tính đến ngay từ đầu trong kiến trúc hệ thống.
- Tất cả các layer, từ load balancer đến database, đều phải có khả năng mở rộng đồng bộ.
Bizfly Cloud cung cấp triển khai scalability ở cấp hạ tầng, tham khảo tài liệu chính thức về https://bizflycloud.vn/docs/auto_scaling/
2. Mở rộng theo chiều dọc (Vertical Scaling) và mở rộng theo chiều ngang (Horizontal Scaling)
Đây là hai chiến lược chính để triển khai scaling, bắt nguồn từ những triết lý hoàn toàn khác biệt.
Vertical Scaling sẽ tăng cường sức mạnh cho một server đơn lẻ - bổ sung thêm CPU, RAM hoặc sử dụng loại storage nhanh hơn. Ứng dụng và kiến trúc hệ thống vẫn giữ nguyên; bạn chỉ đơn thuần nâng cấp phần cứng mà ứng dụng đó đang chạy trên đó. Cách này khá đơn giản nhưng lại có giới hạn: các server vật lý cuối cùng cũng sẽ đạt đến ngưỡng tối đa về hiệu năng. Hơn nữa, vì chỉ có một server duy nhất, đây cũng trở thành một "điểm lỗi duy nhất" (single point of failure) - nếu máy đó gặp sự cố, mọi thứ chạy trên nó cũng sẽ ngừng hoạt động theo.
Horizontal scaling thực hiện bổ sung thêm nhiều server thay vì tăng hiệu năng cho một máy chủ duy nhất. Làm như vậy thì gần như không có giới hạn tối đa; hơn nữa, nếu một node gặp sự cố, hệ thống chỉ mất đi một phần năng lực xử lý thay vì sụp đổ hoàn toàn. Tuy nhiên, yêu cầu đặt ra là các server phải ở trạng thái stateless - nghĩa là không server nào được lưu trữ dữ liệu riêng của người dùng giữa các lần request. Nếu một server lưu giữ trạng thái, thì mọi request từ user đó đều phải được chuyển hướng về đúng server ban đầu; điều này làm mất đi hoàn toàn mục đích cốt lõi của việc scale theo chiều ngang.
Tóm lại:
- Vertical Scaling: triển khai nhanh, nhưng tiềm ẩn rủi ro downtime và sẽ phát sinh chi phí tốn kém khi vượt mức nhất định.
- Horizontal scaling: linh hoạt hơn, không có giới hạn cứng, nhưng yêu cầu stateless design ngay từ đầu
- Hầu hết các hệ thống hiện đại đều kết hợp cả hai, với horizontal scaling là chiến lược chính
3. Load Balancer
Khi có nhiều server cùng hoạt động (nhờ horizontal scaling), một câu hỏi mới sẽ nảy sinh: làm thế nào để phân bổ các request từ người dùng đến tất cả những server đó? Đây chính là nhiệm vụ của load balancer.
Load Balancer nằm phía trước một server group và điều phối lưu lượng truy cập đến các server trong group đó. Mọi request từ phía client đều được gửi đến load balancer trước, sau đó nó sẽ chuyển tiếp request đó tới một trong các server phía sau. Từ góc nhìn bên ngoài, hệ thống có vẻ như chỉ có một single server; nhưng thực tế bên trong, có thể có hàng chục server đang cùng chia sẻ workload.
Những điểm chính cần lưu ý:
- Load balancer giúp hệ thống phân tán hoạt động như một thực thể duy nhất khi nhìn từ bên ngoài.
- Cơ chế health checks tự động giúp hệ thống có khả năng chống chịu sự cố; load balancer không chỉ đơn thuần phân phối traffic đồng đều.
- Các loại load balancer hoạt động ở những tầng OSI khác nhau (Layer 4 và Layer 7), tùy theo mục đích sử dụng.
Để tìm hiểu cách triển khai thực tế, tham khảo https://bizflycloud.vn/docs/load_balancer/.
4. Latency
Độ trễ là khoảng thời gian tính từ lúc một request được gửi đi cho đến khi nhận lại phản hồi (response). Đây chính là độ trễ mà người dùng thực sự cảm nhận được. Latency thấp mang lại cảm giác tức thì, trong khi latency cao tạo cảm giác chậm chạp, thậm chí gây khó chịu.
Điểm thú vị là latency không phải là một con số duy nhất, mà là tổng hợp của nhiều khoảng trễ nhỏ hơn cộng dồn lại. Thời gian truyền tải qua mạng, thời gian xử lý của máy chủ và thời gian truy vấn cơ sở dữ liệu đều góp phần tạo nên độ trễ tổng thể. Điều này có nghĩa là việc giảm độ trễ không nằm ở chỗ tối ưu hóa mọi thứ cùng một lúc, mà là xác định xem lớp nào đang gây ra độ trễ lớn nhất, rồi tập trung giải quyết "nút thắt" cụ thể đó.
Một vài điểm cốt yếu cần lưu ý về latency:
- Latency thường được đo bằng mili giây (ms).
- Các nguyên nhân gây ra latency rất đa dạng, từ khoảng cách network, thời gian xử lý của server, cho đến thời gian query database.
- Latency không đồng nghĩa với việc hệ thống có thể xử lý đồng thời một lượng lớn người dùng - đây là vấn đề về throughput, nội dung mà chúng ta sẽ tìm hiểu ngay sau đây.
5. Throughput
Nếu latency cho thấy “một request được hoàn thành nhanh đến mức nào”, thì throughput lại đề cập đến “khối lượng công việc mà hệ thống có thể hoàn thành trong một khoảng thời gian nhất định” - thường được đo bằng số lượng request trên mỗi giây (RPS).
Hai chỉ số này thường xuyên bị nhầm lẫn với nhau, mặc dù chúng đo lường những yếu tố hoàn toàn khác biệt. Hệ thống có thể xử lý từng request nhanh nhưng throughput vẫn thấp nếu chỉ xử lý được một request tại một thời điểm. Ngược lại, hệ thống có thể xử lý mỗi request chậm hơn một chút nhưng đạt throughput cao nhờ xử lý nhiều request song song.
Tối ưu latency không đồng nghĩa với cải thiện throughput — mỗi chỉ số cần chiến lược thiết kế riêng.
Một vài lưu ý:
Latency = tốc độ xử lý của một single request.
Throughput = tổng năng lực xử lý của hệ thống trong một khoảng thời gian nhất định.
Các hệ thống có throughput cao thường dựa vào cơ chế xử lý song song thay vì chỉ đơn thuần là sử dụng các server chạy "nhanh hơn".
Nếu bạn muốn thử nghiệm đo lường API throughput, tài liệu của Grafana k6 - một trong những công cụ load testing mã nguồn mở phổ biến nhất - có hướng dẫn chi tiết về cách đo lường throughput trong quá trình thực hiện load test.
6. CDN (Mạng phân phối nội dung - Content Delivery Network)
CDN là một mạng lưới các máy chủ được phân bổ ở nhiều nơi, lưu trữ các bản sao của nội dung tĩnh (static content) và cung cấp chúng cho người dùng có vị trí gần máy chủ nhất. Thay vì mỗi người dùng phải truy xuất hình ảnh từ một server ở thành phố khác, họ có thể lấy dữ liệu đó từ một server đặt ngay tại thành phố của mình.
Giải pháp này mang lại hai lợi ích chính. Thứ nhất, nó giúp giảm độ trễ đối với các nội dung không thay đổi theo từng người dùng, ví dụ hình ảnh, video và các tệp script. Thứ hai, nó giảm đáng kể workload cho máy chủ gốc (origin server), vì phần lớn các request được xử lý bởi các edge node trước khi kịp truyền đến máy chủ gốc.
Điểm hạn chế: nội dung được lưu trong bộ nhớ đệm (cache) có thể bị outdate nếu dữ liệu gốc thay đổi mà cache chưa được cập nhật hoặc bị vô hiệu hóa. Chính vì vậy, chiến lược cache invalidation đóng vai trò cực kỳ quan trọng trong việc thiết lập một hệ thống CDN hiệu quả.
Các điểm chính về CDN:
- CDN hoạt động hiệu quả nhất đối với static content, thay vì dữ liệu thay đổi tùy theo từng người dùng.
- Những lợi ích chính bao gồm giảm latency và giảm tải cho máy chủ gốc (origin server).
- Việc vô hiệu hóa cache (cache invalidation) là thách thức kỹ thuật hàng đầu khi vận hành một CDN.
Để tìm hiểu sâu hơn về cách thức hoạt động thực tế từ một trong những CDN được sử dụng rất phổ biến: https://bizflycloud.vn/docs/cdn/
7. API Gateway
Khái niệm cuối cùng trong danh sách của chúng ta là API gateway. Đây là một điểm truy cập duy nhất (single entry point) nằm phía trước các dịch vụ backend, đảm nhận các chức năng chung như xác thực, giới hạn tốc độ truy cập (rate limiting), SSL termination và request routing - tất cả đều được tập trung tại một nơi.
Nếu không có API gateway, mỗi service sẽ phải tự triển khai cơ chế xác thực và giới hạn tốc độ truy cập riêng. Hãy thử tưởng tượng bạn có 10 microservice - nghĩa là bạn phải duy trì sự đồng nhất cho 10 cơ chế xác thực riêng biệt. Với API gateway, mọi thứ được tập trung lại. Tất cả các service nằm phía sau nó đều được hưởng các cơ chế bảo vệ này mà không cần phải triển khai lại từ đầu.
Điểm đánh đổi là: API gateway trở thành một thành phần hạ tầng trọng yếu, đòi hỏi tính sẵn sàng cao và không được phép trở thành điểm nghẽn, vì mọi request đều phải đi qua nó trước khi đến được service đích.
Những điểm chính cần ghi nhớ:
- API gateway tập trung hóa các chức năng như xác thực, rate limiting và routing.
- Mỗi backend service trở nên đơn giản hơn vì không còn phải tự mình triển khai các vấn đề mang tính bao quát (cross-cutting concerns).
- Do đóng vai trò là điểm truy cập duy nhất, API gateway cần được thiết kế để đảm bảo tính sẵn sàng cao (high availability).
