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

Đáp án

B và C.

• B — Provisioned IOPS cho hiệu năng nhất quán, độ trễ thấp, dành cho ứng dụng I/O nặng như database quan hệ hoặc NoSQL lớn
• C — Magnetic volume có chi phí mỗi gigabyte thấp nhất, phù hợp dữ liệu ít truy cập và ứng dụng ưu tiên giá rẻ

Vì sao đúng

B — mô tả đúng về Provisioned IOPS (io1/io2):

Bạn KHAI số IOPS cần → AWS đảm bảo mức đó
    → hiệu năng nhất quán, không phụ thuộc dung lượng
    → độ trễ dưới một mili giây (io2 Block Express)
    → dành cho database chịu tải cao

io2 còn có độ bền 99,999% — cao hơn gp3 và io1 một bậc, quan trọng cho database quan trọng.

C — và Magnetic (standard) đúng là loại rẻ nhất mỗi GB trong các loại EBS:

Magnetic (standard):  ~0,05 USD/GB-tháng
gp2 / gp3:            ~0,08–0,10 USD/GB-tháng
io1 / io2:            ~0,125 USD/GB-tháng + phí IOPS

Nó là thế hệ cũ, dùng đĩa từ thật, phù hợp cho dữ liệu truy cập không thường xuyên — đúng như mô tả trong phương án.

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

• **D. gp3 với multi-attach cho hiệu năng nhất quán, thiết kế cho ứng dụng cần khả năng chịu lỗi đa AZ — đây là phương án gần nhất và có phần gp3 đúng, nhưng nó sai hai chỗ: multi-attach chỉ hỗ trợ io1 và io2, KHÔNG hỗ trợ gp3. Và multi-attach chỉ cho phép gắn volume vào nhiều instance trong CÙNG MỘT AZ — EBS không bao giờ trải qua nhiều AZ.
• **A. Spot volume có chi phí mỗi GB thấp nhất — loại volume này KHÔNG TỒN TẠI: "Spot" là mô hình mua EC2 instance, không có khái niệm EBS volume kiểu Spot.
• **E. SR-IOV volume phù hợp cho nhiều loại workload — nhầm khái niệm hoàn toàn: SR-IOV là công nghệ ảo hoá thiết bị MẠNG (nền tảng của Enhanced Networking trên EC2). Nó không phải loại EBS volume.

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

Phương án C phản ánh danh mục EBS cũ. Magnetic (standard) là thế hệ trước, AWS đã khuyến nghị không dùng cho workload mới từ lâu. Hiện nay loại rẻ nhất mỗi GB là:

sc1 (Cold HDD):        ~0,015 USD/GB-tháng   ← rẻ nhất hiện nay
st1 (Throughput HDD):  ~0,045 USD/GB-tháng
standard (Magnetic):   ~0,05 USD/GB-tháng    ← đáp án theo bộ đề

Nghĩa là câu "Magnetic rẻ nhất trong MỌI loại EBS" không còn đúng với danh mục hiện tại. Nó vẫn là đáp án đúng theo bộ đề vì đây là kiến thức ở thời điểm câu hỏi được soạn, và vì bốn phương án còn lại đều sai rõ ràng hơn.

Ghi nhớ

Các loại EBS volume — bảng cần thuộc: | Loại | Công nghệ | IOPS tối đa | Phù hợp | |---|---|---|---| | gp3 | SSD | 16.000 (cấu hình ĐỘC LẬP với dung lượng) | mặc định tốt cho hầu hết | | gp2 | SSD | 16.000 (3 IOPS/GB) | thế hệ trước của gp3 | | io1 | SSD | 64.000 | I/O nặng | | io2 Block Express | SSD | 256.000 | database quan trọng nhất | | st1 | HDD | 500 (tối ưu THÔNG LƯỢNG) | big data, log, xử lý tuần tự | | sc1 | HDD | 250 | dữ liệu lạnh, rẻ nhất | | standard | HDD (thế hệ cũ) | 40–200 | không dùng cho mới |

gp3 là cải tiến quan trọng so với gp2:

gp2: IOPS = 3 × dung lượng (GB)
    → muốn 6.000 IOPS phải mua 2 TB dù chỉ cần 200 GB dữ liệu

gp3: IOPS và throughput cấu hình RIÊNG
    → 200 GB + 6.000 IOPS → rẻ hơn nhiều
    → và gp3 rẻ hơn gp2 khoảng 20% ở cùng dung lượng

Quy tắc chọn:

Không rõ nên chọn gì → gp3 Database cần IOPS rất cao và ổn định → io2 Đọc ghi TUẦN TỰ, khối lượng lớn (log, big data) → st1 Dữ liệu lạnh, ưu tiên giá → sc1

Hai loại HDD (st1, sc1) tối ưu THÔNG LƯỢNG chứ không phải IOPS — chúng rất tệ cho truy cập ngẫu nhiên và không dùng làm root volume được.

Ba đặc điểm căn bản của EBS: | Đặc điểm | Chi tiết | |---|---| | Gắn với MỘT Availability Zone | chuyển AZ phải qua snapshot | | Bền vững độc lập với instance | trừ khi DeleteOnTermination = true | | Snapshot có phạm vi Region | sao chép chéo Region được |

Multi-attach — làm rõ vì phương án D nhắc tới: | Đặc điểm | Chi tiết | |---|---| | Chỉ io1 và io2 | KHÔNG hỗ trợ gp3 | | Tối đa 16 instance | trong CÙNG một AZ | | Cần hệ thống tệp hỗ trợ truy cập đồng thời | ext4 hay XFS thông thường sẽ HỎNG DỮ LIỆU |

Dòng cuối là cảnh báo quan trọng: multi-attach chỉ dùng được với ứng dụng biết điều phối ghi (như cụm Oracle RAC), không phải cách "chia sẻ tệp giữa các máy". Muốn chia sẻ tệp thì dùng EFS.

EBS và các lựa chọn lưu trữ khác: | Dịch vụ | Loại | Chia sẻ nhiều máy | Đa AZ | |---|---|---|---| | EBS | khối | multi-attach (cùng AZ) | ❌ | | EFS | tệp (NFS) | ✅ hàng nghìn máy | ✅ | | FSx for Windows | tệp (SMB) | ✅ | ✅ (Multi-AZ) | | Instance store | khối cục bộ | ❌ | ❌ | | S3 | object | ✅ (qua API) | ✅ |

Với yêu cầu "nhiều instance cùng đọc ghi, chịu lỗi đa AZ" — thứ mà phương án D mô tả sai — câu trả lời đúng là EFS, không phải EBS.

Ba cách tối ưu chi phí EBS: | Cách | Tiết kiệm | |---|---| | Chuyển gp2 sang gp3 | ~20% ngay lập tức, không cần ngừng máy | | Xoá volume mồ côi | volume available vẫn tính tiền | | Dọn snapshot cũ bằng Data Lifecycle Manager | snapshot tích tụ âm thầm |

Chuyển gp2 sang gp3 là tối ưu dễ nhất trên AWS: một lệnh, không gián đoạn, giảm ngay chi phí:

aws ec2 modify-volume --volume-id vol-0abc123 --volume-type gp3

Và một lưu ý cho tình huống trong đề: nếu ứng dụng web cần dữ liệu bền vững và nhiều instance cùng truy cập, EBS không phải câu trả lời dù nó bền hơn instance store. Kiến trúc đúng là tệp người dùng ở S3 hoặc EFS, phiên đăng nhập ở ElastiCache, dữ liệu ứng dụng ở RDS — instance giữ trạng thái là mô hình khó mở rộng.

Đáp án

B — Tạo RDS Read Replica của database sản xuất và hướng đội Phân tích Dữ liệu truy vấn trên replica đó.

Vì sao đúng

Đề nêu ba yêu cầu, và read replica đáp ứng cả ba: | Yêu cầu | Cơ chế | |---|---| | Chạy truy vấn phân tích trên dữ liệu sản xuất | replica có bản sao đầy đủ, cập nhật liên tục | | KHÔNG ảnh hưởng hiệu năng ứng dụng | truy vấn chạy trên instance RIÊNG BIỆT | | Tiết kiệm chi phí | rẻ hơn nhiều so với dựng kho dữ liệu |

