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

Đáp án

D, E — hai bước đưa hệ CRM cũ lên AWS với ít công vận hành nhất:

• E — Chuyển hệ CRM sang chạy trên EC2 instance.
• D — Đưa cơ sở dữ liệu của CRM sang Amazon RDS.

Vì sao đúng

Đề nói legacy CRM system và LEAST operational overhead. Hai chữ này quyết định: hệ thống cũ thường không viết lại được, nên chiến lược đúng là rehost phần ứng dụng, replatform phần dữ liệu.

⚠ Điểm mấu chốt: với hệ thống cũ không sửa được mã, RDS là chỗ duy nhất giảm được công vận hành đáng kể:

CRM cũ chạy trên một máy chủ tại chỗ
        ↓
    Ứng dụng: thường phụ thuộc thư viện và cấu hình cũ → chỉ rehost được (EC2)
        ↓
    Cơ sở dữ liệu: nói chuyện bằng giao thức chuẩn (MySQL/PostgreSQL/SQL Server)
        ↓
    → thay bằng RDS mà KHÔNG cần sửa mã ứng dụng
        ↓
    → AWS lo vá lỗi, sao lưu tự động, Multi-AZ, giám sát

Đây là mấu chốt: đổi cơ sở dữ liệu sang dịch vụ có quản lý thường không đòi sửa ứng dụng — chỉ đổi chuỗi kết nối. Đó là khoản giảm công vận hành lớn nhất mà bạn mua được với rủi ro thấp nhất.

⚠ Kiểm bản quyền phần mềm trước khi chuyển lên EC2:

Nhiều phần mềm CRM cũ cấp phép theo lõi CPU hoặc theo địa chỉ MAC
        ↓
    Chuyển lên EC2 có thể vi phạm hoặc phải mua lại giấy phép
        ↓
    → xác nhận điều khoản trước khi lên kế hoạch, đây là chỗ dự án hay vỡ ngân sách

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

• B (dùng AWS Lambda để xử lý dữ liệu thời gian thực) — đây là phương án gần nhất và nó chạm đúng mục tiêu "enhance data processing speed" của đề. Nhưng nó đòi viết lại ứng dụng — Lambda chạy các hàm không trạng thái, giới hạn 15 phút, và một hệ CRM cũ nguyên khối không cắt thành hàm được nếu không tái kiến trúc lớn. Đề nói thẳng LEAST operational overhead; refactor một hệ thống cũ là con đường tốn công nhất trong nhóm 7R. Nó cũng không giải quyết gì cho hai mục tiêu còn lại là tính sẵn sàng và lượng dữ liệu tăng.

• C (dựng Site-to-Site VPN từ máy chủ tại chỗ tới AWS) — giữ nguyên hệ thống ở chỗ cũ và chỉ nối mạng vào AWS. Máy chủ vẫn quá tải giờ cao điểm, vẫn là điểm hỏng đơn lẻ, vẫn phải tự vận hành. VPN là bước hỗ trợ trong quá trình di chuyển, không phải đích đến, và tự nó không cải thiện bất kỳ mục tiêu nào đề nêu.

• A (triển khai Amazon Redshift làm kho dữ liệu) — sai loại tải. Redshift là kho dữ liệu phân tích (OLAP): quét lớn, tổng hợp, báo cáo. CRM là hệ giao dịch (OLTP): đọc ghi từng bản ghi khách hàng, cập nhật liên tục. Đưa CRM chạy trên Redshift sẽ cho hiệu năng tệ hơn hẳn, và đó cũng không phải thứ Redshift được thiết kế để làm.

Ghi nhớ

⚠ Bảy chiến lược di chuyển (7R) xếp theo công sức — bảng phải thuộc: | Chiến lược | Công sức | Giảm vận hành | |---|---|---| | Retire / Retain | thấp nhất | — | | Rehost (lift and shift) | thấp | ít | | Replatform | trung bình | nhiều — đây là điểm ngọt | | Repurchase | trung bình | nhiều, nhưng đổi sản phẩm | | Refactor | cao nhất | nhiều nhất, rủi ro nhất |

Từ khoá nhận diện:

"legacy system" + "LEAST operational overhead" → rehost + replatform, KHÔNG refactor "managed database" → RDS hoặc Aurora "Lambda" cho hệ thống nguyên khối cũ → đòi viết lại, trái yêu cầu "Redshift" cho hệ giao dịch → SAI, đó là kho phân tích "Site-to-Site VPN" như giải pháp cuối cùng → chỉ là bước nối mạng

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Ứng dụng có nối được RDS không | đổi chuỗi kết nối và chạy thử toàn bộ luồng nghiệp vụ | | Có Multi-AZ chưa | describe-db-instances, xem MultiAZ | | Hiệu năng có khá hơn không | so thời gian phản hồi trước và sau, ở cùng khung giờ cao điểm |

Và một lời khuyên: hãy đo hiệu năng ở đúng khung giờ cao điểm trước khi di chuyển, để có mốc so sánh. Đây là chỗ các dự án rehost khó chứng minh giá trị nhất: sau khi lên cloud, hệ thống chạy nhanh hơn hay chậm hơn thường chỉ được đánh giá bằng cảm nhận, vì không ai ghi lại con số cũ. Và cảm nhận thì luôn nghiêng về phía tiêu cực — người dùng nhớ rất rõ những lần chậm sau khi chuyển đổi, còn những lần chậm trước đó thì đã quen tới mức không còn để ý. Không có số liệu nền, bạn không có cách nào phân biệt giữa một sự cố thật và một kỳ vọng đã thay đổi.

Đáp án

C — Tạo kết nối Direct Connect tới Region thứ hai; dùng DynamoDB global table để sao chép dữ liệu sang Region đó; sửa ứng dụng để chuyển vùng sang Region thứ hai khi cần.

Vì sao đúng

Đề có hai yêu cầu, và mỗi yêu cầu loại đi một nửa danh sách phương án.

⚠ Điểm mấu chốt: global table là cơ chế sao chép DỰNG SẴN — mọi cách tự đồng bộ đều kém hơn:

DynamoDB global table
        ↓
    Sao chép liên tục giữa các Region, độ trễ thường dưới một giây
        ↓
    Multi-active: ghi được ở cả hai Region
        ↓
    → không có thành phần nào phải vận hành, không có gì để hỏng

Tự đồng bộ bằng Streams + Lambda (phương án B)
        ↓
    Phải viết mã, xử lý lỗi, xử lý thứ tự, xử lý thử lại
        ↓
    → tự dựng lại thứ AWS đã làm sẵn, theo cách kém tin cậy hơn

Vì sao "consistent network performance" bắt buộc là Direct Connect. VPN chạy trên Internet công cộng: độ trễ dao động, có mất gói, không có cam kết băng thông. Direct Connect là đường riêng với hiệu năng ổn định — đúng nghĩa "maintained at all times".

# bật global table cho Region thứ hai
aws dynamodb update-table --table-name giao-dich \
  --replica-updates '[{"Create":{"RegionName":"ap-northeast-1"}}]'

⚠ Điều kiện để bật global table:

Bảng phải bật DynamoDB Streams với StreamViewType = NEW_AND_OLD_IMAGES
        ↓
    Tên bảng phải giống hệt nhau ở mọi Region
        ↓
    → thiếu một trong hai thì lời gọi tạo replica bị từ chối

Về vế "sửa ứng dụng để chuyển vùng". Vì global table ghi được ở cả hai Region, ứng dụng chỉ cần đổi endpoint sang Region thứ hai — không có bước promote, không có thời gian chờ đồng bộ.

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

• A (Direct Connect tới Region thứ hai, tạo bảng DynamoDB giống hệt ở đó, bật auto scaling, sửa ứng dụng để ghi vào Region thứ hai) — đây là phương án gần nhất và nó đúng ở vế mạng: Direct Connect tới Region thứ hai là lựa chọn chuẩn cho hiệu năng ổn định. Nó hỏng ở vế dữ liệu. "Tạo một bảng giống hệt" chỉ tạo ra một bảng rỗng và không liên quan — không có cơ chế nào sao chép dữ liệu giữa hai bảng, nên khi chuyển vùng, ứng dụng ghi vào một bảng không có dữ liệu lịch sử nào. Bật auto scaling chỉ quản lý dung lượng, hoàn toàn không phải chuyện sao chép. Đây là bẫy tinh vi vì mọi thành phần đều là thật và mô tả nghe rất trơn tru, nhưng thiếu đúng mắt xích khiến hai Region liên hệ được với nhau.

• B (VPN có quản lý tới Region thứ hai, bản sao bảng, DynamoDB Streams + Lambda để đồng bộ) — sai ở vế mạng vì VPN đi qua Internet, không đảm bảo hiệu năng ổn định. Và ở vế dữ liệu, tự viết Lambda đồng bộ là làm lại global table bằng tay: phải tự xử lý thử lại, thứ tự sự kiện, xung đột, và Lambda chết thì dữ liệu lệch mà không có gì báo.

• D (VPN có quản lý, bản sao bảng, Streams + AWS DMS để đồng bộ) — cùng lỗi về mạng, cộng thêm một lỗi công cụ: DMS không đọc DynamoDB Streams. DMS dùng DynamoDB làm đích (target) chứ không phải nguồn theo cách này; câu "bật Streams rồi dùng DMS đồng bộ" mô tả một luồng không tồn tại.

Ghi nhớ

⚠ Bốn cách nối tại chỗ với AWS — bảng phải thuộc: | Cách | Hiệu năng | Dùng khi | |---|---|---| | Direct Connect | ổn định, cam kết băng thông | "consistent network performance" | | Site-to-Site VPN | dao động theo Internet | rẻ, nhanh triển khai, hoặc làm đường lùi | | DX + VPN backup | ổn định, có dự phòng | mẫu chuẩn cho production | | Internet thuần | kém nhất | không dùng cho tải quan trọng |

Từ khoá nhận diện:

"consistent network performance" → Direct Connect, loại mọi phương án VPN "multi-Region" + DynamoDB → global table "tạo bảng giống hệt ở Region khác" mà không nhắc global table → SAI, không có sao chép "Streams + Lambda để đồng bộ giữa hai Region" → tự làm lại global table, kém hơn "DMS đọc DynamoDB Streams" → LUÔN SAI, luồng đó không tồn tại

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Độ trễ sao chép | chỉ số ReplicationLatency theo từng cặp Region | | Có ghi bị từ chối không | ReplicationThrottledRequests | | Chuyển vùng có chạy không | đổi endpoint sang Region hai và chạy thử toàn bộ nghiệp vụ |

Và một lời khuyên: hãy cấp dung lượng ghi ở Region thứ hai ngang với Region chính, đừng cấp theo lưu lượng hiện tại của nó. Đây là chỗ chuyển vùng thất bại đúng vào lúc cần nhất: ở chế độ bình thường, Region dự phòng chỉ nhận lưu lượng sao chép nên trông như không cần nhiều dung lượng, và việc cấp thấp cho nó có vẻ là quyết định tiết kiệm hợp lý. Nhưng khi chuyển vùng, toàn bộ tải sản xuất dồn sang trong vài giây, dung lượng không kịp co giãn, và bảng bắt đầu throttle — nghĩa là sự cố mạng ban đầu vừa biến thành sự cố ứng dụng. Với chế độ on-demand thì vấn đề này biến mất, và đó là lý do chính đáng nhất để chọn nó cho bảng đa Region.

Đáp án

C, E — hai cách xác thực bằng giải pháp tự xây và uỷ quyền bằng IAM role:

• C — Dùng giải pháp tự xây tương thích SAML, xác thực bằng LDAP, rồi dùng SAML assertion để uỷ quyền tới IAM identity provider.
• E — Dùng giải pháp tự xây tương thích OpenID Connect để xác thực, dùng Amazon Cognito để uỷ quyền.

Vì sao đúng

Đề đặt hai ràng buộc cứng: giải pháp xác thực phải do công ty tự xây, và uỷ quyền phải dùng IAM role. AWS có đúng hai chuẩn liên kết danh tính đáp ứng được điều đó.

⚠ Điểm mấu chốt: cả hai đường đều kết thúc ở thông tin đăng nhập TẠM THỜI gắn với một IAM role:

Đường SAML:
    Người dùng đăng nhập vào IdP tự xây (kiểm tra bằng LDAP)
        ↓
    IdP phát SAML assertion có thuộc tính Role
        ↓
    Gọi sts:AssumeRoleWithSAML
        ↓
    → nhận thông tin đăng nhập tạm của IAM role

Đường OIDC + Cognito:
    Người dùng đăng nhập vào IdP OIDC tự xây
        ↓
    Nhận ID token (JWT)
        ↓
    Đưa token cho Cognito identity pool
        ↓
    → Cognito đổi lấy thông tin đăng nhập tạm của IAM role

Vì sao Cognito hợp với ứng dụng di động (E). Cognito identity pool sinh ra đúng cho tình huống này: nhận token từ nhà cung cấp danh tính bên ngoài rồi đổi thành thông tin đăng nhập AWS tạm thời cho ứng dụng khách. Nó còn hỗ trợ role theo nhóm và role theo quy tắc dựa trên nội dung token.

# đổi token OIDC lấy thông tin đăng nhập AWS
aws cognito-identity get-id \
  --identity-pool-id ap-southeast-1:abc-123 \
  --logins '{"idp.congty.vn":"<id-token>"}'

aws cognito-identity get-credentials-for-identity \
  --identity-id <identity-id> \
  --logins '{"idp.congty.vn":"<id-token>"}'

⚠ Hai loại pool của Cognito rất hay bị lẫn: | Loại | Việc | |---|---| | User pool | thư mục người dùng — Cognito TỰ xác thực | | Identity pool | đổi token bên ngoài lấy IAM credentials — uỷ quyền |

Đề nói giải pháp xác thực do công ty tự xây, nên đường đúng là identity pool, không phải user pool.

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

• B (giải pháp SAML tự xây để xác thực, dùng AWS SSO để uỷ quyền) — đây là phương án gần nhất và nửa đầu của nó trùng với C: IdP SAML tự xây là hoàn toàn hợp lệ. Nó vướng ở nửa sau. AWS IAM Identity Center (trước là AWS SSO) được thiết kế cho nhân viên truy cập tài khoản AWS và ứng dụng nội bộ — nó có cổng đăng nhập riêng, quản lý permission set, gán quyền theo tài khoản. Đó không phải cơ chế cho người dùng cuối của một ứng dụng di động, vốn có thể lên tới hàng trăm nghìn danh tính không thuộc tổ chức. Với ứng dụng di động, đường chuẩn là Cognito identity pool.

• D (giải pháp OIDC tự xây với AWS SSO cho cả xác thực lẫn uỷ quyền) — mâu thuẫn nội tại. Nếu AWS SSO làm xác thực thì giải pháp tự xây không còn vai trò gì, trái với yêu cầu của đề. Và như trên, SSO không phải công cụ cho người dùng ứng dụng di động.

• A (LDAP connector bằng API Gateway + Lambda, Lambda authorizer kiểu token dùng JWT) — giải quyết một bài toán khác. Lambda authorizer bảo vệ API Gateway: nó quyết định request có được gọi API hay không. Nó không sinh ra IAM role credentials cho ứng dụng khách, nên không đáp ứng yêu cầu "use IAM roles for authorization" theo nghĩa đề đang nói. Đây là cơ chế uỷ quyền ở tầng API, không phải liên kết danh tính vào AWS.

Ghi nhớ

⚠ Bốn cách liên kết danh tính vào AWS — bảng phải thuộc: | Cách | Dành cho | API | |---|---|---| | SAML 2.0 | nhân viên, IdP doanh nghiệp (AD FS, Okta) | AssumeRoleWithSAML | | OIDC + Cognito identity pool | người dùng ứng dụng web/di động | GetCredentialsForIdentity | | OIDC trực tiếp | workload (GitHub Actions, EKS) | AssumeRoleWithWebIdentity | | IAM Identity Center | nhân viên truy cập tài khoản AWS | cổng đăng nhập riêng |

Từ khoá nhận diện:

"mobile application" + "federated access" → Cognito identity pool "custom-built authentication" + "IAM roles for authorization" → SAML hoặc OIDC "AWS SSO" cho người dùng ứng dụng di động → SAI, SSO dành cho nhân viên "Lambda authorizer" để cấp IAM credentials → SAI, nó chỉ gác cổng API Gateway "Cognito user pool" khi xác thực do bên ngoài làm → nhầm loại pool, cần identity pool

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Token có claim đúng không | giải mã JWT, đọc aud, iss, và các claim ánh xạ role | | Role có được assume không | CloudTrail, sự kiện AssumeRoleWithWebIdentity | | Người dùng có quyền quá rộng không | IAM Access Analyzer trên role của identity pool |

Và một lời khuyên: hãy giới hạn role của Cognito identity pool bằng điều kiện trên chính danh tính người dùng, đừng cấp một role dùng chung cho mọi người. Đây là chỗ rò rỉ dữ liệu giữa các tài khoản người dùng hình thành mà không ai để ý: nếu role cho phép dynamodb:GetItem trên cả bảng, thì mọi người dùng ứng dụng đều đọc được dữ liệu của mọi người dùng khác — ứng dụng của bạn chỉ hiển thị dữ liệu của họ, nhưng thông tin đăng nhập AWS nằm trong tay thiết bị, và bất kỳ ai mở công cụ gỡ lỗi ra đều gọi API trực tiếp được. Không có log nào đánh dấu điều đó là bất thường, vì về mặt kỹ thuật đó là một lời gọi hợp lệ với quyền hợp lệ. Cách chặn là điều kiện dynamodb:LeadingKeys gắn với cognito-identity.amazonaws.com:sub.

Đáp án

A, B — hai bước để sự cố vẫn tới được hệ thống ticket ngay cả trong cửa sổ bảo trì:

• B — Tạo EventBridge rule khớp sự kiện CloudTrail có lời gọi API của root user, đặt hàng đợi SQS làm target.
• A — Sửa Lambda để đọc tin nhắn từ hàng đợi SQS và chỉ trả về thành công khi API của hệ thống ticket đã xử lý xong.

Vì sao đúng

Vấn đề của đề rất cụ thể: hệ thống ticket offline 4 giờ mỗi tháng, và trong khoảng đó sự kiện bị mất. Lời giải là chèn một nơi giữ việc lại giữa lúc phát hiện và lúc gửi đi.

⚠ Điểm mấu chốt: SQS chỉ xoá tin nhắn khi người tiêu thụ báo thành công — đó chính là cơ chế cứu dữ liệu:

Root user gọi API
        ↓
    EventBridge khớp mẫu → đẩy tin nhắn vào SQS
        ↓
    Lambda đọc tin nhắn, thử gọi API của hệ thống ticket
        ↓
    Ticket đang bảo trì → Lambda ném lỗi → KHÔNG xoá tin nhắn
        ↓
    Tin nhắn hiện lại sau visibility timeout, thử lại
        ↓
    → sau 4 giờ bảo trì, mọi tin nhắn tồn đọng được xử lý hết

Câu "return successfully when the ticketing system API has processed the request" trong phương án A là mấu chốt và không phải chi tiết thừa: với event source mapping từ SQS, Lambda chỉ xoá tin nhắn khi hàm kết thúc thành công. Nếu hàm nuốt lỗi và trả về thành công, tin nhắn bị xoá và sự cố mất vĩnh viễn.

Vì sao chuyển từ lịch chạy sang EventBridge (B). Kiến trúc cũ chạy Lambda theo lịch, dùng Athena truy vấn log — nghĩa là có độ trễ, tốn tiền quét, và mỗi lần chạy hỏng là bỏ sót một khoảng. EventBridge bắt sự kiện ngay khi CloudTrail ghi nhận:

{
  "source": ["aws.signin", "aws.iam", "aws.s3"],
  "detail-type": ["AWS API Call via CloudTrail"],
  "detail": {"userIdentity": {"type": ["Root"]}}
}

⚠ Bắt buộc phải có dead-letter queue, nếu không tin nhắn hỏng sẽ lặp mãi rồi biến mất:

Một tin nhắn khiến hàm luôn ném lỗi (dữ liệu sai định dạng)
        ↓
    Thử lại tới maxReceiveCount rồi rơi vào DLQ
        ↓
    Không có DLQ → tin nhắn hết thời gian giữ (mặc định 4 ngày) rồi biến mất
        ↓
    → và nó chiếm chỗ, làm chậm việc xử lý các tin nhắn hợp lệ

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

• E (Lambda được kích hoạt bởi SNS topic, sửa mã để thử lại mỗi 5 phút nếu API của ticket không phản hồi) — đây là phương án gần nhất và ý tưởng thử lại là đúng hướng. Nhưng nó chọn sai dịch vụ và sai cách. SNS không giữ tin nhắn: nếu người nhận không xử lý được, tin nhắn mất — SNS chỉ có chính sách thử lại giới hạn và không có kho tồn đọng như SQS. Còn phần "thử lại mỗi 5 phút" bên trong hàm thì đâm thẳng vào trần 15 phút của Lambda: một cửa sổ bảo trì 4 giờ dài gấp 16 lần thời gian tối đa hàm được phép chạy. Hàm sẽ hết giờ và chết trong khi vẫn đang chờ. Đây là bẫy hay vì logic thử lại nghe rất hợp lý cho tới khi đối chiếu với con số 4 giờ trong đề.

• C (SNS topic nhận CloudWatch alarm, alarm gọi Lambda) — cùng vấn đề không giữ được tin nhắn, cộng thêm sai nguồn dữ liệu. CloudWatch alarm dựa trên chỉ số theo ngưỡng, còn thứ cần bắt ở đây là một sự kiện cụ thể — lời gọi API của root user. Đó là việc của EventBridge, không phải của alarm.

• D (SQS nhận CloudWatch alarm, alarm publish vào SQS) — dùng đúng SQS nhưng sai đường dẫn: CloudWatch alarm không publish trực tiếp vào SQS, đích của alarm là SNS, Auto Scaling, EC2 action hoặc Systems Manager. Và như trên, alarm không phải cách phát hiện một hành động API cụ thể.

Ghi nhớ

⚠ Bốn dịch vụ nhắn tin và khả năng giữ tin — bảng phải thuộc: | Dịch vụ | Giữ tin nhắn | Dùng khi | |---|---|---| | SQS | tới 14 ngày | người nhận có thể offline | | SNS | không (chỉ thử lại giới hạn) | fan-out tức thời | | EventBridge | không (nhưng có archive và replay) | định tuyến sự kiện theo luật | | Kinesis | tới 365 ngày | luồng dữ liệu, đọc lại được |

Từ khoá nhận diện:

"downstream system offline / maintenance window" → SQS làm bộ đệm "CloudTrail events for root user" → EventBridge rule với mẫu userIdentity.type = Root "SNS" khi người nhận có thể offline lâu → SAI, SNS không giữ tin "retry every 5 minutes" trong Lambda cho cửa sổ 4 giờ → SAI, vượt trần 15 phút "CloudWatch alarm publish to SQS" → SAI, alarm không có đích SQS

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Có tin nhắn tồn đọng không | ApproximateNumberOfMessagesVisible | | Tin nhắn cũ nhất bao lâu rồi | ApproximateAgeOfOldestMessage | | Có tin nhắn hỏng không | độ sâu của dead-letter queue |

Và một lời khuyên: hãy kiểm tra rằng hàm của bạn thật sự ném lỗi khi API ticket thất bại, đừng để nó bắt ngoại lệ rồi ghi log và trả về bình thường. Đây là cách toàn bộ cơ chế bảo vệ này bị vô hiệu hoá mà không để lại dấu vết: hàng đợi vẫn hoạt động, tin nhắn vẫn được đọc, Lambda vẫn báo Success cho mọi lời gọi, độ sâu hàng đợi vẫn về 0 đúng như mong đợi — và mọi sự cố xảy ra trong cửa sổ bảo trì vẫn biến mất y như trước, chỉ khác là giờ chúng biến mất sau khi đi qua một hạ tầng trông rất đáng tin cậy. Mẫu try/except bao quanh lời gọi API bên ngoài là phản xạ tự nhiên của hầu hết lập trình viên, và ở đây nó chính là lỗi.

Đáp án

B — Chuyển Aurora Serverless v1 sang Aurora MySQL đa Region (global database), sao chép dữ liệu liên tục giữa Region chính và Region phụ; dùng AWS SAM để triển khai lại ứng dụng ở Region phụ khi cần.

Vì sao đúng

Hai con số của đề quyết định tất cả: RTO 10 phút và RPO 2 phút. Chúng loại mọi cách sao lưu theo lô.

⚠ Điểm mấu chốt: Aurora Serverless v1 KHÔNG hỗ trợ global database — đó là lý do phải đổi engine:

Aurora Serverless v1
        ↓
    Không có cross-Region replica, không có global database
        ↓
    Cách duy nhất sang Region khác: sao chép snapshot — theo lô
        ↓
    → RPO bằng chu kỳ chụp snapshot, không thể đạt 2 phút

Aurora MySQL (provisioned) với global database
        ↓
    Sao chép ở tầng lưu trữ, độ trễ thường DƯỚI 1 giây
        ↓
    → RPO khoảng 1 giây, RTO dưới 1 phút khi promote

Đây là mấu chốt của cả câu hỏi và là lý do phương án B phải đổi loại cơ sở dữ liệu chứ không chỉ thêm bản sao.

Phần ứng dụng đơn giản hơn nhiều. API Gateway + Lambda là serverless, không có gì chạy sẵn để trả tiền. Triển khai lại bằng SAM ở Region phụ mất vài phút — nằm gọn trong RTO 10 phút:

sam deploy --region ap-northeast-1 \
  --stack-name ung-dung-dr \
  --parameter-overrides DbEndpoint=<endpoint-region-phu>

⚠ RTO 10 phút phải tính cả thời gian phát hiện, không chỉ thời gian thao tác:

Phát hiện sự cố (alarm)          ~2 phút
        ↓
Quyết định chuyển vùng           ~2 phút
        ↓
Promote global database          ~1 phút
        ↓
sam deploy ở Region phụ          ~3 phút
        ↓
Đổi DNS (TTL thấp)               ~1 phút
        ↓
→ vừa khít 10 phút, không có chỗ cho việc dựng hạ tầng từ đầu

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

• A (sao chép snapshot Aurora Serverless v1 sang Region dự phòng, script SAM để triển khai lại, khi có sự cố thì khôi phục từ snapshot mới nhất) — đây là phương án gần nhất và phần ứng dụng của nó hoàn toàn đúng: dùng SAM triển khai lại ở Region phụ là cách chuẩn cho kiến trúc serverless. Nó chỉ hỏng ở tầng dữ liệu, và hỏng ở cả hai chỉ tiêu. Sao chép snapshot là cơ chế theo lô: RPO bằng khoảng cách giữa hai lần chụp, không cách nào xuống 2 phút. Và khôi phục một cụm Aurora từ snapshot mất hàng chục phút tới hàng giờ tuỳ kích thước — vượt xa RTO 10 phút. Đây là bẫy hay vì nó là phương án duy nhất ngoài B mô tả một quy trình DR mạch lạc, chỉ là dùng công cụ có độ trễ sai bậc.

• C (cụm Aurora Serverless v1 thứ hai ở Region khác, Lambda tự sao chép dữ liệu mỗi 2 phút) — tự viết cơ chế sao chép, và con số 2 phút chỉ đúng trong trường hợp lý tưởng. Thực tế: Lambda phải biết dữ liệu nào đã đổi, xử lý thất bại, xử lý thứ tự, và nếu nó chết thì hai bên lệch nhau mà không có gì báo. RPO thực tế bằng khoảng cách giữa hai lần chạy thành công, không phải giữa hai lần được lên lịch. Đây là làm lại global database bằng tay theo cách kém tin cậy hơn nhiều.

• D (Aurora MySQL Read Replica ở Region khác, cấu hình sao lưu tự động với chu kỳ 2 phút) — nửa đầu hợp lý nhưng nửa sau mô tả một thứ không tồn tại: sao lưu tự động của RDS/Aurora chạy mỗi ngày một lần trong backup window, không cấu hình được chu kỳ 2 phút. Aurora có continuous backup cho point-in-time recovery, nhưng đó là trong cùng Region và không phải "automated backups with a 2-minute interval". Cross-Region read replica thì đúng hướng, nhưng global database mới là công cụ dựng riêng cho bài toán này.

Ghi nhớ

⚠ Bốn khác biệt Aurora Serverless v1 và v2 — bảng phải thuộc: | | Serverless v1 | Serverless v2 | |---|---|---| | Co giãn | theo bậc, có thể gián đoạn | liên tục, không gián đoạn | | Global database | KHÔNG hỗ trợ | hỗ trợ | | Read replica | không | có | | Về 0 dung lượng | có (pause) | có (từ 2024, xuống 0 ACU) |

Từ khoá nhận diện:

"RPO tính bằng phút hoặc giây" → sao chép liên tục, không phải snapshot "RTO 10 phút" + Aurora → global database, không phải khôi phục từ snapshot "Aurora Serverless v1" + đa Region → phải đổi sang provisioned hoặc v2 "automated backups with a 2-minute interval" → LUÔN SAI, sao lưu tự động là hằng ngày "Lambda tự sao chép mỗi N phút" → tự làm lại global database, kém tin cậy hơn

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Độ trễ sao chép thật | AuroraGlobalDBReplicationLag | | RTO thật | diễn tập chuyển vùng, bấm giờ từ lúc alarm kêu | | SAM có triển khai được ở Region phụ không | chạy thử sam deploy vào Region đó trước |

