Hành trình xây dựng Kiến trúc Cloud-Native: Bài #1 – Chuẩn bị ứng dụng cho việc tăng trưởng tốc độ cao (Hypergrowth) 

Trong chuỗi bài này, chúng ta sẽ dùng ví dụ một công ty về thương mại điện tử với các thách thức về việc tăng trưởng tốc độ cao (hypergrowth). Hành trình của họ từ việc chạy các ứng dụng dạng monolith (loại ứng dụng nguyên khối mà tập trung các tính năng tại một hệ thống, không được chia nhỏ thành các microservices) đến ứng dụng dạng Cloud-Native (Thuần chạy trên Cloud), thông qua đó sẽ cung cấp  thiết kế về mặt kiến trúc, và chiến lược mà bạn có thể ứng dụng trở nên linh hoạt và sáng tạo.

Phần sau của chuỗi bài này, chúng tôi sẽ chia sẻ các định vị những thử thách một cách tức thời và tạo sự thay đổi từng chút một để ứng dụng cloud-native theo hướng riêng (domain driven cloud native application)

Trong bài đầu tiên này, chúng ta sẽ định nghĩa về tăng trưởng tốc độ cao (hypergrowth), mô tả thiết kế hệ thống hiện tại và mức độ ưu tiên trong kinh doanh của công ty. Và cuối cùng chúng ta sẽ bàn về các thử thách kỹ thuật trong các giai đoạn tăng trưởng tốc độ cao.

Tăng trưởng tốc độ cao (hypergrowth) là gì?

Tăng trưởng tốc độ cao có thể xảy ra trong các sự kiện đã được hoạch định như Black Friday, hay các yếu tố bên ngoài như thay đổi chính sách chính phủ.

Việc này đặt ra các thử thách về nền tảng và công nghệ, cụ thể đó là việc mở rộng các ứng dụng Backend mà không ảnh hưởng đến người dùng. Điều này yêu cầu sự tối ưu hoá thiết kế hệ thống tại các lớp (layer), hay có nghĩa là việc suy nghĩ lại về cách ứng dụng được kiến trúc. Để làm được điều này bạn cần ứng dụng những nguyên lý phát triển ứng dụng, cụ thể là microservices, các cơ sở dữ liệu chuyên biệt, các quy trình tự động release phần mềm; mô hình vận hành serverless; tự động và liên tục bảo mật.

Thiết kế hệ thống hiện tại

Trong ví dụ về công ty thương mại điện tử, ứng dụng được chạy với thiết kế như sau:

  • Ứng dụng dạng monolith (máy chủ ứng dụng và máy chủ web) chạy trên Amazon EC2. Kết nối đến cơ sở dữ liệu PostgreSQL chạy trên Amazon RDS
  • Cơ sở dữ liệu (CSDL) có nhiều bảng lớn (kích thước hơn 200GB) được thiết kế để giảm thiểu số lượng gọi đến CSDL. Các bảng này có hàng trăm cột để giảm thiểu các câu lệnh JOIN và tăng thông lượng của hệ thống. CSDL triển khai kiến trúc Multi-AZ để đảm bảo tính sẵn sàng (high availability).
  • Ứng dụng monolith viết bằng Java và triển khai dạng biên dịch bao gồm tất cả phụ thuộc và thư viện kích thước lớn hơn 5GB. Đội ngũ mất 2-3 giờ để biên dịch và kiểm thử mỗi khi lập trình viên commit mã nguồn mới.
  • Ứng dụng được thiết kế tự động mở rộng dựa trên lưu lượng người dùng và các chỉ số khác như mức độ sử dụng CPU, mức độ sử dụng bộ nhớ, và tần suất lỗi.

Với thiết kế hệ thống hiện tại, ứng dụng có thể mở rộng 03 lần tăng trưởng lưu lượng người dùng. Tuy nhiên, trong một vài tuần đặc biệt, hệ thống có thể tăng trưởng đến 10 lần và còn có thể mở rộng hơn, điều này dẫn đến tăng trưởng tốc độ cao.