Vì sao việc tách biệt là quan trọng:

Truy vấn phân tích thường:
    - quét lượng dữ liệu lớn
    - chạy lâu
    - tiêu tốn nhiều CPU và I/O
        ↓
Chạy trên database sản xuất:
    → tranh giành tài nguyên với ứng dụng OLTP
    → giao dịch của người dùng chậm hoặc timeout

Read replica loại bỏ hoàn toàn tương tác đó:

Primary  → chỉ phục vụ ứng dụng OLTP
   │ sao chép BẤT ĐỒNG BỘ (không làm chậm primary)
   ▼
Replica  → chỉ phục vụ đội phân tích

Và sao chép bất đồng bộ là chi tiết quan trọng: primary ghi xong là trả lời client ngay, việc đồng bộ sang replica diễn ra ở nền — nên tạo replica không làm chậm ứng dụng.

aws rds create-db-instance-read-replica   --db-instance-identifier db-phan-tich   --source-db-instance-identifier db-san-xuat   --db-instance-class db.r6g.large

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

• **C. Cấu hình Multi-AZ và cho đội phân tích truy vấn standby instance — đây là phương án gần nhất và là hiểu nhầm rất phổ biến: standby instance của Multi-AZ KHÔNG truy cập được. Nó không có endpoint riêng, không phục vụ truy vấn nào — nó chỉ ngồi chờ để tiếp quản khi primary hỏng.
• **A. Dựng cụm Amazon Redshift và di chuyển database sản xuất vào đó — quá nặng và đắt cho nhu cầu này: Redshift là kho dữ liệu cho phân tích quy mô rất lớn, chi phí cao hơn hẳn, và cần dựng thêm đường ống ETL để đồng bộ dữ liệu. Đề hỏi "MOST cost-effective".
• **D. Nâng cấp lên instance lớn hơn — không giải quyết vấn đề cô lập: máy mạnh hơn vẫn chia sẻ tài nguyên giữa hai loại tải. Truy vấn phân tích nặng vẫn ảnh hưởng ứng dụng, chỉ là ngưỡng chịu đựng cao hơn một chút. Và chi phí tăng cho cả tải sản xuất lẫn tải phân tích.

Ghi nhớ

Read replica và Multi-AZ — bảng phân biệt cốt lõi: | | Read replica | Multi-AZ | |---|---|---| | Mục đích | MỞ RỘNG khả năng đọc | SẴN SÀNG CAO | | Truy cập được instance thứ hai | ✅ có endpoint riêng | ❌ KHÔNG BAO GIỜ | | Sao chép | bất đồng bộ | đồng bộ | | Failover | thủ công (promote) | tự động | | Vị trí | cùng AZ, khác AZ, hoặc khác Region | AZ khác cùng Region | | Số lượng | tới 5 (RDS) / 15 (Aurora) | 1 standby |

"Standby của Multi-AZ không truy cập được" là điều cần thuộc lòng — nó là bẫy xuất hiện rất thường xuyên trong đề thi.

Và chúng bổ sung nhau, thường dùng cùng lúc:

Primary (Multi-AZ)  ──đồng bộ──▶  Standby        (sẵn sàng cao)
      │
      └──bất đồng bộ──▶  Read replica            (phân tích, báo cáo)

Bốn công dụng của read replica: | Công dụng | Chi tiết | |---|---| | Tách tải phân tích và báo cáo | ← câu này | | Gánh bớt truy vấn đọc của ứng dụng | mở rộng khả năng đọc | | Replica xuyên Region | phục hồi thảm hoạ + giảm độ trễ cho người dùng xa | | Nâng cấp có kiểm soát | promote replica đã nâng cấp phiên bản |

Ba lưu ý khi dùng read replica cho phân tích: | Lưu ý | Chi tiết | |---|---| | Độ trễ sao chép | dữ liệu trên replica có thể chậm vài giây — chấp nhận được cho báo cáo | | Kích thước replica có thể KHÁC primary | truy vấn phân tích nặng thì cho replica nhiều RAM hơn | | Thêm chỉ mục riêng trên replica | tối ưu cho truy vấn phân tích mà không ảnh hưởng primary |

Dòng giữa là tối ưu thực dụng đáng chú ý: replica không cần cùng cấu hình với primary. Đội phân tích chạy truy vấn quét nhiều dữ liệu thì replica nên có nhiều bộ nhớ; ngược lại nếu chỉ chạy báo cáo nhẹ thì dùng instance nhỏ hơn primary để tiết kiệm.

Metric cần theo dõi: ReplicaLag. Nếu độ trễ tăng cao, nguyên nhân thường là:

① Primary ghi quá nhiều, replica không theo kịp
② Replica thiếu tài nguyên (CPU, I/O)
③ Truy vấn dài trên replica chặn việc áp dụng thay đổi

Nguyên nhân ③ đáng chú ý với ca sử dụng phân tích: một truy vấn chạy hàng chục phút có thể làm replica tụt hậu đáng kể.

Ba lựa chọn khi nhu cầu phân tích vượt quá khả năng của read replica: | Lựa chọn | Phù hợp | |---|---| | Amazon Redshift | kho dữ liệu, phân tích trên hàng tỷ dòng | | Athena trên dữ liệu xuất ra S3 | truy vấn thỉnh thoảng, chi phí thấp | | Aurora + zero-ETL sang Redshift | đồng bộ gần thời gian thực, không cần đường ống ETL |

Zero-ETL integration là tính năng đáng biết: Aurora tự sao chép dữ liệu sang Redshift trong vài giây mà không cần viết job ETL nào — kết hợp được OLTP và phân tích quy mô lớn.

Và một lựa chọn nhẹ nhàng cho việc kiểm toán mà đề nhắc tới: nếu nhu cầu chỉ là theo dõi và kiểm toán giao dịch của người dùng, hãy cân nhắc ghi log sự kiện ra S3 (qua Kinesis Firehose) rồi truy vấn bằng Athena. Cách này không đụng gì tới database sản xuất và chi phí thấp hơn cả read replica.

Và một lưu ý về kiến trúc trong đề: ứng dụng chạy trên ECS Fargate, nên hãy đảm bảo đội phân tích kết nối tới endpoint của replica, không phải endpoint chính. Đây là lỗi cấu hình dễ xảy ra và triệu chứng của nó — ứng dụng chậm vào giờ chạy báo cáo — mất khá lâu mới lần ra nguyên nhân.

Đáp án

A và C.

• A — Dùng Amazon CloudFront với website làm custom origin
• C — Dùng Amazon ElastiCache làm kho dữ liệu trong bộ nhớ hoặc cache cho website

Vì sao đúng

Đề nêu vấn đề: trang tin toàn cầu bị chậm vì tải tăng, độc giả bỏ đi nếu quá 10 giây — và hai đáp án tấn công vào hai nguyên nhân khác nhau: | Nguyên nhân | Giải pháp | |---|---| | Người dùng ở XA máy chủ — độ trễ mạng cao | A — CloudFront phục vụ từ điểm biên gần họ | | Database bị hỏi lặp đi lặp lại — chậm ở backend | C — ElastiCache trả lời từ bộ nhớ |

A — CloudFront giải quyết cả độ trễ lẫn tải:

Không có CDN:
    Độc giả ở châu Âu → máy chủ ở Singapore
        → mỗi request đi nửa vòng trái đất
        → và MỌI request đều tới EC2

Có CloudFront:
    Độc giả → điểm biên gần nhất (một trong hơn 600 điểm)
        → nội dung đã cache trả về NGAY
        → EC2 chỉ nhận request cho nội dung chưa cache

Với trang tin, phần lớn nội dung giống nhau cho mọi độc giả — tỷ lệ cache hit rất cao, nên hiệu quả đặc biệt lớn.

C — ElastiCache cắt tải ở tầng dữ liệu:

Không có cache:
    Mỗi lượt xem bài → truy vấn database
        → 10.000 người đọc cùng một bài = 10.000 truy vấn giống hệt nhau

Có ElastiCache:
    Lần đầu → database → lưu vào cache
    9.999 lần sau → trả từ BỘ NHỚ (dưới một mili giây)

