Chương 1. Kiến trúc một máy chủ

Hai tháng sau sự cố được phân tích ở chương 0, hệ thống Chợ Phố vẫn vận hành trên một máy chủ (server) duy nhất. Câu hỏi còn bỏ ngỏ từ chương trước là: nếu ổ đĩa (disk) của máy chủ này hỏng, dữ liệu có khôi phục (restore) được không. Sáng thứ Hai 26/10, An, người phụ trách kỹ thuật, tiến hành lần khôi phục thử đầu tiên. Vì không có máy chủ nào khác, việc khôi phục được thực hiện vào một cơ sở dữ liệu (database) tạm trên chính máy chủ production.

Thư mục sao lưu (backup) vẫn có đủ một tệp cho mỗi đêm:

Từ ngày 16 tháng 9, mỗi tệp chỉ còn 20 byte, đúng bằng kích thước của một tệp gzip rỗng, trong khi tác vụ định kỳ (cron job) không phát ra cảnh báo nào.

Kiến trúc một máy chủ là cách triển khai (deploy) trong đó mọi thành phần của hệ thống chạy trên cùng một máy. Ở Chợ Phố, máy chủ chứa Tomcat chạy ứng dụng Java, PostgreSQL lưu dữ liệu, thư mục ảnh sản phẩm, và một tác vụ định kỳ thực hiện sao lưu lúc 2 giờ sáng. Việc triển khai được thực hiện thủ công: đăng nhập qua SSH, lấy mã nguồn mới và khởi động lại Tomcat.

Kiến trúc này phù hợp với giai đoạn đầu của sản phẩm vì chi phí thấp và vận hành đơn giản. Tuy nhiên, nó có hai đặc điểm cần được phân tích.

Đặc điểm thứ nhất là tranh chấp tài nguyên (resource contention). Các thành phần dùng chung CPU, bộ nhớ trong (RAM) và ổ đĩa, nên một tác vụ nặng của thành phần này làm giảm hiệu năng của các thành phần còn lại. Đặc điểm thứ hai là sự tồn tại của các điểm lỗi đơn (single point of failure, SPOF), tức các thành phần mà khi hỏng sẽ làm toàn bộ hệ thống ngừng hoạt động. Sự việc sáng thứ Hai liên quan đến cả hai đặc điểm. Phần tiếp theo phân tích nguyên nhân của bản sao lưu rỗng.

Tác vụ sao lưu được khai báo trong crontab bằng một dòng lệnh duy nhất:

Lệnh này tạo một đường ống lệnh (pipeline): đầu ra của pg_dump được chuyển trực tiếp sang gzip để nén. Ngày 16 tháng 9, một migration bổ sung tính năng mã giảm giá đã tạo bảng vouchers bằng tài khoản quản trị, nhưng không cấp quyền đọc cho tài khoản backup_ro. Từ đêm đó, pg_dump dừng lại với một lỗi có dạng như sau (câu chữ cụ thể phụ thuộc phiên bản):

Theo mã nguồn của pg_dump, công cụ này khoá mọi bảng cần đọc ngay khi bắt đầu, nên lỗi quyền xảy ra trước khi bất kỳ dữ liệu nào được ghi ra. Ở định dạng plain, pg_dump chỉ ghi kết quả sau khi đã đọc xong cấu trúc dữ liệu. Vì vậy gzip nhận đầu vào rỗng và tạo ra một tệp nén rỗng.

Mã thoát (exit code) của một đường ống lệnh trong shell, theo mặc định, là mã thoát của lệnh cuối cùng. Lệnh cuối cùng ở đây là gzip, và gzip hoàn tất việc nén phần dữ liệu nhận được mà không gặp lỗi. Vì vậy cron ghi nhận tác vụ thành công.

Thông báo lỗi của pg_dump được ghi ra đầu ra lỗi chuẩn (stderr), và cron gửi phần đầu ra này qua thư điện tử cho chủ sở hữu crontab. Tuy nhiên, máy chủ không cài dịch vụ (service) gửi thư, nên các thông báo này không đến được người vận hành.

