GĐ30 — AWS SAA: Compute, Scaling, Messaging và Resilience

Mục tiêu: chọn nơi chạy code, tách tải bằng queue và thiết kế phục hồi theo yêu cầu. Kiến thức mạng/quyền ở GĐ29 là nền cho mọi sơ đồ dưới đây.

Kiểm chứng ngày 2026-10-05 (đọc tài liệu AWS; lệnh CLI chỉ kiểm cờ bằng aws ... help và --generate-cli-skeleton, chưa chạy trên AWS; phép tính chi phí Lambda chạy bằng Node với thời gian chạy giả định): hibernation, health check của ASG, PredefinedMetricSpecification, scale theo SQS, memory Lambda, giá Lambda, REST và HTTP API, quota API Gateway, throttling, DLQ, DLQ redrive. Về AWS Auto Scaling (scaling plans): đã đọc trang what-is và trang migrate, xem mục 4. Các mục viết từ trước giữ nguồn riêng ở cuối mỗi mục.

1. Chọn compute theo workload#

ECS là orchestrator; Fargate là cách cung cấp compute cho container. ECR là registry image, không chạy container. EKS không tự làm app dễ vận hành hơn chỉ vì dùng managed control plane.

Ví dụ tự xây: API NestJS chạy liên tục có thể bắt đầu bằng ECS/Fargate; job xử lý file nhỏ theo upload dùng Lambda; job video dài cần container/Batch. Chọn sau khi đo thời gian, RAM, concurrency và yêu cầu OS.

Nguồn: ECS, Fargate, EKS, compute overview.

2. EC2: instance family, storage và placement#

General purpose cân bằng tài nguyên; compute optimized dành cho CPU; memory optimized cho working set lớn; accelerated computing cho GPU/accelerator. Không chữa thiếu RAM bằng tăng CPU mà chưa đo. Burstable instances có cơ chế CPU credits; đánh giá tải kéo dài và chế độ credit trước khi chọn cho production.

AMI là image khởi tạo, launch template mô tả cấu hình launch; user data hỗ trợ bootstrap. Giữ app/image immutable để máy thay thế chạy cùng phiên bản. Không lưu file upload duy nhất ở instance store hoặc disk app.

Placement groups: cluster cho khoảng cách mạng gần và hiệu năng giữa instance; spread giảm cùng điểm lỗi phần cứng cho nhóm nhỏ; partition chia nhóm phần cứng cho distributed workloads. Không dùng cluster placement làm bằng chứng chịu mất AZ.

Nguồn: Instance types, burstable, placement groups.

Hibernation: giữ RAM qua lần dừng#

Hibernation ghi nội dung RAM vào root volume EBS rồi dừng instance; khi start lại, RAM được nạp lại và tiến trình chạy tiếp, hợp với app khởi động lâu hoặc cache nóng. Điều kiện chính (prerequisites): bật khi launch (không bật được cho instance đang chạy hoặc đã stop); root volume là EBS đã mã hóa, loại gp2/gp3/io1/io2 và đủ chỗ chứa RAM; RAM Linux dưới 150 GiB; chỉ một số instance family, không gồm bare metal; Spot phải là request persistent. Cờ đã kiểm bằng CLI help và skeleton; chưa chạy trên AWS: aws ec2 run-instances --hibernation-options Configured=true ..., sau đó aws ec2 stop-instances --hibernate --instance-ids i-.... Hibernation không thay Auto Scaling hay backup.

3. Load balancer và health check#

Listener nhận kết nối, rule chọn target group, health check theo cấu hình đánh giá target. Load balancer phân phối traffic; không tự thêm EC2. Auto Scaling Group (ASG) hoặc container service mới quản số lượng compute.

Ví dụ /health/ready báo app đã sẵn sàng nhận traffic. Endpoint trả 200 dù app chưa khởi tạo xong có thể khiến deploy gây lỗi. Nhưng health check phụ thuộc một shared DB đang chết cũng có thể làm mọi target unhealthy; cần thiết kế health/readiness theo failure mode và kiểm tra hành vi khi tất cả target unhealthy.

