Tác giả: Cristian Restrepo Lopez và Satesh Sonti
Ngày phát hành: 07 APR 2026
Chuyên mục: Amazon Q, Amazon Redshift, AWS Big Data, Intermediate (200), Monitoring and observability, Technical How-to

Các vấn đề về hiệu suất trong môi trường phân tích thường không được nhận biết cho đến khi chúng làm gián đoạn các dashboard, trì hoãn các công việc ETL hoặc ảnh hưởng đến các quyết định kinh doanh. Đối với các nhóm đang chạy Amazon Redshift Serverless, các hàng đợi truy vấn không được giám sát, các truy vấn chạy lâu hoặc các đợt tăng đột biến không mong muốn về năng lực tính toán có thể làm giảm hiệu suất và tăng chi phí nếu không được phát hiện.

Amazon Redshift Serverless giúp đơn giản hóa việc chạy phân tích ở quy mô lớn bằng cách loại bỏ nhu cầu cấp phát hoặc quản lý cơ sở hạ tầng. Tuy nhiên, ngay cả trong môi trường serverless, việc duy trì khả năng hiển thị về hiệu suất và mức sử dụng là rất cần thiết để vận hành hiệu quả và chi phí dự đoán được. Mặc dù Amazon Redshift Serverless cung cấp các dashboard tích hợp nâng cao để giám sát các chỉ số hiệu suất, việc gửi thông báo trực tiếp đến các nền tảng như Slack mang lại một cấp độ linh hoạt khác. Các cảnh báo theo thời gian thực trong quy trình làm việc của nhóm cho phép thời gian phản hồi nhanh hơn và đưa ra quyết định sáng suốt hơn mà không yêu cầu giám sát dashboard liên tục.

Trong bài viết này, chúng tôi sẽ chỉ cho bạn cách xây dựng một giải pháp giám sát serverless, chi phí thấp cho Amazon Redshift Serverless, chủ động phát hiện các bất thường về hiệu suất và gửi các cảnh báo có thể hành động trực tiếp đến các kênh Slack đã chọn của bạn. Cách tiếp cận này giúp nhóm phân tích của bạn xác định và giải quyết các vấn đề sớm, thường là trước khi người dùng của bạn nhận thấy sự cố.

Tổng quan giải pháp

Giải pháp được trình bày trong bài viết này sử dụng các dịch vụ AWS để thu thập các chỉ số hiệu suất chính từ Amazon Redshift Serverless, đánh giá chúng dựa trên các ngưỡng mà bạn có thể cấu hình linh hoạt và thông báo cho bạn khi phát hiện các bất thường.

Quy trình làm việc hoạt động như sau:

1. Thực thi theo lịch trình – Một quy tắc Amazon EventBridge kích hoạt một hàm AWS Lambda theo lịch trình có thể cấu hình (mặc định, 15 phút một lần trong giờ làm việc).
2. Thu thập chỉ số – Hàm AWS Lambda thu thập các chỉ số bao gồm các truy vấn đang chờ, các truy vấn đang chạy, năng lực tính toán (RPUs), mức sử dụng lưu trữ dữ liệu, số lượng bảng, kết nối cơ sở dữ liệu và các truy vấn chạy chậm bằng cách sử dụng Amazon CloudWatch và Amazon Redshift Data API.
3. Đánh giá ngưỡng – Các chỉ số đã thu thập được so sánh với các ngưỡng được xác định trước của bạn, phản ánh giới hạn hiệu suất và mức sử dụng chấp nhận được.
4. Cảnh báo – Khi một ngưỡng bị vượt quá, hàm Lambda sẽ xuất bản một thông báo đến một Amazon SNS topic.
5. Thông báo Slack – Amazon Q Developer in Chat applications (trước đây là AWS Chatbot) gửi cảnh báo đến kênh Slack được chỉ định của bạn.
6. Khả năng quan sát (Observability) – Nhật ký thực thi Lambda được lưu trữ trong Amazon CloudWatch Logs để khắc phục sự cố và kiểm tra.

Kiến trúc này hoàn toàn serverless và không yêu cầu thay đổi đối với các workload Amazon Redshift Serverless hiện có của bạn. Để đơn giản hóa việc triển khai, chúng tôi cung cấp một template AWS CloudFormation để cấp phát tất cả các tài nguyên cần thiết.

Điều kiện tiên quyết

Trước khi triển khai giải pháp này, bạn phải thu thập thông tin về workgroup và namespace Amazon Redshift Serverless hiện có mà bạn muốn giám sát. Để xác định các tài nguyên Amazon Redshift Serverless của bạn:

1. Mở bảng điều khiển Amazon Redshift.
2. Trong ngăn điều hướng, chọn Serverless dashboard.
3. Ghi lại tên workgroup và namespace của bạn. Bạn sẽ sử dụng các giá trị này khi khởi chạy template AWS CloudFormation của bài viết này.