Như vậy, ba cơ chế giám sát cùng không hoạt động: mã thoát không phản ánh lỗi, thông báo qua thư không được gửi đi, và kích thước tệp không được kiểm tra. Một quy trình sao lưu không được kiểm chứng tạo ra cảm giác an toàn mà không đem lại sự an toàn thực tế. Câu hỏi tiếp theo là mức thiệt hại nếu sự cố phần cứng xảy ra trong khoảng thời gian này.

Mục tiêu điểm khôi phục (Recovery Point Objective, RPO) là lượng dữ liệu tối đa, tính bằng khoảng thời gian, mà tổ chức chấp nhận mất khi xảy ra sự cố. Với một bản sao lưu mỗi đêm, nhóm đặt RPO là một ngày. Lượng dữ liệu mất thực tế lại được xác định bởi bản sao lưu hợp lệ gần nhất.

Bản sao lưu hợp lệ gần nhất là của đêm 15 tháng 9. Nếu ổ đĩa hỏng vào sáng thứ Hai, toàn bộ dữ liệu phát sinh sau thời điểm đó sẽ mất, gồm đơn hàng, tài khoản mới và đánh giá sản phẩm. Mỗi đêm sao lưu lỗi để lại một ngày dữ liệu không được bảo vệ, và đã có 41 đêm lỗi liên tiếp. Với khoảng 1.500 đơn hàng mỗi ngày, số đơn hàng mất ít nhất là 1.500 đơn × 41 ngày = 61.500 đơn. Lượng dữ liệu có thể mất tăng thêm một ngày sau mỗi đêm lỗi chưa được phát hiện, trong khi RPO đặt ra vẫn là một ngày. Các kỹ thuật giảm RPO xuống mức phút được trình bày ở chương 15.

Biện pháp đầu tiên là cấp quyền theo cách không phụ thuộc vào việc người viết migration nhớ cấp quyền cho từng bảng mới. PostgreSQL cung cấp sẵn vai trò chỉ đọc toàn bộ dữ liệu:

Biện pháp thứ hai là thay dòng crontab bằng một script, trong đó mọi lỗi đều làm script thất bại và mọi thất bại đều được thông báo:

Dòng khai báo trình thông dịch ở đầu script có vai trò quan trọng. Tiến trình cron thực thi lệnh bằng /bin/sh, và không phải bản cài đặt sh nào cũng hỗ trợ pipefail. Vì vậy dòng crontab chỉ gọi script, còn script tự khai báo chạy bằng Bash.

Mỗi bước còn lại ngăn một dạng lỗi im lặng. set -o pipefail giữ lại lỗi của mọi lệnh trong đường ống. pg_restore --list đọc mục lục của tệp để phát hiện tệp hỏng. Phép kiểm tra kích thước phát hiện trường hợp lệnh kết thúc bình thường nhưng dữ liệu thiếu. Lệnh curl gửi tín hiệu hoạt động tới hệ thống giám sát, và hệ thống này cảnh báo khi quá 26 giờ không nhận được tín hiệu.

Script cũng sao chép tệp sang một máy khác. Bản sao lưu nằm trên cùng ổ đĩa với dữ liệu gốc sẽ mất cùng lúc với dữ liệu gốc. Nguyên tắc này thường được phát biểu thành quy tắc 3-2-1. Theo quy tắc này, cần duy trì ba bản dữ liệu trên hai loại phương tiện lưu trữ, trong đó một bản đặt ở địa điểm khác.

Các bước kiểm tra trong script phát hiện được những dạng lỗi đã biết. Cách duy nhất để chứng minh một bản sao lưu dùng được là khôi phục nó trên một máy riêng và kiểm tra dữ liệu thu được.

Cơ sở dữ liệu của Chợ Phố có khoảng 250 MB × 240 ngày = 60 GB. Trên một máy thuê theo giờ, việc khôi phục bằng một tiến trình mất 1 giờ 50 phút, tương ứng tốc độ 60 GB ÷ 110 phút ≈ 9,1 MB/giây. Với bốn tiến trình song song (pg_restore -j 4), thời gian giảm còn 45 phút.

