bởi Rielah De Jesus và David Murray | vào ngày 9 tháng 5 năm 2024 | trong Amazon DynamoDB, Case Study, Customer Solutions, Intermediate (200) | Permalink |  Comments |  Share

Heroku là một giải pháp quản lý hoàn toàn nền tảng như một dịch vụ (PaaS) mà làm cho việc triển khai, vận hành và mở rộng các ứng dụng trên AWS trở nên dễ dàng đối với các nhà phát triển. Được thành lập vào năm 2007 và là một phần của Salesforce từ năm 2010, Heroku là nền tảng được lựa chọn cho hàng triệu ứng dụng-từ các nhóm phát triển tại các công ty khởi nghiệp nhỏ đến các doanh nghiệp lớn với quy mô triển khai lớn. Để duy trì tất cả các ứng dụng đó hoạt động trơn tru yêu cầu sự đầu tư liên tục, đáng kể vào cơ sở hạ tầng mà hỗ trợ nền tảng, sử dụng các khối xây dựng có sẵn từ AWS.

Trong bài đăng này, chúng ta thảo luận về một quá trình nâng cấp cơ sở hạ tầng mà Heroku đã hoàn thành vào năm 2023, di chuyển phần cơ sở lưu trữ backend cho các tính năng metrics ứng dụng và cảnh báo của họ từ các cụm Apache Cassandra tự quản lý sang Amazon DynamoDB. Heroku đã có thể hoàn thành quá trình di chuyển này mà không gây ảnh hưởng gì đến khách hàng. Việc di chuyển sang DynamoDB đã tăng độ tin cậy cho nền tảng của họ đồng thời giảm chi phí phục vụ. Trong bài  blog này, chúng ta đi sâu vào kiến trúc tổng thể của hệ thống được đề cập, tại sao họ chuyển sang DynamoDB, cách họ hoàn thành quá trình di chuyển, và kết quả họ đạt được kể từ hoàn thành quá trình đó.

Các số liệu như một dịch vụ

Các số liệu ứng dụng của Heroku được hỗ trợ bởi các số liệu nội bộ dưới dạng dịch vụ (MetaaS). MetaaS thu thập các số liệu quan sát khác nhau từ các ứng dụng chạy trên Heroku, chẳng hạn như lượng thời gian cần thiết để phục vụ một yêu cầu HTTP cụ thể. Những quan sát thô này được tổng hợp để tính toán số liệu thống kê trên mỗi ứng dụng và trên mỗi phút như thời gian phản hồi trung bình, tối đa và 99 phần trăm. Số liệu chuỗi thời gian thu được được lập biểu đồ cho khách hàng trong bảng điều khiển Heroku, cũng như được sử dụng để thúc đẩy chức năng cảnh báo và tự động mở rộng quy mô.

Về cốt lõi, MetaaS là một nền tảng xử lý dữ liệu chuỗi thời gian đa người dùng nền tảng quy mô lớn. Hàng trăm nghìn quan sát mỗi giây ban đầu được đưa vào Apache Kafka trên Heroku. Một tập hợp các công việc xử lý luồng sử dụng những quan sát từ Kafka, tính toán các số liệu khác nhau mà Heroku theo dõi cho từng ứng dụng của khách hàng, xuất dữ liệu kết quả chuỗi thời gian trở lại Kafka, và cuối cùng ghi nó vào một cơ sở dữ liệu—ban đầu là Apache Cassandra trên Amazon Elastic Compute Cloud (Amazon EC2)—cho việc lưu trữ và truy vấn dài hạn. Cơ sở dữ liệu chuỗi thời gian của MetaaS lưu trữ nhiều terabytes dữ liệu, với hàng chục nghìn điểm dữ liệu mới được ghi mỗi giây và cao điểm là một vài nghìn truy vấn đọc mỗi giây.

Sơ đồ dưới đây minh hoạ kiến trúc nguyên bản.

Lý do chọn DynamoDB

Thiết lập của MetaaS với Cassandra đã phục vụ Heroku tốt trong nhiều năm. Tuy nhiên, đến cuối năm 2022, đội kỹ sư Heroku đã bắt đầu khám phá các tùy chọn khác cho cơ sở lưu trữ backend. Các cụm Kafka mà MetaaS sử dụng được cung cấp bởi Apache Kafka trên Heroku, được hỗ trợ bởi một đội với nhiều kinh nghiệm trong việc duy trì và điều chỉnh các cụm Kafka. Các cụm Cassandra, mặt khác, là dành riêng cho MetaaS.

Heroku tin rằng điều quan trọng là phải chuyển sang một dịch vụ được quản lý, vận hành và duy trì bởi một nhóm chuyên gia giống như cụm Kafka của họ – họ chỉ có một đội kỹ sư rất nhỏ giám sát cơ sở hạ tầng cơ sở dữ liệu. Họ đang tìm kiếm một cơ sở dữ liệu được quản lý trên AWS mà phù hợp cho việc lưu trữ một lượng lớn dữ liệu trong một hệ thống phân tán, có thể mở rộng trong khi vẫn duy trì hiệu suất ghi nhanh ở mọi quy mô. Các nhóm khác tại Heroku đã sử dụng DynamoDB cho việc lưu trữ và xử lý dữ liệu của họ mà có các yêu cầu tương tự về độ nhất quán và hiệu suất. Điều này đã làm cho DynamoDB trở thành một lựa chọn đương nhiên cho khối lượng công việc MetaaS.