Triển khai giải pháp

Bạn có thể khởi chạy stack CloudFormation và triển khai giải pháp thông qua liên kết được cung cấp.

GitHub Repo

Khi khởi chạy stack CloudFormation, hãy hoàn thành các bước sau trong AWS CloudFormation Console:

1. Đối với Stack name, nhập một tên mô tả như redshift-serverless-monitoring.
2. Xem xét và sửa đổi các tham số nếu cần cho môi trường của bạn.
3. Xác nhận rằng AWS CloudFormation có thể tạo các tài nguyên IAM với tên tùy chỉnh.
4. Chọn Submit.

Các tham số CloudFormation

Cấu hình Workgroup Amazon Redshift Serverless

Cung cấp chi tiết cho môi trường Amazon Redshift Serverless hiện có của bạn. Các giá trị này kết nối giải pháp giám sát với môi trường Redshift của bạn. Một số tham số đi kèm với các giá trị mặc định mà bạn có thể thay thế bằng cấu hình thực tế của mình.

Lịch trình giám sát

Lịch trình mặc định chạy các truy vấn SQL chẩn đoán 15 phút một lần trong giờ làm việc, cân bằng giữa khả năng phản hồi và hiệu quả chi phí. Chạy thường xuyên hơn có thể làm tăng chi phí, trong khi giám sát ít thường xuyên hơn có thể làm chậm việc phát hiện các vấn đề về hiệu suất. Bạn có thể điều chỉnh lịch trình này theo nhu cầu thực tế của mình.

Cấu hình ngưỡng

Các ngưỡng nên được điều chỉnh dựa trên đặc điểm workload của bạn.

Mẹo: Bắt đầu với các ngưỡng thận trọng và tinh chỉnh chúng sau khi quan sát hành vi cơ bản trong một đến hai tuần.

Cấu hình Lambda

Cấu hình cài đặt hàm AWS Lambda. Các giá trị mặc định được chọn phù hợp với hầu hết các kịch bản giám sát. Bạn có thể muốn thay đổi chúng chỉ trong trường hợp khắc phục sự cố.

Cấu hình bảo mật – Amazon Virtual Private Cloud (VPC)

Nếu tổ chức của bạn có yêu cầu cách ly mạng, bạn có thể tùy chọn bật triển khai VPC cho hàm Lambda. Khi được bật, hàm Lambda sẽ chạy trong các subnet VPC được chỉ định của bạn, cung cấp khả năng cách ly mạng và cho phép truy cập vào các tài nguyên chỉ có trong VPC.

Lưu ý rằng việc triển khai VPC có thể làm tăng thời gian khởi động lạnh (cold start) và yêu cầu NAT Gateway hoặc VPC endpoints để truy cập dịch vụ AWS. Chúng tôi khuyên bạn nên cấp phát các interface VPC endpoints (thông qua AWS PrivateLink) cho năm dịch vụ mà hàm Lambda gọi, điều này giúp giữ tất cả lưu lượng truy cập riêng tư mà không phải chịu chi phí định kỳ của NAT Gateway.

Cấu hình bảo mật – Mã hóa

Nếu tổ chức của bạn yêu cầu mã hóa dữ liệu khi lưu trữ, bạn có thể tùy chọn bật mã hóa AWS Key Management Service (AWS KMS) cho các biến môi trường của hàm Lambda, CloudWatch Logs và SNS topic. Khi được bật, template sẽ mã hóa từng tài nguyên bằng cách sử dụng các khóa AWS KMS mà bạn cung cấp, có thể là một khóa dùng chung duy nhất cho cả ba dịch vụ, hoặc các khóa riêng lẻ để quản lý khóa chi tiết và tách biệt kiểm toán.

Lưu ý rằng mã hóa AWS KMS yêu cầu chính sách khóa phải cấp các quyền thích hợp cho từng dịch vụ tiêu thụ (Lambda, CloudWatch Logs và SNS).

1. Trên trang xem xét, chọn I acknowledge that AWS CloudFormation might create IAM resources with custom names.
2. Chọn Submit.

Các tài nguyên được tạo

Stack CloudFormation tạo các tài nguyên sau:

• Quy tắc EventBridge để thực thi theo lịch trình
• Hàm AWS Lambda (runtime Python 3.12)
• Amazon SNS topic cho cảnh báo
• Vai trò IAM với các quyền cho CloudWatch, Amazon Redshift Data API và SNS
• CloudWatch Log Group cho nhật ký Lambda

Lưu ý: Việc triển khai CloudFormation thường mất 10–15 phút để hoàn tất. Bạn có thể theo dõi tiến độ theo thời gian thực trong tab Events của stack CloudFormation của mình.

Cấu hình sau triển khai

Sau khi stack CloudFormation đã được tạo thành công, hãy hoàn thành các bước sau.

