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

Đáp án

A — Cấu hình Lambda "on success" destination và định tuyến kết quả tới Amazon SNS.

Vì sao đúng

Đề nêu hai yêu cầu, và mỗi yêu cầu quyết định một nửa đáp án:

1. Chuyển tiếp kết quả thực thi đi nơi khác
2. Bằng thông báo pub/sub

Vế thứ nhất — Lambda destination. Đây là tính năng dựng sẵn cho gọi bất đồng bộ: sau khi hàm chạy xong, Lambda tự gửi kết quả tới một đích mà không cần bạn viết mã gửi:

aws lambda put-function-event-invoke-config \
  --function-name xu-ly \
  --destination-config '{
    "OnSuccess": {"Destination": "arn:aws:sns:ap-southeast-1:123456789012:ket-qua"},
    "OnFailure": {"Destination": "arn:aws:sqs:ap-southeast-1:123456789012:that-bai"}
  }'

Bản ghi gửi đi chứa cả request lẫn response:

{
  "version": "1.0",
  "requestContext": {"functionArn": "...", "condition": "Success", "requestId": "..."},
  "requestPayload": {...},
  "responsePayload": {...}
}

Vế thứ hai — SNS vì đề nói "pub/sub". Đó là mô hình một-tới-nhiều, và SNS là dịch vụ pub/sub của AWS. SQS thì ngược lại — nó là hàng đợi, mỗi message một consumer.

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

• D. Lambda "on success" destination nhưng gửi tới SQS — cơ chế đúng nhưng sai mô hình: SQS là hàng đợi (point-to-point), không phải pub/sub. Đề nói rõ cần thông báo pub/sub.
• C. CloudWatch Events alarm kích hoạt khi Lambda thực thi thành công, gửi tới SNS — sai hai chỗ. Thứ nhất, "alarm" hoạt động trên METRIC số, không phản ứng với từng lần chạy. Thứ hai, kể cả dùng EventBridge rule thì Lambda không phát sự kiện "thực thi thành công" lên EventBridge, và quan trọng nhất — bạn không lấy được KẾT QUẢ trả về của hàm theo cách đó.
• B. Cùng cơ chế sai như C, lại còn gửi tới SQS — sai cả hai vế.

Ghi nhớ

Lambda destination — tính năng thay thế DLQ cũ, mạnh hơn hẳn: | Đích hợp lệ | Ghi chú | |---|---| | SNS | pub/sub, fan-out | | SQS | hàng đợi | | Lambda | gọi hàm khác | | EventBridge | định tuyến theo mẫu |

Điều kiện quan trọng: destination CHỈ hoạt động với gọi bất đồng bộ (S3, SNS, EventBridge, hoặc --invocation-type Event). Với gọi đồng bộ, client đã nhận kết quả trực tiếp nên không cần destination.

So sánh với DLQ cũ: | | DLQ (cũ) | Destination (mới) | |---|---|---| | Chỉ khi lỗi | ✅ | có cả success | | Nội dung | chỉ payload gốc | request + response/lỗi đầy đủ | | Đích | SQS, SNS | SQS, SNS, Lambda, EventBridge |

Destination được khuyến nghị thay cho DLQ vì nó mang theo ngữ cảnh đầy đủ — biết cả đầu vào lẫn kết quả, thay vì chỉ đầu vào.

Và phân biệt hai dịch vụ nhắn tin: | | SNS (push) | SQS (pull) | |---|---|---| | Mô hình | pub/sub — một tới nhiều | hàng đợi — một tới một | | Lưu trữ | không | tới 14 ngày |

Đáp án

D — Bản ghi trong Kinesis Data Stream chỉ được giữ 24 giờ theo mặc định.

Vì sao đúng

Đây là phép tính rất đơn giản một khi biết con số:

Thời gian giữ mặc định: 24 giờ
Chu kỳ xử lý của EC2:   48 giờ
                        ─────
Kết quả: một nửa dữ liệu HẾT HẠN và bị xoá trước khi consumer đọc tới

Cụ thể hơn: khi consumer chạy ở giờ thứ 48, những bản ghi đến trong 24 giờ đầu tiên đã biến mất. Chúng không hề bị lỗi — chúng chỉ đơn giản là hết hạn lưu trữ.

Điều này khớp hoàn hảo với các dữ kiện trong đề: cảm biến gửi dữ liệu đúng (đúng — dữ liệu đã vào stream), EC2 khoẻ mạnh (đúng — nó chạy bình thường), nhưng thiếu một lượng lớn dữ liệu.

Có hai cách sửa:

Cách 1 — tăng thời gian giữ:

aws kinesis increase-stream-retention-period \
  --stream-name du-lieu-cam-bien \
  --retention-period-hours 168        # 7 ngày

