Ngân hàng đề — AWS Certified Solutions Architect Associate

Đáp án

C và D — Tạo AMI của các instance và chép chúng sang Region khác; khi có thảm hoạ thì khởi chạy instance ở Region thứ hai từ các AMI đó.

Vì sao đúng

Đề cần bảo đảm khởi chạy được EC2 ở Region khác khi có thảm hoạ, và AMI là đơn vị đúng cho việc này: | Bước | Việc | |---|---| | D — tạo AMI và chép sang Region khác | chuẩn bị trước | | C — khởi chạy instance từ AMI ở Region đó | khi cần dùng |

⚠ AMI là tài nguyên theo REGION — phải chép mới dùng được:

AMI ở ap-southeast-1
    → KHÔNG khởi chạy được máy ở ap-northeast-1
        ↓
    Phải copy-image sang Region đích trước

Chép AMI:

aws ec2 copy-image \
  --source-region ap-southeast-1 --source-image-id ami-abc \
  --region ap-northeast-1 --name "ung-dung-ban-sao" \
  --encrypted --kms-key-id <arn-khoa-vung-dich>

⚠ Snapshot mã hoá cần khoá KMS Ở REGION ĐÍCH:

Khoá KMS KHÔNG dùng chung giữa các Region
    → phải chỉ định khoá của Region đích
        ↓
    Quên là lệnh copy thất bại, hoặc AMI mới
      không mã hoá như mong đợi

Tự động hoá bằng Data Lifecycle Manager:

aws dlm create-lifecycle-policy \
  --description "AMI hang ngay + chep xuyen vung" \
  --state ENABLED --execution-role-arn <arn-role> \
  --policy-details '{
    "PolicyType": "IMAGE_MANAGEMENT",
    "ResourceTypes": ["INSTANCE"],
    "TargetTags": [{"Key": "DR", "Value": "co"}],
    "Schedules": [{
      "Name": "hang-ngay",
      "CreateRule": {"Interval": 24, "IntervalUnit": "HOURS",
                     "Times": ["17:00"]},
      "RetainRule": {"Count": 7},
      "CrossRegionCopyRules": [{
        "TargetRegion": "ap-northeast-1",
        "Encrypted": true,
        "CmkArn": "<arn-khoa-vung-dich>",
        "RetainRule": {"Interval": 7, "IntervalUnit": "DAYS"}}]}]}'

⚠ AMI chứa gì: | Thành phần | Chi tiết | |---|---| | Snapshot của volume gốc | hệ điều hành và phần mềm | | Snapshot của volume dữ liệu | nếu khai trong block device mapping | | Quyền khởi chạy | ai dùng được AMI | | Kiến trúc, virtualization type | |

Khởi chạy khi cần:

aws ec2 run-instances --region ap-northeast-1 \
  --image-id ami-ban-sao --instance-type m5.large \
  --subnet-id subnet-vung-moi \
  --security-group-ids sg-vung-moi \
  --iam-instance-profile Name=VaiTroUngDung

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Chi phí gần như bằng 0 lúc bình thường | chỉ tiền lưu snapshot | | Máy dựng lại y hệt | | | Diễn tập rẻ — dựng rồi xoá | |

Vì sao các phương án khác sai

• **A. Bật cross-region snapshot cho EC2 instance — không có tính năng "cross-region snapshot" bật một lần cho instance; snapshot là của volume EBS, và việc chép xuyên Region phải làm tường minh (bằng copy-snapshot hoặc DLM).
• **B. Chép snapshot bằng S3 Cross-Region Replication — snapshot EBS được lưu trong S3 do AWS quản lý, không nằm trong bucket của bạn; CRR không đụng tới chúng.
• **E. Khởi chạy instance ở Region thứ hai bằng S3 API — S3 API không khởi chạy EC2; đây là mô tả một thao tác không tồn tại.

Ghi nhớ

⚠ Tài nguyên theo Region — bảng phải thuộc: | Tài nguyên | Phạm vi | |---|---| | AMI | một Region — phải copy | | EBS snapshot | một Region — phải copy | | Chứng chỉ ACM | một Region | | Auto Scaling group | một Region | | Security group | một VPC | | IAM role, policy | toàn cầu | | Route 53 hosted zone | toàn cầu | | Tên bucket S3 | toàn cầu (dữ liệu ở một Region) |

Từ khoá nhận diện:

"launch EC2 in another Region for DR" → AMI + copy-image "automate AMI creation and copy" → DLM "replicate whole servers continuously" → Elastic Disaster Recovery (DRS) "replicate S3 objects" → Cross-Region Replication

⚠ DRS là lựa chọn khi cần RPO tính bằng giây:

AMI hằng ngày: RPO tệ nhất 24 giờ
        ↓
AWS Elastic Disaster Recovery: nhân bản liên tục mức khối
    → RPO tính bằng giây
    → nhưng đắt hơn nhiều

Ba thứ AMI KHÔNG mang theo: | Thứ | Phải chuẩn bị riêng | |---|---| | Dữ liệu ghi sau lần chụp | sao chép riêng | | Cấu hình mạng của Region mới | VPC, subnet, SG | | Chứng chỉ ACM | tạo ở Region đích |

⚠ Đừng dùng AMI làm cơ chế sao lưu DỮ LIỆU:

AMI chụp hằng ngày
    → dữ liệu CSDL trong đó cũ tới 24 giờ
        ↓
    CSDL phải có cơ chế riêng:
    RDS snapshot xuyên vùng, Aurora Global Database,
    DynamoDB Global Tables

Ba lưu ý về chia sẻ AMI: | Lưu ý | Chi tiết | |---|---| | Chia sẻ theo account ID hoặc ID tổ chức | | | Snapshot mã hoá phải chia sẻ cả khoá KMS | | | Chặn chia sẻ công khai ở cấp tài khoản | |

aws ec2 enable-image-block-public-access \
  --image-block-public-access-state block-new-sharing

Ba lưu ý về hạn ngạch ở Region DR: | Hạn ngạch | Vì sao quan trọng | |---|---| | Số vCPU chạy được | Region ít dùng có quota rất thấp | | Số AMI | | | Số Elastic IP | |

⚠ Đây là thứ hay giết RTO nhất:

Kế hoạch DR cần 20 máy
    → quota Region phụ chỉ cho 8
        ↓
    Phát hiện giữa lúc sự cố
    → kiểm tra và xin tăng quota TRƯỚC

Ba lưu ý về tự động hoá dựng lại: | Cách | Chi tiết | |---|---| | CloudFormation StackSets | triển khai nhiều Region | | Tham số hoá AMI ID theo Region | | | Test bằng cách dựng rồi xoá | |

Mappings:
  AmiTheoVung:
    ap-southeast-1: {Ami: ami-abc}
    ap-northeast-1: {Ami: ami-def}
Resources:
  May:
    Type: AWS::EC2::Instance
    Properties:
      ImageId: !FindInMap [AmiTheoVung, !Ref "AWS::Region", Ami]

Ba lưu ý về chi phí: | Khoản | Chi tiết | |---|---| | Snapshot tính theo dữ liệu thật | | | Chép xuyên vùng tính phí truyền dữ liệu | | | Giữ ít bản là đủ — 7 bản thường hợp lý | |

Ba lưu ý về dọn dẹp: | Lưu ý | Chi tiết | |---|---| | Huỷ đăng ký AMI KHÔNG xoá snapshot | | | Snapshot mồ côi tích tụ và tính tiền | | | DLM tự dọn theo RetainRule | |

⚠ Đây là khoản lãng phí âm thầm rất phổ biến:

aws ec2 describe-snapshots --owner-ids self \
  --query "Snapshots[?starts_with(Description,'Created by CreateImage')].
    [SnapshotId,VolumeSize,StartTime]" --output table

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Kiểm tra AMI mới nhất đã có ở Region phụ | | | Khởi chạy thử một máy, bấm giờ | | | Kiểm tra hạn ngạch Region phụ | |

aws ec2 describe-images --owners self --region ap-northeast-1 \
  --query "sort_by(Images,&CreationDate)[-3:].[Name,CreationDate]" \
  --output table

Và một lời khuyên: hãy khởi chạy thử một máy từ AMI đã chép, mỗi quý một lần. Một AMI nằm ở Region DR trông giống hệt nhau dù nó khởi động được hay không — và điều kiện duy nhất để biết chắc là đã từng khởi động nó thật.

Đáp án

A — Chụp snapshot của CSDL, chép thành snapshot đã mã hoá, rồi khôi phục CSDL từ snapshot mã hoá đó.

Vì sao đúng

Đề cần bật mã hoá cho bản sao lưu của một RDS instance chưa mã hoá, và đây là con đường duy nhất.

⚠ Mã hoá bản sao lưu đi theo mã hoá của INSTANCE:

Instance chưa mã hoá → snapshot tự động cũng chưa mã hoá
    → không có công tắc riêng cho "mã hoá backup"
        ↓
    Muốn backup mã hoá thì INSTANCE phải mã hoá

Đây chính là lý do phương án C sai — không tồn tại ô "Enable encryption" trong phần backup.

Ba bước:

# 1. Snapshot instance chưa mã hoá
aws rds create-db-snapshot \
  --db-instance-identifier csdl-web \
  --db-snapshot-identifier anh-chup-chua-ma-hoa

# 2. Chép snapshot, BẬT mã hoá ở bước này
aws rds copy-db-snapshot \
  --source-db-snapshot-identifier anh-chup-chua-ma-hoa \
  --target-db-snapshot-identifier anh-chup-da-ma-hoa \
  --kms-key-id <arn-khoa> --copy-tags

# 3. Khôi phục instance mới từ snapshot mã hoá
aws rds restore-db-instance-from-db-snapshot \
  --db-instance-identifier csdl-web-moi \
  --db-snapshot-identifier anh-chup-da-ma-hoa \
  --db-instance-class db.r6g.large --multi-az

⚠ Bước 2 là chỗ duy nhất mã hoá được "thêm vào":

Không thể mã hoá lúc tạo snapshot (bước 1)
Không thể mã hoá lúc khôi phục (bước 3)
        ↓
    Chỉ lúc CHÉP snapshot mới chọn được khoá KMS

Sau khi có instance mã hoá, mọi thứ về sau tự mã hoá:

Instance mã hoá
    → snapshot tự động mã hoá
    → read replica mã hoá
    → snapshot thủ công mã hoá
        ↓
    Đúng yêu cầu "encryption for FUTURE backups"

⚠ Có thời gian ngừng dịch vụ — instance mới có endpoint KHÁC:

Ứng dụng phải đổi chuỗi kết nối
    → giảm thiểu bằng Route 53 CNAME
        ↓
    Trỏ csdl.noi-bo.vidu.com tới endpoint
    → chuyển đổi chỉ là đổi một bản ghi DNS

Ba việc phải kiểm lại trên instance mới: | Việc | Chi tiết | |---|---| | Parameter group | | | Security group và subnet group | | | Read replica phải tạo lại | |

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Cả dữ liệu cũ lẫn backup mới đều mã hoá | | | Không đổi mã ứng dụng | | | Xoá được các bản backup cũ chưa mã hoá | |

Vì sao các phương án khác sai

• **B. Tạo read replica có mã hoá rồi thăng cấp lên chính — đây là phương án gần nhất và nghe rất hợp lý, nhưng không tạo được read replica mã hoá từ instance CHƯA mã hoá: RDS yêu cầu replica cùng trạng thái mã hoá với nguồn.
• **C. Vào phần backup của cấu hình CSDL và tích ô "Enable encryption" — ô này không tồn tại; mã hoá là thuộc tính của instance, chỉ đặt được lúc tạo.
• **D. Bật mã hoá mặc định cho bucket S3 chứa backup — bản sao lưu RDS nằm trong S3 do AWS quản lý, không nằm trong bucket của bạn; bạn không cấu hình được nó.

Ghi nhớ

⚠ Bốn quy tắc mã hoá RDS phải thuộc: | Quy tắc | Chi tiết | |---|---| | Chỉ bật được LÚC TẠO instance | | | Không tắt được sau khi bật | | | Read replica phải CÙNG trạng thái mã hoá với nguồn | | | Snapshot của instance mã hoá cũng mã hoá | |

⚠ Cách duy nhất đổi trạng thái mã hoá:

Chưa mã hoá → mã hoá:
    snapshot → copy có KMS key → restore
        ↓
Mã hoá → chưa mã hoá:
    KHÔNG có đường trực tiếp
    → phải dump và nạp lại bằng công cụ CSDL

Từ khoá nhận diện:

"encrypt existing unencrypted RDS" → snapshot, copy encrypted, restore "encrypt existing EBS volume" → snapshot, copy encrypted, create volume "encrypt existing S3 objects" → copy object hoặc S3 Batch Operations "encrypt in transit" → SSL/TLS, rds.force_ssl

⚠ EBS theo đúng mẫu này — nhớ chung một lần:

aws ec2 copy-snapshot --source-snapshot-id snap-abc \
  --source-region ap-southeast-1 --encrypted --kms-key-id <arn>

Ba lưu ý về giảm thời gian ngừng: | Cách | Chi tiết | |---|---| | Route 53 CNAME cho endpoint CSDL | | | DMS CDC đồng bộ thay đổi trong lúc chuyển | | | Chọn cửa sổ ít lưu lượng | |

⚠ Mẫu chuyển đổi gần như không gián đoạn:

1. Khôi phục instance mã hoá từ snapshot (mất thời gian)
2. Dùng DMS CDC đồng bộ thay đổi từ cũ sang mới
3. Chờ độ trễ về 0, dừng ghi, đổi DNS
        ↓
    Ngừng vài phút thay vì cả giờ

Ba lưu ý về khoá KMS: | Loại khoá | Chi phí | Kiểm soát | |---|---|---| | AWS managed (aws/rds) | miễn phí | không sửa key policy được | | Customer managed | ~1 USD/tháng | đầy đủ |

⚠ Bảo vệ khoá bằng key policy:

{"Effect": "Deny", "Principal": "*",
 "Action": ["kms:ScheduleKeyDeletion", "kms:DisableKey"],
 "Resource": "*",
 "Condition": {"StringNotEquals":
   {"aws:PrincipalArn": "arn:aws:iam::123456789012:role/QuanTriKhoa"}}}

Xoá khoá = mọi snapshot và instance dùng nó
           không đọc được vĩnh viễn

Ba lưu ý về mã hoá khi truyền: | Lưu ý | Chi tiết | |---|---| | Khác hoàn toàn mã hoá at rest | | | Bật rds.force_ssl=1 trong parameter group | | | Client phải có RDS CA bundle | |

aws rds modify-db-parameter-group \
  --db-parameter-group-name nhom-tham-so \
  --parameters "ParameterName=rds.force_ssl,ParameterValue=1,
                ApplyMethod=pending-reboot"

Ba lưu ý về sao chép xuyên Region: | Lưu ý | Chi tiết | |---|---| | Khoá KMS không dùng chung giữa Region | | | Phải chỉ định khoá của Region đích | | | Snapshot chưa mã hoá chép sang được, rồi mã hoá lúc chép | |

Ba lưu ý về xoá backup cũ: | Lưu ý | Chi tiết | |---|---| | Snapshot thủ công tồn tại tới khi bạn xoá | | | Snapshot tự động xoá theo retention | | | Xoá instance có tuỳ chọn giữ snapshot cuối | |

⚠ Đề nói sẽ huỷ backup chưa mã hoá — đừng vội:

Xoá snapshot cũ TRƯỚC khi xác nhận
instance mới chạy đúng
    → không còn đường lùi
        ↓
    Giữ ít nhất một bản cũ vài ngày

Ba lưu ý về tuân thủ: | Công cụ | Việc | |---|---| | Config rule rds-storage-encrypted | | | Config rule rds-snapshot-encrypted | | | SCP chặn tạo RDS chưa mã hoá | |

{"Effect": "Deny", "Action": "rds:CreateDBInstance",
 "Resource": "*",
 "Condition": {"Bool": {"rds:StorageEncrypted": "false"}}}

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Kiểm tra StorageEncrypted: true | | | Chờ một chu kỳ, xem snapshot tự động có mã hoá | | | So số dòng vài bảng | |

aws rds describe-db-snapshots \
  --db-instance-identifier csdl-web-moi --snapshot-type automated \
  --query "DBSnapshots[].[DBSnapshotIdentifier,Encrypted]" --output table

Và một lời khuyên: hãy đặt SCP chặn tạo RDS chưa mã hoá ngay sau khi hoàn tất. Quy trình snapshot–copy–restore tốn một cửa sổ ngừng dịch vụ, và cách duy nhất để không phải làm lại là biến việc quên bật mã hoá thành điều không thể xảy ra.

Đáp án

C — Dùng volume Provisioned IOPS SSD (io2) với Amazon EBS Multi-Attach.

Vì sao đúng

Đề cho bốn dữ kiện, và cả bốn đều khớp chính xác với Multi-Attach: | Dữ kiện | Ý nghĩa | |---|---| | Ghi ĐỒNG THỜI từ nhiều EC2 vào một volume KHỐI | Multi-Attach | | Instance dựa trên Nitro | điều kiện bắt buộc của Multi-Attach | | Cùng một Availability Zone | điều kiện bắt buộc thứ hai | | Hiệu năng cao | io2 tới 256.000 IOPS |

⚠ Multi-Attach CHỈ hỗ trợ io1 và io2 — đây là lý do D sai:

gp2, gp3, st1, sc1: KHÔNG hỗ trợ Multi-Attach
    → chỉ io1 và io2
        ↓
    Phương án D (gp2 + Multi-Attach) mô tả
      một cấu hình không tồn tại

Ba điều kiện bắt buộc: | Điều kiện | Chi tiết | |---|---| | Loại volume io1 hoặc io2 | | | Instance dựa trên Nitro | | | Mọi instance CÙNG một AZ | |

Tạo và gắn:

aws ec2 create-volume --availability-zone ap-southeast-1a \
  --size 500 --volume-type io2 --iops 20000 \
  --multi-attach-enabled --encrypted

for i in i-abc i-def i-ghi; do
  aws ec2 attach-volume --volume-id vol-abc \
    --instance-id $i --device /dev/sdf
done

⚠ Cảnh báo quan trọng nhất — cần HỆ THỐNG TỆP CỤM:

ext4, XFS giả định CHỈ MỘT máy ghi
    → hai máy gắn cùng volume với XFS
        ↓
    HỎNG DỮ LIỆU, không phải "chậm" hay "xung đột"
    → hệ thống tệp bị phá huỷ

Phải dùng hệ thống tệp biết phối hợp: | Hệ thống tệp | Chi tiết | |---|---| | GFS2 | Red Hat, cần cluster suite | | OCFS2 | Oracle | | Ứng dụng tự quản lý khối thô | Oracle RAC |

⚠ Hoặc dùng volume ở dạng THÔ, không định dạng:

Oracle RAC, một số CSDL phân tán
    → đọc ghi trực tiếp lên block device
    → tự lo khoá và phối hợp
        ↓
    Đây mới là ca dùng chính của Multi-Attach

Ba giới hạn: | Giới hạn | Giá trị | |---|---| | Số instance tối đa | 16 | | Phạm vi | một AZ duy nhất | | Không dùng làm volume khởi động | |

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Lưu trữ khối dùng chung, độ trễ thấp | | | io2 có độ bền 99,999% | | | Tới 256.000 IOPS với Block Express | |

Vì sao các phương án khác sai

• **D. gp2 với Multi-Attach — đây là phương án gần nhất và chỉ sai một chi tiết, nhưng chi tiết đó khiến nó không tồn tại: gp2 không hỗ trợ Multi-Attach. Chỉ io1 và io2.
• **B. EFS với NFSv4.1 — EFS cho phép nhiều máy truy cập chung thật, nhưng nó là lưu trữ TỆP chứ không phải KHỐI; đề nói rõ "shared block storage volume".
• **A. S3 với Transfer Acceleration — S3 là lưu trữ đối tượng, không mount làm block device; Transfer Acceleration chỉ tăng tốc tải lên từ xa.

Ghi nhớ

⚠ Ba loại lưu trữ và khả năng dùng chung — bảng phải thuộc: | Loại | Dùng chung | Giao thức | |---|---|---| | EBS thường | không — một instance | block | | EBS Multi-Attach | có — 16 máy, MỘT AZ, io1/io2 | block | | EFS | có — hàng nghìn máy, nhiều AZ | NFS | | FSx for Windows | có | SMB | | S3 | qua API | HTTP |