Hai giải pháp này bổ sung nhau ở hai tầng khác nhau — đó là lý do câu hỏi yêu cầu chọn hai.

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

• **E. Dùng RDS Multi-AZ để mở rộng khả năng ĐỌC — đây là phương án gần nhất và là hiểu nhầm phổ biến nhất về Multi-AZ: standby instance KHÔNG phục vụ truy vấn nào. Multi-AZ là cơ chế sẵn sàng cao, không phải mở rộng đọc. (Thứ mở rộng đọc là read replica.)
• **B. Dùng AWS Storage Gateway để phân phối nội dung qua nhiều Region — sai công cụ: Storage Gateway là dịch vụ lưu trữ lai, kết nối trung tâm dữ liệu tại chỗ với AWS. Nó không phân phối nội dung web.
• **D. Triển khai website ra MỌI Region trong các VPC khác nhau — đắt và phức tạp quá mức: nhân bản hạ tầng ra hàng chục Region đòi đồng bộ dữ liệu, quản lý triển khai, và chi phí khổng lồ. CloudFront đạt hiệu quả tương tự với chi phí thấp hơn rất nhiều.

Ghi nhớ

Ba tầng cache trong kiến trúc web — thứ tự từ ngoài vào: | Tầng | Dịch vụ | Cắt được gì | |---|---|---| | Biên (CDN) | CloudFront | request không tới máy chủ | | Ứng dụng | ElastiCache | truy vấn không tới database | | Database | read replica | phân tán tải đọc |

Ba tầng bổ sung nhau — mỗi tầng chặn bớt một phần tải xuống tầng dưới, và tầng ngoài cùng luôn hiệu quả nhất về chi phí.

Hai engine của ElastiCache: | | Redis / Valkey | Memcached | |---|---|---| | Cấu trúc dữ liệu | phong phú: list, set, sorted set, hash | chỉ chuỗi | | Bền vững | ✅ snapshot và AOF | ❌ | | Sao chép và failover | ✅ | ❌ | | Pub/Sub | ✅ | ❌ | | Đa luồng | (Valkey có) | ✅ |

Redis là lựa chọn mặc định cho hầu hết trường hợp — nó làm được mọi thứ Memcached làm và nhiều hơn thế.

Ba mẫu cache thường dùng: | Mẫu | Cách hoạt động | |---|---| | Lazy loading (cache-aside) | đọc cache trước, miss thì đọc DB rồi ghi vào cache | | Write-through | ghi vào DB thì ghi luôn vào cache | | TTL | đặt thời hạn để dữ liệu không cũ mãi |

Lazy loading là mẫu phổ biến nhất:

def lay_bai_viet(id_bai):
    khoa = f'bai:{id_bai}'
    du_lieu = cache.get(khoa)
    if du_lieu is None:                    # cache miss
        du_lieu = db.query(id_bai)
        cache.setex(khoa, 300, du_lieu)    # TTL 5 phút
    return du_lieu

Ưu điểm: chỉ cache thứ thực sự được đọc. Nhược điểm: lần đọc đầu luôn chậm, và dữ liệu có thể cũ trong khoảng TTL.

Với trang tin, TTL ngắn (30–300 giây) là cân bằng tốt — nội dung mới xuất hiện đủ nhanh mà vẫn cắt được phần lớn truy vấn.

Ba cấu hình CloudFront quan trọng cho trang tin: | Cấu hình | Chi tiết | |---|---| | Cache policy theo loại nội dung | ảnh và CSS: TTL dài; trang tin: TTL ngắn | | Origin Shield | thêm một lớp cache trung tâm — giảm tải origin đáng kể | | Compression | tự nén gzip/brotli, giảm dung lượng truyền |

Origin Shield đặc biệt hữu ích cho trang có lượng truy cập toàn cầu: không có nó, mỗi trong hơn 600 điểm biên đều gọi origin riêng khi cache miss; có nó, các điểm biên gọi qua một lớp trung gian nên origin chỉ nhận một request.

Và cache cả nội dung ĐỘNG cũng khả thi:

Trang chủ tin tức thay đổi mỗi vài phút
    → đặt TTL 60 giây
    → 10.000 lượt xem trong phút đó chỉ tạo 1 request tới origin
    → giảm tải 99,99%

Nhiều người chỉ cache nội dung tĩnh và bỏ lỡ phần lợi ích lớn nhất này.

Ba metric cần theo dõi: | Metric | Ý nghĩa | |---|---| | CloudFront CacheHitRate | dưới 80% là có chỗ để tối ưu | | ElastiCache CacheHitRate | tỷ lệ trúng cache | | ElastiCache Evictions | tăng nghĩa là cache quá nhỏ |

Evictions tăng là tín hiệu rõ ràng cần tăng kích thước node — cache đang phải đẩy dữ liệu ra để nhường chỗ, làm giảm tỷ lệ trúng.

Và một lời khuyên về thứ tự triển khai cho tình huống của đề: đặt CloudFront trước. Nó cho hiệu quả lớn nhất với ít thay đổi nhất — không cần sửa mã ứng dụng, chỉ đổi bản ghi DNS. Sau đó đo lại xem tải còn lại ở đâu rồi mới thêm ElastiCache; rất có thể sau khi có CDN, tải database đã giảm đủ để chưa cần tới tầng cache thứ hai.

Đáp án

B — Đặt IOPS là 500 rồi giữ queue length THẤP.

Vì sao đúng

Đề cho một con số quyết định: mỗi volume có dung lượng 10 GiB.

Và io1 có tỷ lệ IOPS trên dung lượng bị giới hạn cứng:

io1: tối đa 50 IOPS cho mỗi GiB
    10 GiB × 50 = 500 IOPS
        ↑ đây là mức TỐI ĐA đặt được cho volume 10 GiB

Nên 500 là con số cao nhất hợp lệ — 600 và 800 đều bị từ chối khi tạo volume.

Và vì sao queue length phải THẤP:

Queue length = số request I/O đang CHỜ được xử lý

Queue dài:
    → thông lượng (IOPS) cao hơn — đĩa luôn có việc làm
    → NHƯNG mỗi request phải chờ lâu hơn → ĐỘ TRỄ TĂNG

Queue ngắn:
    → độ trễ THẤP
    → phù hợp với workload "low-latency" mà đề yêu cầu

Đề nói rõ hai mục tiêu: "maintain high IOPS WHILE KEEPING THE LATENCY DOWN" — nên phải lấy IOPS tối đa cho phép (500) và giữ hàng đợi ngắn.

AWS khuyến nghị cho io1:

Queue length khoảng 1 cho mỗi 500 IOPS đã cấp phát
    → 500 IOPS → queue length ~1

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

• **D. Đặt IOPS là 800 rồi giữ queue length thấp — đây là phương án gần nhất về mặt cũng chọn queue ngắn, nhưng 800 IOPS VƯỢT GIỚI HẠN của volume 10 GiB (tối đa 500). Cấu hình này không tạo được.
• **C. Đặt IOPS là 600 rồi giữ queue length cao — sai cả hai: 600 vượt giới hạn 500, và queue dài làm tăng độ trễ — ngược với yêu cầu.
• **A. Đặt IOPS là 400 rồi giữ queue length thấp — hợp lệ nhưng không tối ưu: đề yêu cầu "maintain HIGH IOPS", mà 400 thấp hơn mức tối đa 500 mà volume này đạt được.

Ghi nhớ

Tỷ lệ IOPS trên dung lượng của các loại EBS — bảng cần thuộc: | Loại | Tỷ lệ tối đa | IOPS tối đa mỗi volume | |---|---|---| | io1 | 50 IOPS / GiB | 64.000 | | io2 | 500 IOPS / GiB | 64.000 (256.000 với Block Express) | | gp2 | 3 IOPS / GiB (burst tới 3.000) | 16.000 | | gp3 | 500 IOPS / GiB | 16.000 |

io2 có tỷ lệ gấp 10 lần io1 — cùng volume 10 GiB, io2 đạt được 5.000 IOPS thay vì 500. Đây là lý do io2 gần như luôn tốt hơn io1 với cùng mức giá.