Mục tiêu thời gian khôi phục (Recovery Time Objective, RTO) là khoảng thời gian tối đa hệ thống được phép ngừng hoạt động trước khi khôi phục xong. Trước buổi khôi phục thử, Chợ Phố chưa đặt RTO và cũng không biết thời gian khôi phục thực tế. Sau buổi thử, nhóm ước tính được thời gian khôi phục thực tế. Ước tính gồm thời gian khôi phục song song vừa đo, khoảng 60 phút chuẩn bị máy mới và khoảng 15 phút cập nhật DNS (chương 26). Tổng là 45 + 60 + 15 = 120 phút, nên nhóm đặt RTO là 2 giờ.

Quy trình kiểm chứng được tự động hoá bằng một script chạy hằng tuần. Bước cuối cùng kiểm tra sự hiện diện của dữ liệu mới nhất, vì một lần khôi phục không báo lỗi chưa chứng minh rằng dữ liệu đầy đủ. Script xoá rồi tạo lại cơ sở dữ liệu kiểm tra chopho_kiemtra trước mỗi lần khôi phục, nên chỉ được chạy trên máy kiểm tra.

Lần khôi phục thứ hai trong buổi sáng sử dụng một tệp đầy đủ. Tiến trình khôi phục đọc tệp nén, giải nén và ghi hàng chục GB lên ổ đĩa, đồng thời PostgreSQL của hệ thống production cũng đọc và ghi trên chính ổ đĩa đó.

Theo mô hình hàng đợi (queue) ở chương 0, mỗi tài nguyên dùng chung hoạt động như một hàng đợi. Trong điều kiện bình thường, ổ đĩa bận khoảng 45% thời gian. Khi đó, thời gian một yêu cầu (request) vào ra ở ổ đĩa, gồm cả chờ và xử lý, bằng 1 / (1 − 0,45) ≈ 1,8 lần thời gian xử lý. Khi tiến trình khôi phục chạy, mức sử dụng (utilization) tăng lên 92%, và tỉ lệ này trở thành 1 / (1 − 0,92) = 12,5, gấp khoảng 7 lần trạng thái bình thường.

Đo lường thay vì phỏng đoán

Hai công cụ có sẵn trên Linux cho phép xác định tài nguyên đang nghẽn:

Cột %util là tỉ lệ thời gian ổ đĩa bận. Với SSD và RAID, chỉ số này không cho biết thiết bị đã đạt giới hạn hay chưa, nên cần xem cùng hai chỉ số sau. Cột aqu-sz là độ dài trung bình của hàng đợi yêu cầu, còn r_await và w_await là thời gian trung bình của mỗi thao tác đọc, ghi, tính bằng mili giây.

Trong vmstat, cột b là số tiến trình đang bị chặn do chờ vào ra, còn wa là tỉ lệ thời gian CPU nhàn rỗi vì chờ ổ đĩa. Số liệu cho thấy CPU chưa bận, trong khi nhiều tiến trình đang chờ ổ đĩa. Đây cũng là dạng sự cố đã phân tích ở chương 0: tài nguyên cạn trước tiên không phải là CPU.

Bộ nhớ trong là tài nguyên dùng chung thứ hai, được chia cho heap của JVM, vùng đệm của PostgreSQL và bộ nhớ đệm (cache) của hệ điều hành.

Biện pháp trước mắt là không thực hiện khôi phục trên máy production. Biện pháp lâu dài là tách cơ sở dữ liệu khỏi các thành phần khác, nội dung của chương tiếp theo.

Bảng dưới liệt kê các điểm lỗi đơn của Chợ Phố sau khi rà soát.

Dòng cuối của bảng chỉ ra rằng con người cũng có thể là điểm lỗi đơn. Quy trình triển khai của Chợ Phố chỉ tồn tại trong trí nhớ của An. Văn bản hoá quy trình và chuyển nó thành script là biện pháp chi phí thấp nhất để loại bỏ điểm lỗi này. Tự động hoá triển khai được trình bày ở chương 7.

Độ sẵn sàng (availability) của một máy chủ có thể ước lượng từ tổng thời gian ngừng hoạt động trong năm. Giả định mỗi năm có một lần hỏng ổ đĩa, với thời gian khôi phục bằng ước tính ở mục trước. Ngoài ra có bốn lần khởi động lại để cập nhật hệ điều hành, và một lần bảo trì của nhà cung cấp kéo dài 1 giờ. Tổng thời gian ngừng là 2 giờ + 4 × 10 phút + 1 giờ ≈ 3,7 giờ, tương ứng độ sẵn sàng ≈ 99,96%.