Cách 2 — xử lý thường xuyên hơn (cách đúng hơn về mặt kiến trúc): Kinesis được thiết kế cho xử lý gần thời gian thực; dùng nó như một kho lưu trữ hai ngày là dùng sai công cụ.

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

• C. EC2 instance thất bại không liên tục — mâu thuẫn với đề: đề nói rõ đã kiểm tra log giám sát và instance khoẻ mạnh.
• B. Kinesis có quá nhiều shard — thừa shard không gây mất dữ liệu, nó chỉ khiến bạn trả tiền nhiều hơn cần thiết. Thiếu shard mới gây throttle ở phía ghi, và khi đó producer sẽ báo lỗi — nhưng đề nói cảm biến gửi dữ liệu đúng.
• A. Redshift không phù hợp để lưu dữ liệu luồng — đây là nhận định có phần đúng về mặt kiến trúc (Redshift là kho phân tích, thường nạp theo lô), nhưng nó không giải thích được việc dữ liệu MẤT. Nếu Redshift không nhận được dữ liệu thì sẽ có lỗi nạp, không phải im lặng thiếu.

Ghi nhớ

Thời gian giữ dữ liệu của Kinesis Data Streams: | Mức | Giá trị | |---|---| | Mặc định | 24 giờ | | Tối đa (không phụ phí kéo dài) | 7 ngày (168 giờ) | | Tối đa với long-term retention | 365 ngày | | Tối thiểu | 24 giờ |

Việc kéo dài quá 24 giờ có tính thêm phí lưu trữ, và quá 7 ngày thì phí cao hơn nữa cùng với phí truy xuất riêng.

Metric quan trọng nhất để phát hiện sớm vấn đề này: | Metric | Ý nghĩa | |---|---| | GetRecords.IteratorAgeMilliseconds | consumer đang tụt lại bao xa so với đầu stream |

Nếu giá trị này tăng dần và tiến gần tới thời gian giữ, bạn sắp mất dữ liệu. Đây là metric phải đặt alarm cho mọi ứng dụng Kinesis:

aws cloudwatch put-metric-alarm --alarm-name consumer-tut-lai \
  --namespace AWS/Kinesis --metric-name GetRecords.IteratorAgeMilliseconds \
  --dimensions Name=StreamName,Value=du-lieu-cam-bien \
  --statistic Maximum --period 300 --threshold 43200000 \
  --comparison-operator GreaterThanThreshold --evaluation-periods 1

(Ngưỡng 43.200.000 mili giây = 12 giờ, tức một nửa thời gian giữ mặc định.)

So sánh thời gian giữ giữa các dịch vụ luồng và hàng đợi: | Dịch vụ | Thời gian giữ | |---|---| | Kinesis Data Streams | 24 giờ – 365 ngày | | DynamoDB Streams | 24 giờ (cố định) | | SQS | 60 giây – 14 ngày | | MSK (Kafka) | cấu hình tuỳ ý | | SNS | không lưu |

Và bài học chung: luôn kiểm tra thời gian giữ so với chu kỳ xử lý. Đây là loại lỗi im lặng — không có exception nào, chỉ đơn giản là dữ liệu biến mất.

Đáp án

B — AWS Serverless Application Model (SAM).

Vì sao đúng

Đề nêu hai yêu cầu, và yêu cầu thứ hai là điểm quyết định:

1. Triển khai Lambda và API Gateway trong một stack duy nhất
2. Build và kiểm thử CỤC BỘ trước khi triển khai lên AWS

SAM CLI là công cụ duy nhất chạy được Lambda tại chỗ, bằng cách mô phỏng môi trường Lambda trong container Docker:

sam init                                    # tạo dự án từ template
sam build                                   # biên dịch, cài phụ thuộc
sam local invoke HamCuaToi --event su-kien.json    # chạy MỘT hàm
sam local start-api                         # dựng API Gateway giả tại localhost:3000
curl http://localhost:3000/don-hang         # gọi thử như thật
sam deploy --guided                         # triển khai lên AWS

Lệnh sam local start-api đặc biệt hợp với đề: nó mô phỏng cả API Gateway lẫn Lambda trên máy bạn, nên kiểm thử được toàn bộ luồng mà không cần triển khai gì.

Và vế thứ nhất cũng được đáp ứng: SAM khai cả hai trong một template ngắn gọn:

Transform: AWS::Serverless-2016-10-31
Resources:
  XuLyDonHang:
    Type: AWS::Serverless::Function
    Properties:
      Handler: index.handler
      Runtime: nodejs20.x
      Events:
        ApiPost:
          Type: Api                    # ← API Gateway được tạo ngầm
          Properties: {Path: /don-hang, Method: post}

Vì hàm chạy trong container giống môi trường Lambda thật, bạn phát hiện được cả những lỗi phụ thuộc hệ điều hành mà chạy trực tiếp trên máy sẽ không thấy.

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

