AWS Study Group

Kiến trúc để mở rộng quy mô với private integrations của API Gateway

bởi James Beswick | ngày 26 tháng 9 2023 | trong Amazon API Gateway, Serverless | Permalink |  Chia sẻ

Bài viết này viết bởi Lior Sadan, Sr. Solutions Architect, and Anandprasanna Gaitonde,
Sr. Solutions Architect.

Các tổ chức sử dụng Amazon API Gateway để xây dựng API an toàn và mạnh mẽ nhằm cung cấp các dịch vụ cho những ứng dụng khác và các người dùng bên ngoài. Khi môi trường phát triển thành nhiều microservices, khách hàng phải chắc rằng tầng API có thể xử lý việc mở rộng mà không ảnh hưởng tới vấn đề bảo mật và hiệu năng. API Gateway cung cấp nhiều loại API và tùy chọn tích hợp, và các nhà phát triển phải xem xét xem mỗi loại API sẽ ảnh hưởng tới khả năng mở rộng của API layer một cách an toàn và hiệu quả như thế nào khi môi trường microservices mở rộng.

Bài viết này so sánh những lựa chọn về kiến trúc cho việc xây dựng API để có khả năng mở rộng, private integration cho microservices. Nó bao gồm các REST API, HTTP API và việc sử dụng các private integrations của chúng, và chỉ ra cách phát triển các kiến trúc microservices an toàn, có khả năng mở rộng.

Tổng quan

Đây là một phương án tiêu biểu trong việc triển khai API Gateway với tích hợp backend vào  nhiều microservices:

API Gateway xử lý lớp API, đồng thời liên kết với backend microservice chạy trên Amazon EC2, Amazon Elastic Container Service (ECS), hay Amazon Elastic Kubernetes Service (EKS). Bài viết này tập trung vào đóng gói microservices nhằm hiển thị các internal endpoint mà lớp API sau này hiển thị ra bên ngoài.

Để giữ cho các microservice an toàn và được bảo vệ với các truy cập từ bên ngoài, chúng thông thường được triển khai bên trong một mạng con riêng biệt (private subnet) với Amazon Virtual Private Cloud (VPC) – khiến nó không thể truy cập trực tiếp từ internet. API Gateway cung cấp một phương pháp để hiển thị những tài nguyên một cách an toàn bên ngoài VPC thông qua private integrations sử dụng VPC link. Private integration chuyển tiếp lưu lượng truy cập từ bên ngoài được gửi đến API đến tài nguyên private, mà các dịch vụ không thể nhìn thấy từ internet và không thể ra khỏi AWS network. Để biết thêm thông tin, hãy đọc Các Best practices để Thiết kế API riêng và Private integrations của Amazon API Gateway. 

Tình huống ví dụ có bốn microservice có thể được lưu trữ trên một hoặc nhiều VPC. Nó cho thấy các mẫu tích hợp các microservice với bộ cân bằng tải front-end và API Gateway thông qua các VPC link.

Mặc dù các VPC link cho phép kết nối riêng tư với các microservice, khách hàng có thể có thêm các nhu cầu:

  • Tăng mở rộng quy mô: Hỗ trợ một số lượng lớn microservice phía sau API Gateway.
  • Triển khai độc lập: Bộ cân bằng tải riêng cho mỗi microservice cho phép các nhóm thực hiện triển khai Blue/Green độc lập mà không ảnh hưởng đến các nhóm khác.
  • Giảm thiểu phức tạp: Khả năng sử dụng các bộ cân bằng tải microservice hiện có thay vì tìm hiểu thêm các bộ cân bằng tải khác để đạt được API Gateway intergration.
  • Độ trễ thấp: Đảm bảo độ trễ tối thiểu trong luồng request/response của API.

API Gateway cung cấp các HTTP API và REST API (xem Chọn giữa REST API và HTTP API) để xây dựng các RESTful APIs. Đối với kiến trúc microservice lớn, loại API ảnh hưởng đến các cân nhắc trong việc tích hợp:

VPC link đã hỗ trợ tích hợp vớiĐịnh mức VPC link trên mỗi tài khoản trên mỗi Khu vực
REST APINetwork Load Balancer (NLB)20
HTTP APINetwork Load Balancer (NLB), Application Load Balancer (ALB), and AWS Cloud Map10

Bài đăng này trình bày bốn tùy chọn private integration có tính đến các khả năng và hạn ngạch khác nhau của VPC link cho API REST và HTTP:

  • Phương án 1: HTTP API sử dụng VPC link tới nhiều NLB hoặc ALB.
  • Phương án 2: REST API sử dụng nhiều VPC link.
  • Phương án 3: REST API sử dụng VPC link với NLB.
  • Phương án 4: REST API sử dụng VPC link với các mục tiêu NLB và ALB.

