Tác giả: Mircea Bud, Alexandra Munteanu, and Daniel Urzica
Ngày phát hành: 22 JAN 2026
Chuyên mục: Amazon RDS, Customer Solutions, Database, Intermediate (200), Migration, RDS for PostgreSQL

Đây là bài đăng của khách mời từ Mircea Bud, Alexandra Munteanu và Daniel Urzica từ Tradeshift.

Vào năm 2023, Tradeshift đã di chuyển một trong những cơ sở dữ liệu PostgreSQL cốt lõi của mình từ các phiên bản Amazon Elastic Compute Cloud (Amazon EC2) tự quản lý sang Amazon Relational Database Service (Amazon RDS) cho PostgreSQL. Quyết định này được đưa ra sau khi các rủi ro vận hành và giới hạn hiệu suất ngày càng tăng khiến thiết lập hiện có trở nên không bền vững.

Cơ sở dữ liệu đã phát triển lên 18TB và hỗ trợ các dịch vụ backend chính. Nó chạy trên cơ sở hạ tầng cũ kỹ, với mức sử dụng lưu trữ cao và các quy trình khôi phục tốn thời gian. Hiệu suất suy giảm, chậm trễ trong việc vá lỗi và sự lệch lạc về kiến trúc so với phần còn lại của nền tảng đã khiến việc tiếp tục đầu tư vào thiết lập EC2 trở nên không khả thi.

Tradeshift cần một giải pháp được quản lý có thể giảm thiểu rủi ro ngừng hoạt động, cải thiện khả năng quan sát và đơn giản hóa các hoạt động liên tục. Amazon RDS đã đáp ứng các yêu cầu đó. Trong bài đăng này, chúng tôi giải thích lý do chúng tôi di chuyển sang Amazon RDS, cách chúng tôi thực hiện quá trình di chuyển và nêu bật những lợi ích vô giá mà nó mang lại về độ an toàn, tính linh hoạt và tuân thủ kiểm toán.

Những thách thức của cơ sở dữ liệu PostgreSQL tự quản lý trên EC2

Thiết lập PostgreSQL dựa trên EC2 tự quản lý ngày càng trở nên khó duy trì do chi phí vận hành. Quy trình khôi phục chậm và phần lớn là thủ công. Recovery Time Objective (RTO) đã tăng lên gần 48 giờ. Recovery Point Objective (RPO) dao động quanh mức một giờ.

Cụm được cấp phát trên các phiên bản i3.metal với bộ nhớ NVMe cố định. Mức sử dụng dung lượng liên tục vượt quá 90 phần trăm, và việc tăng dung lượng yêu cầu thời gian ngừng hoạt động và cấu hình lại. Vì EC2 i3.metal sử dụng bộ nhớ cục bộ có kích thước cố định theo thiết kế (để mang lại hiệu suất IOPS cao nhất), việc mở rộng bộ nhớ đó yêu cầu cấu hình lại. Các giải pháp thay thế đã được yêu cầu, như gắn các volume EBS và thay đổi lược đồ cơ sở dữ liệu để sử dụng các tablespace liền kề, nơi các bảng ít quan trọng nhất cuối cùng có thể được di chuyển.

Việc tuân thủ vá lỗi cũng là một mối quan tâm. Các bản vá hệ điều hành và cơ sở dữ liệu không được áp dụng đủ thường xuyên để đáp ứng các tiêu chuẩn kiểm toán. Điều này là do quy trình thủ công phức tạp và tốn thời gian cần thiết cho việc nâng cấp:

• Trong trường hợp nâng cấp hệ điều hành, giải pháp cũ yêu cầu tạo một bản sao đọc mới, cho phép nó đồng bộ hóa (mất hàng giờ), thăng cấp nó thành bản chính, và sau đó thay thế bản sao cũ bằng một bản khác. Quy trình này yêu cầu tối thiểu 20 phút ngừng hoạt động nếu tất cả các bước diễn ra suôn sẻ.
• Đối với nâng cấp phiên bản PostgreSQL, thời gian ngừng hoạt động thậm chí còn lâu hơn vì dịch vụ ứng dụng sẽ không khởi động nếu không có bản sao đọc.