Ước lượng này chỉ đúng khi bản sao lưu hợp lệ. Với bản sao lưu rỗng như trong tình huống, một lần hỏng ổ đĩa dẫn đến mất dữ liệu vĩnh viễn, và chỉ số độ sẵn sàng không còn ý nghĩa.

Ngoài rủi ro hỏng hóc, một máy chủ duy nhất còn có giới hạn về năng lực khi số người dùng tăng. Phương án trực tiếp nhất là nâng cấu hình của chính máy này, và mục tiếp theo xác định phương án đó kéo dài được bao lâu.

Mở rộng theo chiều dọc (scale up) là việc tăng năng lực của một máy, bằng cách bổ sung CPU, bộ nhớ trong hoặc thay ổ đĩa nhanh hơn, mà không thay đổi mã nguồn. Đây là phương án hợp lý ở giai đoạn một máy chủ, với điều kiện xác định được nó đem lại bao nhiêu thời gian.

Số người dùng của Chợ Phố tăng khoảng 8% mỗi tháng, và mức sử dụng CPU giờ cao điểm hiện là 35%. Ngưỡng nâng cấp được chọn là 70%, vì từ mức này độ trễ (latency) do hàng đợi tăng nhanh. Giải phương trình 35% × 1,08ⁿ = 70% được n ≈ 9 tháng.

Mỗi lần nhân đôi cấu hình, mức sử dụng giảm một nửa và, với tốc độ tăng không đổi, chạm ngưỡng sau một khoảng thời gian như cũ. Phương án này có giới hạn trên, vì cấu hình lớn nhất mà nhà cung cấp cho thuê là hữu hạn, và việc đổi cấu hình thường đòi hỏi tắt máy.

Lựa chọn tài nguyên để nâng cấp phải dựa trên số đo. Mức sử dụng CPU cao kéo dài cho thấy cần thêm CPU. Tỉ lệ đọc ổ đĩa cao do bộ nhớ đệm không đủ cho thấy cần thêm bộ nhớ trong. Đây thường là phương án rẻ và hiệu quả, vì truy cập bộ nhớ nhanh hơn truy cập ổ đĩa nhiều bậc. Chỉ số %util cao như trong tình huống cho thấy cần ổ đĩa có số thao tác vào ra mỗi giây (IOPS) lớn hơn.

Mở rộng theo chiều dọc không giải quyết hai vấn đề của tình huống. Máy có cấu hình lớn hơn vẫn là một máy, tức vẫn là điểm lỗi đơn. Các thành phần vẫn dùng chung ổ đĩa, nên tranh chấp tài nguyên vẫn tồn tại.

Sau các biện pháp trên, Chợ Phố có quy trình sao lưu tự kiểm tra hằng đêm, một bản sao lưu ở máy khác, và lịch khôi phục thử hằng tuần. Rủi ro mất dữ liệu giảm đáng kể.

Tuy nhiên, cơ sở dữ liệu vẫn dùng chung máy với ứng dụng và các tác vụ nặng. Phương án tiếp theo là chuyển cơ sở dữ liệu sang một máy riêng. Khi đó, mỗi truy vấn (query) sẽ phải đi qua mạng.

Hai máy giao tiếp với nhau theo cách nào? Mỗi lần gọi qua mạng tốn thêm bao nhiêu thời gian? Và khi kết nối (connection) giữa hai máy qua mạng không ổn định, thành phần nào bị ảnh hưởng trước? Chương 2 phân tích các câu hỏi này.

• PostgreSQL Documentation: pg_dump, pg_restore, chương "Backup and Restore", tham số shared_buffers, vai trò pg_read_all_data.
• GNU Bash Reference Manual: mục "Pipelines" và lệnh set (-e, -u, -o pipefail).
• Trang man crontab(5), iostat(1), vmstat(8).
• Quy tắc 3-2-1 thường được gắn với Peter Krogh (The DAM Book); nguồn gốc chính xác chưa xác minh được.
• Tài liệu của pg_dump không mô tả mã thoát. Việc công cụ trả mã khác 0 khi lỗi và nội dung thông báo lỗi được xác định từ mã nguồn, và có thể khác nhau giữa các phiên bản.