Từ khoá nhận diện:

"shared block storage, concurrent writes, same AZ" → EBS Multi-Attach (io2) "shared file system, Linux" → EFS "shared file system, Windows" → FSx for Windows "object storage" → S3

⚠ Multi-Attach KHÔNG phải giải pháp sẵn sàng cao:

Volume vẫn nằm trong MỘT AZ
    → AZ hỏng = mọi máy mất volume
        ↓
    Đề nói "data resilience and high availability"
    → Multi-Attach cho khả năng dùng chung,
      không cho tính sẵn sàng xuyên AZ

Ba lưu ý về Nitro: | Lưu ý | Chi tiết | |---|---| | Phần lớn instance đời mới đều Nitro | | | C5, M5, R5 trở lên | | | Kiểm tra trước khi thiết kế | |

aws ec2 describe-instance-types \
  --instance-types m5.large \
  --query "InstanceTypes[0].Hypervisor"

Ba lưu ý về io2 Block Express: | Lưu ý | Chi tiết | |---|---| | Tới 256.000 IOPS mỗi volume | | | Tới 4.000 MB/s thông lượng | | | Tới 64 TiB dung lượng | |

⚠ Tỷ lệ IOPS trên dung lượng có giới hạn:

io2: tối đa 500 IOPS mỗi GiB
    → volume 100 GiB tối đa 50.000 IOPS
        ↓
    Cần IOPS rất cao thì phải tăng dung lượng

Ba lưu ý về chi phí: | Khoản | Chi tiết | |---|---| | io2 tính theo GB + theo IOPS cấp phát | | | Đắt nhất trong các loại EBS | | | Multi-Attach không tính phí thêm | |

Ba lựa chọn thay thế đáng cân nhắc: | Lựa chọn | Khi nào | |---|---| | FSx for Lustre | HPC, thông lượng rất cao | | FSx for NetApp ONTAP | hỗ trợ iSCSI, dùng chung khối | | Ứng dụng phân tán không cần đĩa chung | thiết kế tốt hơn |

⚠ Thường có thiết kế tốt hơn Multi-Attach:

Nhiều máy cùng ghi một đĩa
    → bài toán phối hợp rất khó
        ↓
    Cân nhắc: mỗi máy một volume riêng,
    dữ liệu chung để ở S3, DynamoDB, hoặc CSDL

Ba lưu ý về I/O fencing: | Lưu ý | Chi tiết | |---|---| | io2 hỗ trợ NVMe reservations | | | Cho phép cách ly máy hỏng khỏi volume | | | Cần thiết cho cụm nghiêm túc | |

Ba lưu ý về giám sát: | Metric | Ý nghĩa | |---|---| | VolumeQueueLength | hàng đợi I/O | | VolumeReadOps / VolumeWriteOps | | | Theo dõi từ MỌI máy đã gắn | |

Ba lưu ý về snapshot: | Lưu ý | Chi tiết | |---|---| | Snapshot vẫn hoạt động bình thường | | | Nhưng nhất quán dữ liệu do ứng dụng lo | | | Đóng băng I/O ở mọi máy trước khi chụp | |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Kiểm tra MultiAttachEnabled: true | | | Xác nhận hệ thống tệp là loại cụm | | | Thử ghi đồng thời và kiểm tính toàn vẹn | |

aws ec2 describe-volumes --volume-ids vol-abc \
  --query "Volumes[0].[MultiAttachEnabled,VolumeType,
    length(Attachments)]"

Và một lời khuyên: hãy xác nhận hệ thống tệp là loại cụm trước khi gắn volume vào máy thứ hai. Multi-Attach cho phép thao tác đó thành công về mặt kỹ thuật mà không cảnh báo gì — và hậu quả của việc dùng ext4 hay XFS ở đây không phải là hiệu năng kém mà là dữ liệu bị phá huỷ.

Đáp án

D — Tạo một Multi-AZ RDS Read Replica của DB instance sản xuất.

Vì sao đúng

Đề nêu ba yêu cầu, và phương án này đáp ứng cả ba: | Yêu cầu | Cách đáp ứng | |---|---| | Công cụ báo cáo truy cập cùng dữ liệu | read replica có bản sao dữ liệu | | KHÔNG ảnh hưởng hiệu năng bản sản xuất | truy vấn báo cáo chạy trên replica | | Bản thân công cụ phải SẴN SÀNG CAO | replica cấu hình Multi-AZ |

⚠ Vế thứ ba là chỗ phân biệt D với C:

Read replica bình thường: một instance, một AZ
    → AZ đó hỏng = công cụ báo cáo ngừng
        ↓
Read replica cấu hình Multi-AZ:
    → chính replica có standby riêng
    → AZ hỏng vẫn phục vụ

Tạo replica Multi-AZ:

aws rds create-db-instance-read-replica \
  --db-instance-identifier replica-bao-cao \
  --source-db-instance-identifier csdl-san-xuat \
  --db-instance-class db.r6g.2xlarge \
  --multi-az \
  --publicly-accessible false

⚠ Read replica có thể có cỡ KHÁC bản chính:

Sản xuất: db.r6g.xlarge (tối ưu cho giao dịch)
Replica báo cáo: db.r6g.2xlarge (tối ưu cho truy vấn nặng)
        ↓
    Không phải giống nhau
    → chọn cỡ theo đúng tải của từng bên

Và có thể có index riêng:

Truy vấn báo cáo cần index mà sản xuất không cần
    → MySQL read replica cho phép thêm index riêng
        ↓
    Tăng tốc báo cáo mà không làm chậm ghi ở bản chính

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Tách hoàn toàn tải báo cáo | | | Replica tự có failover | | | Thăng cấp được thành instance độc lập nếu cần | |

⚠ Nhân bản là BẤT ĐỒNG BỘ — dữ liệu có độ trễ:

Read replica của RDS dùng nhân bản logic (binlog)
    → độ trễ vài giây tới vài phút tuỳ tải
        ↓
    Báo cáo chấp nhận được
    → nhưng KHÔNG dùng cho việc đòi dữ liệu tức thời

aws cloudwatch get-metric-statistics --namespace AWS/RDS \
  --metric-name ReplicaLag \
  --dimensions Name=DBInstanceIdentifier,Value=replica-bao-cao \
  --start-time 2026-08-30T00:00:00Z --end-time 2026-08-30T01:00:00Z \
  --period 300 --statistics Maximum

Vì sao các phương án khác sai

• **C. Tạo Single-AZ read replica, rồi tạo replica thứ hai TỪ replica đó — đây là phương án gần nhất và cũng tách được tải, nhưng replica lồng nhau cộng dồn độ trễ, và mỗi cái vẫn là Single-AZ nên không sẵn sàng cao. Phức tạp hơn mà kém hơn.
• **B. Tạo Multi-AZ xuyên Region rồi tạo replica ở Region thứ hai — RDS Multi-AZ không hoạt động xuyên Region; Multi-AZ là trong một Region. Và đặt công cụ báo cáo ở Region khác thêm độ trễ mà không có lý do.
• **A. Dùng Data Lifecycle Manager tạo và quản lý snapshot — DLM quản lý snapshot EBS, không phải RDS; và snapshot là ảnh chụp tĩnh, không phải nguồn dữ liệu sống cho công cụ báo cáo.

Ghi nhớ

⚠ Multi-AZ vs Read Replica — bảng phải thuộc: | | Multi-AZ | Read Replica | |---|---|---| | Mục đích | TÍNH SẴN SÀNG | MỞ RỘNG ĐỌC | | Nhân bản | đồng bộ | bất đồng bộ | | Standby/replica đọc được | ❌ (RDS) | ✅ | | Failover tự động | ✅ | ❌ phải promote | | Xuyên Region | ❌ | ✅ |

⚠ Hai thứ này KẾT HỢP được — đó chính là đáp án:

Read replica CÓ THỂ tự nó là Multi-AZ
    → vừa mở rộng đọc, vừa sẵn sàng cao
        ↓
    Đây là điều đề đang hỏi

Từ khoá nhận diện:

"reporting must not impact production, must be HA" → Multi-AZ read replica "automatic failover only" → Multi-AZ "scale reads" → read replica "replicas that are also failover targets" → Aurora

⚠ Aurora làm việc này gọn hơn RDS:

Aurora Replica: vừa phục vụ đọc
                vừa là mục tiêu failover
        ↓
    Không cần phân biệt "standby" và "replica"
    → một instance làm cả hai vai

Ba lưu ý về số lượng replica: | Engine | Số replica tối đa | |---|---| | RDS MySQL, MariaDB, PostgreSQL | 15 | | Aurora | 15 Aurora Replica | | RDS SQL Server | không hỗ trợ read replica truyền thống |

Ba lưu ý về độ trễ nhân bản: | Nguyên nhân | Chi tiết | |---|---| | Ghi nhiều ở bản chính | | | Replica cỡ nhỏ hơn nguồn | | | Truy vấn dài khoá replica | |

⚠ Đặt cảnh báo cho ReplicaLag:

aws cloudwatch put-metric-alarm --alarm-name replica-tre \
  --namespace AWS/RDS --metric-name ReplicaLag \
  --dimensions Name=DBInstanceIdentifier,Value=replica-bao-cao \
  --statistic Average --period 300 --evaluation-periods 2 \
  --threshold 300 --comparison-operator GreaterThanThreshold \
  --alarm-actions <arn-sns>

Replica tụt hậu 30 phút mà không ai biết
    → báo cáo dùng dữ liệu cũ
    → quyết định sai mà không có dấu hiệu nào

Ba lưu ý về endpoint: | Lưu ý | Chi tiết | |---|---| | Replica có endpoint RIÊNG | | | Ứng dụng báo cáo trỏ vào endpoint đó | | | Multi-AZ của replica không đổi endpoint khi failover | |

Ba lưu ý về thăng cấp: | Lưu ý | Chi tiết | |---|---| | Promote biến replica thành instance độc lập | | | KHÔNG đảo ngược được | | | Dùng cho DR hoặc tách môi trường | |

