Cách xây dựng hệ thống có khả năng mở rộng cho người mới bắt đầu – Ngày 1: Clone

Bài viết như một ghi chú ghi khi tác giả tìm hiểu về xây dựng hệ thống có khả năng mở rộng (Scalability).

Bài viết được dịch từ link: Scalability for Dummies – Part 1: Clones

Mình đã đọc bài viết ở link trên từ khá lâu(khoảng 2 – 3 năm trước), qua thời gian ứng dụng vào thực tế có thể đã hiểu được 1 phần của bài viết, nay muốn viết lại bằng tiếng Việt như để ghi chú cho mình.

Làm thế nào để xây dựng một web service có khả năng mở rộng? Câu trả lời có thể dài dòng nhưng sẽ có nhiều điều thú vị trong đó. Vì vậy tôi sẽ chia sẻ nó ở đây – blog của tôi, và tôi sẽ chia nó làm nhiều phần để dễ theo dõi hơn.

Ngày 1: Clone

Các máy chủ của một web service có khả năng mở rộng được ẩn sau một hệ thống cân bằng tải. Hệ thống cân bằng tải này sẽ phân bố đều các request của người dùng tới máy chủ/cụm máy chủ của ứng dụng. Điều đó có nghĩa, nếu một người dùng tên Steve tương tác với ứng dụng của bạn, request thứ nhất của anh ta có thể được xử lý bởi máy chủ số 2. Khi anh ta có thêm 1 request thứ 2 tới ứng dụng, thì request này có thể được xử lý bởi máy chủ số 9, và request thứ 3 có thể lại được xử lý bởi máy chủ số 2.

Steve luôn nhận được kết quả mà mình mong muốn cho mỗi request, không phụ thuộc vào việc máy chủ nào xử lý request. Điều này chỉ ra nguyên tắc vàng đầu tiên khi thiết kế một hệ thống có khả năng mở rộng: Mọi server chứa chính xác logic, codebase của ứng dụng. Server không lưu trữ bất kỳ thông tin nào liên quan tới người dùng trên ổ đĩa local hay memory của nó, như session hay ảnh đại diện của người dùng.

Session nên được lưu trữ ở một trung tâm lưu trữ dữ liệu, nơi mà mọi máy chủ của ứng dụng có thể truy cập tới. Nó có thể là một cơ sở dữ liệu độc lập, hoặc một bộ nhớ cache độc lập – ví dụ: Redis. Mộ bộ nhớ cache độc lập sẽ tốt hơn một cơ sở dữ liệu cho việc lưu trữ và truy cập các session. Độc lập ở đây có thể hiểu là cơ sở dữ liệu hay bộ nhớ cache không nằm trên một trong những máy chủ ứng dụng. Thay vào đó, nó có thể nằm đâu đó ở trong hoặc ở gần trung tâm dữ liệu (db server) của các máy chủ ứng dụng.

Việc triển khai ứng dụng lên các máy chủ ứng dụng thì sao? Làm thế nào để đảm bảo khi có một thay đổi trong code của bạn, thay đổi đó sẽ được gửi tới tất cả các máy chủ và không máy chủ nào thực thi code chưa được thay đổi? Thật may mắn chúng ta có một công cụ tuyệt vời – Capistrano. Nó cần bạn bỏ ra thời gian để tìm hiểu nó, đặc biệt nếu Ruby on Rails không phải thế mạnh của bạn.
(Lời tác giả: Bài viết gốc được viết các đây 10 năm, trong suốt quá trình đó, có nhiều công cụ có thể làm việc tương tự và tốt hơn Capistrano).

Khi bạn đã “outsourcing” và tất cả các máy chủ ứng dụng đều đăng chạy với code mới nhất, giờ bạn có thể tạo một file ảnh (image file) từ một trong những máy chủ ứng dụng (AWS gọi nó là AMI – Amazon Machine Image.). Sử dụng AMI như một “super-clone”, các instance máy chủ ứng dụng có thể được tạo mới từ AMI đó. Khi bạn muốn thêm một instance/clone, chỉ cần triển khai phiên bản code mới nhất một lần và bạn đã sẵn sàng.

Hết ngày 1!