Cụm này là cụm cuối cùng trong hệ thống của chúng tôi vẫn được quản lý bằng Puppet (các manifest tùy chỉnh được phát triển nhưng dựa trên kho lưu trữ puppetlabs-postreql công khai), điều này làm tăng rủi ro và giảm khả năng chuẩn hóa các thực hành vận hành của chúng tôi.

Tại sao chúng tôi chọn Amazon RDS cho PostgreSQL

Sau khi xem xét các lựa chọn, chúng tôi đã chọn Amazon RDS cho PostgreSQL. Nó cung cấp một môi trường PostgreSQL được quản lý hoàn toàn với khả năng tương thích cao và công cụ trưởng thành.

Cải thiện khả năng sẵn sàng và khôi phục

Amazon RDS đã mang lại những cải tiến đáng kể về khả năng sẵn sàng và khôi phục. Khôi phục tại một thời điểm (PITR) sau sự cố hỏng dữ liệu, có thể yêu cầu khôi phục cơ sở dữ liệu bao gồm khôi phục snapshot (RTO trong vài phút) và phát lại WAL từ kho lưu trữ (RTO trong vài giờ). Đối với lỗi phần cứng, RTO nằm trong khoảng vài phút. RDS cũng mang lại các khoảng RPO ngắn hơn nhiều, nâng cao khả năng bảo vệ dữ liệu của chúng tôi. Tự động chuyển đổi dự phòng, tạo snapshot và sao lưu (RDS backup) đã làm cho các kịch bản khôi phục trở nên dễ đoán hơn và ít phụ thuộc vào các bước thủ công.

Đơn giản hóa việc vá lỗi và sẵn sàng kiểm toán

Amazon RDS xử lý các bản cập nhật thường xuyên cho cả engine PostgreSQL và hệ điều hành cơ bản. Điều này đã đơn giản hóa quy trình kiểm toán của chúng tôi và loại bỏ sự lệch lạc về bản vá.

Khả năng hiển thị tốt hơn về hành vi truy vấn

Bảng điều khiển Performance Insights tích hợp sẵn đã giúp chúng tôi giám sát các mẫu khối lượng công việc trong thời gian thực. Các nhóm của chúng tôi có thể xác định và giải quyết các truy vấn chậm nhanh hơn với các cảnh báo và số liệu của Amazon CloudWatch. Chúng tôi cũng dựa vào một số tiện ích mở rộng PostgreSQL được RDS hỗ trợ:

• log_fdw và postgres_fdw để thu thập nhật ký cấp hệ điều hành trong cơ sở dữ liệu
• pg_cron để lên lịch các tác vụ bảo trì cơ sở dữ liệu nội bộ
• aws_s3 để tương tác với Amazon Simple Storage Service (Amazon S3) như một giải pháp lưu trữ dài hạn cho nhật ký kiểm toán và dữ liệu cũ

Những công cụ này đã cải thiện khả năng của chúng tôi trong việc phát hiện và phản hồi các vấn đề hiệu suất mà không cần tự động hóa bên ngoài hoặc các tác nhân của bên thứ ba.

Thực hiện di chuyển với thời gian ngừng hoạt động tối thiểu

Di chuyển một hệ thống sản xuất có quy mô này đòi hỏi phải lập kế hoạch cẩn thận. Tập dữ liệu 18TB có một luồng lưu lượng ghi ổn định và thời gian ngừng hoạt động phải được giữ ở mức tối thiểu.

Chúng tôi đã chọn replication logic gốc của PostgreSQL làm phương pháp di chuyển. Nó cung cấp khả năng tương thích hoàn toàn với khối lượng công việc của chúng tôi và không yêu cầu quyền truy cập cấp hệ điều hành. Với replication logic, chúng tôi đã đồng bộ hóa dữ liệu tăng dần mà không chặn các ghi của ứng dụng.