aws rds promote-read-replica \
  --db-instance-identifier replica-bao-cao

Ba lưu ý về chi phí: | Khoản | Chi tiết | |---|---| | Replica tính phí như một instance đầy đủ | | | Multi-AZ nhân đôi chi phí replica đó | | | Cân nhắc cỡ nhỏ hơn nếu báo cáo nhẹ | |

Ba lưu ý về tối ưu truy vấn báo cáo: | Lưu ý | Chi tiết | |---|---| | Thêm index riêng cho replica (MySQL) | | | Chạy báo cáo nặng ngoài giờ cao điểm | | | Cân nhắc Redshift nếu quá nặng | |

⚠ Khi nào nên chuyển sang kho dữ liệu:

Báo cáo quét hàng trăm triệu dòng, có join phức tạp
    → read replica vẫn là CSDL giao dịch
        ↓
    Redshift hoặc Athena trên S3 hợp hơn nhiều
    → dùng DMS hoặc Glue đưa dữ liệu sang

Ba lưu ý về bảo mật: | Lưu ý | Chi tiết | |---|---| | Replica kế thừa trạng thái mã hoá của nguồn | | | Đặt trong subnet riêng tư | | | Tài khoản chỉ đọc cho công cụ báo cáo | |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Chạy báo cáo, xem CPU bản chính không tăng | | | Theo dõi ReplicaLag | | | Thử failover của replica | |

Và một lời khuyên: hãy đặt cảnh báo cho ReplicaLag cùng lúc với việc dựng replica. Nhân bản bất đồng bộ không báo lỗi khi tụt hậu — nó chỉ lặng lẽ phục vụ dữ liệu cũ, và một báo cáo dựa trên số liệu của nửa tiếng trước trông y hệt một báo cáo đúng.

Đáp án

A — Dùng Amazon EC2 Instance Store.

Vì sao đúng

Đề cho ba dữ kiện, và cả ba đều chỉ vào instance store: | Dữ kiện | Ý nghĩa | |---|---| | Cần 135.000 IOPS | instance store cho hàng triệu IOPS | | Tầng lưu trữ được NHÂN BẢN qua mọi máy trong cụm | mất một node không mất dữ liệu | | Phải TIẾT KIỆM | instance store MIỄN PHÍ — đã gồm trong giá máy |

⚠ Vế thứ hai là chìa khoá — nó vô hiệu hoá nhược điểm của instance store:

Instance store: mất dữ liệu khi máy dừng
    → thường là lý do KHÔNG dùng nó
        ↓
    Nhưng đề nói dữ liệu ĐÃ được nhân bản
      qua mọi instance trong cụm
        ↓
    Mất một máy = dữ liệu vẫn còn ở máy khác
    → nhược điểm biến mất

⚠ Và instance store MIỄN PHÍ:

io2 với 135.000 IOPS:
    → phí dung lượng + phí mỗi IOPS cấp phát
    → hàng nghìn USD mỗi tháng mỗi volume
        ↓
Instance store: 0 USD thêm
    → đã tính trong giá của instance

Chọn họ instance có NVMe SSD: | Họ | Đặc điểm | |---|---| | i4i, i3 | tối ưu I/O — IOPS cao nhất | | d3, d2 | dung lượng lớn, HDD | | m5d, c5d, r5d | biến thể có NVMe của họ thông dụng |

aws ec2 run-instances --image-id ami-abc \
  --instance-type i4i.4xlarge --count 4 \
  --placement GroupName=cum-hpc

Chuẩn bị ổ NVMe sau khi khởi động:

lsblk
sudo mkfs -t xfs /dev/nvme1n1
sudo mkdir -p /du-lieu && sudo mount /dev/nvme1n1 /du-lieu

⚠ Phải định dạng lại sau MỖI lần khởi động lại máy:

Instance store xoá sạch khi stop/start
    → ổ trống, chưa có hệ thống tệp
        ↓
    Đặt script định dạng và mount vào user data

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | IOPS cao nhất, độ trễ thấp nhất | | | Không tốn thêm tiền | | | Không tiêu băng thông EBS của instance | |

⚠ Điểm cuối rất đáng chú ý trong HPC:

EBS đi qua mạng, chiếm băng thông EBS của máy
    → cạnh tranh với lưu lượng khác
        ↓
Instance store gắn TRỰC TIẾP vào máy chủ vật lý
    → không chiếm băng thông mạng nào

Ghi nhớ về chất lượng câu hỏi

⚠ Phương án C về mặt kỹ thuật ngày nay là khả thi.

io2 Block Express hỗ trợ tới 256.000 IOPS mỗi volume, nên 135.000 IOPS là con số đạt được:

Nhưng đề đặt tiêu chí "cost-effective"
    → io2 tính phí RIÊNG cho mỗi IOPS cấp phát
    → 135.000 IOPS là khoản rất lớn mỗi tháng
        ↓
    Instance store cho cùng hiệu năng với giá 0
    → và dữ liệu đã được nhân bản nên không cần độ bền của EBS

Khi đề viết, io1 chỉ đạt 64.000 IOPS nên C là bất khả thi; ngày nay C khả thi nhưng vẫn sai vì lý do chi phí. Kết luận không đổi, nhưng lý do thì đã đổi — đáng biết để không lập luận bằng một giới hạn đã lỗi thời.

Vì sao các phương án khác sai

• **C. EBS Provisioned IOPS với 135.000 IOPS — xem phần trên: khả thi nhưng đắt hơn nhiều lần, và độ bền của EBS là thứ đề không cần vì dữ liệu đã nhân bản.
• **D. Enhanced Networking với EBS HDD Throughput Optimized — st1 chỉ đạt ~500 IOPS, thiếu 270 lần so với yêu cầu; và enhanced networking cải thiện mạng chứ không cải thiện đĩa.
• **B. S3 với byte-range fetch — S3 là lưu trữ đối tượng qua HTTP, độ trễ hàng mili giây; không thể đóng vai trò đĩa cục bộ cho HPC.

Ghi nhớ

⚠ Bốn lựa chọn lưu trữ cho HPC — bảng phải thuộc: | Lựa chọn | IOPS | Bền vững | Chi phí | |---|---|---|---| | Instance store | cao nhất, hàng triệu | ❌ mất khi dừng máy | miễn phí | | io2 Block Express | tới 256.000 | ✅ | rất cao | | FSx for Lustre | thông lượng rất cao, dùng chung | ✅ | cao | | EFS | trung bình, dùng chung | ✅ | trung bình |

Từ khoá nhận diện:

"highest IOPS, data replicated across cluster, cost-effective" → instance store "shared high-throughput file system for HPC" → FSx for Lustre "persistent block storage, high IOPS" → io2 "low latency between instances" → cluster placement group

⚠ Instance store mất dữ liệu khi nào: | Sự kiện | Dữ liệu | |---|---| | Stop rồi start | MẤT | | Terminate | MẤT | | Máy chủ vật lý hỏng | MẤT | | Reboot | CÒN | | Hibernate | mất |

⚠ Chỉ reboot là giữ được — đây là điểm hay bị nhầm.

Ba trường hợp instance store là lựa chọn ĐÚNG: | Trường hợp | Vì sao | |---|---| | Dữ liệu đã nhân bản qua cụm | đề này | | Cache, scratch, shuffle của Spark | tái tạo được | | CSDL phân tán tự nhân bản | Cassandra, Elasticsearch |

Ba lưu ý về cluster placement group: | Lưu ý | Chi tiết | |---|---| | HPC thường cần độ trễ mạng thấp giữa các máy | | | Cluster placement group đặt máy gần nhau | | | Tới 100 Gbps giữa các instance | |

aws ec2 create-placement-group --group-name cum-hpc \
  --strategy cluster

Ba lưu ý về EFA: | Lưu ý | Chi tiết | |---|---| | Elastic Fabric Adapter cho HPC và ML | | | Bỏ qua kernel, độ trễ rất thấp | | | Cần trong cùng cluster placement group | |

Ba lưu ý về FSx for Lustre: | Lưu ý | Chi tiết | |---|---| | Hệ thống tệp dùng chung cho HPC | | | Liên kết với bucket S3 | | | Thông lượng tới hàng trăm GB/s | |

⚠ Lustre là lựa chọn khi cần DÙNG CHUNG:

Instance store: mỗi máy một đĩa riêng
    → phải tự nhân bản (đề này đã có)
        ↓
FSx for Lustre: mọi máy thấy CÙNG hệ thống tệp
    → không phải tự lo nhân bản

Ba lưu ý về sao lưu khi dùng instance store: | Lưu ý | Chi tiết | |---|---| | Chép định kỳ sang S3 | | | Hoặc dựa vào nhân bản của ứng dụng | | | Không có snapshot cho instance store | |

Ba lưu ý về hiệu năng thật: | Lưu ý | Chi tiết | |---|---| | Ổ NVMe mới cần "làm nóng" lần đầu ghi | | | Ghi toàn bộ một lượt để đạt hiệu năng ổn định | | | Đo bằng fio chứ đừng tin thông số | |

sudo fio --filename=/dev/nvme1n1 --rw=randread --bs=4k \
  --iodepth=64 --numjobs=4 --ioengine=libaio --direct=1 \
  --runtime=60 --name=do-iops --group_reporting

Ba lưu ý về chi phí: | Khoản | Chi tiết | |---|---| | Instance store gồm trong giá máy | | | Họ i4i đắt hơn m5 nhưng có NVMe lớn | | | So tổng chi phí, không so giá giờ | |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đo IOPS thật bằng fio | | | Tắt một node, xem cụm còn dữ liệu | | | Kiểm tra user data tự mount sau reboot | |

Và một lời khuyên: hãy đặt script định dạng và mount ổ NVMe vào user data ngay từ đầu. Instance store trở lại trạng thái trống sau mỗi lần stop/start, và một cụm HPC khởi động lại vào cuối tuần sẽ chào bạn bằng những máy chạy bình thường nhưng không có ổ dữ liệu nào được gắn.

Đáp án

D — Dùng target tracking policy giữ mức sử dụng CPU trung bình toàn nhóm ở 40%.

Vì sao đúng

Đề nêu đúng một yêu cầu, và target tracking là chính sách được thiết kế cho câu đó: | Yêu cầu | Cách đáp ứng | |---|---| | Giữ CPU của cả đội máy ở mức 40% | đặt một mục tiêu, ASG tự lo phần còn lại |