gp3 cũng đáng chú ý: nó cho 3.000 IOPS cơ sở MIỄN PHÍ bất kể dung lượng, nên volume 10 GiB gp3 đã có sẵn 3.000 IOPS — nhiều gấp sáu lần io1 ở cùng dung lượng, và rẻ hơn.

Quan hệ giữa ba đại lượng — nội dung cốt lõi của câu hỏi:

Queue length ↑  →  IOPS ↑  nhưng  Độ trễ ↑
Queue length ↓  →  IOPS ↓  nhưng  Độ trễ ↓

Đây là sự đánh đổi không tránh được. Với workload giao dịch nhạy cảm độ trễ như HPC tài chính trong đề, độ trễ quan trọng hơn thông lượng tối đa.

Ba metric CloudWatch để theo dõi EBS: | Metric | Ý nghĩa | |---|---| | VolumeQueueLength | số request đang chờ — theo dõi để cân bằng | | VolumeReadOps / VolumeWriteOps | IOPS thực tế | | VolumeTotalReadTime / WriteTime | tính ra độ trễ trung bình | | BurstBalance | chỉ với gp2 — tín dụng burst còn lại |

Công thức tính độ trễ trung bình:

Độ trễ đọc (giây) = VolumeTotalReadTime / VolumeReadOps

Ba điều kiện để đạt IOPS đã cấp phát: | Điều kiện | Chi tiết | |---|---| | Instance phải được tối ưu cho EBS | EBS-optimized — hầu hết instance thế hệ mới bật mặc định | | Băng thông EBS của instance đủ lớn | instance nhỏ có trần băng thông riêng | | Kích thước I/O phù hợp | io1 tính một IOP cho mỗi 256 KiB; I/O lớn hơn bị đếm thành nhiều IOP |

Dòng cuối hay gây bất ngờ: ghi một khối 1 MiB không phải là 1 IOP mà là 4 IOP — nên workload ghi khối lớn cạn IOPS nhanh hơn dự tính.

Ba đặc điểm khác của io2 đáng biết: | Đặc điểm | Chi tiết | |---|---| | Độ bền 99,999% | cao gấp 100 lần so với gp3 và io1 (99,8–99,9%) | | Multi-attach | gắn vào tối đa 16 instance trong cùng AZ | | io2 Block Express | tới 256.000 IOPS, độ trễ dưới một mili giây |

Và một lưu ý về chi phí cho cụm HPC như đề mô tả: io1 tính phí RIÊNG cho IOPS đã cấp phát, ngoài phí dung lượng. Với volume nhỏ nhưng IOPS cao, phần IOPS thường chiếm phần lớn hoá đơn — nên hãy kiểm tra xem gp3 có đáp ứng đủ không trước khi chọn io1, vì gp3 cho 3.000 IOPS miễn phí và rẻ hơn đáng kể ở dung lượng nhỏ.

Đáp án

A — Tạo DynamoDB Global Table ở Region thứ hai, nhân bản Auto Scaling group và Application Load Balancer; dùng Route 53 DNS failover; thiết lập AWS Well-Architected Tool để nhận khuyến nghị theo thực hành tốt của AWS.

Vì sao đúng

Đề nêu hai yêu cầu riêng biệt, và phương án này giải đúng cả hai: | Yêu cầu | Giải pháp | |---|---| | Ứng dụng vẫn hoạt động khi MỘT REGION sập, ít thời gian ngừng nhất | Global Table + hạ tầng dựng SẴN + Route 53 failover | | Tự động rà soát kiến trúc theo thực hành tốt của AWS | AWS Well-Architected Tool |

Vì sao "ít thời gian ngừng nhất" đòi hạ tầng phải dựng SẴN:

Dựng sẵn (warm standby):
    Region A sập → Route 53 health check phát hiện
        → chuyển DNS sang Region B (đã chạy sẵn)
        → thời gian ngừng: TÍNH BẰNG PHÚT

Dựng khi có sự cố (từ CloudFormation):
    Region A sập → mới bắt đầu triển khai stack
        → tạo VPC, ALB, ASG, DynamoDB, chờ instance khởi động
        → thời gian ngừng: HÀNG CHỤC PHÚT tới hàng giờ

Và DynamoDB Global Table là mấu chốt của tầng dữ liệu:

Global Table sao chép ĐA CHỦ (multi-active) giữa các Region
    → dữ liệu đã có sẵn ở Region B, cập nhật liên tục
    → độ trễ sao chép thường DƯỚI MỘT GIÂY
    → đọc VÀ ghi được ở cả hai Region

Và AWS Well-Architected Tool khớp chính xác với yêu cầu thứ hai: nó là công cụ rà soát kiến trúc theo sáu trụ cột và đưa ra danh sách rủi ro cùng khuyến nghị cải thiện.

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

• **B. Tạo global secondary index (GSI) của bảng DynamoDB ở Region thứ hai; dùng Compute Optimizer — đây là phương án gần nhất và có phần Route 53 đúng, nhưng nó sai ở hai chỗ: GSI là chỉ mục TRONG CÙNG một bảng ở cùng Region — nó không nhân bản dữ liệu sang Region khác. Và Compute Optimizer chỉ khuyến nghị kích thước tài nguyên (loại instance, dung lượng), không rà soát kiến trúc.
• **C. Viết CloudFormation template và triển khai ở Region thứ hai khi có sự cố; dùng Amazon Managed Service for Prometheus — thời gian ngừng dài: phải dựng toàn bộ hạ tầng từ đầu lúc đang có sự cố. Và Prometheus là hệ thống thu thập metric, không đưa ra khuyến nghị kiến trúc.
• **D. CloudFormation triển khai khi có sự cố + Lambda cập nhật bản ghi Route 53 + Amazon Managed Grafana — cùng vấn đề thời gian ngừng, và Grafana là công cụ TRỰC QUAN HOÁ dữ liệu, không phải công cụ rà soát thực hành tốt.

Ghi nhớ

Bốn chiến lược phục hồi thảm hoạ — bảng cần thuộc: | Chiến lược | RTO | Chi phí | Cách làm | |---|---|---|---| | Backup & Restore | hàng giờ | thấp nhất | khôi phục từ sao lưu | | Pilot Light | hàng chục phút | thấp | giữ tầng dữ liệu chạy, compute tắt | | Warm Standby | vài phút | vừa | bản thu nhỏ CHẠY SẴN ← câu này | | Multi-Site Active/Active | gần bằng 0 | cao nhất | cả hai Region cùng phục vụ |

Đề hỏi "least amount of downtime possible" trong khuôn khổ các phương án → chọn cái có hạ tầng dựng sẵn.

Sáu trụ cột của AWS Well-Architected Framework: | Trụ cột | Nội dung | |---|---| | Operational Excellence | vận hành và cải tiến liên tục | | Security | bảo vệ dữ liệu và hệ thống | | Reliability | phục hồi sau sự cố, đáp ứng nhu cầu | | Performance Efficiency | dùng tài nguyên hiệu quả | | Cost Optimization | tránh chi phí không cần thiết | | Sustainability | giảm tác động môi trường |

Ba công cụ khuyến nghị của AWS — đừng nhầm: | Công cụ | Khuyến nghị về | |---|---| | Well-Architected Tool | KIẾN TRÚC tổng thể theo sáu trụ cột | | Compute Optimizer | KÍCH THƯỚC tài nguyên (EC2, EBS, Lambda, Fargate) | | Trusted Advisor | kiểm tra nhanh về chi phí, bảo mật, hạn mức, chịu lỗi |

Ba đặc điểm của DynamoDB Global Tables: | Đặc điểm | Chi tiết | |---|---| | Đa chủ (multi-active) | đọc VÀ ghi ở mọi Region | | Nhất quán cuối cùng | thường dưới một giây | | Giải quyết xung đột "last writer wins" | ghi cùng lúc ở hai Region thì bản mới nhất thắng |

Yêu cầu để bật Global Tables: bảng phải bật DynamoDB Streams với NEW_AND_OLD_IMAGES, và các bảng phải rỗng khi tạo global table lần đầu (với phiên bản cũ).