Bước 1: Ghi lại các output của CloudFormation

1. Điều hướng đến bảng điều khiển AWS CloudFormation.
2. Chọn stack của bạn và chọn tab Outputs.
3. Ghi lại các giá trị cho LambdaRoleArn và SNSTopicArn. Bạn sẽ cần chúng trong các bước tiếp theo.

Bước 2: Cấp quyền cho Amazon Redshift

Cấp quyền cho hàm Lambda để truy vấn các bảng hệ thống Amazon Redshift để lấy dữ liệu giám sát. Hoàn thành các bước sau để cấp quyền truy cập cần thiết:

1. Điều hướng đến bảng điều khiển Amazon Redshift.
2. Trong ngăn điều hướng bên trái, chọn Query Editor V2.
3. Kết nối với workgroup Amazon Redshift Serverless của bạn.
4. Thực thi các lệnh SQL sau, thay thế <IAM Role ARN> bằng giá trị LambdaRoleArn từ các output CloudFormation của bạn:

CREATE USER "IAMR:<IAM Lambda Role>" WITH PASSWORD DISABLE;
GRANT ROLE "sys:monitor" TO "IAMR:<IAM Role>";

Các lệnh này tạo một người dùng AmazonRedshift được liên kết với vai trò IAM của Lambda và cấp cho nó vai trò Amazon Redshift sys:monitor. Vai trò này cung cấp quyền truy cập chỉ đọc vào các bảng catalog và hệ thống mà không cấp quyền cho các bảng dữ liệu người dùng.

Bước 3: Cấu hình thông báo Slack

Amazon Q Developer in chat applications cung cấp tích hợp AWS gốc và xác thực được quản lý, loại bỏ mã webhook tùy chỉnh và giảm độ phức tạp trong thiết lập. Để nhận cảnh báo trong Slack, hãy cấu hình Amazon Q Developer in Chat Applications để kết nối SNS topic của bạn với kênh Slack ưa thích của bạn:

1. Điều hướng đến Amazon Q Developer in chat applications (trước đây là AWS Chatbot) trong bảng điều khiển AWS.
2. Làm theo hướng dẫn trong tài liệu tích hợp Slack để cấp quyền truy cập AWS vào không gian làm việc Slack của bạn.
3. Khi cấu hình kênh Slack, đảm bảo rằng bạn chọn đúng AWS Region nơi bạn đã triển khai stack CloudFormation.
4. Trong phần Notifications, chọn SNS topic được tạo bởi stack CloudFormation của bạn (tham khảo giá trị output SNSTopicArn).
5. Giữ nguyên các quyền IAM chỉ đọc mặc định cho cấu hình kênh.

Sau khi cấu hình, các cảnh báo sẽ tự động xuất hiện trong Slack bất cứ khi nào các ngưỡng bị vượt quá.

Chi phí cần cân nhắc

Với cấu hình mặc định, giải pháp này phát sinh chi phí hoạt động tối thiểu. Hàm Lambda thực thi khoảng 693 lần mỗi tháng (15 phút một lần trong 8 giờ làm việc, từ Thứ Hai đến Thứ Sáu), dẫn đến chi phí hàng tháng khoảng 0,33 USD. Điều này bao gồm chi phí tính toán Lambda (0,26 USD) và các lệnh gọi API CloudWatch GetMetricData (0,07 USD). Tất cả các dịch vụ khác (EventBridge, SNS, CloudWatch Logs và Amazon Redshift Data API). Amazon Redshift Data API không có phí bổ sung nào ngoài mức tiêu thụ RPU Amazon Redshift Serverless tối thiểu cho việc thực thi truy vấn bảng hệ thống Amazon Redshift Serverless. Bạn có thể giảm chi phí bằng cách giảm tần suất giám sát (ví dụ: 30 phút một lần) hoặc tăng khả năng phản hồi bằng cách chạy thường xuyên hơn (ví dụ: 5 phút một lần) với mức tăng chi phí tương ứng.

Tất cả các chi phí là ước tính và có thể thay đổi tùy thuộc vào môi trường của bạn. Các biến thể thường xảy ra vì các truy vấn quét bảng hệ thống có thể mất nhiều thời gian hơn hoặc yêu cầu tài nguyên bổ sung tùy thuộc vào độ phức tạp của hệ thống.

Các phương pháp bảo mật tốt nhất

Giải pháp này triển khai các biện pháp kiểm soát bảo mật sau:

• Các chính sách IAM được giới hạn trong các ARN tài nguyên cụ thể cho workgroup Amazon Redshift, namespace, SNS topic và log group.
• Quyền truy cập câu lệnh Data API bị hạn chế đối với ID người dùng IAM của chính hàm Lambda.
• Vai trò cơ sở dữ liệu sys:monitor chỉ đọc để truy cập siêu dữ liệu hoạt động. Giới hạn cho vai trò được tạo bởi template CloudFormation.
• Số lượng thực thi đồng thời được dành riêng tối đa là năm.