⚠ Target tracking hoạt động giống bộ điều nhiệt:

Bạn đặt: "giữ CPU trung bình ở 40%"
        ↓
    ASG tự tính cần bao nhiêu máy
    → CPU 80% → thêm nhiều máy
    → CPU 45% → thêm ít máy
    → CPU 25% → bớt máy
        ↓
    Càng xa mục tiêu, phản ứng càng mạnh

Cấu hình:

aws autoscaling put-scaling-policy \
  --auto-scaling-group-name asg-web \
  --policy-name giu-cpu-40 \
  --policy-type TargetTrackingScaling \
  --target-tracking-configuration '{
    "TargetValue": 40.0,
    "PredefinedMetricSpecification": {
      "PredefinedMetricType": "ASGAverageCPUUtilization"},
    "DisableScaleIn": false}'

⚠ ASG tự tạo CloudWatch alarm cho bạn:

Target tracking sinh ra hai alarm:
    → AlarmHigh (mở rộng)
    → AlarmLow (thu nhỏ)
        ↓
    Đừng sửa hay xoá chúng bằng tay
    → chúng do chính sách quản lý

Ba metric dựng sẵn: | Metric | Dùng khi | |---|---| | ASGAverageCPUUtilization | tải nặng CPU | | ALBRequestCountPerTarget | ứng dụng web — thường tốt hơn | | ASGAverageNetworkIn/Out | tải nặng mạng |

⚠ Với ứng dụng web, số request thường là tín hiệu tốt hơn CPU:

CPU tăng SAU khi request đã dồn tới
    → luôn phản ứng trễ một nhịp
        ↓
    Số request mỗi máy là tín hiệu SỚM hơn

Ba lợi ích so với step scaling: | Lợi ích | Chi tiết | |---|---| | Chỉ khai một con số | | | Tự điều chỉnh biên độ theo độ lệch | | | Ưu tiên giữ tính sẵn sàng khi mở rộng | |

⚠ Target tracking mở rộng nhanh nhưng thu nhỏ chậm — có chủ ý:

Thêm máy: phản ứng nhanh, tránh quá tải
Bớt máy: từ tốn, tránh dao động
        ↓
    Thiết kế nghiêng về an toàn

Vì sao các phương án khác sai

• **B. Step scaling dùng PercentChangeInCapacity — đây là phương án gần nhất và cũng co giãn được, nhưng bạn phải tự định nghĩa từng bậc ngưỡng và tự bảo trì chúng; target tracking cho cùng kết quả với một con số.
• **C. Simple scaling khởi chạy máy khi CPU trung bình chạm 40% — simple scaling chỉ thêm một lượng cố định rồi chờ hết cooldown mới đánh giá lại; nó không giữ được mức mục tiêu, chỉ phản ứng một lần mỗi chu kỳ.
• **A. Dùng CloudWatch alarm tuỳ chỉnh báo cho ASG qua SNS — SNS gửi thông báo cho người hoặc dịch vụ đăng ký; nó không kích hoạt hành động co giãn của ASG.

Ghi nhớ

⚠ Bốn chính sách mở rộng — bảng phải thuộc: | Chính sách | Cách hoạt động | |---|---| | Target tracking | giữ một metric ở mức mục tiêu — mặc định tốt nhất | | Step scaling | bậc thang theo mức độ vượt ngưỡng | | Simple scaling | một hành động rồi chờ cooldown — cách cũ | | Scheduled | theo giờ và ngày định trước | | Predictive | học lịch sử, chuẩn bị TRƯỚC |

Từ khoá nhận diện:

"keep CPU at X%" → target tracking "different action for different severity" → step scaling "traffic spikes at a known time" → scheduled "recurring daily pattern, prepare in advance" → predictive

⚠ AWS khuyến nghị target tracking cho hầu hết trường hợp:

Simple scaling là cách CŨ NHẤT
    → chỉ dùng khi cần tương thích ngược
        ↓
    Thiết kế mới: target tracking,
    thêm scheduled nếu có mẫu đoán trước

Ba yếu tố quyết định tốc độ phản ứng: | Yếu tố | Ảnh hưởng | |---|---| | Chu kỳ metric | 1 phút (detailed) vs 5 phút | | Instance warm-up | thời gian máy sẵn sàng | | Thời gian khởi động ứng dụng | |

⚠ Bật detailed monitoring là cải thiện rẻ nhất:

aws autoscaling update-auto-scaling-group \
  --auto-scaling-group-name asg-web \
  --default-instance-warmup 180

Metric 5 phút: phát hiện tải tăng chậm tới 5 phút
Metric 1 phút: phát hiện trong 1 phút
    → ~0,30 USD mỗi máy mỗi tháng

Ba lưu ý về default-instance-warmup: | Lưu ý | Chi tiết | |---|---| | Thay thế cooldown kiểu cũ | | | Máy chưa "ấm" không tính vào metric | | | Đặt bằng thời gian ứng dụng thật sự sẵn sàng | |

⚠ Không đặt warm-up gây mở rộng thừa:

Máy mới vừa khởi động, CPU thấp
    → kéo trung bình xuống
    → ASG tưởng đã đủ
        ↓
    Hoặc ngược lại: máy đang boot CPU 100%
    → ASG tưởng quá tải, thêm nữa

Ba lưu ý về nhiều chính sách: | Lưu ý | Chi tiết | |---|---| | Gắn nhiều target tracking cùng lúc được | | | ASG chọn hành động cho ra NHIỀU máy nhất | | | Ví dụ: CPU 40% VÀ request 1000/máy | |

Ba lưu ý về metric tuỳ chỉnh: | Lưu ý | Chi tiết | |---|---| | Dùng được metric tự đẩy lên CloudWatch | | | Ví dụ: độ sâu hàng đợi mỗi máy | | | Phải là metric có ý nghĩa TRÊN MỖI MÁY | |

{"TargetValue": 100.0,
 "CustomizedMetricSpecification": {
   "MetricName": "SoTinNhanMoiMay",
   "Namespace": "UngDung",
   "Statistic": "Average"}}

⚠ Metric phải tỷ lệ NGHỊCH với số máy:

Tổng số tin nhắn trong hàng đợi
    → thêm máy KHÔNG làm giảm con số đó ngay
    → target tracking không hội tụ
        ↓
    Phải dùng "tin nhắn mỗi máy" thay vì tổng

Ba lưu ý về DisableScaleIn: | Lưu ý | Chi tiết | |---|---| | Đặt true để chỉ mở rộng, không thu nhỏ | | | Dùng khi có chính sách thu nhỏ riêng | | | Mặc định false — nên giữ nguyên | |

Ba lưu ý về health check: | Lưu ý | Chi tiết | |---|---| | Dùng ELB thay vì EC2 | | | health-check-grace-period đủ dài | | | Quá ngắn = vòng lặp giết máy | |

Ba lưu ý về min và max: | Lưu ý | Chi tiết | |---|---| | min-size ít nhất bằng số AZ | | | max-size là trần an toàn cho chi phí | | | Đặt cảnh báo khi chạm max | |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Chạy tải giả, xem CPU hội tụ về 40% | | | Xem lịch sử hoạt động của ASG | | | Kiểm tra alarm do chính sách tạo ra | |

aws autoscaling describe-scaling-activities \
  --auto-scaling-group-name asg-web --max-items 10 \
  --query "Activities[].[StartTime,StatusCode,Description]" --output table

Và một lời khuyên: hãy cân nhắc ALBRequestCountPerTarget thay cho CPU với ứng dụng web. CPU chỉ tăng sau khi lưu lượng đã dồn tới, nên chính sách dựa trên nó luôn phản ứng chậm hơn một nhịp so với chính sách dựa trên số request đang thật sự đến.

Đáp án

D — Sửa mã ứng dụng để dùng một cụm Amazon ElastiCache for Redis.

Vì sao đúng

Đề cho ba con số, và cả ba đều vượt khả năng của việc đọc thẳng từ S3: | Dữ kiện | Ý nghĩa | |---|---| | Hơn 1 TRIỆU thao tác đọc mỗi giây | vượt xa giới hạn tiền tố của S3 | | Độ trễ dưới 5 ms | S3 là hàng chục mili giây | | Trong khoảng thời gian NGẮN | tải bùng nổ — hợp cache |

⚠ Hai giới hạn của S3 khiến nó không đáp ứng được:

Giới hạn tần suất: ~5.500 GET mỗi giây MỖI TIỀN TỐ
    → 1 triệu/giây cần ~180 tiền tố phân tán hoàn hảo
        ↓
Độ trễ: S3 thường 20-100 ms cho first byte
    → không thể xuống dưới 5 ms

Redis giải quyết cả hai: | Vấn đề | Redis | |---|---| | Thông lượng | hàng trăm nghìn tới hàng triệu ops/giây mỗi node | | Độ trễ | dưới 1 ms | | Mở rộng | cluster mode: thêm shard |

Dựng cụm cluster mode:

aws elasticache create-replication-group \
  --replication-group-id danh-muc-media \
  --replication-group-description "Cache danh muc noi dung" \
  --engine redis --cache-node-type cache.r7g.xlarge \
  --num-node-groups 6 --replicas-per-node-group 2 \
  --automatic-failover-enabled --multi-az-enabled \
  --transit-encryption-enabled --at-rest-encryption-enabled

⚠ Cluster mode là bắt buộc ở quy mô này:

Cluster mode disabled: một shard
    → mọi lệnh đọc đổ vào một primary (và replica)
    → trần khoảng vài trăm nghìn ops/giây
        ↓
Cluster mode enabled: 6 shard
    → tải chia đều theo hash slot
    → cộng dồn vượt 1 triệu ops/giây

Mẫu cache-aside:

import redis, boto3, json

r = redis.RedisCluster(host='danh-muc.abc.clustercfg.apse1.cache.amazonaws.com',
                       port=6379, ssl=True, decode_responses=True)
s3 = boto3.client('s3')