Phương án 1: HTTP API sử dụng VPC link tới nhiều NLB hoặc ALB

HTTP API cho phép kết nối một VPC link duy nhất với nhiều ALB, NLB hoặc các tài nguyên được đăng ký với dịch vụ AWS Cloud Map. Điều này cung cấp tiếp cận phân tán để kết nối với nhiều backend microservice. Tuy nhiên, các bộ cân bằng tải được tích hợp với một VPC link nhất định phải nằm trong cùng một VPC.

Hai microservice nằm trong cùng một VPC, mỗi microservice có riêng một ALB chuyên dụng. ALB listener sẽ định hướng lưu lượng truy cập HTTPS đến target group của backend microservice tương ứng. Một VPC link duy nhất được kết nối với hai ALB trong VPC đó. API Gateway sử dụng các quy tắc định tuyến dựa trên đường dẫn để chuyển tiếp các yêu cầu đến bộ cân bằng tải và microservice thích hợp. Cách tiếp cận này được đề cập trong Các best practices để thiết kế API riêng và tích hợp riêng của Amazon API Gateway – HTTP API. Các Sample CloudFormation template dùng để triển khai giải pháp này có sẵn trên GitHub.

Bạn có thể thêm các ALB và microservice trong giới hạn IP của VPC. Sử dụng Network Address Usage (NAU) để thiết kế phân bổ microservices trên các VPC. Mở rộng quy mô ra ngoài của một VPC bằng cách thêm các VPC link để kết nối nhiều VPC hơn, trong phạm vi giới hạn của VPC link. Bạn có thể mở rộng thêm bằng cách sử dụng các quy tắc định tuyến như định tuyến dựa trên đường dẫn (path-based) tại ALB để kết nối thêm nhiều dịch vụ phía sau một ALB (xem  Quotas cho Application Load Balancer của bạn). Kiến trúc này cũng có thể được xây dựng bằng cách sử dụng NLB.

Ưu điểm:

  • Khả năng mở rộng cao. Phân tán đến nhiều microservices sử dụng một VPC link và/hoặc khả năng multiplexing của ALB/NLB.
  • Tích hợp trực tiếp với bộ cân bằng tải của các microservices hiện có giúp loại bỏ nhu cầu tìm hiểu các thành phần mới và giảm thiểu gánh nặng vận hành.
  • Độ trễ thấp hơn cho request/response API nhờ tích hợp trực tiếp.
  • Bộ cân bằng tải dành riêng cho mỗi microservice cho phép triển khai độc lập cho các nhóm microservices.

Phương án 2: REST API sử dụng nhiều VPC links

Đối với các REST API, kiến trúc hỗ trợ nhiều microservice có thể khác nhau do những điểm cần lưu ý sau:

  • NLB là private integration chỉ hỗ trợ duy nhất cho REST API.
  • Kết nối VPC cho REST API chỉ có thể có một NLB đích.

Mỗi NLB cần một VPC link riêng, ngay cả khi các NLB nằm trong cùng một VPC. Mỗi NLB phục vụ một microservice, với một listener để định tuyến lưu lượng truy cập API Gateway đến target group. Định tuyến dựa trên đường dẫn của API Gateway sẽ gửi các yêu cầu đến NLB phù hợp và microservice tương ứng. Thiết lập cần thiết cho private integration này tương tự như ví dụ được mô tả trong Hướng dẫn: Xây dựng REST API với API Gateway private integration.

Để mở rộng quy mô hơn, hãy thêm VPC link và tích hợp NLB bổ sung cho mỗi microservice, có thể cùng hoặc khác VPC dựa trên nhu cầu và yêu cầu cô lập của bạn. Cách tiếp cận này bị giới hạn bởi hạn ngạch của các VPC link trên mỗi tài khoản trên mỗi Region.

Ưu điểm:

  • Một NLB trên request path giúp giảm thiểu phức tạp của hoạt động.
  • Các NLB riêng cho từng microservice cho phép triển khai microservice độc lập.
  • Không có thêm các hop trong request path của API dẫn đến độ trễ thấp hơn.

Lưu ý:

  • Giới hạn khả năng mở rộng do ánh xạ một-một giữa các kết nối VPC với NLB và microservice, bị giới hạn bởi hạn ngạch của các VPC link trên mỗi tài khoản trên mỗi Region.

Phương án 3: REST API sử dụng VPC link với NLB

Ánh xạ một-một giữa các VPC link với các NLB và các microservice trong phương án 2 bị giới hạn về khả năng mở rộng do giới hạn của VPC link. Một giải pháp thay thế là sử dụng nhiều microservices trên mỗi NLB.