Để tăng cường hơn nữa tư thế bảo mật của bạn, hãy xem xét các cải tiến sau:

• Bật EnableKMSEncryption để mã hóa các biến môi trường, nhật ký và tin nhắn SNS khi lưu trữ.
• Bật EnableVPC để triển khai hàm trong VPC nhằm cách ly mạng.
• Kiểm tra quyền truy cập thông qua AWS CloudTrail.

Quan trọng: Đây là mã mẫu để sử dụng phi sản xuất. Hãy làm việc với các nhóm bảo mật và pháp lý của bạn để đáp ứng các yêu cầu về bảo mật, quy định và tuân thủ của tổ chức bạn trước khi triển khai. Giải pháp này thể hiện khả năng giám sát nhưng yêu cầu tăng cường bảo mật bổ sung cho môi trường sản xuất, bao gồm cấu hình mã hóa, giới hạn chính sách IAM, triển khai VPC và kiểm thử toàn diện.

Dọn dẹp

Để xóa tất cả tài nguyên và tránh các khoản phí phát sinh nếu bạn không muốn sử dụng giải pháp nữa:

1. Xóa stack CloudFormation.
2. Xóa tích hợp Slack khỏi Amazon Q Developer in chat applications.

Khắc phục sự cố

• Nếu không có chỉ số hoặc chẩn đoán SQL không đầy đủ được trả về, hãy xác minh rằng workgroup Amazon Redshift Serverless đang hoạt động với hoạt động truy vấn gần đây và đảm bảo người dùng cơ sở dữ liệu có vai trò sys:monitor (GRANT ROLE sys:monitor TO <user>) trong trình chỉnh sửa truy vấn. Nếu không có vai trò này, các truy vấn sẽ thực thi thành công nhưng chỉ trả về dữ liệu hiển thị cho các quyền của người dùng đó thay vì toàn bộ hoạt động của cluster.
• Đối với các hàm được triển khai trong VPC không thể truy cập các dịch vụ AWS, hãy xác nhận rằng các VPC endpoint hoặc NAT Gateway đã được cấu hình cho CloudWatch, Amazon Redshift Data API, Amazon Redshift Serverless, SNS và CloudWatch Logs.
• Nếu hàm Lambda hết thời gian chờ, hãy tăng các tham số LambdaTimeout và QueryTimeoutSeconds. Thời gian chờ mặc định là 240 giây phù hợp với hầu hết các workload, nhưng các cluster có nhiều truy vấn đang hoạt động có thể yêu cầu thêm thời gian để hoàn thành chẩn đoán SQL.

Kết luận

Trong bài viết này, chúng tôi đã chỉ ra cách bạn có thể xây dựng một giải pháp giám sát chủ động cho Amazon Redshift Serverless bằng cách sử dụng AWS Lambda, Amazon CloudWatch và Amazon SNS với tích hợp Slack. Bằng cách tự động thu thập các chỉ số, đánh giá các ngưỡng và gửi cảnh báo gần như theo thời gian thực đến Slack hoặc nền tảng cộng tác ưa thích của bạn, giải pháp này giúp phát hiện sớm các vấn đề về hiệu suất và chi phí. Vì bản thân giải pháp là serverless, nó phù hợp với các mục tiêu đơn giản hóa hoạt động của Amazon Redshift Serverless—tự động mở rộng quy mô, yêu cầu bảo trì tối thiểu và mang lại giá trị cao với chi phí thấp. Bạn có thể mở rộng nền tảng này với các chỉ số bổ sung, logic chẩn đoán hoặc các kênh thông báo thay thế để đáp ứng nhu cầu của tổ chức bạn.

Để tìm hiểu thêm, hãy xem tài liệu Amazon Redshift về giám sát và tối ưu hóa hiệu suất.

Về tác giả

Cristian Restrepo Lopez
Cristian là Kiến trúc sư Giải pháp tại AWS, giúp khách hàng xây dựng các ứng dụng dữ liệu hiện đại tập trung vào phân tích. Ngoài công việc, anh ấy thích khám phá các công nghệ mới nổi và kết nối với cộng đồng dữ liệu.

Satesh Sonti
Satesh là Kiến trúc sư Giải pháp Chuyên gia Phân tích chính có trụ sở tại Atlanta, chuyên xây dựng các nền tảng dữ liệu doanh nghiệp, kho dữ liệu và các giải pháp phân tích. Anh ấy có hơn 19 năm kinh nghiệm trong việc xây dựng tài sản dữ liệu và dẫn dắt các chương trình nền tảng dữ liệu phức tạp cho các khách hàng ngân hàng và bảo hiểm trên toàn cầu.