Một quá trình di chuyển cẩn thận 

Với kế hoạch đã được lập ra và mã được viết, tất cả những gì còn lại là nhiệm vụ hoán đổi cơ sở lưu trữ backend của một hệ thống phân tán, quy mô lớn, thông lượng cao mà không gây ảnh hưởng đến khách hàng hiện tại. Kiến trúc của MetaaS đã mang lại cho Heroku một lợi thế đáng kể—họ đã có một loạt công việc xử lý luồng để ghi dữ liệu chuỗi thời gian từ Kafka đến Cassandra. Điều này giúp họ dễ dàng thiết lập một nhóm công việc xử lý luồng để ghi cùng một loại dữ liệu đó vào DynamoDB mà không có tác động rõ rệt nào đến phần còn của hệ thống như bước đầu tiên của quá trình di chuyển.

Các chỉ số vận hành rất quan trọng đối với khách hàng của Heroku. Để đảm bảo rằng dữ liệu được ghi thành công vào DynamoDB, nhóm đã triển khai một loạt các bài kiểm tra khác nhau mà được xây dựng dựa trên kiểm thử đơn vị và tích hợp truyền thống của họ. Họ bắt đầu chạy một tỉ lệ nhỏ truy vấn đọc đến MetaaS mà đọc từ cả Cassandra và DynamoDB để xác nhận rằng dữ liệu được nhất quán trong cả hai cơ sở dữ liệu. Mọi truy vấn mà tạo ra kết quả khác nhau giữa hai đường dẫn mã đều được ghi lại. Sau khi thử nghiệm trong môi trường pre-production, họ tăng dần thử nghiệm cho đến khi 100% các truy vấn được chạy qua cả hai đường dẫn mã. Sự thay đổi này cũng không có tác động rõ ràng, vì khách hàng vẫn nhận được kết quả từ đường dẫn mã Cassandra, tuy nhiên nó cho phép họ tìm ra và khắc phục một số trường hợp phức tạp mà đã vượt qua kiểm thử đơn vị và tích hợp truyền thống của họ.

Một sự chuyển dịch suôn sẻ

Với việc thử nghiệm xác thực dữ liệu cho thấy rằng DynamoDB liên tục trả về kết quả giống như Cassandra, việc họ sẵn sàng để chuyển sang chỉ là vấn đề về thời gian. MetaaS lưu trữ dữ liệu không quá 30 ngày, sau đó dữ liệu sẽ cũ đi và bị xoá (với DynamoDB, sử dụng tính năng TTL tiện ích). Điều này có nghĩa rằng không cần phải sắp xếp việc nâng và chuyển dữ liệu lịch sử từ Cassandra sang DynamoDB. Sau khi xác thực rằng cùng một nguồn dữ liệu được ghi vào cả hai nơi, họ có thể chỉ cần đợi cho đến khi hai cơ sở dữ liệu được đồng bộ hoá.

Bắt đầu lại với các môi trường thử nghiệm của mình, Họ đã bắt đầu cắt giảm dần các truy vấn mà chỉ đọc từ DynamoDB, cẩn thận đề phòng trường hợp có bất kỳ báo cáo nào của khách hàng về hành vi kỳ lạ mà bằng cách nào đó bị bỏ sót trước đó. Không có truy vấn nào, và 100% các truy vấn tới MetaaS đã được DynamoDB phục vụ từ tháng 5 năm 2023. Heroku đã đợi một vài tuần chỉ để đảm bảo rằng họ không cần phải quay lại các thay đổi trước đó.

Sơ đồ sau minh hoạ kiến trúc đã được cập nhập.

Kết quả

Sau hơn một năm trải nghiệm, Heroku đang cảm thấy hài lòng về lựa chọn sử dụng dịch vụ cơ sở dữ liệu được quản lý của họ. DynamoDB đã hoạt động ổn định và hiệu quả ở quy mô lớn. Heroku đã giảm được tới 90% chi phí vận hành cho việc vá lỗi và điều chỉnh các máy chủ cơ sở dữ liệu, đạt được mục tiêu ban đầu của họ. Ngoài ra, DynamoDB hoá ra vừa nhanh hơn vừa rẻ hơn so với các cụm Cassandra trên Amazon EC2. Nó đã giảm độ trễ tối đa cho việc truy vấn xuống 75% và giảm chi phí khoảng 50%.

Ví dụ, như được hiển thị trong biển đồ sau, trước 18:00, họ đang truy vấn Cassandra và nhận thấy độ trễ p99 tăng đột biến khá đều đặn, trong khi sau 18:00, họ chuyển sang truy vấn DynamoDB và nhận thấy không còn các đỉnh đó nữa.