Một NLB đơn có thể phục vụ nhiều microservice trong cùng một VPC bằng cách sử dụng nhiều listeners, mỗi listener trên một port riêng cho mỗi microservice. Ví dụ, NLB1 phục vụ hai microservice trong một VPC. NLB2 phục vụ hai microservice khác trong một VPC thứ hai. Với nhiều microservice trên một NLB, định tuyến được xác định cho REST API bằng cách chọn integration point cho một phương thức. Bạn định nghĩa từng dịch vụ bằng cách kết hợp việc chọn VPC link được tích hợp với một NLB cụ thể và một port cụ thể được gán cho mỗi microservice tại NLB Listener và được trỏ đến từ Endpoint URL.

Để mở rộng quy mô hơn nữa, hãy thêm các listener bổ sung vào NLB hiện có, giới hạn bởi Quotas cho Network Load Balancer của bạn. Trong trường hợp mỗi microservice có bộ cân bằng tải hoặc điểm truy cập riêng, chúng được cấu hình làm các target cho NLB. Ngoài ra, hãy tích hợp các microservice bổ sung bằng cách thêm các VPC link bổ sung.

Lợi ích:

  • Khả năng mở rộng lớn hơn – giới hạn bởi quotas listener của NLB và VPC link.
  • Quản lý ít NLB dùng hỗ trợ nhiều microservice hơn giúp giảm thiểu phức tạp vận hành.
  • Độ trễ thấp với mỗi NLB đơn trên request path.

Lưu ý:

  • Cấu hình chia sẻ NLB giới hạn các triển khai độc lập cho các nhóm microservice riêng lẻ.

Phương án 4: REST API với VPC link với NLB và ALB targets

Khách hàng thường xây dựng các microservice với ALB làm điểm truy cập chính. Để truyền tải các microservice này thông qua API Gateway REST API, bạn có thể tận dụng ALB làm target cho NLB. Kiến trúc này cũng cho phép hỗ trợ nhiều microservice hơn so với kiến trúc ở phương án 3.

Một VPC link (VPCLink1) được tạo với NLB1 trong VPC1. ALB1 và ALB2 đóng vai trò front-end cho các microservice mS1 và mS2, được thêm làm mục tiêu của NLB trên các listener riêng biệt. VPC2 có cấu hình tương tự. Nhu cầu phân tách và IP space của bạn sẽ quyết định xem các microservice có thể nằm trong một hoặc nhiều VPC.

Để mở rộng quy mô hơn nữa:

  • Tạo các VPC link bổ sung để tích hợp các NLB mới.
  • Thêm listeners NLB để hỗ trợ thêm các ALB target.
  • Cấu hình ALB với các quy tắc dựa trên đường dẫn để định tuyến yêu cầu đến nhiều microservices.

Lợi ích:

  • Khả năng mở rộng cao khi tích hợp các dịch vụ sử dụng NLB và ALB.
  • Các nhóm có thể triển khai độc lập khi mỗi ALB được dành riêng cho một microservice.

Lưu ý:

  • Sử dụng nhiều bộ cân bằng tải trên request path có thể làm tăng độ trễ.

Lưu ý và best practices

Ngoài các cân nhắc về mở rộng quy mô với tích hợp VPC link được thảo luận trong bài viết này, còn có một số điểm khác cần lưu ý:

Kết luận

Bài viết này hướng dẫn xây dựng tích hợp API Gateway với khả năng mở rộng cho các microservice sử dụng VPC link. VPC Link cho phép chuyển tiếp lưu lượng truy cập từ bên ngoài đến các microservice phía sau mà không cần để lộ chúng ra internet hoặc rời khỏi mạng AWS. Bài viết đề cập đến các cân nhắc về mở rộng quy mô dựa trên việc sử dụng REST API so với HTTP API và cách chúng tích hợp với NLB hoặc ALB trên các VPC khác nhau.

Mặc dù việc lựa chọn loại API và bộ cân bằng tải còn phụ thuộc vào các yếu tố thiết kế khác, nhưng việc lưu ý đến các cân nhắc về mở rộng quy mô được thảo luận trong bài viết này là rất quan trọng khi thiết kế kiến trúc lớp API của bạn. Bằng cách tối ưu hóa triển khai API Gateway cho hiệu suất, độ trễ và nhu cầu vận hành, bạn có thể xây dựng một API mạnh mẽ, an toàn để phơi bày các microservice ở quy mô lớn.

Để tìm hiểu thêm về các tài nguyên học hỏi serverless, hãy truy cập Serverless Land.

TAGS: contributed, serverless

←
→

Leave a comment