Ba cấu hình Route 53 failover cần đúng: | Cấu hình | Chi tiết | |---|---| | Health check gắn với từng record | không có health check thì không failover | | TTL THẤP (60 giây hoặc ít hơn) | client cache câu trả lời cũ tới khi hết TTL | | Failover routing policy: PRIMARY và SECONDARY | hoặc dùng weighted/latency với health check |

TTL là yếu tố quyết định thời gian ngừng thực tế: dù Route 53 chuyển hướng ngay lập tức, người dùng đã cache bản ghi cũ vẫn gọi tới Region đã sập cho tới khi TTL hết hạn.

Và một lưu ý về chi phí cho kiến trúc trong đề: warm standby nghĩa là trả tiền cho hạ tầng ở Region thứ hai suốt thời gian nó không được dùng. Cách giảm chi phí là giữ ASG ở Region dự phòng với MinSize rất nhỏ (ví dụ 1 instance) rồi để nó mở rộng khi nhận lưu lượng — vẫn nhanh hơn nhiều so với dựng từ đầu, mà chi phí chờ thấp hơn hẳn.

Đáp án

A — Kết hợp Kubernetes Metrics Server và Kubernetes Cluster Autoscaler để quản lý số lượng node.

Vì sao đúng

Đề nêu yêu cầu rõ: hạ tầng BÊN DƯỚI phải tự co giãn theo nhu cầu, với ít công vận hành nhất.

Và đây là hai tầng co giãn của Kubernetes, mỗi tầng một việc:

Tầng POD (Horizontal Pod Autoscaler, dựa trên Metrics Server):
    tải tăng → tăng SỐ POD
        ↓
    hết chỗ trên node hiện có → pod ở trạng thái Pending
        ↓
Tầng NODE (Cluster Autoscaler):
    thấy pod Pending → THÊM NODE vào Auto Scaling group
    thấy node trống lâu → GỠ NODE đi

Đề nói "underlying INFRASTRUCTURE automatically scales in and out" — tức là tầng NODE, và Cluster Autoscaler là thành phần chuẩn cho việc đó.

Metrics Server là điều kiện tiên quyết:

Không có Metrics Server:
    → HPA không biết CPU và bộ nhớ của pod
    → không tăng pod
    → không có pod Pending
    → Cluster Autoscaler KHÔNG BAO GIỜ được kích hoạt

Và đây là công cụ chuẩn của hệ sinh thái Kubernetes — cài bằng Helm, không phải tự viết logic:

helm install cluster-autoscaler autoscaler/cluster-autoscaler   --set autoDiscovery.clusterName=cum-eks   --set awsRegion=ap-southeast-1

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

• **D. Thiết lập CloudWatch alarm cho mức dùng CPU hoặc số request để theo dõi metric của ứng dụng — đây là phương án gần nhất và theo dõi đúng thứ, nhưng alarm chỉ QUAN SÁT, không HÀNH ĐỘNG. Nó thông báo khi tải cao, nhưng không thêm node hay pod nào.
• **C. Dùng AWS App Mesh để kiểm soát giao tiếp giữa các service; dùng CloudWatch Application Insights để kích hoạt tự động co giãn — sai vai trò cả hai: App Mesh là service mesh lo việc định tuyến và quan sát lưu lượng giữa các service. Application Insights phát hiện và chẩn đoán sự cố, nó không kích hoạt co giãn.
• **B. Tích hợp API Gateway edge-optimized với EKS để quản lý và phơi API — giải quyết vấn đề khác: API Gateway lo việc quản lý API (xác thực, giới hạn tốc độ, phiên bản). Nó không co giãn hạ tầng của cụm.

Ghi nhớ

Ba tầng tự co giãn trong Kubernetes trên AWS: | Tầng | Công cụ | Điều chỉnh | |---|---|---| | Pod (ngang) | Horizontal Pod Autoscaler (HPA) | SỐ LƯỢNG pod | | Pod (dọc) | Vertical Pod Autoscaler (VPA) | tài nguyên yêu cầu của mỗi pod | | Node | Cluster Autoscaler hoặc Karpenter | SỐ LƯỢNG node |

HPA và Cluster Autoscaler phải dùng CÙNG NHAU — thiếu một cái là hệ thống không co giãn được đầy đủ.

Karpenter — lựa chọn hiện đại thay cho Cluster Autoscaler: | | Cluster Autoscaler | Karpenter | |---|---|---| | Cơ chế | điều chỉnh Auto Scaling group | gọi thẳng API EC2 | | Tốc độ | vài phút | vài chục giây | | Chọn loại instance | theo nhóm node đã định nghĩa sẵn | TỰ chọn loại phù hợp nhất với pod đang chờ | | Gom pod để tiết kiệm | hạn chế | ✅ tự hợp nhất (consolidation) | | Độ trưởng thành | lâu đời, ổn định | mới hơn, AWS đang đẩy mạnh |

Karpenter thường tốt hơn cho tải biến động như đề mô tả — nó chọn đúng loại và kích thước instance cho các pod đang chờ thay vì bị bó buộc trong các node group định sẵn. (Cluster Autoscaler vẫn là đáp án đúng theo bộ đề và vẫn hoạt động tốt.)

Và có một cách bỏ qua hoàn toàn tầng node: EKS trên Fargate.

Không có node nào để quản lý
    → mỗi pod tự có tài nguyên riêng
    → chỉ cần HPA, không cần Cluster Autoscaler

Đổi lại: không hỗ trợ DaemonSet, không dùng được GPU, chỉ EFS cho lưu trữ bền vững, và đắt hơn tính theo vCPU-giờ.

Ba cấu hình quan trọng của HPA:

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
spec:
  minReplicas: 2
  maxReplicas: 20
  metrics:
    - type: Resource
      resource:
        name: cpu
        target:
          type: Utilization
          averageUtilization: 70

Điều kiện bắt buộc cho HPA hoạt động: pod phải khai resources.requests.

resources:
  requests: {cpu: "250m", memory: "512Mi"}
  limits:   {cpu: "500m", memory: "1Gi"}

Không khai requests thì HPA không tính được phần trăm sử dụng — và đây là lỗi cấu hình phổ biến nhất khiến HPA "không làm gì cả".

Ba lưu ý về Cluster Autoscaler: | Lưu ý | Chi tiết | |---|---| | Cần IAM permission qua IRSA | autoscaling:SetDesiredCapacity, DescribeAutoScalingGroups... | | Node group phải có tag đúng | k8s.io/cluster-autoscaler/enabled | | Mỗi node group nên có MỘT loại instance đồng nhất | vì Cluster Autoscaler giả định các node trong nhóm giống nhau |

Và một cách giảm chi phí đáng kể cho cụm EKS có tải biến động: dùng mixed instance policy với Spot cho node group phục vụ workload chịu được gián đoạn. Kết hợp với Cluster Autoscaler, cụm tự mở rộng bằng máy Spot rẻ hơn tới 70% và co lại khi hết tải.

Đáp án

D — Bật Cross-Region Replication (CRR).

Vì sao đúng

Đề nêu yêu cầu quyết định: dữ liệu không được ảnh hưởng kể cả khi mất một AZ HOẶC khi cả một REGION gặp sự cố.

Và S3 đã tự lo phần AZ:

S3 Standard sao chép dữ liệu tự động qua ÍT NHẤT 3 AZ
    → mất một AZ: KHÔNG ảnh hưởng gì, không cần làm gì thêm
    → độ bền 99,999999999% (11 số 9)

Nhưng sự cố cả Region thì S3 không tự xử lý:

Region us-east-1 gặp sự cố toàn diện
    → bucket ở đó không truy cập được
    → cần một BẢN SAO ở Region KHÁC

Cross-Region Replication làm đúng việc đó:

Object ghi vào bucket nguồn (us-east-1)
    ↓ tự động, bất đồng bộ
Sao chép sang bucket đích ở Region khác (ví dụ us-west-2)
    → giữ nguyên metadata, tag, ACL
    → giữ nguyên storage class (hoặc đổi nếu cấu hình)