Session cần tồn tại ngoài một máy để scale/replacement; stickiness là công cụ routing, không thay durable session storage. Connection draining/deregistration delay giúp request đang chạy hoàn tất khi target rời pool.

Nguồn: Elastic Load Balancing, ALB health checks, target attributes.

4. Auto Scaling: chọn metric đúng#

ASG có min/desired/max capacity. Nó thay máy hỏng và có thể scale theo policy, nhưng cần cấu hình health check, thời gian warmup, launch template, subnet và capacity phù hợp.

Ví dụ tự xây: worker xử lý 2 job/giây, mục tiêu chờ dưới 30 giây. Backlog mục tiêu khoảng 2 × 30 = 60 job/worker khi giả định throughput ổn định. Dùng backlog per worker thay tổng queue length đơn thuần; đo lại nếu job có độ nặng khác nhau.

API I/O-bound có thể CPU thấp nhưng connection pool cạn. Metric scaling phải phản ánh bottleneck, còn max capacity phải bảo vệ DB/dependency khỏi connection storm.

Nguồn: Dynamic scaling, SQS scaling.

ASG sau ALB và target tracking#

Muốn ASG thay máy theo kết quả health check của ALB, phải bật loại health check ELB: mặc định ASG bỏ qua kết quả của load balancer và chỉ dùng status check của EC2 (health checks). Khi cả nhóm cùng bị báo unhealthy, ASG không thay hết một lúc mà giới hạn tốc độ để bạn kịp sửa. Scale ngang cũng cần ứng dụng stateless, xem GĐ21 mục 3. Tạo ASG (đã kiểm cờ bằng CLI help; chưa chạy trên AWS; subnet, ARN và số liệu là ví dụ):

aws autoscaling create-auto-scaling-group \  --auto-scaling-group-name web-asg \  --launch-template LaunchTemplateName=web-lt,Version='$Latest' \  --min-size 2 --max-size 6 --desired-capacity 2 \  --vpc-zone-identifier "subnet-aaaa1111,subnet-bbbb2222" \  --target-group-arns arn:aws:elasticloadbalancing:us-east-1:111122223333:targetgroup/web-tg/943f017f100becff \  --health-check-type ELB \  --health-check-grace-period 300 \  --default-instance-warmup 120

--health-check-grace-period cho app thời gian khởi động trước khi bị coi là hỏng; 300 và 120 giây ở đây là giả định, đặt theo thời gian khởi động thực đo được. Target tracking giữ một metric gần giá trị đích. ALBRequestCountPerTarget là số request trung bình mỗi target; ResourceLabel ghép phần cuối của ARN load balancer và phần cuối của ARN target group, và chỉ dùng được khi target group đã gắn vào ASG (PredefinedMetricSpecification):

{  "TargetValue": 1000.0,  "PredefinedMetricSpecification": {    "PredefinedMetricType": "ALBRequestCountPerTarget",    "ResourceLabel": "app/web-alb/778d41231b141a0f/targetgroup/web-tg/943f017f100becff"  }}

aws autoscaling put-scaling-policy \  --auto-scaling-group-name web-asg \  --policy-name alb-requests-per-target \  --policy-type TargetTrackingScaling \  --target-tracking-configuration file://config.json

TargetValue 1000 là giả định; chọn từ load test chứ không đoán. Với queue, số message trong hàng đợi (metric CloudWatch ApproximateNumberOfMessagesVisible của SQS; ApproximateNumberOfMessages là thuộc tính hàng đợi, nếu bạn publish thành custom metric thì tên metric do bạn đặt) không tỷ lệ với số instance nên không phải metric target tracking tốt; dùng backlog mỗi instance = số message / số instance InService, đích = độ trễ chấp nhận / thời gian xử lý một message. Ví dụ của AWS: 10 instance, 1500 message, 0,1 giây mỗi message, chấp nhận trễ 10 giây: đích = 10 / 0,1 = 100; hiện tại 1500 / 10 = 150, vượt đích nên thêm 5 instance (1500 / 100 = 15). Metric này là custom metric, hoặc dùng metric math để khỏi tự publish (SQS scaling, metric math).

Ba cái tên Auto Scaling#