def lay_muc(ma):
    khoa = f"muc:{ma}"
    gia_tri = r.get(khoa)
    if gia_tri:
        return json.loads(gia_tri)
    doi_tuong = s3.get_object(Bucket='kho-media', Key=f"danh-muc/{ma}.json")
    du_lieu = json.loads(doi_tuong['Body'].read())
    r.setex(khoa, 300, json.dumps(du_lieu))
    return du_lieu

⚠ setex đặt TTL ngay khi ghi — đừng dùng set trần:

Không có TTL: khoá lỗi thời nằm mãi
    → bộ nhớ đầy dần, bắt đầu đuổi khoá ngẫu nhiên
        ↓
    TTL là lưới an toàn cho mọi lỗi vô hiệu hoá cache

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Độ trễ dưới 1 ms | | | Giảm mạnh số request tới S3 (và phí) | | | Có Multi-AZ và failover | |

Vì sao các phương án khác sai

• **C. Dùng CloudFront cache nội dung ở edge — đây là phương án gần nhất và là câu trả lời đúng cho việc phục vụ NGƯỜI DÙNG CUỐI, nhưng đề nói máy chủ danh mục (nằm trong AWS) đọc dữ liệu; CloudFront tối ưu cho client phân tán địa lý, không cho một máy chủ trong VPC đọc một triệu lần mỗi giây.
• **B. Dùng DynamoDB Accelerator (DAX) — DAX chỉ tăng tốc DynamoDB; dữ liệu ở đây nằm trong S3 nên DAX không áp dụng được.
• **A. Dùng instance store trên chính máy chủ danh mục — nhanh nhưng dữ liệu chỉ có ở một máy, mất khi máy dừng, và không chia sẻ được giữa nhiều máy chủ danh mục.

Ghi nhớ

⚠ Bốn lớp cache — bảng phải thuộc: | Lớp | Dịch vụ | Cache cho ai | |---|---|---| | Edge | CloudFront | người dùng cuối phân tán | | Ứng dụng | ElastiCache | máy chủ trong VPC | | CSDL | DAX | chỉ DynamoDB | | API | API Gateway cache | phản hồi API |

Từ khoá nhận diện:

"millions of reads/sec, sub-millisecond, from servers" → ElastiCache "global users, static content" → CloudFront "microsecond DynamoDB reads" → DAX "session store" → ElastiCache Redis

⚠ Giới hạn tần suất của S3 phải nhớ: | Thao tác | Giới hạn mỗi tiền tố | |---|---| | GET / HEAD | 5.500 mỗi giây | | PUT / POST / DELETE | 3.500 mỗi giây |

S3 tự mở rộng theo tiền tố
    → nhưng cần thời gian và cần tiền tố phân tán
        ↓
    Tải đột biến 1 triệu/giây sẽ bị 503 SlowDown

Ba chế độ của ElastiCache Redis: | Chế độ | Khi nào | |---|---| | Cluster mode disabled | tập dữ liệu vừa một node | | Cluster mode enabled | cần phân mảnh, thông lượng rất cao | | Serverless | tải thất thường, không muốn chọn cỡ |

Ba lưu ý về cluster mode: | Lưu ý | Chi tiết | |---|---| | Client phải hỗ trợ cluster protocol | | | Dùng configuration endpoint | | | Lệnh đa khoá phải cùng hash slot | |

⚠ Hash tag ép các khoá liên quan vào cùng slot:

r.mget([f"muc:{{{ma_the_loai}}}:1",
        f"muc:{{{ma_the_loai}}}:2"])

Phần trong {} quyết định hash slot
    → các khoá cùng thể loại nằm cùng shard
    → MGET hoạt động được

Ba lưu ý về đọc từ replica: | Lưu ý | Chi tiết | |---|---| | Reader endpoint cân bằng giữa replica | | | Tăng thông lượng đọc nhiều lần | | | Dữ liệu có thể trễ vài mili giây | |

Ba lưu ý về kích thước node: | Lưu ý | Chi tiết | |---|---| | Chừa ~25% bộ nhớ cho overhead | | | Họ r7g tối ưu bộ nhớ | | | Nhiều node nhỏ vs ít node lớn — đo mới biết | |

Ba metric cần theo dõi: | Metric | Ý nghĩa | |---|---| | CacheHitRate | thấp = cache vô ích | | Evictions | tăng = thiếu bộ nhớ | | CPUUtilization mỗi node | |

⚠ Redis đơn luồng cho lệnh — CPU một core là nút thắt:

Redis xử lý lệnh trên MỘT luồng
    → node 16 core vẫn chỉ dùng ~1 core cho lệnh
        ↓
    Thêm SHARD chứ đừng thêm core

Ba lưu ý về chi phí: | Khoản | Chi tiết | |---|---| | Tính theo giờ node | | | Nhưng giảm mạnh phí request S3 | | | 1 triệu GET S3 ≈ 0,40 USD | |

⚠ Tính thử phí S3 nếu không có cache:

1 triệu GET/giây trong 60 giây = 60 triệu request
    → ~24 USD cho MỘT PHÚT
        ↓
    Cache trả tiền cho chính nó rất nhanh

Ba lưu ý về vô hiệu hoá cache: | Cách | Chi tiết | |---|---| | TTL ngắn | đơn giản nhất | | Xoá khoá khi cập nhật nguồn | chính xác hơn | | S3 event → Lambda → xoá khoá Redis | tự động |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đo độ trễ p99 trước và sau | | | Theo dõi CacheHitRate | | | Kiểm tra request tới S3 có giảm | |

Và một lời khuyên: hãy thêm shard chứ đừng tăng cỡ node khi chạm trần thông lượng. Redis xử lý lệnh trên một luồng duy nhất, nên một node lớn hơn cho bạn nhiều bộ nhớ hơn nhưng gần như không thêm chút thông lượng lệnh nào.

Đáp án

A — Tạo một Amazon EFS file share và lập vai trò IAM cho phép Fargate giao tiếp với EFS.

Vì sao đúng

Đề nêu hai yêu cầu, và EFS là dịch vụ duy nhất trong bốn phương án đáp ứng cả hai: | Yêu cầu | Cách đáp ứng | |---|---| | Truy cập ĐỒNG THỜI vào tệp | EFS — hàng nghìn client mount cùng lúc | | Gắn được vào Fargate | Fargate hỗ trợ EFS volume gốc |

⚠ Fargate CHỈ hỗ trợ EFS làm bộ nhớ ngoài bền vững:

Fargate không có EC2 nào để bạn gắn EBS
    → không mount EBS được
    → không mount FSx được
        ↓
    EFS là lựa chọn duy nhất cho lưu trữ tệp bền vững

Gắn EFS vào task definition:

{"family": "phan-tich",
 "requiresCompatibilities": ["FARGATE"],
 "networkMode": "awsvpc",
 "cpu": "2048", "memory": "8192",
 "executionRoleArn": "<arn-execution-role>",
 "taskRoleArn": "<arn-task-role>",
 "volumes": [{
   "name": "du-lieu-chung",
   "efsVolumeConfiguration": {
     "fileSystemId": "fs-abc",
     "transitEncryption": "ENABLED",
     "authorizationConfig": {
       "accessPointId": "fsap-abc",
       "iam": "ENABLED"}}}],
 "containerDefinitions": [{
   "name": "phan-tich",
   "image": "<id>.dkr.ecr.ap-southeast-1.amazonaws.com/phan-tich:1.0",
   "mountPoints": [{
     "sourceVolume": "du-lieu-chung",
     "containerPath": "/du-lieu"}]}]}

⚠ transitEncryption: ENABLED là BẮT BUỘC với Fargate:

Fargate không cho mount NFS trần
    → phải bật mã hoá khi truyền
        ↓
    Thiếu là task không khởi động được

Task role cần quyền EFS:

{"Effect": "Allow",
 "Action": ["elasticfilesystem:ClientMount",
            "elasticfilesystem:ClientWrite",
            "elasticfilesystem:ClientRootAccess"],
 "Resource": "<arn-file-system>",
 "Condition": {"StringEquals":
   {"elasticfilesystem:AccessPointArn": "<arn-access-point>"}}}

⚠ Access point là thực hành nên theo:

aws efs create-access-point --file-system-id fs-abc \
  --posix-user 'Uid=1000,Gid=1000' \
  --root-directory 'Path=/phan-tich,
    CreationInfo={OwnerUid=1000,OwnerGid=1000,Permissions=0755}'

Ép thư mục gốc và POSIX user cho từng ứng dụng
    → nhiều ứng dụng dùng chung một file system
      mà không thấy dữ liệu của nhau

Dùng Elastic throughput cho hiệu năng:

aws efs create-file-system --performance-mode generalPurpose \
  --throughput-mode elastic --encrypted

⚠ Đừng dùng chế độ bursting cho ứng dụng phân tích:

Bursting: thông lượng cơ sở theo dung lượng
    → file system nhỏ có thông lượng rất thấp
    → cạn credit là chậm thảm hại
        ↓
    Elastic throughput: tự lên xuống theo tải

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Nhiều task đọc ghi cùng lúc | | | Tự mở rộng, không cấp dung lượng | | | Dữ liệu sống qua vòng đời của task | |

Vì sao các phương án khác sai

• **D. Dùng FSx for Lustre — đây là phương án gần nhất về mặt hiệu năng cao và dùng chung, và Lustre thật sự nhanh hơn EFS cho HPC, nhưng Fargate không mount được FSx; chỉ EC2 và EKS trên EC2 mới làm được.
• **C. Dùng EBS volume cho Fargate — Fargate không có instance để gắn EBS; và EBS không cho truy cập đồng thời từ nhiều task ở nhiều AZ.
• **B. Dùng S3 bucket — S3 là lưu trữ đối tượng, không mount làm hệ thống tệp; ứng dụng phải viết lại theo API và mất ngữ nghĩa POSIX.

Ghi nhớ

⚠ Lưu trữ cho Fargate — bảng phải thuộc: | Loại | Fargate hỗ trợ | |---|---| | EFS | ✅ — lựa chọn duy nhất cho tệp bền vững | | Ephemeral storage | ✅ — 20-200 GB, MẤT khi task dừng | | EBS | ✅ từ 2024 nhưng gắn theo TASK, không dùng chung | | FSx | ❌ | | Instance store | ❌ |

⚠ Fargate có ephemeral storage — nhưng không bền:

{"ephemeralStorage": {"sizeInGiB": 100}}