• A. AWS CloudFormation — triển khai được cả hai dịch vụ trong một stack, nhưng không có công cụ chạy cục bộ nào. Bạn phải triển khai lên AWS mới kiểm thử được — vòng lặp chậm và tốn tiền. (Và SAM thực chất là phần mở rộng của CloudFormation — nó thêm cú pháp rút gọn cộng với bộ CLI.)
• D. AWS CodeBuild — dịch vụ build được quản lý chạy TRÊN CLOUD. Nó biên dịch và chạy test, nhưng không phải công cụ phát triển cục bộ. (CodeBuild có local agent chạy bằng Docker, nhưng đó là để gỡ lỗi buildspec, không phải để chạy Lambda.)
• C. AWS Elastic Beanstalk — nền tảng chạy ứng dụng trên EC2, không phải serverless. Nó không triển khai Lambda và không có cơ chế kiểm thử cục bộ.

Ghi nhớ

Các lệnh chính của SAM CLI: | Lệnh | Việc | |---|---| | sam init | tạo dự án từ template | | sam build | biên dịch, cài phụ thuộc | | sam local invoke | chạy một hàm cục bộ trong Docker | | sam local start-api | dựng API Gateway giả tại localhost:3000 | | sam local start-lambda | dựng endpoint Lambda giả để SDK gọi vào | | sam local generate-event | sinh sự kiện mẫu (S3, SNS, API Gateway…) | | sam deploy --guided | triển khai, hỏi và lưu cấu hình | | sam sync --watch | đồng bộ thay đổi lên AWS ngay khi sửa mã |

Ba công cụ hay bị lẫn: | Công cụ | Là gì | Chạy cục bộ được? | |---|---|---| | SAM | framework serverless + CLI | ✅ | | CloudFormation | dịch vụ triển khai hạ tầng | ❌ | | CDK | hạ tầng bằng ngôn ngữ lập trình | ❌ (nhưng dùng chung với sam local được) |

Chúng không loại trừ nhau: nhiều đội dùng CDK để định nghĩa hạ tầng rồi cdk synth ra template và dùng sam local invoke để kiểm thử hàm cục bộ.

Hạn chế cần biết của sam local: nó mô phỏng Lambda và API Gateway, nhưng không mô phỏng các dịch vụ AWS khác. Hàm gọi DynamoDB sẽ gọi tới DynamoDB thật bằng credential của bạn — trừ khi bạn trỏ endpoint sang DynamoDB Local hoặc LocalStack.

Đáp án

A — Task sẽ được đặt lên các container instance thuộc task group "databases".

Vì sao đúng

Đọc từng phần của cấu hình:

{
  "expression": "task:group == databases",
  "type": "memberOf"
}

Ghép lại: chỉ đặt task lên những container instance đang chạy task của nhóm databases.

Đây là ràng buộc tuyệt đối, không phải ưu tiên: nếu không có instance nào thoả biểu thức, task ở trạng thái PENDING thay vì được đặt lên máy khác.

Cần phân biệt rõ hai khái niệm của ECS: | Khái niệm | Vai trò | |---|---| | Constraint | BỘ LỌC — instance nào ĐƯỢC PHÉP | | Strategy | ƯU TIÊN — trong số hợp lệ thì chọn cái nào |

Cấu hình trong đề dùng placementConstraints, nên nó là bộ lọc.

Mục đích thực tế của mẫu này: gom các workload cùng loại lên cùng nhóm máy — ví dụ chạy CSDL trên các instance có ổ đĩa nhanh, tách khỏi các instance chạy web.

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

• B. Task sẽ TRỞ THÀNH thành viên của task group "databases" — hiểu ngược chiều: biểu thức này LỌC nơi đặt task, nó không gán nhóm cho task. Muốn gán nhóm thì dùng tham số --group khi chạy task:

  aws ecs run-task --cluster cum-chinh --task-definition csdl --group databases
  

• C. Task sẽ KHÔNG được đặt lên instance thuộc nhóm "databases" — đảo ngược ý nghĩa: memberOf là bao gồm, không phải loại trừ. Muốn loại trừ thì viết !=.
• D. Task không được chạy trừ khi có tag "databases" — nhầm hai khái niệm: task:group là NHÓM TASK, không phải tag của tài nguyên. Lọc theo tag thì dùng attribute: với thuộc tính tuỳ chỉnh.

Ghi nhớ

Hai constraint của ECS (bộ lọc): | Type | Hành vi | |---|---| | distinctInstance | mỗi instance tối đa một task | | memberOf | chỉ instance thoả biểu thức Cluster Query Language |

Vài biểu thức CQL hữu ích:

task:group == databases                       nhóm task
attribute:ecs.instance-type =~ t3.*           họ instance
attribute:ecs.availability-zone in [ap-southeast-1a, ap-southeast-1c]
attribute:ecs.os-type == linux
attribute:loai-may == csdl                    thuộc tính tuỳ chỉnh