Hình 1 – Mô hình kiến trúc tăng trưởng tốc độ cao

Ưu tiên kinh doanh

Trong khi ứng dụng đã được thiết kế để đáp ứng sự tăng trưởng 03 lần về lưu lượng người dùng. Với một số yêu cầu tăng trưởng tăng thêm, công ty đã lựa chọn tập trung đảm bảo tính ổn định (reliability) và mở rộng (scalability) thông qua nhận thức được các thử thách sau:

Một vài các ưu tiên cốt lõi để đáp ứng tăng trưởng tốc độ cao:

  • Ngăn ngừa mất doanh thu – Bởi vì việc tăng trưởng lưu lượng người dùng theo cấp số mũ, hệ thống dễ dẫn đến mất truy xuất và mất doanh thu do khách hàng không thể truy xuất được dịch vụ. Đội ngũ vận hành thiết lập mục tiêu để nhận dạng tất cả các điểm thắt cổ chai và lỗi đơn (single point of failure) mà có thể dẫn đến hệ thống mất truy xuất.
  • Giảm thiểu khách hàng dừng sử dụng dịch vụ (Customer Churn) – Công ty đánh giá tỉ lệ khách hàng dừng sử dụng dịch vụ và cách để tăng trải nghiệm khách hàng thay vì tập trung vào tìm kiếm khách hàng mới.
  • Tăng cường kiểm soát chi phí và sự rõ ràng – Đội ngũ tài chính quan sát chặt chẽ các khoản chi phí và kiểm tra cách mở rộng tính rõ ràng trong chi trả giữa các đội ngũ, tính năng, và sản phẩm.
  • Thời gian đưa sản phẩm tới thị trường – Bởi sự tăng trưởng khách hàng và nhu cầu sử dụng, công ty cần phát triển và đưa ra các sản phẩm / dịch vụ tương ứng. Họ thiết lập mục tiêu giảm thiểu chu kỳ vòng đời phát triển và phát triển cơ chế nâng cao tốc độ phát triển.

Thử thách về mặt kỹ thuật 

Phần này sẽ mô tả các thử thách chính nhóm theo những quan sát về vận hành và kiến trúc được tổ chức bởi đội ngũ AWS.

Application (Ứng dụng)
  • Ứng dụng ràng buộc chặt chẽ (Tight coupling & dependency between modules) – Ứng dụng hiện tại được thiết kế để mở rộng theo toàn bộ các thành phần chứ không mở rộng từng phần. Điều này gây lãng phí tài nguyên hệ thống. Hơn nữa một vài phần hệ thống không được cấu hình mở rộng theo tỉ lệ như nhau dẫn tới lỗi hệ thống.
  • Việc mở rộng kém hiệu quả – Ứng dụng mở rộng dựa vào Amazon EC2 Auto Scaling để tự động thêm máy chủ mới khi có thể tải hệ thống. Tuy nhiên, việc mở rộng này cần tối thiểu 05 phút để các máy chủ này sẵn sàng tiếp nhận các yêu cầu từ người dùng. Điều này bởi vì để một máy chủ ở trạng thái sẵn sàng tiếp nhận yêu cầu cần trải qua các bước như cài đặt tất cả các phụ thuộc, khởi động khối ứng dụng monolith, và những kiểm tra nhanh với các dịch vụ.