Amazon EC2 Auto Scaling quản lý ASG. Application Auto Scaling scale các tài nguyên khác (service ECS, bảng DynamoDB, replica Aurora, Spot Fleet). "AWS Auto Scaling" với scaling plan là sản phẩm thứ ba: theo What is a scaling plan?, nó cấu hình auto scaling cho nhiều tài nguyên liên quan cùng lúc (ví dụ gom theo tag production, testing, development) và hỗ trợ cả predictive scaling cho ASG. Trang đó vẫn còn và AWS Auto Scaling vẫn nằm trong danh sách in-scope của kỳ thi. Trang đó chỉ khuyến nghị chuyển sang predictive scaling policy đặt trực tiếp trên tài nguyên nếu bạn dùng scaling plan chỉ cho predictive scaling (có hướng dẫn di chuyển); đọc các trang này không cho thấy ngày ngừng hỗ trợ, và bài này không khẳng định có hay không.

5. Lambda và API Gateway#

Lambda chạy handler khi có trigger; môi trường có thể tái sử dụng nhưng không được coi là durable state. Timeout tối đa hiện tại là 15 phút; kiểm tra quota chính thức khi thiết kế. Concurrency tăng sẽ tăng số kết nối tới DB/dependency; reserved concurrency giới hạn/đặt phần concurrency cho function, provisioned concurrency chuẩn bị execution environments để giảm cold start.

Gắn Lambda vào VPC để truy cập private resources không tự cấp Internet. Gắn vào public subnet cũng không tự nhận public IP; kiểm tra NAT/endpoints nếu function cần egress. Với RDS, cân nhắc pool và RDS Proxy theo nhu cầu.

API Gateway cung cấp managed API endpoint, routing và các tính năng auth/throttling theo loại API. REST API, HTTP API và WebSocket API có bộ tính năng/chi phí khác nhau; chọn theo yêu cầu, không mặc định REST API cho mọi HTTP endpoint.

Nguồn: Lambda quotas, concurrency, Lambda VPC, API Gateway.

Lambda: bộ nhớ, thời gian và chi phí#

Memory cấu hình từ 128 MB đến 10.240 MB; CPU tăng tỷ lệ theo memory, và ở 1.769 MB hàm có tương đương một vCPU (cấu hình memory). Tiền duration = GB-giây = memory (GB) x thời gian chạy (giây). Giá niêm yết khi đọc ngày 2026-10-05 ở us-east-1, x86, bậc đầu: 0,0000166667 USD mỗi GB-giây và 0,20 USD mỗi triệu request, duration làm tròn lên từng mili giây (Lambda pricing). Bảng dưới là phép tính cho 10 triệu lần gọi mỗi tháng, bỏ qua free tier; thời gian chạy là giả định để minh họa, không phải số đo (đã chạy bằng Node trong scratchpad):

Gấp đôi memory chỉ không tốn thêm khi duration giảm một nửa trở lên (hòa vốn ở 150 ms so với dòng đầu). Hàm CPU-bound thường giảm duration gần tỷ lệ; hàm chủ yếu chờ I/O thì ít. Đo bằng CloudWatch hoặc công cụ AWS Lambda Power Tuning rồi mới chọn. Đổi memory (cờ đã kiểm bằng CLI help; chưa chạy trên AWS):

aws lambda update-function-configuration \  --function-name my-function --memory-size 1024

API Gateway: authorizer và throttling#

Nguồn bảng: REST hay HTTP API, truy cập REST API, truy cập HTTP API. Chọn nhanh: người dùng đăng nhập bằng Cognito user pool (JWT) và API chỉ cần xác thực thì HTTP API với JWT authorizer; cần WAF, API key theo khách hàng hoặc resource policy thì REST API; token tự định nghĩa thì Lambda authorizer; gọi giữa hai workload AWS thì IAM. API key và usage plan dùng để theo dõi và giới hạn mức dùng của client đã được cấp quyền, không phải cơ chế xác thực.