Toán tử dùng được: ==, !=, >, <, in, not_in, exists, not_exists, và =~ (khớp biểu thức chính quy).

Ba strategy của ECS (ưu tiên): | Type | Mục tiêu | |---|---| | spread | rải đều — sẵn sàng cao | | binpack | dồn chặt — tiết kiệm chi phí | | random | ngẫu nhiên |

Thứ tự áp dụng: constraint chạy trước để thu hẹp tập ứng viên, rồi strategy mới chọn trong tập đó — nên hai cơ chế kết hợp được:

"placementConstraints": [{"type": "memberOf", "expression": "attribute:loai-may == csdl"}],
"placementStrategy": [{"field": "attribute:ecs.availability-zone", "type": "spread"}]

Và lưu ý: với Fargate, placement constraint không dùng được — không có instance nào để lọc.

Đáp án

A — Tạo một Change Set.

Vì sao đúng

Change set là bản xem trước của những gì CloudFormation sẽ làm — nó tính toán các thay đổi nhưng KHÔNG thực hiện:

# 1. Tạo change set
aws cloudformation create-change-set \
  --stack-name ung-dung-production \
  --change-set-name xem-truoc-v2 \
  --template-body file://template-moi.yaml \
  --capabilities CAPABILITY_IAM

# 2. Xem những gì sẽ thay đổi
aws cloudformation describe-change-set \
  --stack-name ung-dung-production --change-set-name xem-truoc-v2

# 3. Hài lòng thì mới áp dụng
aws cloudformation execute-change-set \
  --stack-name ung-dung-production --change-set-name xem-truoc-v2

Kết quả ở bước 2 cho biết chính xác từng tài nguyên bị ảnh hưởng:

{"Changes": [{
  "ResourceChange": {
    "Action": "Modify",
    "LogicalResourceId": "CoSoDuLieu",
    "ResourceType": "AWS::RDS::DBInstance",
    "Replacement": "True",                  ← ⚠ TÀI NGUYÊN SẼ BỊ THAY THẾ
    "Details": [{"Target": {"Attribute": "Properties", "Name": "DBInstanceClass",
                            "RequiresRecreation": "Always"}}]
  }}]}

Trường Replacement: True là thứ giá trị nhất: nó cảnh báo rằng tài nguyên sẽ bị xoá và tạo lại — với CSDL nghĩa là mất dữ liệu. Đây là loại sự cố mà change set sinh ra để ngăn chặn.

Ba giá trị của Action: | Action | Nghĩa | |---|---| | Add | tạo tài nguyên mới | | Modify | sửa tài nguyên có sẵn | | Remove | xoá tài nguyên |

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

• B. Dùng direct update — thực hiện thay đổi NGAY LẬP TỨC mà không xem trước. Đó chính xác là thứ đề muốn tránh.
• C. Dùng drift detection — chức năng khác hẳn: nó phát hiện tài nguyên đã bị sửa THỦ CÔNG ngoài CloudFormation, tức là so trạng thái thực tế với template hiện tại. Nó nhìn về quá khứ, không dự đoán thay đổi sắp tới.
• D. Tạo StackSet — dùng để triển khai một stack lên NHIỀU tài khoản và Region cùng lúc. Nó là công cụ mở rộng phạm vi triển khai, không phải công cụ xem trước.

Ghi nhớ

Ba công cụ an toàn của CloudFormation: | Công cụ | Việc | Nhìn về | |---|---|---| | Change set | xem trước thay đổi SẮP tới | tương lai | | Drift detection | phát hiện sửa đổi thủ công ĐÃ xảy ra | quá khứ | | Stack policy | chặn cập nhật một số tài nguyên | bảo vệ |

Quy trình triển khai an toàn cho production:

1. Tạo change set
2. Đọc kỹ, đặc biệt là "Replacement: True"
3. Kiểm tra DeletionPolicy cho tài nguyên có dữ liệu
4. Sao lưu CSDL nếu cần
5. Execute change set

Hai thuộc tính bảo vệ dữ liệu nên đặt cho tài nguyên quan trọng:

DeletionPolicy: Snapshot
UpdateReplacePolicy: Snapshot

Cặp này đảm bảo: xoá stack thì chụp snapshot, và cập nhật buộc thay thế cũng chụp snapshot — thuộc tính thứ hai rất hay bị quên.

Và stack policy là lớp bảo vệ cứng hơn nữa — nó chặn hẳn việc cập nhật một số tài nguyên:

{"Statement": [
  {"Effect": "Allow", "Action": "Update:*", "Principal": "*", "Resource": "*"},
  {"Effect": "Deny", "Action": "Update:Replace", "Principal": "*",
   "Resource": "LogicalResourceId/CoSoDuLieu"}
]}