Database (CSDL)
  • Giới hạn về thông lượng hệ thống – CSDL được chạy trên Amazon RDS Multi-AZ r5.24xlarge và đã hầu hết tới cực hạn về mở rộng theo chiều dọc. Liên tiếp có nhiều lỗi về tối đa lượng kết nối, thắt cổ chai CPU, và thời gian để thực hiện một câu truy vấn. Ứng dụng monolith gởi các câu lệnh đọc / ghi đến CSDL với kỳ vọng thời gian phản hồi ít hơn 10ms (1/100 giây).
  • Các giao dịch chạy thời gian dài (long running transaction) – CSDL hiện tại có hàng trăm cột. Thiết kế này hoạt động tốt theo kỳ vọng thông lượng hệ thống trong quá khứ. Tuy nhiên, hiện tại chúng bộc lộ những yếu điểm ví dụ như: mỗi khi có một câu lệnh cập nhật, chúng cần cập nhật hàng trăm dòng, điều này khiến cho các câu lệnh đọc bị khoá trong khoảnh khắc đó. Hơn nữa câu lệnh đọc sẽ lấy một lượng lớn dữ liệu không cần thiết.
DevOps 
  • Vòng đời release lâu hơn – Nhiều đội phát triển phần mềm cùng cộng tác và commit mã nguồn vào nhánh chính (main branch) của hệ thống kiểm soát phiên bản (SVC – Source Version Control). Mỗi khi có sự thay đổi, việc cập nhật này sẽ được phản ánh trong các môi trường phát triển phần mềm như Dev, Test, Production một cách độc lập bởi vì chúng ta đã tạo CI/CD pipeline để phòng chống các thay đổi ngoài ý muốn đến môi trường Production. Điều này đòi hỏi sự hợp tác giữa các đội ngũ để đảm bảo phiên bản đúng của phụ thuộc được triển khai trên môi trường Production và được phê duyệt bởi đội ngũ kiểm thử.
Bảo mật, Vận hành, và Giám sát 
  • Giới hạn mỗi tài khoản và thử thách về bảo mật – Tất cả môi trường (Dev, Test, Pre-production, Production) chạy trên một tài khoản đơn Amazon Web Services. Bởi vì ứng dụng tăng trưởng nhanh nên việc giám sát các giới hạn của tài khoản cũng cần được quan tâm. Bởi vì chúng ta không thay đổi nhiều từ thiết kế ban đầu (triển khai sử dụng một Amazon VPC cho mỗi môi trường, chúng ta gặp phải soft-limit của số lượng VPC có thể tạo trong mỗi Region. Chúng ta cũng gặp phải các giới hạn dịch vụ như là số lượng API Calls đồng thời đến Amazon S3, số lượng IAM Users, số lượng máy chủ Amazon EC2 on-demand khởi chạy, và số lượng Launch configuration cho nhóm Amazon EC2 Auto Scaling Group.
  • Nâng cao khả năng dò tìm lỗi và thời giản khắc phục sự cố – Hệ thống log hiện tại cung cấp thông tin về những thành phần đơn lẻ nhưng thiết đi góc nhìn liền mạch của toàn bộ hệ thống. Điều này gây khó khăn khi cần dò tìm một lỗi xảy ra, đặc biệt ở môi trường Production.
Business Continuity (Tính liên tục trong kinh doanh)
  • Tính sẵn sàng – như đề cập trong Reliability Pillar Whitepaper, Độ sẵn sàng tổng thể hệ thống có thể khác với độ sẵn sàng của từng thành phần. Độ sẵn sàng được tính toán với những phụ thuộc là 99%. Đối với tính quan trọng của hệ thống này với tổ chức, thiết kế hệ thống hiện tại không đảm bảo mức độ dịch vụ mới với độ sẵn sàng 99,99%.

Kết luận 

Trong bài đầu tiên này chúng ta đã định nghĩa về tăng trưởng tốc độ cao và liệt kê các thử thách mà công ty đang gặp phải. Trong các bài tiếp theo, chúng ta sẽ bàn về kiểu mẫu kiến trúc, công cụ và chiến lược để nhận diện các thử thách. Chúng ta cũng chia sẻ cách tạo ra các thay đổi một cách từ từ để đạt được kiến trúc cloud-native. Trong bài tiếp theo chúng ta sẽ nói về những kiểu mẫu thiết kế để tối đa thông lượng hệ thống.


Bài được dịch từ bài viết trên AWS Blogs, bạn có thể xem bài viết gốc tại đây.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: