learnit

Thiết kế ứng dụng Serverless

5 phút đọcSeries: NoteBook: AWS Certified Solutions Architect Associate SAA-C031 lượt xem

MyTodoList

Yêu cầu

Chúng tôi muốn tạo một ứng dụng di động với các yêu cầu sau:

  1. Expose REST API qua HTTPS
  2. Serverless architecture
  3. Người dùng có thể tương tác trực tiếp với thư mục riêng của họ trong S3
  4. Người dùng xác thực thông qua serverless service
  5. Người dùng có thể ghi và đọc các công việc cần làm (to-dos), nhưng chủ yếu là đọc
  6. Cơ sở dữ liệu cần có khả năng mở rộng và hỗ trợ thông lượng đọc cao

Cung cấp quyền truy cập trực tiếp từ mobile app đến Amazon S3

  1. Người dùng đăng nhập qua Cognito → nhận token + tạm thời được cấp quyền IAM.
  2. Mobile app sử dụng quyền này để:
    1. Gọi trực tiếp tới Amazon S3 để lưu/truy xuất file.
    2. Gửi request đến API Gateway để thao tác logic (quản lý to-do).
  3. API Gateway → gọi Lambda function, xử lý business logic và tương tác với DynamoDB.
  4. DynamoDB lưu to-do, phản hồi lại client.

Caching API Gateway

Tăng hiệu suất hệ thống thông qua việc cache các phản hồi tại Amazon API Gateway và tăng tốc độ truy vấn DynamoDB bằng DAX (DynamoDB Accelerator).

  1. Mobile client → đăng nhập qua Cognito
  2. Sau xác thực, client → gửi request GET /todos tới API Gateway
  3. API Gateway:
    1. Kiểm tra cache nội bộ
    2. Nếu cache hit → trả về
    3. Nếu cache miss:
      1. Gọi Lambda
      2. Lambda → query DAX → DAX → DynamoDB nếu cần
      3. Trả về kết quả → lưu cache tại API Gateway

Tổng kết

  • Serverless REST API: sử dụng HTTPS, API Gateway, Lambda, DynamoDB
  • Sử dụng Cognito để tạo các credentials tạm thời nhằm truy cập vào S3 bucket với chính sách giới hạn (restricted policy).
    → Người dùng ứng dụng có thể truy cập trực tiếp vào tài nguyên AWS theo cách này.
    → Mô hình này có thể áp dụng tương tự với DynamoDB, Lambda, v.v.
  • Cache dữ liệu đọc (read) từ DynamoDB bằng cách sử dụng DAX
  • Cache các request REST tại lớp API Gateway
  • Thiết lập bảo mật xác thực và phân quyền (authentication & authorization) thông qua Cognito

MyBlog.com

Yêu cầu

  • Website này cần có khả năng scale global.
  • Các bài viết blog ít khi được tạo mới, nhưng lại được đọc thường xuyên.
  • Một phần nội dung website là tệp tĩnh (purely static files), phần còn lại là REST API động (dynamic REST API).
  • Caching cần được triển khai ở bất kỳ nơi nào có thể.
  • Khi có người dùng mới đăng ký, hệ thống cần gửi email chào mừng (welcome email).
  • Khi người dùng upload ảnh lên blog, hệ thống cần tự động tạo ảnh thumbnail cho ảnh đó.

Triển khai phân phối static content, globally, securely

  1. Client request
    1. Người dùng (client) mở trang web, yêu cầu một nội dung tĩnh (HTML, CSS, JS, ảnh, v.v.).
  2. CloudFront Edge Location
    1. Request được định tuyến đến edge location gần nhất (CDN).
    2. Nếu nội dung đã được cache, CloudFront trả về ngay → giảm thời gian phản hồi.
    3. Nếu cache hết hạn hoặc chưa có, CloudFront tiếp tục truy xuất bản gốc từ backend.
  3. CloudFront gửi request về origin (S3)
    1. CloudFront sử dụng OAC (Origin Access Control) để đại diện truy cập vào Amazon S3.
    2. CloudFront gửi request đến bucket S3 chứa nội dung gốc.
  4. Amazon S3 kiểm tra Bucket Policy
    1. S3 chỉ cho phép các request đến từ CloudFront dựa trên aws:SourceArn (OAC).
    2. Từ chối toàn bộ các request không đến từ CloudFront → chặn truy cập trực tiếp qua public URL.
  5. Phản hồi về Client
    1. Sau khi lấy nội dung từ S3, CloudFront:
    2. Cache lại nội dung tại edge location.
    3. Trả nội dung về client.

Hỗ trợ REST API

  1. Client gửi request (REST HTTPS) đến một endpoint API (được phân phối qua CloudFront).
    1. Nếu nội dung cần là tĩnh (HTML, JS, CSS), CloudFront trả về từ Amazon S3.
    2. Nếu request là API call (dạng /api/xyz), CloudFront route xuống API Gateway.
  2. Amazon API Gateway nhận request API từ client:
    1. Đây là entry point chính cho toàn bộ các request dạng động.
    2. Gateway chịu trách nhiệm xác thực (nếu bật), logging, throttling, routing đến backend phù hợp.
  3. API Gateway invoke AWS Lambda function:
    1. Tại đây, Lambda đảm nhận việc xử lý logic nghiệp vụ.
    2. Có thể là thao tác xử lý dữ liệu, transform dữ liệu đầu vào, tạo response trả về.
  4. Lambda truy vấn dữ liệu thông qua DAX (DynamoDB Accelerator):
    1. DAX là lớp cache nằm trước DynamoDB, giúp giảm độ trễ (latency) của các truy vấn lặp lại.
    2. Nếu key đã có trong DAX → trả dữ liệu ngay (cache hit).
    3. Nếu chưa có (cache miss) → DAX sẽ truy vấn DynamoDB thay cho Lambda.
  5. DynamoDB lưu trữ dữ liệu:
    1. Đây là database NoSQL dùng để lưu trữ mọi thông tin liên quan.
    2. Khi dữ liệu được truy vấn hoặc ghi mới → DAX có thể được cập nhật tương ứng.
  6. Lambda tạo response và trả ngược lại:
    1. Kết quả từ DynamoDB hoặc DAX được xử lý trong Lambda.
    2. Lambda trả response về API Gateway → gửi trả về client qua HTTPS.

Ngoài ra có thể tận dụng DynamoDB Global Table

User Welcome Email

  1. DynamoDB ➝ DynamoDB Stream
    Khi một bản ghi mới (ví dụ: user đăng ký) được ghi vào bảng DynamoDB, DynamoDB Stream sẽ ghi nhận sự thay đổi này.
  2. DynamoDB Stream ➝ AWS Lambda
    DynamoDB Stream tự động invoke một Lambda function, truyền payload chứa dữ liệu thay đổi (INSERT, MODIFY, REMOVE).
  3. AWS Lambda ➝ Amazon Simple Email Service (SES)
    Lambda function xử lý payload (ví dụ: lấy email của user mới), sau đó sử dụng AWS SDK để gọi đến Amazon SES nhằm gửi email welcome.
  4. IAM Role cấp quyền gửi email
    Lambda sử dụng một IAM Role đã được cấp quyền ses:SendEmail, cho phép gửi email thông qua SES.
Bạn thấy bài này thế nào?