Với stack policy này, ngay cả khi bạn vô tình chạy một update làm thay thế CSDL, CloudFormation cũng từ chối.

Đáp án

B — Query với eventually consistent read.

Vì sao đúng

Có hai quyết định, và mỗi quyết định tiết kiệm một nửa chi phí.

Quyết định 1 — Query thay vì Scan: | | Query | Scan | |---|---|---| | Đọc | chỉ item khớp partition key | TOÀN BỘ bảng hoặc index | | Chi phí | theo lượng dữ liệu khớp | theo TOÀN BỘ dữ liệu quét qua |

Đây là khác biệt lớn nhất. Với index có hàng triệu item mà bạn chỉ cần vài chục, Query rẻ hơn Scan hàng nghìn lần.

Quyết định 2 — eventually consistent thay vì strongly consistent:

Eventually consistent: 0,5 RCU cho mỗi 4 KB
Strongly consistent  : 1   RCU cho mỗi 4 KB   ← gấp đôi

table.query(
    IndexName='ChiMucTraCuu',
    KeyConditionExpression=Key('loai_san_pham').eq('dien-tu'),
    ConsistentRead=False          # mặc định — rẻ một nửa
)

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

• D. Query với strongly consistent read — KHÔNG THỰC HIỆN ĐƯỢC, và đây là điểm quan trọng nhất của câu này: GSI KHÔNG BAO GIỜ hỗ trợ strongly consistent read. Truyền ConsistentRead=True khi truy vấn GSI sẽ nhận ValidationException. Lý do: GSI được cập nhật bất đồng bộ sau khi ghi vào bảng gốc, nên DynamoDB không thể đảm bảo tính nhất quán mạnh.
• C. Scan với eventually consistent read — loại đọc rẻ, nhưng Scan đọc toàn bộ index nên tốn hơn Query rất nhiều.
• A. Scan với strongly consistent read — tệ nhất về mọi mặt, và cũng không làm được trên GSI vì lý do ở trên.

Ghi nhớ

Đặc điểm quan trọng nhất của GSI: | Đặc điểm | GSI | |---|---| | Strongly consistent read | ❌ KHÔNG BAO GIỜ | | Capacity | RIÊNG, phải cấp riêng | | Tạo lúc nào | bất cứ lúc nào | | Partition key | tự do chọn |

So sánh với LSI: | | GSI | LSI | |---|---|---| | Strongly consistent | ❌ | ✅ | | Partition key | tự do | phải giống bảng gốc | | Capacity | riêng | dùng chung với bảng | | Tạo lúc nào | bất cứ lúc nào | chỉ khi tạo bảng | | Số lượng | 20 | 5 |

Bốn cách đọc dữ liệu, theo hiệu quả giảm dần: | Thao tác | Dùng khi | Chi phí | |---|---|---| | GetItem | biết chính xác khoá của một item | thấp nhất | | BatchGetItem | biết khoá của nhiều item | thấp | | Query | nhiều item cùng partition key | trung bình | | Scan | không có lựa chọn nào khác | cao nhất |

Và một hiểu nhầm phổ biến cần tránh: FilterExpression KHÔNG giảm RCU. Bộ lọc được áp sau khi dữ liệu đã được đọc và tính tiền — bạn chỉ nhận về ít kết quả hơn, không trả ít tiền hơn:

Scan đọc 50 GB → tính tiền cho 50 GB → FilterExpression bỏ bớt → trả về 100 MB
                        ↑ bạn trả tiền ở đây

Muốn thật sự giảm dữ liệu đọc thì phải thiết kế khoá cho Query hoặc thêm GSI phù hợp.

Đáp án

A — Dùng DynamoDB Streams.

Vì sao đúng

Yêu cầu: ghi lại mọi thay đổi mới trên bảng DynamoDB sang một bảng khác trong cùng Region.

DynamoDB Streams ghi lại mọi thay đổi ở mức item theo đúng thứ tự, và Lambda đọc stream đó để ghi sang bảng đích:

Bảng gốc (có thay đổi)
      ↓ DynamoDB tự phát bản ghi thay đổi
  DynamoDB Streams
      ↓ event source mapping
    Lambda → ghi vào bảng lưu trữ

aws dynamodb update-table --table-name bang-goc \
  --stream-specification StreamEnabled=true,StreamViewType=NEW_AND_OLD_IMAGES

aws lambda create-event-source-mapping \
  --function-name ghi-lich-su \
  --event-source-arn <arn-cua-stream> \
  --starting-position LATEST --batch-size 100

Hàm nhận được cả ảnh cũ lẫn ảnh mới — rất hợp cho việc lưu lịch sử thay đổi:

def lambda_handler(event, context):
    for ban_ghi in event['Records']:
        bang_lich_su.put_item(Item={
            'id': ban_ghi['dynamodb']['Keys']['id']['S'],
            'thoi_diem': ban_ghi['dynamodb']['ApproximateCreationDateTime'],
            'thao_tac': ban_ghi['eventName'],        # INSERT / MODIFY / REMOVE
            'anh_cu': ban_ghi['dynamodb'].get('OldImage'),
            'anh_moi': ban_ghi['dynamodb'].get('NewImage')
        })

Điểm mấu chốt: ứng dụng hiện có không phải sửa một dòng nào — DynamoDB tự phát sự kiện.

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

• B. Dùng "DynamoDB snapshots" — không có khái niệm này. DynamoDB có on-demand backup và point-in-time recovery, nhưng chúng là bản chụp toàn bộ bảng để khôi phục, không phải luồng thay đổi liên tục. Chúng cũng không ghi vào một bảng khác.
• D. Dùng CloudTrail — CloudTrail không ghi thao tác dữ liệu của DynamoDB theo mặc định. Nó ghi lời gọi API quản trị (tạo bảng, sửa capacity). (Có thể bật data event cho DynamoDB, nhưng đó là đường vòng đắt đỏ cho việc mà Streams làm sẵn và miễn phí.)
• C. Dùng CloudWatch Events — EventBridge phản ứng với sự kiện của dịch vụ AWS, nó không theo dõi thay đổi dữ liệu ở mức item trong bảng của bạn.

Ghi nhớ

Bốn kiểu StreamViewType: | Kiểu | Nội dung | |---|---| | KEYS_ONLY | chỉ khoá chính | | NEW_IMAGE | item sau thay đổi | | OLD_IMAGE | item trước thay đổi | | NEW_AND_OLD_IMAGES | cả hai — linh hoạt nhất cho việc lưu lịch sử |

Đặc điểm của DynamoDB Streams: | Đặc điểm | Chi tiết | |---|---| | Thời gian giữ | 24 giờ (cố định) | | Thứ tự | đảm bảo trong mỗi partition key | | Đảm bảo | exactly-once ghi vào stream, at-least-once khi Lambda đọc | | Chi phí | miễn phí phần stream; chỉ trả tiền lời gọi Lambda |

So sánh hai lựa chọn stream của DynamoDB: | | DynamoDB Streams | Kinesis Data Streams for DynamoDB | |---|---|---| | Giữ dữ liệu | 24 giờ | tới 365 ngày | | Consumer | tối đa 2 mỗi shard | nhiều, độc lập | | Thứ tự | đảm bảo | không đảm bảo tuyệt đối | | Quản lý | không có gì | phải quản shard |

Một mẹo hữu ích: item bị TTL xoá cũng xuất hiện trong Streams, với userIdentity.principalId = "dynamodb.amazonaws.com" — nên bạn lưu trữ dữ liệu hết hạn sang S3 hoặc bảng khác trước khi nó mất hẳn.

Và nhớ viết hàm idempotent — Lambda đọc stream với đảm bảo at-least-once, nên cùng một bản ghi có thể được xử lý nhiều lần.

Đáp án

A và B.

• B — Tạo Auto Scaling group cho cả web tier lẫn application tier
• A — Dựng Elastic Load Balancer cho cả hai tầng

Vì sao đúng

Đề yêu cầu ứng dụng phải chịu lỗi (fault tolerant) và đàn hồi (elastic), và câu hỏi giới hạn ở web tier và application tier.

Hai đáp án này là hai trụ cột không tách rời của một kiến trúc như vậy:

Internet
   ↓
ALB (public)  ────────────── A
   ↓
Web tier: ASG các EC2 chạy Tomcat  ── B
   ↓
ALB nội bộ  ─────────────── A
   ↓
App tier: ASG các EC2 Linux  ────── B
   ↓
RDS MySQL Multi-AZ

Và chi tiết quan trọng: cần ALB ở CẢ HAI tầng. ALB thứ hai là internal (không có IP công khai), cho phép web tier và app tier mở rộng độc lập — web tier gọi vào endpoint của ALB nội bộ thay vì gọi thẳng vào một instance cụ thể.

Nếu thiếu ALB nội bộ, web tier phải biết địa chỉ từng máy app tier — và khi ASG thay máy thì mọi thứ hỏng.

Nên đặt thêm HealthCheckType: ELB cho ASG: với mặc định EC2, ASG chỉ kiểm tra máy còn chạy không, nên ứng dụng chết mà máy vẫn bật sẽ không được thay thế.

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