Bài học kinh nghiệm

Các dịch vụ của Heroku truy cập DynamoDB thông qua VPC endpoints. Các chính sách AWS Identity and Access Management (IAM) được thiết lập để yêu cầu rằng lưu lượng truy cập phải được gửi tới DynamoDB thông qua các VPC endpoint, điều này cho phép các ứng dụng trong VPC của bạn truy cập DynamoDB mà không lộ ra ngoài internet công cộng.

Heroku sử dụng tính năng tự động mở rộng quy mô của DynamoDB để quản lý dung lượng đọc đã cấp phát cho các bảng MetaaS, bởi vì lưu lượng truy vấn tự nhiên thay đổi trong suốt tuần phụ thuộc vào số lượng khách hàng đang xem số liệu trong bảng điều khiển Heroku. Mẫu ghi của MetaaS có tính dự đoán cao hơn nhiều, vì vậy họ có thể điều chỉnh thủ công dung lượng ghi cho các bảng của họ, vượt quá mục tiêu tối đa 90% của tự động mở rộng quy mô. Đối với khối lượng công việc có mức tiêu thụ trung bình với một vài đỉnh điểm, tự động mở rộng quy mô có thể là một cách tuyệt vời để tiết kiệm chi phí so với việc cấp phát cho công suất cao nhất; đối với các khối lượng công việc có tính dự đoán trước, nó có thể giúp bạn cấp phát dung lượng cần thiết để tiết kiệm chi phí.

Việc ghi vào DynamoDB luôn tiêu tốn ít nhất một đơn vị dung lượng ghi (WCU), nhưng có thể tiêu tốn nhiều hơn dựa trên kích thước của bản ghi được ghi—1 WCU cho mỗi KB dữ liệu, tối đa giới hạn kích thước bản ghi là 400KB trong DynamoDB. Mặc dù hầu hết các bản ghi hồ sơ MetaaS đều rất nhỏ, họ đã phát hiện ra một số ngoại lệ mà vượt quá giới hạn 400 KB. Heroku đã có thể giải quyết được vấn đề đó (và cũng tiết kiệm được một khoản chi phí) bằng cách nén gzip những bản ghi lớn hơn này trước khi ghi chúng vào DynamoDB. Dữ liệu MetaaS được truy vấn tương đối ít, do đó chi phí về thời gian nén và giải nén dữ liệu của CPU là không đáng kể so với việc giảm các WCU và sự tiện lợi khi không thể thay đổi lược đồ của chúng.

Cuối cùng, ngay từ giai đoạn đầu quá trình thử nghiệm của họ, họ đã gặp phải một số điểm nghẽn bất ngờ khi ghi dữ liệu vào DynamoDB. Yếu tố hạn chế chính hoá ra lại là thiếu cấu hình của HTTP client được sử dụng bởi SDK của DynamoDB—đối với các khối lượng công việc quy mô cao, việc thực hiện một số tính chỉnh thay vì chỉ sử dụng các thiết lập mặc định là rất đáng giá. Họ đã thấy được sự cải thiện đáng kể khi mà họ tăng số lượng kết nối đồng thời cho phép đến DynamoDB, điều chỉnh lại số lượng kết nối nhàn rỗi để giữ lại cho việc tái sử dụng trong tương lai, và cấu hình thời gian chờ cũng như các lần thử lại mà một cách tích cực hơn so với các thiết lập mặc định.

Kết luận

Trong bài đăng này, chúng ta thảo luận về cách mà Heroku đã nâng cấp cơ sở hạ tầng bằng cách chuyển từ các cụm Cassandra tự quản lý sang DynamoDB. Heroku đã hoàn thành việc di chuyển này mà không gây ảnh hưởng đến khách hàng, nâng cao độ tin cậy cho nền tảng của họ đồng thời giảm các chi phí. Heroku đã giảm chi phí cơ sở hạ tầng cloud lên đến 50% sau khi chuyển từ Cassandra tự quản lý trên EC2 sang DynamoDB. Sự cải thiện về hiệu suất là do hiệu suất truy vấn của DynamoDB có thể dự đoán được nhiều hơn – với Cassandra đôi khi chúng có độ trễ tăng đột biến lên tới 80 ms khi lưu lượng truy cập cao điểm. Với DynamoDB họ đang chạy các truy vấn liên tục dưới 20 ms, điều này đã giảm độ trễ đáng kể trong việc cung cấp số liệu tới các khách hàng của họ.

Bạn có bất kỳ mẹo hay câu hỏi nào khác về việc chạy khối lượng công việc quy mô cao trên DynamoDB? Hãy cho chúng tôi biết ở phần bình luận! Để bắt đầu với DynamoDB, hãy xem hướng dẫn dành cho nhà phát triển và bảng điều khiển AWS DynamoDB.

Bài đăng này là sự hợp tác chung giữa Heroku và AWS và đang được đồng xuất bản trên cả Blog của Heroku và Blog Cơ sở dữ liệu AWS.

Bạn có thể đọc bài viết gốc tại đây.