Throttling: mặc định mỗi account, mỗi Region là 10.000 request mỗi giây với bucket burst tối đa 5.000, chung cho mọi API trong Region đó và giới hạn RPS có thể xin tăng, còn burst do đội API Gateway đặt theo hạn mức RPS của account, khách hàng không xin đổi trực tiếp (quotas); một số Region mới mặc định thấp hơn (2.500 và 1.250). Vượt giới hạn thì client nhận 429. Thứ tự áp dụng: giới hạn theo client hoặc theo method trong usage plan, rồi giới hạn theo method ở stage, rồi giới hạn account trong Region, rồi giới hạn Region do AWS đặt. Một API ồn ào có thể ăn hết hạn mức account của các API khác, nên đặt giới hạn stage hoặc method cho API quan trọng. Nguồn: quotas, throttling.

6. SQS: buffer tải và xử lý lặp#

SQS tách producer khỏi consumer. Standard queue có at-least-once delivery và best-effort ordering; worker phải idempotent. Visibility timeout tạm ẩn message sau khi receive; thành công thì delete. Worker chết trước delete → message có thể được nhận lại.

FIFO không bảo đảm side effect ở database/payment xảy ra đúng một lần trong mọi tình huống. Nếu worker commit DB rồi chết trước ack/delete, ứng dụng vẫn cần khóa idempotency/transaction.

Ví dụ tự xây: jobId unique trong bảng xử lý, transaction ghi kết quả và đánh dấu hoàn tất; khi retry thấy hoàn tất thì không tạo side effect lại. Không đánh dấu done trước khi side effect thành công. Xem GĐ10 để triển khai cơ chế.

Nguồn: SQS Standard, visibility timeout, FIFO deduplication.

SQS: cấu hình DLQ bằng JSON#

Tạo DLQ trước, lấy ARN, rồi gắn redrive policy vào queue nguồn. Điểm hay sai: RedrivePolicy là một chuỗi JSON nằm trong JSON, không phải object lồng. Block dưới đã kiểm cờ bằng CLI help; chưa chạy trên AWS (tên queue, account ID và số liệu là ví dụ):

aws sqs create-queue --queue-name jobs-dlq \  --attributes MessageRetentionPeriod=1209600aws sqs get-queue-attributes --queue-url "$DLQ_URL" \  --attribute-names QueueArnaws sqs set-queue-attributes --queue-url "$JOBS_URL" \  --attributes file://redrive.json

{  "RedrivePolicy": "{\"deadLetterTargetArn\":\"arn:aws:sqs:us-east-1:111122223333:jobs-dlq\",\"maxReceiveCount\":\"5\"}",  "VisibilityTimeout": "60",  "ReceiveMessageWaitTimeSeconds": "20"}

Giải thích: sau 5 lần message được nhận mà không bị xóa, SQS chuyển nó sang jobs-dlq; worker chết giữa chừng cũng tính là một lần nhận. ReceiveMessageWaitTimeSeconds 20 bật long polling. DLQ phải cùng account và Region với queue nguồn. Với queue Standard, retention của DLQ phải dài hơn queue nguồn (retention tối đa 14 ngày) vì enqueue timestamp không đổi. Đừng gắn DLQ vào FIFO nếu bạn không muốn phá thứ tự message. Cờ và định dạng theo ví dụ trong aws sqs set-queue-attributes help; chi tiết: Using dead-letter queues.

Sau khi sửa lỗi, đưa message từ DLQ về queue nguồn bằng redrive (đã kiểm cờ bằng CLI help; chưa chạy trên AWS):

aws sqs start-message-move-task \  --source-arn arn:aws:sqs:us-east-1:111122223333:jobs-dlq \  --max-number-of-messages-per-second 50

Không có --destination-arn thì message về queue nguồn ban đầu; nếu đặt thì hai queue phải cùng loại (DLQ FIFO thì đích cũng FIFO). Redrive không lọc hay sửa message, một task chạy tối đa 36 giờ, và message được redrive là message mới (retention tính lại). Quyền tối thiểu và vài giới hạn khác ở DLQ redrive. Nên đặt alarm CloudWatch khi DLQ có message, vì DLQ không tự báo ai. Nền tảng về idempotency, retry và chế độ hỏng: GĐ19 mục 7 và GĐ21 mục 7.