• E. Dựng ELB chỉ cho application tier — chỉ đúng một nửa của đáp án A. Web tier cũng cần load balancer, nếu không thì không có gì phân phối traffic từ Internet vào và không có health check cho tầng đó.
• D. Dùng RDS MySQL Multi-AZ cho back end — đúng về mặt kiến trúc và nên làm, nhưng đề hỏi cụ thể về web tier và application tier. Đây là câu trả lời cho tầng dữ liệu.
• C. Tạo CloudFront distribution cho web tier — CDN cải thiện độ trễ cho nội dung tĩnh và giảm tải cho origin, nhưng nó không làm tầng web đàn hồi hay chịu lỗi. Nếu mọi instance web đều chết, CloudFront cũng không phục vụ được nội dung động.

Ghi nhớ

Ba trụ cột của kiến trúc web đàn hồi và chịu lỗi: | Trụ cột | Thành phần | |---|---| | Phi trạng thái | đưa session ra ElastiCache hoặc DynamoDB | | Phân phối tải | ALB / NLB, trải nhiều AZ | | Co giãn tự động | Auto Scaling group |

Trụ cột đầu tiên đáng nhấn mạnh với ứng dụng Tomcat: nếu session còn nằm trong bộ nhớ của từng instance thì ASG sẽ làm người dùng bị đăng xuất mỗi khi thay máy. Đây là bước refactor thường bị bỏ sót khi di trú ứng dụng cũ lên đám mây.

Kiến trúc ba tầng đầy đủ trên AWS: | Tầng | Thành phần | Subnet | |---|---|---| | Web | ALB công khai + ASG EC2 | ALB ở public, EC2 ở private | | App | ALB nội bộ + ASG EC2 | private | | Data | RDS Multi-AZ | private, không có route ra Internet |

Và bốn việc nên làm để thực sự chịu lỗi:

1. Tối thiểu 2 instance ở mỗi tầng, trải trên ≥ 2 AZ
2. HealthCheckType: ELB kèm HealthCheckGracePeriod đủ dài
3. RDS Multi-AZ cho tầng dữ liệu
4. Session ra kho ngoài — điều kiện để ba việc trên có ý nghĩa

Đáp án

B — Lưu session data trong Amazon ElastiCache.

Vì sao đúng

Đề nêu ba yêu cầu, và ElastiCache đáp ứng cả ba:

1. Chịu lỗi
2. Co giãn tự nhiên (natively scalable)
3. Gián đoạn dịch vụ không được ảnh hưởng trải nghiệm người dùng

Nguyên tắc nền tảng: tầng web phải phi trạng thái. Session phải nằm ở kho ngoài, để mọi instance đều phục vụ được mọi người dùng:

Client → ELB → EC2 (thay thế được bất cứ lúc nào)
                 ↓
           ElastiCache Redis (kho session dùng chung)

Nên chọn Redis thay vì Memcached ở đây, vì chỉ Redis có nhân bản và tự động failover — đúng vế "fault-tolerant":

aws elasticache create-replication-group \
  --replication-group-id session-store \
  --engine redis --cache-node-type cache.r6g.large \
  --num-node-groups 2 --replicas-per-node-group 2 \
  --automatic-failover-enabled --multi-az-enabled

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

• C. Bật sticky session trên load balancer — đây là bẫy chính, và nó đi ngược yêu cầu: sticky session ghim mỗi người dùng vào đúng instance đang giữ session của họ. Khi instance đó hỏng — hoặc bị ASG thu hồi lúc scale-in — session mất hoàn toàn và người dùng bị đăng xuất giữa chừng. Nó che vấn đề đi chứ không giải quyết.
• D. Lưu session trên S3 — quá chậm cho session: mỗi request phải gọi API S3, độ trễ hàng chục tới hàng trăm mili giây, trong khi session được đọc ở mọi request. S3 rất bền nhưng sai công cụ.
• A. Lưu session trong CloudFront — sai bản chất: CloudFront là CDN cache nội dung ở edge, nó không phải kho lưu trữ và không có API để ứng dụng ghi/đọc dữ liệu session.

Ghi nhớ

Các lựa chọn lưu session ngoài: | Kho | Độ trễ | Bền | Chọn khi | |---|---|---|---| | ElastiCache Redis | thấp nhất — dưới mili giây | vừa (có nhân bản, snapshot) | cần nhanh nhất + chịu lỗi | | DynamoDB | mili giây một chữ số | rất bền, đa AZ | cần bền, có TTL, không quản lý | | RDS | cao hơn | bền | quá nặng cho session |

Cả hai lựa chọn đầu đều đúng về mặt kiến trúc; cách chọn theo từ khoá trong đề:

• "lowest latency", "fastest" ⇒ ElastiCache Redis
• "durable", "no management", "TTL" ⇒ DynamoDB

Ba thứ không bao giờ dùng làm kho session: | Không dùng | Vì sao | |---|---| | Bộ nhớ hoặc ổ đĩa cục bộ | mất khi instance được thay | | Instance store | mất khi instance dừng | | Sticky session làm giải pháp duy nhất | instance hỏng là mất session |