Dùng cho tệp tạm trong lúc xử lý
    → mất sạch khi task kết thúc
        ↓
    Không thay thế được EFS

Từ khoá nhận diện:

"Fargate + shared file storage" → EFS "EC2 + shared file storage, Linux" → EFS "EC2 + Windows shared files" → FSx for Windows "HPC, highest throughput, EC2" → FSx for Lustre

Ba lưu ý về hiệu năng EFS: | Lưu ý | Chi tiết | |---|---| | Độ trễ cao hơn EBS — đi qua mạng | | | Không hợp CSDL đòi độ trễ thấp | | | Rất hợp tệp dùng chung và tài sản | |

⚠ Nếu ứng dụng phân tích cần thông lượng cực cao:

EFS Elastic throughput: tới hàng GB/s
        ↓
FSx for Lustre: tới hàng TRĂM GB/s
    → nhưng phải chạy trên EC2, không phải Fargate
        ↓
    Đánh đổi: đơn giản (Fargate+EFS)
              hay hiệu năng tối đa (EC2+Lustre)

Ba chế độ throughput của EFS: | Chế độ | Khi nào | |---|---| | Elastic | mặc định, tải không đoán trước | | Provisioned | cần thông lượng ổn định cao | | Bursting | cũ, phụ thuộc dung lượng |

Ba lớp lưu trữ EFS: | Lớp | Giá tương đối | |---|---| | Standard | 100% | | Infrequent Access | ~8% + phí đọc | | Archive | ~4% + phí đọc cao hơn |

aws efs put-lifecycle-configuration --file-system-id fs-abc \
  --lifecycle-policies \
    '[{"TransitionToIA":"AFTER_30_DAYS"},
      {"TransitionToPrimaryStorageClass":"AFTER_1_ACCESS"}]'

Ba lưu ý về mạng: | Lưu ý | Chi tiết | |---|---| | Mount target ở MỖI AZ task có thể chạy | | | Security group mở cổng 2049 (NFS) | | | SG của mount target nhận từ SG của task | |

⚠ Thiếu mount target ở một AZ là lỗi ngẫu nhiên:

Fargate đặt task ở AZ ngẫu nhiên trong subnet đã khai
    → AZ nào thiếu mount target
        ↓
    Task ở đó không khởi động được
    → lỗi xuất hiện "thỉnh thoảng"

Ba lưu ý về bảo mật: | Lưu ý | Chi tiết | |---|---| | Bật mã hoá at rest LÚC TẠO — không sửa sau | | | transitEncryption bắt buộc với Fargate | | | File system policy giới hạn theo IAM | |

Ba lưu ý về Fargate: | Lưu ý | Chi tiết | |---|---| | Platform version 1.4 trở lên cho EFS | | | Không SSH được — dùng ECS Exec | | | CPU và bộ nhớ theo tổ hợp cố định | |

aws ecs execute-command --cluster cum-phan-tich \
  --task <id-task> --container phan-tich \
  --interactive --command "/bin/sh"

Ba lưu ý về chi phí: | Khoản | Chi tiết | |---|---| | EFS tính theo GB thật dùng | | | Elastic throughput tính theo lượng đọc ghi | | | Lifecycle sang IA giảm nhiều | |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Ghi tệp ở task A, đọc ở task B | | | Kiểm tra mount target đủ mọi AZ | | | Đo thông lượng thật | |

aws efs describe-mount-targets --file-system-id fs-abc \
  --query "MountTargets[].[AvailabilityZoneName,LifeCycleState]" \
  --output table

Và một lời khuyên: hãy kiểm tra EFS có mount target ở mọi AZ mà task Fargate được phép chạy. Thiếu một AZ không gây lỗi lúc dựng — nó chỉ khiến một phần task ngẫu nhiên không khởi động được, và đó là dạng sự cố khó lần ra nhất vì nó trông như một vấn đề tạm thời.

Đáp án

B — Multi-site.

Vì sao đúng

Đề dùng chính thuật ngữ định nghĩa chiến lược này: | Dữ kiện | Khớp với | |---|---| | Chuyển vùng LIỀN MẠCH, gián đoạn tối thiểu | RTO gần bằng 0 | | Mất dữ liệu tối thiểu | RPO gần bằng 0 | | Cấu hình ACTIVE-ACTIVE | định nghĩa của multi-site |

⚠ "Active-active" chỉ có ở một chiến lược duy nhất:

Backup & Restore: không có gì chạy ở DR
Pilot Light:      chỉ dữ liệu, app TẮT
Warm Standby:     app CHẠY nhưng KHÔNG phục vụ
        ↓
Multi-site:       CẢ HAI vùng ĐANG PHỤC VỤ lưu lượng thật

Kiến trúc điển hình:

Route 53 (weighted hoặc latency routing)
    ├── Vùng A: ALB + ASG + Aurora Global (writer)
    └── Vùng B: ALB + ASG + Aurora Global (reader)
        ↓
    Cả hai nhận lưu lượng
    → một vùng hỏng, health check rút nó ra
    → vùng còn lại tiếp nhận toàn bộ

Route 53 latency-based routing:

aws route53 change-resource-record-sets --hosted-zone-id <id> \
  --change-batch '{"Changes":[{
    "Action":"UPSERT",
    "ResourceRecordSet":{
      "Name":"ung-dung.vidu.com","Type":"A",
      "SetIdentifier":"vung-a",
      "Region":"ap-southeast-1",
      "HealthCheckId":"<id-health-check-a>",
      "AliasTarget":{"HostedZoneId":"<id-alb-a>",
        "DNSName":"alb-a.ap-southeast-1.elb.amazonaws.com",
        "EvaluateTargetHealth":true}}}]}'

⚠ Tầng dữ liệu là phần khó nhất của multi-site: | Dịch vụ | Khả năng ghi nhiều vùng | |---|---| | DynamoDB Global Tables | ✅ active-active thật | | Aurora Global Database | ❌ một writer duy nhất | | S3 CRR / bi-directional | ✅ eventual |

Aurora Global: đọc ở mọi vùng, GHI chỉ ở một vùng
    → "active-active" ở tầng ứng dụng
    → nhưng ghi vẫn phải đi về vùng chính
        ↓
    Ghi thật sự ở mọi vùng cần DynamoDB Global Tables

⚠ DynamoDB Global Tables giải quyết xung đột kiểu "last writer wins":

Hai vùng cùng ghi một item
    → bản ghi có timestamp muộn hơn thắng
        ↓
    Ứng dụng phải chấp nhận điều này,
    hoặc thiết kế để tránh ghi cùng khoá ở hai nơi

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | RTO và RPO gần bằng 0 | | | Phục vụ người dùng gần nhất | độ trễ thấp hơn | | Vùng DR được kiểm chứng liên tục | |

⚠ Vế thứ ba quan trọng hơn người ta nghĩ:

Warm Standby: hạ tầng DR chạy nhưng chưa phục vụ thật
    → không biết chắc nó chịu được tải thật
        ↓
Multi-site: nó ĐANG phục vụ tải thật mỗi ngày
    → không có bất ngờ vào ngày sự cố

Vì sao các phương án khác sai

• **A. Warm standby — đây là phương án gần nhất về mặt RTO thấp (tính bằng phút), nhưng vùng phụ chỉ chạy ở quy mô nhỏ và CHƯA phục vụ lưu lượng; đề nói rõ "active-active".
• **D. Pilot light — tầng ứng dụng ở vùng phụ TẮT hoàn toàn; RTO tính bằng chục phút.
• **C. Backup and restore — chỉ có bản sao lưu, phải dựng lại toàn bộ; RTO tính bằng giờ tới ngày.

Ghi nhớ

⚠ Bốn chiến lược DR — bảng phải thuộc: | Chiến lược | RTO | RPO | Chi phí | Vùng DR | |---|---|---|---|---| | Backup & Restore | giờ - ngày | giờ | thấp nhất | không có gì | | Pilot Light | chục phút | phút | thấp | dữ liệu, app TẮT | | Warm Standby | phút | giây | trung bình | app chạy NHỎ | | Multi-Site | gần 0 | gần 0 | cao nhất | app PHỤC VỤ THẬT |

⚠ Cách phân biệt nhanh nhất — nhìn tầng ứng dụng ở vùng DR:

Không có gì            → Backup & Restore
Dữ liệu có, app TẮT    → Pilot Light
App chạy, CHƯA phục vụ → Warm Standby
App ĐANG phục vụ       → Multi-Site

Từ khoá nhận diện:

"active-active, seamless, minimal downtime and data loss" → Multi-site "scaled down but fully functional" → Warm standby "core services replicated, others off" → Pilot light "restore from backups" → Backup and restore

Ba định nghĩa phải thuộc: | Chỉ số | Nghĩa | |---|---| | RTO | bao lâu để KHÔI PHỤC dịch vụ | | RPO | được phép MẤT bao nhiêu dữ liệu | | Chi phí | tăng theo mức RTO/RPO càng thấp |

Ba kiểu định tuyến Route 53 cho multi-site: | Kiểu | Chi tiết | |---|---| | Latency-based | gửi tới vùng nhanh nhất | | Weighted | chia theo tỷ lệ | | Geolocation | theo vị trí người dùng |

⚠ Luôn kèm health check:

Không có health check
    → Route 53 vẫn gửi lưu lượng tới vùng đã chết
        ↓
    `EvaluateTargetHealth: true` cho alias record
    → tự rút vùng hỏng ra

Ba lưu ý về TTL: | Lưu ý | Chi tiết | |---|---| | TTL thấp = chuyển nhanh hơn | | | TTL 60 giây là mức thường dùng | | | TTL cao làm RTO thực tế dài hơn | |

Ba lưu ý về chi phí multi-site: | Khoản | Chi tiết | |---|---| | Hạ tầng đầy đủ ở CẢ HAI vùng | | | Phí truyền dữ liệu xuyên vùng | | | Nhân đôi công vận hành và triển khai | |

⚠ Chi phí không chỉ là tiền máy:

Mỗi lần triển khai phải làm ở hai vùng
Mỗi lần gỡ lỗi phải nhìn hai nơi
Mỗi thay đổi cấu hình phải đồng bộ
        ↓
    Dùng CloudFormation StackSets hoặc CDK
    → đừng bao giờ cấu hình tay