Và một lời khuyên: hãy chạy sam deploy vào Region dự phòng ít nhất một lần trước khi cần tới nó thật. Kế hoạch DR dựa trên "sẽ triển khai lại khi có sự cố" ẩn chứa một giả định chưa bao giờ được kiểm chứng: rằng template sẽ chạy được ở đó. Thực tế thường không vậy — một AMI id cứng chỉ tồn tại ở Region gốc, một loại instance chưa có ở Region đó, một chứng chỉ ACM chưa được tạo, một hạn mức chưa được nâng, một tên bucket đã bị người khác chiếm. Mỗi thứ đều nhỏ và sửa trong vài phút, nhưng bạn không có vài phút để sửa từng cái khi đồng hồ RTO đang chạy — và không có cách nào biết chúng tồn tại cho tới khi thật sự bấm nút triển khai.

Đáp án

C, E, F — ba bước dựng site DR ở Region khác cho nền tảng thương mại điện tử:

• E — Bật DynamoDB global table để sao chép bảng sang Region thứ hai.
• F — Bật S3 Cross-Region Replication cho các bucket chứa hình ảnh.
• C — Bật Route 53 health check để phát hiện site chính hỏng và chuyển lưu lượng sang site DR.

Vì sao đúng

Đề liệt kê ba loại tài nguyên, và ba phương án đúng lo đúng ba tầng đó cộng với cơ chế chuyển hướng.

⚠ Điểm mấu chốt: mỗi dịch vụ có cơ chế sao chép RIÊNG dựng sẵn — dùng cơ chế đó luôn tốt hơn tự viết:

DynamoDB → global table (multi-active, dưới một giây)
S3        → Cross-Region Replication (bất đồng bộ, thường vài giây)
Route 53  → health check + failover routing
        ↓
    → không có mã nào phải viết, không có thành phần nào phải vận hành

E — vì sao global table thay vì Streams + Lambda. Global table làm đúng việc đó ở tầng dịch vụ, có xử lý xung đột, có giám sát sẵn, và ghi được ở cả hai Region.

F — vì sao CRR cho S3. Nó sao chép object mới sang bucket ở Region khác một cách tự động:

aws s3api put-bucket-replication --bucket anh-san-pham \
  --replication-configuration '{
    "Role": "arn:aws:iam::111122223333:role/S3ReplicationRole",
    "Rules": [{"Status":"Enabled","Priority":1,
      "Filter":{},"DeleteMarkerReplication":{"Status":"Enabled"},
      "Destination":{"Bucket":"arn:aws:s3:::anh-san-pham-dr"}}]}'

⚠ CRR chỉ sao chép object TẠO SAU khi bật — dữ liệu cũ phải chuyển riêng:

Bật CRR hôm nay
        ↓
    Object tải lên từ hôm nay trở đi được sao chép
        ↓
    Toàn bộ ảnh đã có từ trước KHÔNG được đụng tới
        ↓
    → phải chạy S3 Batch Replication để xử lý phần cũ

C — vì sao Route 53 health check. Không có nó thì việc chuyển vùng là thao tác thủ công. Health check gắn với failover routing cho phép DNS tự loại Region hỏng.

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

• A (bật DynamoDB Streams và event-source mapping tới Lambda để ghi vào bảng ở Region hai) — đây là phương án gần nhất và nó thật sự sao chép được dữ liệu: đây là cách người ta làm trước khi global table ra đời. Nhưng nó là bản tự viết của một tính năng đã có sẵn, và mỗi mảnh tự viết là một chỗ có thể hỏng: phải tự xử lý thử lại, tự xử lý thứ tự, tự xử lý trường hợp Lambda bị throttle, tự giám sát độ lệch. Global table cho cùng kết quả với độ trễ thấp hơn, không cần dòng mã nào, và còn cho phép ghi ở cả hai Region — thứ mà bản tự viết một chiều không làm được.

• B (bật versioning trên bucket S3 và bật "cross-Region snapshots") — versioning là điều kiện cần để bật CRR, nhưng tự nó không sao chép gì sang Region khác. Và không có khái niệm "cross-Region snapshot" cho S3 — snapshot là khái niệm của EBS và RDS. Đây là phương án ghép hai thuật ngữ đúng thành một mô tả sai.

• D (bật "multi-Region targets" trên Elastic Load Balancer, trỏ tới EC2 ở cả hai Region) — ELB là dịch vụ trong phạm vi một Region; nó không có target ở Region khác và không có tuỳ chọn nào tên như vậy. Muốn phân phối lưu lượng giữa các Region thì phải dùng Route 53 hoặc Global Accelerator.

Ghi nhớ

⚠ Bốn cơ chế sao chép đa Region theo dịch vụ — bảng phải thuộc: | Dịch vụ | Cơ chế | Chiều | |---|---|---| | DynamoDB | global table | hai chiều (multi-active) | | S3 | CRR / MRR | một chiều (hai chiều nếu cấu hình cả hai) | | Aurora | global database | một chiều (ghi ở Region chính) | | EBS / RDS | sao chép snapshot | theo lô |

Từ khoá nhận diện:

"DR site in a separate Region" → sao chép từng tầng bằng cơ chế riêng của nó "DynamoDB đa Region" → global table "S3 đa Region" → Cross-Region Replication "multi-Region targets on the ELB" → LUÔN SAI, ELB trong một Region "cross-Region snapshots" cho S3 → SAI, S3 không có snapshot

Ba việc kiểm chứng: | Việc | Cách | |---|---| | CRR có chạy không | chỉ số ReplicationLatency và OperationsPendingReplication | | Ảnh cũ đã sang chưa | so số object hai bucket bằng S3 Inventory | | Health check có nhạy không | làm hỏng endpoint thử và bấm giờ tới lúc DNS đổi |

Và một lời khuyên: hãy so số object giữa hai bucket bằng S3 Inventory, đừng tin rằng bật CRR là xong. Đây là khoảng trống dữ liệu điển hình của kế hoạch DR dựa trên replication: bạn bật CRR, thấy chỉ số sao chép chạy đều, độ trễ thấp, không có lỗi nào — và mọi thứ đúng là đang hoạt động hoàn hảo cho những ảnh tải lên từ lúc bật trở đi. Toàn bộ thư viện ảnh sản phẩm tích luỹ nhiều năm trước đó vẫn chỉ nằm ở Region chính, và không có chỉ số nào phản ánh điều đó vì chúng chưa bao giờ là "pending replication". Bạn chỉ phát hiện vào ngày chuyển vùng thật, khi site DR lên hoàn hảo với một cửa hàng đầy ô ảnh vỡ.

Đáp án

B, C — hai bước để CloudFront phục vụ được nội dung tĩnh từ S3:

• C — Thêm một origin nữa vào CloudFront distribution, trỏ tới bucket S3 chứa nội dung tĩnh.
• B — Thêm một cache behavior với path pattern khớp nội dung tĩnh và trỏ tới origin đó.

Vì sao đúng

Lỗi 404 nói chính xác điều gì đang xảy ra: CloudFront chuyển mọi request về origin mặc định là ALB, kể cả những request tìm tệp tĩnh vốn nằm trong S3.

⚠ Điểm mấu chốt: cần đủ HAI mảnh — một origin để biết lấy ở đâu, một behavior để biết khi nào lấy ở đó:

Thêm origin S3 (C) mà không thêm behavior
        ↓
    CloudFront biết bucket tồn tại nhưng không bao giờ dùng tới
        ↓
    → vẫn 404 y như cũ

Thêm behavior (B) mà không có origin S3
        ↓
    Behavior không có đích nào hợp lệ để trỏ tới
        ↓
    → không cấu hình được

Đây là lý do đề bắt chọn hai phương án: chúng là hai nửa của một thay đổi duy nhất.

Cách CloudFront chọn behavior: nó duyệt danh sách theo thứ tự ưu tiên và dùng cái khớp đầu tiên. Default behavior (*) luôn nằm cuối:

aws cloudfront create-distribution --distribution-config file://cau-hinh.json
# trong cau-hinh.json: Origins có cả ALB lẫn S3,
# CacheBehaviors có mục PathPattern="/static/*" TargetOriginId="s3-tinh"

⚠ Thứ tự behavior quyết định — đặt sai là behavior cụ thể không bao giờ được dùng:

Nếu default behavior (*) được đánh giá trước
        ↓
    Nó khớp MỌI đường dẫn
        ↓
    → behavior /static/* phía sau không bao giờ tới lượt
        ↓
    → CloudFront thực ra luôn đặt default ở cuối, nhưng thứ tự giữa các
      behavior cụ thể với nhau thì bạn phải tự sắp cho đúng

Kèm theo đó nên dùng Origin Access Control để bucket chỉ nhận request từ CloudFront.

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

• A (thêm điều kiện host header vào ALB listener và chuyển tiếp header từ CloudFront) — đây là phương án gần nhất và nó là một kỹ thuật thật, dùng đúng chỗ thì rất hữu ích: chuyển tiếp host header từ CloudFront về ALB là cách để ALB định tuyến theo tên miền. Nhưng nó không giải bài này. Vấn đề không phải ALB từ chối request hay định tuyến sai — mà là tệp tĩnh không nằm ở ALB. Không có cấu hình listener nào khiến ALB phục vụ được một object trong S3. Đây là bẫy hay vì nó nghe như đang xử lý một vấn đề định tuyến, trong khi vấn đề thật là thiếu hẳn một origin.

• D (thêm CachePolicyConfig để cho phép HTTP header đi kèm request tới origin) — cache policy quyết định header, cookie và query string nào được đưa vào cache key và chuyển tiếp về origin. Nó ảnh hưởng tới tỷ lệ trúng cache và tới việc origin nhận được thông tin gì, nhưng không đổi được origin nào được gọi. Với một request vẫn đi tới ALB, thêm bao nhiêu header cũng không làm tệp tĩnh xuất hiện ở đó.

• E (thêm rule chuyển tiếp request phương thức GET tới Amazon S3) — CloudFront không định tuyến theo phương thức HTTP. Behavior khớp theo path pattern, không theo GET/POST. Ngoài ra nếu định tuyến được như vậy thì cũng sai: các request GET tới nội dung động cũng sẽ bị đẩy sang S3.

Ghi nhớ

⚠ Bốn thành phần của một CloudFront distribution — bảng phải thuộc: | Thành phần | Việc | |---|---| | Origin | nguồn nội dung: S3, ALB, endpoint tuỳ ý | | Cache behavior | path pattern nào đi tới origin nào, cùng với luật cache | | Cache policy | header/cookie/query string nào vào cache key | | Origin request policy | thứ gì được chuyển tiếp về origin (không vào cache key) |

Từ khoá nhận diện:

"static assets return 404" + ALB là origin mặc định → thiếu origin S3 và behavior "nhiều loại nội dung, nhiều nguồn" → nhiều origin + behavior theo path pattern "CloudFront định tuyến theo phương thức GET" → LUÔN SAI, chỉ theo path pattern "cache policy để đổi origin" → SAI, cache policy không chọn origin "host header condition ở ALB" để phục vụ tệp trong S3 → SAI, ALB không có tệp đó

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Request đi tới origin nào | header X-Cache và log của CloudFront | | Behavior nào khớp | thử curl từng đường dẫn và xem phản hồi | | S3 có cho CloudFront vào không | kiểm bucket policy có principal OAC/OAI |

Và một lời khuyên: hãy kiểm tra chữ hoa chữ thường trong path pattern, đây là nguyên nhân 404 dai dẳng nhất sau khi cấu hình xong. CloudFront khớp path pattern phân biệt hoa thường, nên một behavior khai là /Static/* sẽ không bao giờ khớp request tới /static/logo.png. Cấu hình trông hoàn toàn đúng khi đọc lướt, distribution triển khai thành công, origin S3 hiện đầy đủ trong danh sách — và mọi request tĩnh vẫn tiếp tục rơi vào behavior mặc định rồi về ALB, trả về đúng lỗi 404 mà bạn vừa tưởng đã sửa xong. Không có cảnh báo nào cho một path pattern không bao giờ khớp.

Đáp án

C — Dùng Kinesis Data Streams để thu thập dữ liệu vào, phân tích bằng Kinesis client, và lưu kết quả vào cụm Amazon Redshift bằng Amazon EMR.

Vì sao đúng

Đề nêu bốn yêu cầu, và Kinesis Data Streams là dịch vụ duy nhất trong các phương án thoả cả bốn.

⚠ Điểm mấu chốt: Kinesis Data Streams giữ dữ liệu và cho nhiều bên đọc lại — đó là chỗ nó khác Firehose:

Kinesis Data Streams
        ↓
    Bản ghi nằm trong stream tới 365 ngày
        ↓
    Nhiều ứng dụng tiêu thụ độc lập, mỗi cái giữ vị trí đọc riêng
        ↓
    Đọc lại được từ đầu nếu xử lý sai
        ↓
    → "durability for the data" theo đúng nghĩa đề nêu

Kinesis Data Firehose
        ↓
    Đưa thẳng vào đích rồi thôi, không giữ, không đọc lại được
        ↓
    → không có nơi nào để phân tích gần thời gian thực bằng client riêng

Phép tính quy mô — vì sao cần Kinesis:

aws kinesis create-stream --stream-name du-lieu-moi-truong \
  --stream-mode-details StreamMode=ON_DEMAND

⚠ Chế độ on-demand tự co giãn shard — tránh phải tính toán và điều chỉnh thủ công:

Chế độ provisioned: bạn tự khai số shard
        ↓
    Thiếu shard → ProvisionedThroughputExceededException
    Thừa shard → trả tiền cho phần không dùng

Chế độ on-demand
        ↓
    Tự co giãn tới gấp đôi đỉnh tải trong 30 ngày qua
        ↓
    → hợp khi số thiết bị còn đang tăng

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

• D (Kinesis Data Firehose thu thập dữ liệu cảm biến, phân tích bằng Kinesis client, lưu vào Amazon RDS) — đây là phương án gần nhất và nó dùng đúng họ dịch vụ Kinesis, chỉ chọn nhầm thành viên. Hai chỗ hỏng. Thứ nhất, Firehose không phải nơi để "Kinesis client" đọc từ đó — Firehose là đường ống một chiều đưa dữ liệu vào đích (S3, Redshift, OpenSearch, Splunk); nó không phơi ra stream để ứng dụng tiêu thụ đọc theo shard và giữ vị trí đọc. Thứ hai, đề nói thẳng "deliver results to a data warehouse" — RDS là cơ sở dữ liệu giao dịch, không phải kho dữ liệu. Redshift mới là kho dữ liệu.

• A (API Gateway đưa request vào SQS, Lambda phân tích, lưu vào Redshift bằng EMR) — hai vấn đề về quy mô và chi phí. Với hàng nghìn thiết bị gửi mỗi giây, đi qua API Gateway rồi SQS nghĩa là hàng nghìn request và hàng nghìn tin nhắn mỗi giây — cả hai đều tính tiền theo lượt, và tổng chi phí vượt xa Kinesis ở khối lượng này. Quan trọng hơn, SQS không giữ được dữ liệu lâu để đọc lại (tối đa 14 ngày, và tin nhắn biến mất khi đã xử lý), nên không đáp ứng yêu cầu về độ bền theo cách đề mô tả.

• B (S3 thu thập dữ liệu vào, "phân tích dữ liệu từ SQS bằng Kinesis", lưu vào Redshift) — mô tả một luồng không mạch lạc. Dữ liệu vào S3 nhưng lại phân tích từ SQS, và Kinesis được đặt vào vai người đọc SQS — không có mối liên hệ nào giữa các bước. Ngoài ra ghi thẳng từng bản ghi 8 KB vào S3 là mẫu chống chỉ định: hàng nghìn object nhỏ mỗi giây, chi phí bị chi phối bởi phí request, và không có gì gần thời gian thực.

Ghi nhớ

⚠ Bốn dịch vụ họ Kinesis — bảng phải thuộc: | Dịch vụ | Việc | Giữ dữ liệu | |---|---|---| | Data Streams | luồng để nhiều bên tiêu thụ, xử lý tuỳ biến | tới 365 ngày | | Data Firehose | đưa thẳng vào S3/Redshift/OpenSearch, biến đổi nhẹ | không giữ | | Managed Service for Apache Flink | phân tích luồng bằng SQL/Flink | theo Flink | | Video Streams | luồng video | có |

Từ khoá nhận diện:

"near real-time analytics" + "durability" → Data Streams "chỉ cần đưa vào S3/Redshift, không xử lý phức tạp" → Firehose "data warehouse" → Redshift, không phải RDS "Kinesis client đọc từ Firehose" → SAI, Firehose không phơi ra stream hàng nghìn bản ghi nhỏ mỗi giây qua API Gateway + SQS → đắt và không hợp quy mô

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Có bị nghẽn ghi không | WriteProvisionedThroughputExceeded | | Có tụt lại sau không | GetRecords.IteratorAgeMilliseconds | | Shard có đủ không | so tổng băng thông vào với số shard × 1 MB/giây |

Và một lời khuyên: hãy đặt cảnh báo trên IteratorAge chứ đừng chỉ theo dõi tỷ lệ lỗi. Đây là cách một đường ống dữ liệu luồng hỏng mà không có lỗi nào xuất hiện: nếu ứng dụng tiêu thụ xử lý chậm hơn tốc độ dữ liệu đổ vào, nó không thất bại — nó chỉ tụt lại xa dần. Mọi lời gọi đều thành công, không có ngoại lệ nào, biểu đồ lỗi phẳng lì ở 0. Thứ duy nhất thay đổi là dữ liệu bạn đang phân tích mỗi lúc một cũ, từ vài giây thành vài phút rồi vài giờ — và với một hệ thống được quảng cáo là "near real-time", điều đó có nghĩa là kết quả trả về cho nhà nghiên cứu đã sai từ lâu trước khi có ai nhận ra.

Đáp án

A — Dùng AWS OpsWorks và triển khai ứng dụng theo chiến lược blue/green.

Vì sao đúng

Đề nêu ba ràng buộc, và ràng buộc thứ hai loại gần hết danh sách: công ty muốn tận dụng công cụ Chef và kinh nghiệm sẵn có.

⚠ Điểm mấu chốt: blue/green cho phép lùi lại NGAY vì môi trường cũ vẫn còn nguyên:

Môi trường blue đang phục vụ production
        ↓
    Dựng môi trường green với phiên bản mới, đầy đủ
        ↓
    Chuyển lưu lượng sang green
        ↓
    Có sự cố → chuyển ngược về blue, vẫn đang chạy nguyên vẹn
        ↓
    → thời gian lùi lại tính bằng giây, không phải thời gian triển khai lại

Đây là điểm phân biệt với mọi chiến lược tại chỗ: với rolling hoặc in-place update, phiên bản cũ đã bị ghi đè, nên lùi lại nghĩa là triển khai lại từ đầu — mất đúng khoảng thời gian mà một sự cố production không cho phép.

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

⚠ AWS OpsWorks đã ngừng hoạt động từ 26/5/2024:

AWS thông báo end-of-life cho OpsWorks Stacks, OpsWorks for Chef Automate
và OpsWorks for Puppet Enterprise
        ↓
    Ngừng nhận khách hàng mới, rồi dừng hẳn dịch vụ
        ↓
    → đáp án này đúng theo khoá của bộ đề, nhưng KHÔNG còn triển khai được

Nếu gặp bài toán này hôm nay, các lựa chọn thay thế là:

Không sửa khoá đáp án, chỉ ghi chú. Khoá phải khớp với cái máy chủ dùng để chấm; đây là ghi chú để bạn biết kiến thức này đã lỗi thời trong thực tế, không phải để chọn khác khi làm bài.

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

• C (OpsWorks với chiến lược canary) — đây là phương án gần nhất và nó chọn đúng dịch vụ, chỉ khác chiến lược triển khai. Canary chuyển lưu lượng dần dần sang phiên bản mới — 5%, rồi 25%, rồi toàn bộ — và theo dõi chỉ số ở từng bước. Đó là chiến lược rất tốt, nhưng nó không tối ưu cho yêu cầu đề nêu: "ability to roll back quickly must be available in case issues occur FOLLOWING a production deployment", tức là sau khi đã triển khai xong. Với canary, khi đã chuyển 100% thì phiên bản cũ cũng không còn, nên lùi lại không nhanh hơn blue/green. Thêm nữa, canary không phải chiến lược có sẵn của OpsWorks theo cách blue/green là.

• B (CodeDeploy với in-place update) — CodeDeploy là công cụ tốt và ngày nay chính là thứ nên dùng, nhưng in-place update ghi đè lên chính các instance đang chạy. Lùi lại nghĩa là triển khai lại bản cũ lên từng máy — mất thời gian, và trong lúc đó dịch vụ đang ở trạng thái hỏng. Phương án này cũng không đáp ứng yêu cầu tận dụng Chef.

• D (Elastic Beanstalk với rolling update) — hai chỗ không khớp. Elastic Beanstalk không dùng Chef, nên bỏ mất kinh nghiệm sẵn có của đội. Và rolling update thay thế instance theo lô, nên trong lúc triển khai có hai phiên bản cùng phục vụ, và lùi lại phải chạy ngược cả quá trình. (Elastic Beanstalk có hỗ trợ blue/green bằng cách swap URL giữa hai môi trường, nhưng phương án này không nói vậy.)

Ghi nhớ

⚠ Năm chiến lược triển khai — bảng phải thuộc: | Chiến lược | Downtime | Lùi lại | Chi phí hạ tầng | |---|---|---|---| | In-place | có thể có | chậm — phải triển khai lại | thấp | | Rolling | không | chậm | thấp | | Rolling with batch | không | chậm | thêm một lô | | Blue/green | không | tức thì | gấp đôi trong lúc chuyển | | Canary | không | tức thì (phần đã chuyển) | thêm một phần nhỏ |

Từ khoá nhận diện:

"leverage existing Chef tools" → OpsWorks (trong đề cũ) "roll back quickly" → blue/green "gradually shift traffic and monitor" → canary "OpsWorks" trong bối cảnh hiện nay → dịch vụ đã ngừng, dùng CodeDeploy + Systems Manager "in-place update" khi đề đòi lùi lại nhanh → SAI

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Lùi lại có thật sự nhanh không | diễn tập lùi lại trong môi trường staging, bấm giờ | | Môi trường cũ còn nguyên không | kiểm số instance của cả hai nhóm sau khi chuyển | | Có tương thích ngược không | chạy phiên bản cũ với lược đồ CSDL mới |

Và một lời khuyên: hãy giữ mọi thay đổi lược đồ cơ sở dữ liệu tương thích ngược với phiên bản đang chạy, nếu không khả năng lùi lại chỉ là ảo tưởng. Đây là chỗ blue/green sụp đổ đúng lúc cần nhất: bạn chuyển sang green, phát hiện lỗi, bấm nút quay về blue trong ba giây — và blue không chạy được nữa, vì phiên bản mới đã chạy migration xoá một cột mà mã cũ vẫn đang đọc. Cơ chế lùi lại hoạt động hoàn hảo ở tầng hạ tầng, không có lỗi nào ở đó cả, nhưng ứng dụng cũ giờ đang nhìn vào một cơ sở dữ liệu nó không hiểu. Nguyên tắc là mỗi lần triển khai chỉ thêm, và chỉ xoá cột ở lần triển khai sau, khi bạn chắc chắn không cần quay lại nữa.

Đáp án

C, D, F — ba bước dựng đường ống gần thời gian thực từ Kafka tại chỗ lên ứng dụng web:

• D — Dựng kết nối AWS Direct Connect từ trung tâm dữ liệu lên AWS.
• F — Tạo Auto Scaling group EC2 kéo tin nhắn từ cụm Kafka tại chỗ, dùng Kinesis Producer Library đưa dữ liệu vào Kinesis data stream.
• C — Tạo WebSocket API trong API Gateway, Lambda xử lý stream, dùng lệnh @connections gửi tin nhắn ngược về client đang kết nối.

Vì sao đúng

Đề nêu ba yêu cầu và mỗi phương án đúng lo một cái.

⚠ Điểm mấu chốt: đẩy dữ liệu tới trình duyệt cần kết nối hai chiều — REST API không làm được:

REST API: client phải HỎI mới có dữ liệu
        ↓
    Muốn "gần thời gian thực" thì phải polling liên tục
        ↓
    → tốn tài nguyên, độ trễ bằng chu kỳ polling

WebSocket API: kết nối mở liên tục
        ↓
    Server chủ động GỬI khi có dữ liệu mới
        ↓
    Lambda gọi @connections POST tới connectionId
        ↓
    → dữ liệu tới trình duyệt ngay khi có

F — vì sao Kinesis Producer Library. KPL là thư viện chính thức để ghi vào Kinesis với hiệu suất cao: nó gom nhiều bản ghi vào một lời gọi (aggregation), tự thử lại, tự xử lý phân phối theo shard.

# phía Lambda: gửi ngược về client qua WebSocket
import boto3, os, json
api = boto3.client('apigatewaymanagementapi',
                   endpoint_url=os.environ['WS_ENDPOINT'])

def handler(su_kien, ngu_canh):
    for ban_ghi in su_kien['Records']:
        du_lieu = ban_ghi['kinesis']['data']
        for ket_noi in lay_danh_sach_ket_noi():
            api.post_to_connection(ConnectionId=ket_noi, Data=du_lieu)

⚠ Phải lưu danh sách connectionId ở đâu đó — WebSocket API không tự giữ:

Client kết nối → route $connect → Lambda lưu connectionId vào DynamoDB
        ↓
    Có dữ liệu mới → đọc danh sách từ DynamoDB → gửi tới từng connectionId
        ↓
    Client ngắt → route $disconnect → xoá khỏi DynamoDB
        ↓
    → thiếu bước này thì không biết gửi cho ai

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

• B (Auto Scaling group kéo tin nhắn từ Kafka, dùng "Amazon Consumer Library" để ghi vào Kinesis) — đây là phương án gần nhất và nó chỉ khác F đúng một từ: cùng cấu trúc, cùng ý tưởng, chỉ sai tên thư viện. Kinesis Client Library (KCL) dùng để ĐỌC từ Kinesis, còn ghi vào Kinesis là việc của Kinesis Producer Library (KPL). Ở đây EC2 đang đưa dữ liệu vào stream, nên phải là KPL. Đây là bẫy kiểm tra đúng một chi tiết: nhớ được chiều của hai thư viện.

• E (GraphQL API trong AppSync, Lambda xử lý stream, dùng @connections gửi callback) — trộn lẫn hai công nghệ. AppSync có cơ chế đẩy dữ liệu riêng là GraphQL subscription, chạy trên WebSocket của chính nó — nó không dùng lệnh @connections, vốn là API của API Gateway WebSocket. Mô tả này ghép cơ chế của dịch vụ này vào dịch vụ kia. (Nếu đề cho phép, AppSync subscription cũng là một lời giải hợp lệ cho bài toán đẩy dữ liệu — nhưng không phải theo cách phương án này mô tả.)

• A (Site-to-Site VPN từ trung tâm dữ liệu lên AWS) — đáp ứng được kết nối nhưng không đáp ứng "consistent network performance". VPN chạy trên Internet công cộng: độ trễ dao động, có mất gói, không cam kết băng thông. Đề nêu thẳng yêu cầu về hiệu năng ổn định, và đó là định nghĩa của Direct Connect.

Ghi nhớ

⚠ Ba loại API của API Gateway — bảng phải thuộc: | Loại | Chiều | Dùng khi | |---|---|---| | REST API | client hỏi, server đáp | API truyền thống, cần usage plan và cache | | HTTP API | như REST nhưng tối giản | rẻ hơn ~70%, độ trễ thấp hơn | | WebSocket API | hai chiều, kết nối mở | server chủ động đẩy dữ liệu |

Từ khoá nhận diện:

"push data to a web application" / "real-time updates" → WebSocket API hoặc AppSync subscription "consistent network performance" → Direct Connect, không phải VPN ghi vào Kinesis → KPL (Producer Library) đọc từ Kinesis → KCL (Client Library) "AppSync với @connections" → SAI, đó là API của API Gateway WebSocket

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Client có nhận được dữ liệu không | wscat -c wss://<api-id>... và quan sát | | Có connectionId chết không | post_to_connection trả GoneException — phải xoá khỏi bảng | | Kinesis có tụt lại không | IteratorAge |

Và một lời khuyên: hãy bắt GoneException khi gửi tin nhắn và xoá ngay connectionId đó khỏi bảng. Đây là chỗ hệ thống đẩy dữ liệu suy thoái dần mà không có lỗi rõ ràng: client đóng trình duyệt, mất mạng, hoặc chỉ đơn giản là nhàn rỗi quá 10 phút và bị API Gateway ngắt — nhưng route $disconnect không phải lúc nào cũng chạy, nhất là khi kết nối đứt đột ngột. Những connectionId chết đó tích lại trong bảng, và mỗi lần có dữ liệu mới, Lambda lại cố gửi cho tất cả — tốn thời gian chạy, tốn tiền, và làm chậm việc gửi cho những client còn sống. Không có gì báo cho bạn biết, vì mỗi lần gửi thất bại chỉ là một ngoại lệ đơn lẻ mà phần lớn mã sẽ bỏ qua.