7. SNS, EventBridge, Step Functions và streaming#

SNS → mỗi consumer một SQS queue giúp consumer chậm không chặn consumer khác. Hai worker đọc cùng queue thường là chia công việc, không phải mỗi worker nhận mọi event.

Stream phù hợp khi cần đọc lại lịch sử và nhiều consumer độc lập; queue phù hợp cho job cần hoàn tất. Ordering cần partition/shard/message-group phù hợp, không suy ra global ordering chỉ từ tên dịch vụ. Step Functions orchestration vẫn cần task idempotent khi retry.

Nguồn: Application integration, Kinesis Streams, Firehose, MSK.

8. Availability, fault tolerance và backup#

High availability giảm downtime bằng redundancy/failover. Fault tolerance chịu một loại lỗi xác định và tiếp tục hoạt động theo thiết kế. Backup phục hồi dữ liệu về trạng thái trước đó. Replica có thể sao chép thao tác xóa nhầm, nên HA/replication không thay backup.

Ví dụ tự xây: ALB + hai app ở hai AZ chưa đủ HA nếu DB chỉ ở một AZ, worker chỉ ở một máy hoặc mọi app cần NAT zonal của AZ-A để gọi API quan trọng. Liệt kê cả dependency bên ngoài.

Timeout giới hạn thời gian chờ; retry backoff/jitter giảm đồng loạt retry; circuit breaker tránh gọi dependency đang lỗi; queue giữ công việc cho lúc consumer phục hồi. Retry request ghi cần idempotency, còn retry nhiều lớp có thể nhân tải.

Nguồn: Reliability pillar, retry/backoff.

9. RTO, RPO và disaster recovery#

RTO: mục tiêu thời gian khôi phục dịch vụ. RPO: mục tiêu khoảng dữ liệu có thể mất tính theo thời gian. Ví dụ tự xây: backup mỗi 24 giờ không tự đáp ứng RPO 15 phút; cần cơ chế backup/log/replication phù hợp và diễn tập.

Không gắn RTO/RPO cố định cho tên chiến lược. Kết quả phụ thuộc dữ liệu, automation, quota, failover và diễn tập. Route 53 failover chỉ chuyển DNS; không tự copy DB, tạo secret hay giải quyết ghi trùng.

Nguồn: Disaster recovery options.

10. Tự kiểm tra#

• Chọn EC2/ECS/Fargate/Lambda cho ba workload và giải thích.

  Đáp án

  Mẫu: (a) API NestJS chạy liên tục, đội nhỏ, ưu tiên ít vận hành: ECS trên Fargate sau ALB; EC2 chỉ khi cần kiểm soát OS hoặc loại instance đặc biệt. (b) Xử lý ảnh nhỏ theo sự kiện upload, tải thất thường: Lambda (mỗi lần gọi tối đa 15 phút). (c) Job video nhiều giờ: container trên Fargate/ECS hoặc AWS Batch, không phải Lambda vì vượt giới hạn 15 phút. Luôn nêu ràng buộc loại phương án (thời gian chạy, RAM, OS) rồi mới nói "ít vận hành". Sai thường gặp: chọn EKS "vì là container" khi không cần Kubernetes API. Xem mục 1.

• Phân biệt ALB phân phối traffic và ASG thêm/thay máy.

  Đáp án

  ALB nhận kết nối qua listener, rule chọn target group, health check quyết định target nhận traffic; nó không tạo EC2. ASG (hoặc service container) giữ số lượng giữa min và max, thay máy hỏng, scale theo policy:

  textReady

  Client --> ALB (subnet public A, B; cross-zone bật mặc định ở ALB)             |  listener 443 -> rule -> target group (health: /health/ready)     +-------+--------+     v                v  EC2 (AZ-A)      EC2 (AZ-B)   <-- Auto Scaling Group: min 2, desired 2, max 6  từ launch template           CloudWatch metric -> scaling policy -> ASG                               ASG đăng ký/gỡ target vào target group

  Sai thường gặp: nghĩ ALB tự scale số máy chủ ứng dụng. Xem mục 3 và 4.