{"Role": "arn:aws:iam::123456789012:role/vai-tro-sao-chep",
 "Rules": [{
   "Status": "Enabled",
   "Priority": 1,
   "Filter": {},
   "Destination": {"Bucket": "arn:aws:s3:::kho-tai-chinh-dr"},
   "DeleteMarkerReplication": {"Status": "Enabled"}}]}

Điều kiện bắt buộc: cả bucket nguồn lẫn đích phải BẬT VERSIONING.

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

• **B. Tạo Lifecycle Policy để sao lưu định kỳ bucket sang Glacier — đây là phương án gần nhất và là hiểu nhầm phổ biến: lifecycle KHÔNG SAO LƯU, nó CHUYỂN object sang lớp lưu trữ khác. Và Glacier vẫn nằm TRONG CÙNG REGION — sự cố Region ảnh hưởng cả nó.
• **C. Tạo bucket mới ở Region khác và cấu hình Cross-Account Access — nhầm cơ chế: cross-account access là cấp QUYỀN cho tài khoản khác, nó không sao chép dữ liệu nào. Bucket mới sẽ trống rỗng.
• **A. Sao chép bucket sang EC2 instance có EBS — giảm độ bền nghiêm trọng: EBS gắn với một AZ duy nhất, độ bền thấp hơn S3 rất nhiều, dung lượng có hạn, và phải tự quản lý việc đồng bộ.

Ghi nhớ

Độ bền và sẵn sàng của các lớp S3: | Lớp | Số AZ | Độ bền | Sẵn sàng | |---|---|---|---| | S3 Standard | ≥ 3 | 11 số 9 | 99,99% | | S3 Standard-IA | ≥ 3 | 11 số 9 | 99,9% | | S3 One Zone-IA | 1 | 11 số 9 nhưng MẤT nếu AZ đó bị phá huỷ | 99,5% | | Glacier các lớp | ≥ 3 | 11 số 9 | tuỳ lớp |

S3 đã chịu được sự cố AZ ở mọi lớp trừ One Zone-IA — nên câu hỏi thực chất chỉ xoay quanh vế "sự cố REGION".

Hai loại sao chép của S3: | Loại | Phạm vi | Dùng cho | |---|---|---| | CRR (Cross-Region Replication) | Region KHÁC | phục hồi thảm hoạ, tuân thủ, giảm độ trễ | | SRR (Same-Region Replication) | cùng Region, bucket khác | gộp log, tách môi trường, tuân thủ nội bộ |

Bốn điều kiện để bật replication:

① Bucket NGUỒN bật versioning
② Bucket ĐÍCH bật versioning
③ IAM role cho phép S3 đọc nguồn và ghi đích
④ Bucket đích phải tồn tại

Ba lưu ý quan trọng về hành vi của replication: | Lưu ý | Chi tiết | |---|---| | CHỈ sao chép object MỚI | object đã có từ trước KHÔNG tự sao chép | | Bất đồng bộ | thường vài giây tới vài phút | | Không sao chép chuỗi (chaining) | A→B→C thì object từ A không tới C |

Dòng đầu là cạm bẫy hay gặp nhất: bật CRR xong tưởng đã an toàn, nhưng 5 TB dữ liệu cũ vẫn chỉ có một bản. Muốn sao chép dữ liệu đã có, dùng S3 Batch Replication:

aws s3control create-job --account-id 123456789012   --operation '{"S3ReplicateObject": {}}'   --manifest-generator file://cau-hinh-manifest.json

Và một tuỳ chọn đáng biết: S3 Replication Time Control (RTC).

Cam kết 99,99% object được sao chép trong 15 PHÚT
    → có SLA và metric theo dõi
    → tính phí thêm

RTC cần thiết khi có yêu cầu tuân thủ về RPO — dữ liệu tài chính trong ngày như đề mô tả là ứng viên hợp lý.

Ba lựa chọn thay thế cho nhu cầu đa Region: | Lựa chọn | Đặc điểm | |---|---| | CRR | sao chép bất đồng bộ, bạn kiểm soát Region đích ← câu này | | S3 Multi-Region Access Point | một endpoint toàn cầu, tự định tuyến tới bucket gần nhất | | Ghi song song từ ứng dụng | kiểm soát cao nhất, phức tạp nhất |

Multi-Region Access Point đáng cân nhắc cho ứng dụng toàn cầu: nó cho một địa chỉ duy nhất, tự chuyển sang Region còn hoạt động khi có sự cố, và ứng dụng không phải biết gì về việc có nhiều bucket.

Và một lưu ý về chi phí: CRR tính phí lưu trữ ở cả hai bucket cộng phí truyền dữ liệu giữa hai Region (~0,02 USD/GB). Với dữ liệu tài chính trong ngày khối lượng lớn, hãy cân nhắc chỉ sao chép các prefix quan trọng thay vì toàn bộ bucket — cấu hình Filter trong rule cho phép làm điều đó.

Đáp án

C — Dùng DynamoDB Auto Scaling.

Vì sao đúng

Đề mô tả triệu chứng rõ: bảng DynamoDB có dung lượng đọc ghi cấu hình sẵn (provisioned) và bị throttle vào giờ cao điểm.

Nguyên nhân và cách chữa:

Chế độ provisioned với con số CỐ ĐỊNH
    → tải tăng vọt vượt mức đã cấp
    → DynamoDB TỪ CHỐI request thừa (ProvisionedThroughputExceededException)
    → ứng dụng chậm hoặc lỗi
        ↓
DynamoDB Auto Scaling:
    → theo dõi mức sử dụng thực tế
    → tự TĂNG dung lượng khi tải lên
    → tự GIẢM khi tải xuống (tiết kiệm chi phí)

Cấu hình mục tiêu sử dụng:

aws application-autoscaling register-scalable-target   --service-namespace dynamodb   --resource-id "table/bang-nguoi-choi"   --scalable-dimension "dynamodb:table:ReadCapacityUnits"   --min-capacity 100 --max-capacity 4000

aws application-autoscaling put-scaling-policy   --policy-type TargetTrackingScaling   --target-tracking-scaling-policy-configuration     '{"TargetValue": 70.0, "PredefinedMetricSpecification":
      {"PredefinedMetricType": "DynamoDBReadCapacityUtilization"}}'

Mục tiêu 70% là con số cân bằng tốt: đủ biên độ hấp thụ đột biến trước khi việc mở rộng kịp diễn ra, mà không lãng phí quá nhiều dung lượng.

Và một chi tiết đáng nhớ: Auto Scaling KHÔNG bật mặc định khi tạo bảng bằng CLI, SDK hay CloudFormation — chỉ Console mới bật sẵn.

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

• **B. Thêm bảng DynamoDB vào một Auto Scaling Group — đây là phương án gần nhất vì cũng nói tới auto scaling, nhưng nó nhầm dịch vụ: EC2 Auto Scaling Group quản lý INSTANCE EC2. DynamoDB không phải instance và không thể đưa vào ASG. Cơ chế đúng là Application Auto Scaling — một dịch vụ khác hẳn.
• **A. Tích hợp Application Load Balancer với bảng DynamoDB — sai hoàn toàn về kiến trúc: ALB phân phối lưu lượng HTTP tới các đích như EC2, container hoặc Lambda. DynamoDB không phải đích của load balancer — nó là dịch vụ được quản lý, truy cập qua API.
• **D. Tạo SQS queue đặt trước bảng DynamoDB — chỉ hoãn vấn đề, không giải quyết, và phá vỡ mô hình đọc: hàng đợi làm phẳng được đỉnh GHI, nhưng game AR cần ĐỌC dữ liệu tức thì — không thể chờ hàng đợi. Và dung lượng vẫn không đủ, chỉ là request xếp hàng thay vì bị từ chối.

Ghi nhớ

Hai chế độ dung lượng của DynamoDB: | | Provisioned | On-Demand | |---|---|---| | Cách hoạt động | khai trước RCU/WCU | tự mở rộng hoàn toàn | | Chi phí | rẻ hơn khi tải ỔN ĐỊNH và dự báo được | đắt hơn mỗi request | | Đột biến bất ngờ | có thể throttle | hấp thụ ngay | | Cần Auto Scaling | ✅ có | ❌ không cần | | Phù hợp | tải đều đặn | tải khó đoán, mới ra mắt |