Ba lưu ý về tính nhất quán dữ liệu: | Lưu ý | Chi tiết | |---|---| | Active-active thật cần CSDL hỗ trợ ghi đa vùng | | | Phải chấp nhận eventual consistency | | | Hoặc phân vùng dữ liệu theo vùng | |

⚠ Mẫu phân vùng dữ liệu tránh được xung đột:

Người dùng châu Á → ghi vào vùng Singapore
Người dùng châu Âu → ghi vào vùng Frankfurt
        ↓
    Không có hai nơi ghi cùng một bản ghi
    → không cần giải quyết xung đột

Ba lưu ý về Route 53 ARC: | Tính năng | Việc | |---|---| | Readiness check | vùng có sẵn sàng thật không | | Routing control | công tắc chuyển vùng có chủ ý | | Zonal shift | rút một AZ khỏi lưu lượng |

Ba lưu ý về diễn tập: | Lưu ý | Chi tiết | |---|---| | Rút một vùng khỏi lưu lượng định kỳ | | | Đo xem vùng còn lại chịu nổi 100% tải không | | | Kiểm tra hạn ngạch đủ cho tải gấp đôi | |

⚠ Đây là điều hay bị bỏ sót nhất trong multi-site:

Hai vùng, mỗi vùng chịu 50% tải
    → một vùng hỏng
        ↓
    Vùng còn lại phải chịu 100%
    → nếu không đủ năng lực thì cũng sập luôn

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Rút một vùng, xem vùng kia gánh nổi | | | Đo độ trễ nhân bản dữ liệu | | | Kiểm tra hạn ngạch ở cả hai vùng | |

Và một lời khuyên: hãy kiểm tra mỗi vùng có đủ năng lực gánh 100% lưu lượng, không phải 50%. Multi-site chia tải khi mọi thứ bình thường, nhưng toàn bộ giá trị của nó nằm ở khoảnh khắc một vùng biến mất — và lúc đó vùng còn lại phải làm việc của cả hai.

Đáp án

C — Cho microservice 1 gửi dữ liệu vào một hàng đợi Amazon SQS, và microservice 2 xử lý tin nhắn từ hàng đợi đó.

Vì sao đúng

Đề nêu hai yêu cầu, và SQS đáp ứng cả hai bằng chính bản chất của nó: | Yêu cầu | Cách đáp ứng | |---|---| | Tích hợp hai microservice | SQS làm lớp trung gian | | Co giãn ĐỘC LẬP | hàng đợi hấp thụ chênh lệch tốc độ |

⚠ Chi tiết "phần thứ hai chậm hơn phần thứ nhất" chính là bài toán SQS giải:

Service 1 xử lý 1000 tin/phút
Service 2 xử lý 200 tin/phút
        ↓
    Không có đệm: service 1 phải chờ service 2
    → hai bên bị ràng buộc tốc độ với nhau
        ↓
    Có SQS: service 1 đẩy tin rồi đi tiếp
    → hàng đợi phình ra, service 2 tiêu dần
    → mỗi bên mở rộng theo nhu cầu riêng

Mở rộng ECS theo độ sâu hàng đợi:

aws application-autoscaling put-scaling-policy \
  --service-namespace ecs \
  --scalable-dimension ecs:service:DesiredCount \
  --resource-id service/cum-ung-dung/dich-vu-2 \
  --policy-name theo-hang-doi \
  --policy-type TargetTrackingScaling \
  --target-tracking-scaling-policy-configuration '{
    "TargetValue": 20.0,
    "CustomizedMetricSpecification": {
      "MetricName": "SoTinNhanMoiTask",
      "Namespace": "UngDung",
      "Statistic": "Average"}}'

⚠ Metric phải là "tin nhắn MỖI TASK", không phải tổng số tin nhắn:

Dùng tổng ApproximateNumberOfMessagesVisible
    → thêm task KHÔNG làm con số đó giảm ngay
    → target tracking không hội tụ, cứ thêm mãi
        ↓
    Chia tổng cho số task đang chạy
    → đó mới là metric hội tụ được

Xử lý tin nhắn với báo lỗi theo từng phần:

def handler(su_kien, ngu_canh):
    that_bai = []
    for ban_ghi in su_kien['Records']:
        try:
            xu_ly(ban_ghi['body'])
        except Exception:
            that_bai.append({'itemIdentifier': ban_ghi['messageId']})
    return {'batchItemFailures': that_bai}

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Service 1 không bao giờ chờ service 2 | | | Service 2 hỏng thì tin nhắn vẫn nằm chờ | | | Mỗi bên mở rộng theo metric riêng | |

⚠ Vế thứ hai là giá trị lớn nhất của SQS:

Service 2 sập
    → không mất dữ liệu, tin nhắn nằm trong hàng đợi
        ↓
    Service 2 hồi phục → tiêu hết tồn đọng
    → sự cố thành chậm trễ, không thành mất mát

Vì sao các phương án khác sai

• **D. Dùng SNS với service 2 đăng ký chủ đề — đây là phương án gần nhất và cũng tách rời hai bên, nhưng SNS là đẩy tức thì, không có bộ đệm: nếu service 2 chậm hoặc chết, tin nhắn bị mất hoặc đẩy lại theo chính sách thử lại — không có hàng đợi để nằm chờ.
• **B. Dùng Kinesis Data Firehose — Firehose giao dữ liệu tới S3, Redshift, OpenSearch; nó không phải kênh cho một microservice đọc theo kiểu tiêu thụ tin nhắn.
• **A. Ghi vào S3 rồi dùng S3 event kích hoạt service 2 — chạy được nhưng nặng nề: mỗi bản ghi thành một object, không có cơ chế thử lại và visibility timeout của hàng đợi, và không kiểm soát được nhịp tiêu thụ.

Ghi nhớ

⚠ SQS vs SNS vs EventBridge — bảng phải thuộc: | Dịch vụ | Mô hình | Bộ đệm | |---|---|---| | SQS | kéo, MỘT người tiêu thụ mỗi tin | ✅ có | | SNS | đẩy, phát tán NHIỀU người nhận | ❌ | | EventBridge | đẩy, định tuyến theo mẫu | ❌ | | Kinesis | kéo, nhiều consumer, đọc lại được | ✅ giữ dữ liệu |

Từ khoá nhận diện:

"decouple, buffer, scale independently" → SQS "fan-out to multiple subscribers" → SNS "route events by content" → EventBridge "ordered stream, replay" → Kinesis

⚠ Mẫu SNS + SQS kết hợp rất phổ biến:

SNS phát tán tới NHIỀU hàng đợi SQS
    → mỗi hệ thống hạ nguồn có bộ đệm riêng
        ↓
    Vừa fan-out vừa có đệm

Ba lưu ý về hàng đợi thư chết: | Lưu ý | Chi tiết | |---|---| | Luôn cấu hình DLQ | | | maxReceiveCount thường 3-5 | | | Cảnh báo khi DLQ có tin | |

aws sqs set-queue-attributes --queue-url <url> \
  --attributes '{"RedrivePolicy":
    "{\"deadLetterTargetArn\":\"<arn-dlq>\",
      \"maxReceiveCount\":\"5\"}"}'

⚠ Không có DLQ thì tin hỏng quay vòng mãi:

Tin nhắn không xử lý được
    → thử lại, thất bại, quay lại hàng đợi
        ↓
    Lặp vô hạn, tốn tiền, che khuất tin nhắn tốt

Ba lưu ý về visibility timeout: | Lưu ý | Chi tiết | |---|---| | Phải LỚN HƠN thời gian xử lý | | | Quá ngắn = tin bị xử lý hai lần | | | Gia hạn được bằng ChangeMessageVisibility | |

Ba lưu ý về idempotency: | Lưu ý | Chi tiết | |---|---| | SQS chuẩn giao ÍT NHẤT một lần | | | Có thể trùng — phải thiết kế chịu được | | | Dùng khoá tự nhiên hoặc bảng khử trùng | |

INSERT INTO ket_qua (ma_ban_ghi, ...) VALUES (...)
ON CONFLICT (ma_ban_ghi) DO NOTHING;

⚠ SQS FIFO nếu thứ tự quan trọng: | Tiêu chí | Standard | FIFO | |---|---|---| | Thứ tự | không đảm bảo | đảm bảo trong group | | Trùng lặp | có thể | đúng một lần | | Thông lượng | gần như không giới hạn | 3.000/giây với batching |

Ba metric cần theo dõi: | Metric | Ý nghĩa | |---|---| | ApproximateAgeOfOldestMessage | tụt hậu bao lâu | | ApproximateNumberOfMessagesVisible | tồn đọng | | NumberOfMessagesSent vs Deleted | |

⚠ ApproximateAgeOfOldestMessage là chỉ số sức khoẻ tốt nhất:

Tuổi tin nhắn cũ nhất tăng đều
    → tiêu thụ chậm hơn sản xuất
        ↓
    Cảnh báo trước khi tồn đọng thành khủng hoảng

Ba lưu ý về giới hạn: | Giới hạn | Giá trị | |---|---| | Kích thước tin nhắn | 256 KB | | Giữ tin tối đa | 14 ngày | | Payload lớn | dùng Extended Client Library với S3 |

Ba lưu ý về long polling: | Lưu ý | Chi tiết | |---|---| | Đặt ReceiveMessageWaitTimeSeconds=20 | | | Giảm số lời gọi API rỗng | | | Giảm chi phí và độ trễ | |

Ba lưu ý về ECS consumer: | Lưu ý | Chi tiết | |---|---| | Task role cần quyền SQS | | | Xử lý SIGTERM để hoàn tất tin đang làm | | | stopTimeout đủ dài | |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Dừng service 2, xem hàng đợi phình | | | Bật lại, xem tiêu hết tồn đọng | | | Theo dõi tuổi tin nhắn cũ nhất | |

Và một lời khuyên: hãy mở rộng service 2 theo "số tin nhắn mỗi task" chứ đừng theo tổng số tin nhắn. Tổng tồn đọng không giảm ngay khi bạn thêm task, nên chính sách dựa trên nó sẽ cứ thêm mãi cho tới khi chạm trần — và bạn có một đội container khổng lồ giải quyết một hàng đợi vốn đã sắp cạn.