• Chọn metric scaling theo bottleneck và giới hạn dependency.

  Đáp án

  API I/O-bound: CPU thấp nhưng connection pool cạn, nên dùng request/target hoặc độ trễ thay vì CPU. Worker queue: backlog per worker (ví dụ 2 job/giây, chờ tối đa 30 giây: khoảng 60 job/worker, giả định throughput ổn định). Đặt max capacity sao cho tổng kết nối tới DB không vượt giới hạn (nhân số instance với pool size). Dùng RDS Proxy hoặc giảm pool khi cần. Xem mục 4 và 5.

• Giải thích crash sau commit trước delete message.

  Đáp án

  Với SQS Standard (at-least-once), message trở lại hàng đợi khi visibility timeout hết (mặc định 30 giây) nên worker khác xử lý lại. Vì vậy handler phải idempotent: bảng xử lý có jobId unique, ghi kết quả và đánh dấu hoàn tất trong cùng transaction; lần retry thấy đã xong thì chỉ delete message. FIFO và deduplication không loại bỏ tình huống này vì lỗi nằm giữa commit và delete. Cấu hình DLQ với số lần receive tối đa để cô lập message độc. Visibility timeout tối đa 12 giờ kể từ lần nhận đầu; đặt dài hơn thời gian xử lý hoặc gia hạn bằng ChangeMessageVisibility. Sai thường gặp: tin "FIFO là exactly-once cho side effect". Xem mục 6 và GĐ10.

• Vẽ SNS fan-out với queue riêng cho mỗi consumer.

  Đáp án

  textReady

                        +--> SQS: email-queue ---> worker email   (+ DLQ)Upload --> SNS topic -+--> SQS: ocr-queue   ---> worker OCR     (+ DLQ)                      +--> SQS: audit-queue ---> worker audit   (+ DLQ)

  Mỗi consumer có queue và tốc độ riêng; consumer chậm không chặn consumer khác; lỗi của một bên chỉ làm đầy DLQ của bên đó. Hai worker đọc cùng một queue là chia việc, không phải mỗi bên nhận mọi event. Xem mục 7.

• Nêu điểm lỗi còn lại trong kiến trúc hai AZ.

  Đáp án

  Bài tập mục 8: liệt kê theo dependency.

  textReady

  Kiến trúc: ALB + 2 app (AZ-A, AZ-B) + RDS + 1 worker + NAT (AZ-A)Điểm lỗi còn lại                     Cách giảm- RDS Single-AZ                      Multi-AZ (standby đồng bộ, AZ khác)- worker một máy                     service từ 2 AZ, queue giữ việc- NAT zonal ở AZ-A, mọi app dùng     NAT mỗi AZ, route cùng AZ (hoặc NAT                                     regional, xem điều kiện)- API bên thứ ba duy nhất            timeout, retry+jitter, breaker- quota/IP subnet cạn khi scale      xem Service Quotas, CIDR rộng- xóa nhầm (replica sao chép cả xóa) backup, PITR, thử restore

  Phân biệt Multi-AZ và read replica (thường bị nhầm trong đề):

  textReady

  Multi-AZ (DB instance):  Primary (AZ-A) ==đồng bộ==> Standby (AZ-B)  mục đích: HA/failover tự động; standby KHÔNG phục vụ đọc  app dùng một endpoint DNS; failover đổi trỏ DNS sang standbyRead replica:            Primary --bất đồng bộ--> Replica(s)  mục đích: scale đọc (endpoint riêng); không failover tự động, nhưng  có thể promote làm DR; cùng hoặc khác Region

  Tín hiệu đề: "high availability" gợi ý Multi-AZ; "read-heavy, giảm tải" gợi ý read replica hoặc cache. Chi tiết DB ở GĐ31. Xem mục 8.