Với game AR có đỉnh tải bất thường như đề mô tả, chế độ On-Demand là lựa chọn đáng cân nhắc nghiêm túc:

Auto Scaling mất VÀI PHÚT để phản ứng
    → đỉnh tải đột ngột vẫn bị throttle trong khoảng đó
On-Demand phản ứng NGAY
    → nhưng đắt hơn khoảng 6–7 lần mỗi request

(DynamoDB Auto Scaling vẫn là đáp án đúng theo bộ đề và phù hợp khi tải có mẫu lặp lại.)

Đơn vị dung lượng của DynamoDB: | Đơn vị | Định nghĩa | |---|---| | 1 RCU | 1 lần đọc NHẤT QUÁN MẠNH item 4 KB mỗi giây, hoặc 2 lần đọc nhất quán cuối cùng | | 1 WCU | 1 lần ghi item 1 KB mỗi giây |

Phép tính ví dụ:

Đọc 100 item/giây, mỗi item 8 KB, nhất quán cuối cùng:
    8 KB → 2 đơn vị 4 KB
    nhất quán cuối cùng → chia 2
    100 × 2 / 2 = 100 RCU

Ba nguyên nhân gây throttle dù dung lượng còn dư: | Nguyên nhân | Cách phát hiện | |---|---| | Hot partition | CloudWatch Contributor Insights — thấy khoá nào bị gọi nhiều | | GSI thiếu dung lượng | GSI có dung lượng RIÊNG, throttle GSI làm chậm cả ghi vào bảng chính | | Đột biến vượt quá burst capacity | DynamoDB giữ dung lượng chưa dùng của 300 giây gần nhất |

Hot partition là nguyên nhân âm thầm hay gặp nhất: nếu partition key có độ phân biệt thấp (ví dụ dùng ngày làm khoá), mọi request dồn vào một phân vùng và bị giới hạn ở 3.000 RCU / 1.000 WCU mỗi phân vùng dù bảng đã cấp nhiều hơn.

Ba cách cải thiện hiệu năng đọc của DynamoDB: | Cách | Lợi ích | |---|---| | DynamoDB Accelerator (DAX) | cache trong bộ nhớ — độ trễ MICROgiây, không tốn RCU | | Đọc nhất quán cuối cùng thay vì mạnh | tốn một nửa RCU | | Thiết kế partition key phân tán tốt | tránh hot partition |

DAX rất phù hợp với game: dữ liệu bảng xếp hạng và hồ sơ người chơi được đọc lặp đi lặp lại, cache cắt được phần lớn tải mà chỉ cần đổi endpoint trong mã.

Ba metric cần đặt alarm: | Metric | Ý nghĩa | |---|---| | ThrottledRequests | request bị từ chối — dấu hiệu trực tiếp của vấn đề | | ConsumedReadCapacityUnits | so với mức đã cấp | | SuccessfulRequestLatency | độ trễ thực tế |

Và một lưu ý về API Gateway trong kiến trúc của đề: bật caching ở tầng API Gateway cắt được lượng lớn request trước khi chúng tới DynamoDB. Với dữ liệu game thay đổi chậm (bảng xếp hạng, cấu hình), TTL chỉ 10–30 giây cũng giảm tải rất đáng kể.

Đáp án

D — Bật Cross-Region Snapshot Copy trên cụm Amazon Redshift.

Vì sao đúng

Đề cần kế hoạch phục hồi thảm hoạ chịu được sự cố CẢ MỘT REGION — và tính năng này là cơ chế dựng sẵn của Redshift cho đúng việc đó.

Cách hoạt động:

Bật cross-region snapshot copy
    → Redshift TỰ ĐỘNG sao chép mọi snapshot sang Region đích
    → cả snapshot tự động lẫn snapshot thủ công
    → đặt được thời hạn giữ riêng cho Region đích
    ↓
Region chính sập → khôi phục cụm từ snapshot ở Region kia

aws redshift enable-snapshot-copy   --cluster-identifier cum-phan-tich   --destination-region us-west-2   --retention-period 30

Và điểm mấu chốt: snapshot mặc định NẰM TRONG CÙNG REGION với cụm.

Snapshot tự động của Redshift lưu ở S3 CÙNG REGION
    → Region đó gặp sự cố → snapshot cũng không truy cập được
    → kế hoạch phục hồi thảm hoạ vô nghĩa

Đó chính là lý do phải bật sao chép chéo Region tường minh.

Và nó là cấu hình bật một lần, không cần bảo trì — khác hẳn việc tự viết job sao chép.

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

• **C. Dùng automated snapshot của cụm Redshift — đây là phương án gần nhất và là bước cần thiết, nhưng nó không đủ: snapshot tự động nằm trong cùng Region với cụm. Sự cố Region làm mất cả cụm lẫn snapshot.
• **A. Tạo job theo lịch tự chụp snapshot và lưu vào S3 bucket — tự làm lại thứ đã có sẵn: Redshift đã chụp snapshot tự động và có sẵn cơ chế sao chép chéo Region. Tự viết job nghĩa là thêm mã phải bảo trì, thêm chỗ hỏng, mà không được lợi ích gì.
• **B. Không làm gì vì Redshift chịu được sự cố cả Region — sai về mặt kỹ thuật: Redshift là dịch vụ trong phạm vi một Region. Cụm nằm trong một VPC ở một Region; nó không tự nhân bản sang Region khác.

Ghi nhớ

Hai loại snapshot của Redshift: | Loại | Đặc điểm | |---|---| | Automated | tự chụp theo lịch, thời hạn giữ 1–35 ngày, XOÁ khi xoá cụm | | Manual | giữ tới khi bạn xoá, SỐNG SÓT khi cụm bị xoá |

Cả hai đều nằm trong cùng Region trừ khi bật cross-region copy.

Ba đặc điểm về phạm vi của Redshift: | Thành phần | Phạm vi | |---|---| | Cụm Redshift | MỘT Availability Zone (hoặc Multi-AZ với RA3) | | Snapshot | Region (sao chép chéo Region được) | | Redshift Serverless | Region |

Redshift cổ điển chạy trong MỘT AZ — đó là điều nhiều người bất ngờ. Muốn chịu lỗi AZ thì dùng Multi-AZ deployment (chỉ có với node loại RA3).

Ba mức chịu lỗi của Redshift — từ thấp tới cao: | Mức | Chịu được | |---|---| | Cụm đơn + snapshot cùng Region | lỗi node (tự thay), lỗi dữ liệu (khôi phục) | | Multi-AZ (RA3) | sự cố một AZ, tự chuyển đổi | | Cross-region snapshot copy | sự cố cả REGION ← câu này |

Ba mức này bổ sung nhau — kiến trúc đầy đủ nên có cả ba.

Ba lưu ý về cross-region snapshot copy: | Lưu ý | Chi tiết | |---|---| | Cụm mã hoá bằng KMS cần cấp phép cho khoá ở Region đích | thiếu bước này thì sao chép thất bại | | Đặt thời hạn giữ riêng cho Region đích | thường ngắn hơn để tiết kiệm | | Chỉ một Region đích mỗi lần | muốn đổi thì tắt rồi bật lại |

Với cụm đã mã hoá, cần cấu hình thêm:

aws redshift enable-snapshot-copy   --cluster-identifier cum-phan-tich   --destination-region us-west-2   --snapshot-copy-grant-name cap-phep-sao-chep

Ba chỉ số cần xác định cho kế hoạch phục hồi thảm hoạ: | Chỉ số | Ý nghĩa | |---|---| | RPO (Recovery Point Objective) | chấp nhận mất bao nhiêu dữ liệu — quyết định tần suất snapshot | | RTO (Recovery Time Objective) | chấp nhận ngừng bao lâu — quyết định chiến lược | | Chi phí | mức chịu lỗi cao hơn thì đắt hơn |

Với cross-region snapshot copy, RTO là thời gian khôi phục cụm từ snapshot — có thể hàng chục phút tới vài giờ tuỳ dung lượng. Nếu cần nhanh hơn, phải giữ sẵn một cụm ở Region kia và dùng cơ chế đồng bộ khác.