Nhóm của chúng tôi đã thiết kế tải ban đầu để giảm thiểu tác động hiệu suất lên cơ sở dữ liệu nguồn bằng cách trải rộng hoạt động đó trong khoảng thời gian hai tuần. Điều này liên quan đến việc chia công việc thành 20 publication (sử dụng các tiêu chí nhóm bảng khác nhau) và giới hạn số lượng worker replication cho mỗi slot replication logic đang hoạt động.

Chúng tôi đã tạo một cụm Amazon RDS mới, sau đó thiết lập các slot replication để phản ánh các thay đổi từ cụm PostgreSQL tự quản lý (chạy trên EC2). Sau khi độ trễ replication được kiểm soát và dữ liệu được xác thực, chúng tôi đã lên lịch một khoảng thời gian ngừng hoạt động ngắn để thực hiện chuyển đổi cuối cùng. Thông tin xác thực và cấu hình người dùng đã được di chuyển mà không có thay đổi. Các dịch vụ Kubernetes đã được cập nhật để trỏ đến các endpoint cơ sở dữ liệu mới. IAM (xác thực cơ sở dữ liệu) đã thay thế việc xử lý thông tin xác thực thủ công để truy cập đọc, điều này phù hợp với các tiêu chuẩn hiện có của chúng tôi cho phần còn lại của hệ thống Amazon RDS.

Cải tiến kiến trúc: Một kiến trúc sạch hơn, có khả năng mở rộng hơn

Quá trình di chuyển cũng giúp chúng tôi loại bỏ các thành phần cũ khỏi nền tảng của mình. Chúng tôi đã ngừng sử dụng tính năng khám phá dịch vụ dựa trên Consul, trước đây đã xử lý việc phân giải endpoint cơ sở dữ liệu. Thay vào đó, tên dịch vụ gốc của Kubernetes hiện cung cấp kết nối sạch và nhất quán.

Xác thực IAM đã thay thế việc quản lý người dùng và mật khẩu thủ công để truy cập vận hành. Điều này đã cải thiện bảo mật và đơn giản hóa việc giới thiệu cho người dùng và dịch vụ mới.

Chúng tôi cũng đã giới thiệu một cách tiếp cận mới để truy vấn cơ sở dữ liệu trên các môi trường. Bằng cách kết hợp xác thực IAM của RDS với các công cụ tích hợp sẵn cho PostgreSQL (aws-cli, jq, psql), chúng tôi có thể thực hiện các truy vấn giữa các phiên bản trong và giữa các VPC. Các script này đã thay thế các công cụ tùy chỉnh rời rạc và hiện chúng cung cấp khả năng hiển thị vào hệ thống dưới dạng một tập hợp bản ghi đầu ra thống nhất.

Kết quả và tác động kinh doanh

Quá trình di chuyển đã tạo ra những cải tiến có thể đo lường được trong nhiều lĩnh vực hoạt động của nền tảng của chúng tôi.

Cải thiện khả năng sẵn sàng và khả năng phục hồi

Khôi phục từ lỗi giờ nay nhanh hơn và dễ đoán hơn. Thời gian khôi phục giảm đáng kể và tần suất các điểm sao lưu tăng lên, nâng cao tư thế phục hồi của chúng tôi. Khả năng mở rộng điện toán và IOPS một cách độc lập có nghĩa là chúng tôi có thể điều chỉnh cơ sở dữ liệu theo nhu cầu nền tảng theo thời gian thực, đặc biệt trong các sự cố hoặc lưu lượng truy cập tăng đột biến.

Hiệu quả hoạt động

Các tác vụ bảo trì như quản lý phân vùng và lưu trữ hiện được xử lý nội bộ bằng cách sử dụng pg_cron. Mặc dù việc lên lịch tác vụ có thể được thực hiện trong thiết lập EC2 bằng cách sử dụng bash-crontab, việc áp dụng tiện ích mở rộng pg_cron có nghĩa là việc lên lịch, giám sát và duy trì các tác vụ đã lên lịch giờ đây được giảm xuống chỉ còn SQL thuần túy, loại bỏ nhu cầu tương tác với hệ điều hành. Giám sát hiệu suất đã được cải thiện nhờ tích hợp sâu hơn giữa các số liệu cơ sở dữ liệu và ngăn xếp khả năng quan sát của chúng tôi.