(Sticky session vẫn hữu ích như tối ưu bổ sung khi đã có kho session ngoài — nó giúp tận dụng cache cục bộ và giảm số lần đọc. Nhưng nó không thay thế được kho chia sẻ.)

Và so sánh hai engine của ElastiCache — điều quyết định lựa chọn cho yêu cầu "fault-tolerant": | | Redis | Memcached | |---|---|---| | Nhân bản, Multi-AZ failover | ✅ | ❌ | | Lưu bền (snapshot, AOF) | ✅ | ❌ | | Mã hoá | ✅ | ❌ | | Cấu trúc dữ liệu | hash, list, set, sorted set | chỉ chuỗi |

Đáp án

C — Tải lên bằng Amazon S3 Transfer Acceleration.

Vì sao đúng

Đề nêu đúng vấn đề mà Transfer Acceleration sinh ra để giải: tải lên S3 từ nhiều văn phòng khắp thế giới, và độ trễ đang làm chậm quá trình.

Cách nó hoạt động: thay vì gửi dữ liệu thẳng qua Internet công khai tới Region đích, client tải lên edge location gần nhất, rồi dữ liệu đi tiếp qua mạng backbone riêng của AWS:

Trước: Văn phòng ở London ──Internet công khai (chậm, nhiều chặng)──→ S3 ở Singapore

Sau:   Văn phòng ở London ──ngắn──→ Edge London ──backbone AWS──→ S3 ở Singapore

Bật chỉ là một lời gọi, và không cần đổi kiến trúc gì:

aws s3api put-bucket-accelerate-configuration \
  --bucket kho-du-lieu --accelerate-configuration Status=Enabled

Rồi client đổi sang endpoint tăng tốc:

Thường:   kho-du-lieu.s3.ap-southeast-1.amazonaws.com
Tăng tốc: kho-du-lieu.s3-accelerate.amazonaws.com

Đây là lý do nó là cách ĐƠN GIẢN NHẤT: một thiết lập, một thay đổi endpoint, không thêm hạ tầng nào.

AWS còn có công cụ so sánh tốc độ để đo trước khi quyết định — vì hiệu quả phụ thuộc khoảng cách và chất lượng đường truyền:

https://s3-accelerate-speedtest.s3-accelerate.amazonaws.com/en/accelerate-speed-comparsion.html

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

• B. Tải lên bucket địa phương ở mỗi Region rồi bật Cross-Region Replication — chạy được nhưng phức tạp và tốn kém hơn nhiều: bạn phải tạo và quản lý nhiều bucket, trả chi phí lưu trữ nhân đôi, và CRR có độ trễ nên job phân tích vẫn phải chờ. Ngoài ra bạn phải tự lo việc client biết bucket nào là "địa phương" của mình.
• D. Tải lên CloudFront rồi tải xuống từ cache về S3 — hiểu sai chiều hoạt động của CloudFront: nó là CDN phân phối nội dung ĐI RA, không phải cơ chế nhận tải lên rồi chuyển tiếp. (CloudFront có hỗ trợ PUT/POST tới origin, nhưng đó không phải "tải xuống từ cache về S3" như phương án mô tả.)
• A. Tải lên qua kết nối VPN được quản lý — VPN không tăng tốc gì: nó vẫn đi qua Internet công khai, chỉ thêm mã hoá và thêm chi phí xử lý. Nó dùng để kết nối riêng tư, không phải để tăng tốc.

Ghi nhớ

Phân biệt hai dịch vụ dùng chung hạ tầng edge nhưng ngược chiều nhau: | | Transfer Acceleration | CloudFront | |---|---|---| | Tối ưu cho | TẢI LÊN từ xa | TẢI XUỐNG, nhiều người xem | | Cache | ❌ | ✅ | | Dùng khi | upload tệp lớn xuyên lục địa | phân phối nội dung |

Nhận dạng nhanh:

• "upload from around the world", "upload latency" ⇒ Transfer Acceleration
• "global users", "improve download performance" ⇒ CloudFront
• "disaster recovery", "data residency" ⇒ Cross-Region Replication

Vài đặc điểm của Transfer Acceleration: | Đặc điểm | Chi tiết | |---|---| | Điều kiện | tên bucket không được chứa dấu chấm | | Chi phí | có phí thêm mỗi GB | | Hiệu quả | càng xa càng rõ; gần Region thì gần như không đổi | | Tương thích | dùng được với multipart upload |

Điểm cuối quan trọng: với tệp rất lớn, kết hợp Transfer Acceleration với multipart upload cho hiệu quả tốt nhất — nhiều phần được tải song song, mỗi phần đi qua đường tăng tốc.

Và nếu dữ liệu quá lớn (hàng chục terabyte trở lên) hoặc đường truyền quá kém, cân nhắc AWS Snowball — chuyển dữ liệu bằng thiết bị vật lý, đôi khi nhanh hơn mọi cách qua mạng.