Ba cách tăng tốc khôi phục: | Cách | Chi tiết | |---|---| | Redshift khôi phục theo kiểu "lười" | cụm nhận truy vấn ngay, dữ liệu nạp dần từ S3 khi được đọc | | Ưu tiên bảng quan trọng | truy vấn chúng trước để chúng được nạp trước | | Dùng node RA3 | tách compute và storage, khôi phục nhanh hơn |

Cơ chế khôi phục lười là ưu điểm lớn của Redshift: bạn không phải chờ toàn bộ dữ liệu được nạp mới bắt đầu truy vấn được — dù các truy vấn đầu tiên sẽ chậm hơn bình thường.

Và một lời khuyên vận hành: hãy diễn tập khôi phục ít nhất mỗi năm một lần. Khôi phục cụm ở Region dự phòng, chạy vài truy vấn kiểm chứng, rồi xoá đi. Chi phí cho vài giờ chạy cụm là nhỏ so với việc phát hiện snapshot không dùng được ngay giữa lúc có sự cố thật.

Đáp án

A — Cài unified CloudWatch agent trên mỗi instance để tự động thu thập và đẩy dữ liệu lên CloudWatch Logs; phân tích bằng CloudWatch Logs Insights.

Vì sao đúng

Đề nêu ba yêu cầu, và unified CloudWatch agent đáp ứng cả ba với ít công nhất: | Yêu cầu | Cơ chế | |---|---| | Thu thập chi tiết hệ thống từ CẢ Windows LẪN Linux | agent hỗ trợ cả hai hệ điều hành | | Hơn một trăm instance | triển khai hàng loạt bằng Systems Manager | | Phân tích bằng công cụ của AWS | Logs Insights truy vấn được ngay |

Unified agent thu thập hai loại dữ liệu cùng lúc:

① LOG:     tệp log của hệ thống và ứng dụng
           Windows Event Log, syslog, log tuỳ chỉnh
② METRIC:  CPU, bộ nhớ, đĩa, mạng, tiến trình
           → trong đó BỘ NHỚ và DUNG LƯỢNG ĐĨA chỉ có được nhờ agent

Và điểm quan trọng cho việc "xem xét các vấn đề hiệu năng" mà đề nêu:

CloudWatch KHÔNG tự biết mức dùng BỘ NHỚ và ĐĨA của EC2
    → những metric đó nằm BÊN TRONG hệ điều hành
    → chỉ agent chạy trong máy mới thu thập được

Triển khai hàng loạt cho hơn 100 máy — không cần vào từng máy:

aws ssm send-command   --document-name "AWS-ConfigureAWSPackage"   --targets "Key=tag:MoiTruong,Values=san-xuat"   --parameters '{"action":["Install"],"name":["AmazonCloudWatchAgent"]}'

Và CloudWatch Logs Insights phân tích bằng ngôn ngữ truy vấn riêng:

fields @timestamp, @message
| filter @message like /ERROR/
| stats count() by bin(1h)
| sort @timestamp desc

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

• **C. Cài AWS Systems Manager Agent (SSM Agent) để tự động thu thập và đẩy dữ liệu lên CloudWatch Logs — đây là phương án gần nhất và SSM Agent thực sự hữu ích, nhưng nó không phải công cụ thu thập log: SSM Agent phục vụ quản lý từ xa (chạy lệnh, vá lỗi, kiểm kê, Session Manager). Nó không tự thu thập và đẩy log ứng dụng lên CloudWatch. (Hai agent này thường cài cùng nhau — SSM Agent để triển khai và quản lý, CloudWatch agent để thu thập dữ liệu.)
• **B. Cài AWS SDK và viết daemon script tuỳ chỉnh đẩy dữ liệu định kỳ — rất nhiều công: phải viết mã cho cả Windows lẫn Linux, xử lý xoay vòng tệp, thử lại khi lỗi mạng, bảo trì trên hơn 100 máy. Đề hỏi cách "with minimal effort".
• **D. Cài AWS Inspector Agent để thu thập và đẩy log — sai vai trò dịch vụ: Amazon Inspector là công cụ đánh giá lỗ hổng bảo mật — nó quét CVE và cấu hình sai. Nó không thu thập log hiệu năng.

Ghi nhớ

Các agent trên EC2 — mỗi cái một việc: | Agent | Việc | |---|---| | Unified CloudWatch Agent | thu thập LOG và METRIC (kể cả bộ nhớ, đĩa) | | SSM Agent | quản lý từ xa: chạy lệnh, vá lỗi, Session Manager, kiểm kê | | Inspector Agent | quét lỗ hổng bảo mật | | Kinesis Agent | đẩy log vào Kinesis |

Metric nào CẦN agent, metric nào KHÔNG: | Metric | Có sẵn không cần agent | |---|---| | CPUUtilization | ✅ | | NetworkIn / NetworkOut | ✅ | | DiskReadOps / DiskWriteOps (mức thiết bị) | ✅ | | StatusCheckFailed | ✅ | | Mức dùng BỘ NHỚ | ❌ CẦN AGENT | | Dung lượng đĩa còn trống | ❌ CẦN AGENT | | Danh sách tiến trình | ❌ cần agent |

Hai dòng "cần agent" là lý do câu hỏi này tồn tại — và cũng là lý do rất nhiều hệ thống không mở rộng theo bộ nhớ được.

Cấu hình mẫu của unified agent:

{
  "metrics": {
    "metrics_collected": {
      "mem": {"measurement": ["mem_used_percent"]},
      "disk": {"measurement": ["used_percent"], "resources": ["/"]}
    },
    "append_dimensions": {"AutoScalingGroupName": "${aws:AutoScalingGroupName}"}
  },
  "logs": {
    "logs_collected": {
      "files": {"collect_list": [{
        "file_path": "/var/log/ung-dung/*.log",
        "log_group_name": "/ung-dung/san-xuat",
        "log_stream_name": "{instance_id}"}]}
    }
  }
}

append_dimensions với AutoScalingGroupName rất quan trọng: nó cho phép tổng hợp metric của cả nhóm thay vì phải xem từng máy — và đó là metric mà Auto Scaling dùng để co giãn.

Ba cách lưu cấu hình agent cho nhiều máy: | Cách | Chi tiết | |---|---| | Systems Manager Parameter Store | một cấu hình dùng chung, sửa một chỗ áp cho tất cả | | Nhúng vào AMI | đơn giản nhưng đổi cấu hình phải nướng AMI mới | | Đẩy qua user data | linh hoạt, nhưng chỉ áp lúc khởi chạy |

Parameter Store là cách được khuyến nghị cho hơn 100 máy:

aws ssm put-parameter --name "AmazonCloudWatch-cau-hinh-chung"   --type String --value file://cau-hinh.json

# Áp cho toàn bộ đội máy
aws ssm send-command --document-name "AmazonCloudWatch-ManageAgent"   --targets "Key=tag:MoiTruong,Values=san-xuat"   --parameters '{"action":["configure"],
                 "optionalConfigurationSource":["ssm"],
                 "optionalConfigurationLocation":["AmazonCloudWatch-cau-hinh-chung"]}'

Ba cách xuất log sang S3 như đề yêu cầu: | Cách | Đặc điểm | |---|---| | Export task từ CloudWatch Logs | thủ công hoặc theo lịch qua Lambda | | Subscription filter → Kinesis Firehose → S3 | liên tục, gần thời gian thực | | Ghi thẳng lên S3 từ agent | không hỗ trợ trực tiếp |

Cách thứ hai là kiến trúc được khuyến nghị cho việc lưu trữ dài hạn: log đi vào CloudWatch để tìm kiếm nhanh, đồng thời chảy sang S3 để lưu trữ rẻ và phân tích bằng Athena.

Và một lưu ý về chi phí: CloudWatch Logs tính phí theo dữ liệu nạp vào (~0,50 USD/GB) và dữ liệu lưu trữ. Với hơn 100 máy ghi log liên tục, khoản này lớn nhanh — hãy đặt thời hạn giữ log (mặc định là vô hạn) và chỉ thu thập những tệp thực sự cần:

aws logs put-retention-policy --log-group-name /ung-dung/san-xuat --retention-in-days 30