Trải nghiệm nhà phát triển tốt hơn

Kiểm soát truy cập dựa trên IAM đã thay thế thông tin xác thực thủ công, giúp việc giới thiệu nhà phát triển và cấp phép người dùng đơn giản và an toàn hơn. Điều chỉnh truy vấn và chẩn đoán sự cố nhanh hơn nhờ khả năng hiển thị được cung cấp bởi RDS Performance Insights và các tiện ích mở rộng telemetry của PostgreSQL.

Lợi ích trên toàn nền tảng

Hệ thống RDS hiện hỗ trợ thực thi truy vấn đa môi trường dựa trên SSO. Điều này cho phép nhóm của chúng tôi kiểm tra và kiểm kê các phiên bản cơ sở dữ liệu ở quy mô lớn. Trước đây, mức độ truy cập này yêu cầu các công cụ riêng biệt và thường là nhiều bước thủ công.

Quá trình di chuyển đã điều chỉnh một trong những dịch vụ backend quan trọng nhất của chúng tôi với phần còn lại của kiến trúc nền tảng và loại bỏ nợ kỹ thuật để chúng tôi có thể mở rộng quy mô tự tin hơn khi doanh nghiệp phát triển.

Kết luận

Bằng cách di chuyển sang Amazon RDS cho PostgreSQL, chúng tôi đã thay thế cơ sở hạ tầng cũ bằng một dịch vụ được quản lý mang lại khả năng sẵn sàng cao hơn, khả năng quan sát tốt hơn và khả năng mở rộng dễ dàng hơn. Sự kết hợp giữa replication logic và các công cụ của Amazon RDS đã mang lại cho chúng tôi một con đường hiện đại hóa rủi ro thấp, ngay cả với một tập dữ liệu lớn, đang hoạt động.

Dự án đã loại bỏ nợ kỹ thuật tồn đọng lâu năm, cải thiện sự tuân thủ và giảm chi phí vận hành khi duy trì một giải pháp PostgreSQL tùy chỉnh dựa trên EC2. Giờ đây, chúng tôi có một nền tảng tiêu chuẩn hóa cho PostgreSQL có thể phát triển theo nhu cầu của doanh nghiệp, mà không ảnh hưởng đến độ tin cậy hoặc hiệu suất.

Truy cập Amazon RDS để tìm hiểu thêm.

Về tác giả

Mircea Bud

Mircea là Kỹ sư phần mềm cấp cao tại Tradeshift, nơi anh đã quản lý hệ thống các phiên bản RDBMS của nền tảng từ năm 2017, dẫn dắt nhóm DBRE (hay còn gọi là DBA). Bên cạnh các hoạt động bảo trì và giám sát liên tục, nhóm DBRE cũng duy trì mối quan hệ chặt chẽ với các nhóm phát triển, hỗ trợ triển khai các yếu tố liên tục cải thiện hiệu quả và khả năng mở rộng khối lượng công việc trên nhiều môi trường khác nhau.

Alexandra Munteanu

Alexandra, cựu Kỹ sư độ tin cậy cơ sở dữ liệu (Database Reliability Engineer) của Tradeshift (2021-2024), đã đóng vai trò quan trọng trong dự án di chuyển sang RDS, bằng cách thiết kế các giải pháp tự động hóa script sáng tạo giúp chuẩn bị, kiểm thử, xác thực và thực hiện quá trình di chuyển cơ sở dữ liệu sang cơ sở hạ tầng hiện đại hóa.

Daniel Urzica

Daniel, hiện là Giám đốc Kỹ thuật tại Tradeshift, đã đóng vai trò quan trọng trong dự án, hỗ trợ nhóm DBRE và đảm bảo tất cả các vấn đề tiềm ẩn được giải quyết trước thời hạn. Anh cũng đảm bảo có sự đồng thuận nội bộ cho việc di chuyển, nhấn mạnh những lợi thế của việc chuyển khỏi các cơ sở dữ liệu chạy bên trong các phiên bản EC2.