• Chọn chiến lược DR theo RTO/RPO và cách diễn tập.

  Đáp án

  Mẫu: RPO 15 phút và RTO 2 giờ: backup hằng ngày không đủ (RPO 24 giờ). Cần log/replication hoặc backup liên tục cho RPO. Về RTO, backup and restore, pilot light hoặc warm standby đều có thể đạt 2 giờ tùy kết quả diễn tập (ví dụ RDS point-in-time restore dùng log giao dịch lên S3 mỗi 5 phút), ngân sách và mức tự động hóa; chỉ chọn cấp đắt hơn khi diễn tập cho thấy restore quá chậm. Backup and restore thường rẻ nhất, restore lâu nhất; multi-site active/active nhanh nhất nhưng đắt và phức tạp xử lý ghi. Đừng gán RTO/RPO cố định cho tên chiến lược; con số thật chỉ biết sau khi diễn tập. Diễn tập: restore bản backup vào môi trường riêng, đo thời gian từ sự cố đến phục vụ lại (RTO) và khoảng dữ liệu thiếu (RPO), ghi lại bước thủ công cần tự động hóa. Route 53 failover chỉ chuyển DNS, không copy DB hay tạo secret. Xem mục 9.

• Tính target tracking cho worker SQS: ASG có 8 instance InService, queue có 2400 message, mỗi instance xử lý một message mất 0,2 giây, chấp nhận chờ tối đa 20 giây. Backlog mục tiêu mỗi instance là bao nhiêu và cần bao nhiêu instance?

  Đáp án

  Backlog mục tiêu mỗi instance = 20 giây / 0,2 giây = 100 message. Backlog hiện tại = 2400 / 8 = 300 message mỗi instance, gấp ba lần mục tiêu. Số instance để về mục tiêu = 2400 / 100 = 24, tức thêm 16 so với hiện tại, nếu max-size cho phép; nếu max là 12 thì backlog mỗi instance dừng ở 200 và thời gian chờ vẫn vượt 20 giây, nên phải nâng max hoặc giảm thời gian xử lý. Tử số là số message có thể nhận: ApproximateNumberOfMessages nếu bạn tự publish custom metric, hoặc ApproximateNumberOfMessagesVisible khi dùng metric math lấy thẳng từ CloudWatch, mẫu số là số instance InService. Sai thường gặp: lấy thẳng độ dài queue làm target value. Xem mục 4 và tài liệu SQS scaling.

• Hàm Lambda 512 MB chạy 300 ms. Sau khi đổi sang 1024 MB, bạn đo được 170 ms. Với 10 triệu lần gọi mỗi tháng (giá x86 ở us-east-1 trong mục 5, bỏ qua free tier), cấu hình mới rẻ hơn hay đắt hơn, và hòa vốn ở bao nhiêu mili giây?

  Đáp án

  Chi phí request như nhau (10 triệu x 0,20 USD / 1 triệu = 2,00 USD). Tính compute: cấu hình cũ 0,5 GB x 0,3 s = 0,15 GB-s mỗi lần, cấu hình mới 1 GB x 0,17 s = 0,17 GB-s. Tổng cũ khoảng 27,00 USD, mới khoảng 30,33 USD: đắt hơn khoảng 3,33 USD (số liệu duration là giả định của đề, giá lấy từ trang pricing). Hòa vốn khi GB-s bằng nhau: 1 GB x t = 0,15 GB-s nên t = 150 ms. Gấp đôi memory chỉ rẻ hơn khi duration giảm hơn một nửa. Chi phí cao hơn có thể vẫn đáng nếu độ trễ giảm quan trọng với người dùng. Nếu hàm chủ yếu chờ I/O, thêm memory thường không rút ngắn duration. Xem mục 5.

• Message nằm 3 ngày trong queue Standard nguồn (retention 4 ngày) rồi chuyển vào DLQ cũng retention 4 ngày. Nó còn tồn tại bao lâu trong DLQ, vì sao, và sửa thế nào?

  Đáp án

  Còn khoảng 1 ngày. Với queue Standard, thời điểm hết hạn tính từ enqueue timestamp gốc và timestamp này không đổi khi message sang DLQ, nên message đã dùng 3 trong 4 ngày. Cách sửa: đặt retention của DLQ dài hơn queue nguồn (tối đa 14 ngày) và đặt cảnh báo khi DLQ có message. Sau khi redrive về queue nguồn, message được coi là message mới (messageID và enqueue time mới), nên retention tính lại. Xem mục 6 và tài liệu DLQ.

Tiếp: GĐ31 — Storage & Databases.