Study Notes - Amazon API Gateway

整理研究 AWS 產品 Amazon API Gateway 的心得筆記，相關的基礎概念、架構考量，請參閱：Overview API Gateway

Amazon API Gateway

Amazon API Gateway 從 Overview 的 應用場景 提到的可視性與 Key Features 來看，可以滿足大部分。以下先整理結論：基本功能、不足的地方。

因為 API Gateway 是泛用名詞，市面上流行的實作很多，像是 Kong、Apiee、Tyk … 等。我的文章中提及 AWS 的 API Gateway 我會使用官方名稱：Amazon API Gateway 稱呼，避免名詞誤解。

功能

Amazon API Gateway 是 AWS Managed Service，功能非常多、且完整，底下整理各個面向的功能：

  • 彈性的整合 AWS 很多服務，像是：
    • Serverless: 最常見的是整合 Lambda
    • 內部串接：透過 VPC Links -> NLB -> EC2，可以整合 VPC 內部 EC2 的服務
    • 外部串接：當作 HTTP Proxy ，可以轉導到外部
    • 只要是 API 形式的都可以串接，AWS Services 都有 Endpoint，換言之，都可以很輕易的串接
  • API 定義 / 開發 / 測試
    • 支援資料結構轉換 (Transformation)，像是把 JSON 轉換成 XML，詳細使用案例 Q8 描述。
    • 支援資料模型定義，例如 HTTP 500 的 return data model
    • 支援類似 wildcard 的 resource 定義，寫法像這樣: {resourceName+}
    • 可以產生 Client SDK，支援各大語言
    • 支援 Stage 概念，提供不同環境需求，像是測試、正式 …
    • 支援 Export / Import swagger 格式
    • 支援文件管理
  • 安全與認證：
    • 支援客製化認證機制，可以透過 Lambda 或者直接使用 Cognito.
      • 分成 token, request 兩種認證方式
      • 有 Cache / TTL 機制。
    • 支援客製化 DNS + ACM (SSL) + CloudFront 整合，但是注意 ACM 要在 us-east-1 申請
    • 支援 CORS (cross-origin resource sharing)
    • 支援 IAM 認證
    • 支援 URL Query String, Header, Body Validation
    • 支援 Resource Policy，可以透過 IAM 控管 IP 來源
  • Infra / Network
    • 整合 CloudFront (CDN)，但是無法設定 CloudFront 參數
    • 支援 Edge or Regional CDN
    • 可以透過 VPC Links 存取 VPC 內部服務，實作是透過 NLB -> Target Group -> EC2
    • 支援 Resource Policy，可以透過 IAM Policy 控管權限、安全 (e.g., 限制特定 SourceIp)
  • Operation
    • Usage Plan
      • 每個 Usage Plan 都可以綁定多個 API Stage，各別定義 Rate Limit, Burst, Quota
      • 多把 API Key 整合與管理, 有簡單的使用統計 (真的很簡單)
      • 支援大量 API Key Import
    • 整合 CloudWatch Logs 與自訂 Log 格式
    • 支援 Cache (另外計費)
    • 支援 Canary Deployment
    • 有簡單的 Dashboard

一些想到的問題

整理一些我想到、遇到的問題，有一些可以在 Amazon API Gateway FAQ 找到。

Q1: 內部服務對串，可以用 Amazon API Gateway？

Q2: API Gateway 支援防火牆？

  1. 網路層目前沒有，只能夠過應用層管控，像是 API Key、Authorizer、IAM Policy
  2. 另外可以使用 Resource Policies，透過 IAM Policy 管控 SourceIp。 2018/04/02 Announce

Q3: Usage Plan 上限只有 300 不夠怎麼辦？

這是 Soft limit，發 ticket 調整。

Q4: 可以整合 WAF？

建立 Regional Rest API，然後在前面放一個 CloudFront 就可以使用 WAF, see: placing Cloudfront in front of API Gateway

Q5: 部署如果發現有問題，可以 Rollback?

可以，Stage 中的 Deployment 都有 History.

Q6: 如果請求數目超過 Rate Limit 會怎樣？

會收到 HTTP 429 的回應。詳細參閱 Rate Limit and Throttling 的說明。

Q7: 為什麼要有 Throttling, Rate Limit？

Q8: 整合到 Amazon API Gateway 之後，可不可以處理既有 API Service 的 Response 資料結構？例如原本回傳的是 XML，想改成 JSON？

可以，進出 (Request / Response) 都可以。例如原本後端服務只能處理 XML，但是希望讓客戶使用 JSON。可以透過 Integration Request / Integration Response 的 Body Mapping Template 重新處理資料結構，把 JSON 轉換成 XML，Client 使用 JSON，後端服務同樣處理 XML。Body Mapping Template 裡夠過 Apache Velocity Template Language (VTL) 重新 Format 資料結構。

Q9: 什麼情境需要使用 API Gateway?

我遇到的和想到以下：

  1. 既有的 API，沒有資安保護機制，像是 Rate Limit 的機制，被爬蟲機器人打的嫑嫑的 ….
  2. 新舊服務轉換過程中，需要有權限管控，例如，只允許某一把 Key 只能存取特定 Rest API
  3. 既有 API 資料結構要做轉換，如 Q8 提到的案例
  4. 需要知道 API 的使用狀況

Q10: 團隊裡怎麼導入 API Gateway?

我的方法：

  1. 先找一些 Side Project，像是整合 Slack 通知，整合 Mobile APP 測試的通知，確認自己能夠掌握 API Gateway
  2. 扎實的掌握 API Gateway 相關的技術與實踐方法，同時找人分享，把好東西傳出去
  3. Q9 的問題早晚會遇到的，具體使用 API Gateway 解決問題。

Q11: 可以知道每個 api-key or 每個 Rest API 的使用狀況？

  • api-key 要透過 CloudWatch Log 分析，然後產生對應的 Metric。可以做到，但是要花一點功，請參考 Study Notes - CloudWatch 的說明
  • 每個 Rest API 同樣可以在 CloudWatch Metric 查看使用狀況，同時也可知道每個 stage 的分佈

Q12: 可以管控每個 Rest API 的 Rate Limit?

可以，在 stage，可以個別展開 Rest API，然後配置各個 Rate Limit, Throttle 的數字。但是不能超過 Per Region 的上限，預設為 10,000，詳細參閱： Rate Limit and Throttling

相關 AWS Services

Amazon API Gateway 要有其他 AWS Services 基本概念，我分成必要性、選擇性和整合性三大類：

  • 必要：使用 API Gateway 一定會遇到
  • 選擇性：
  • 整合性：
    • 他可以串接 AWS 大部分的 Services
    • 當作 Proxy 使用

學習筆記

接下來陸續整理 Amazon API Gateway 實際上應用的筆記，以下是目前想到的課題：

東西有點多，有空就陸續整理。

不足與潛在需求 (許願池)

等下整理在 Study 過程中，發現的問題。

  • Infra / Security / Network
    • 目前沒有純的 Internal API Gateway，所以內部服務對串要自己蓋。
    • 沒有辦法整合 WAF，但是有變通方式，例如在 API Gateway 前面再放一個 CloudFront, see: placing Cloudfront in front of API Gateway 用 Regional Rest API 即可
    • (Regional Rest API + CloudFront) 可以達到 Custom Domain Names + CloudFront 的效果，但是彈性不佳，期望可以設定 CloudFront in API Gateway
    • Updated 2018/11/19: Amazon API Gateway adds support for AWS WAF
  • Functions
    • API Key 的使用率管理功能太陽春，只能顯示一天的用量。現在要透過 CloudWatch Logs 自己幹。
    • API Key 不支援 Expiration 功能
    • AWS CLI Import swagger 不能指定 Rest API id，會建一個新的，但是 Console 可以
    • Integration timeout: 29s 是 hard limit …
    • Payload Size: 10 MB 是 hard limit …
  • Operation
    • Health Check
  • Skill Stack
    • 使用 Amazon API Gateway 最好連同相關 AWS Services 也要略知一二，像是 VPC、NLB、Lambda、CloudWatch …

老問題：被綁死還是自幹？

這個問題我在 Survey Monitoring System 的時候糾結了快兩年，最後在 Study Notes - CloudWatch 找到答案。而 Cloud Native 的時代來臨，與其擔心被綁死，倒不如好好的 面對它、學習它、駕馭它、活用它，如果真的要換，概念應該都是通用的，要跳也很快。

這跟以前在買吉他效果器是一樣的問題，與其去質疑設備本身好不好，倒不如質疑自己能否 面對它、學習它、駕馭它、活用它。後來設備的採購我都是先 Ｋ 完手冊之後，把裡面不懂的東西都搞懂了之後，才真的去採購。底下是當時的心得：

當然，不練琴，手指頭、腦袋跟不上，再好的設備，都只是很貴的裝飾品。

挑戰

Amazon API Gateway 看起來很完整，功能強大，但是導入新技術總是會面臨一些問題：

  • 團隊
    • 如何讓上層知道 API Gateway 是啥？如何說服團隊學習使用它？
    • 如何讓非技術背景的人了解他的用意
    • 如何教育訓練團隊
    • 開發流程
  • 技術面
    • 使用 API Gateway 的人，最好也懂 AWS 相關技術，特別是 CloudWatch、CloudFront、Lambda、IAM …
    • Amazon API Gateway 的 Console 不是很好用
    • Amazon API Gateway 除錯不易，一定要熟悉 CloudWatch Logs
    • 部署流程不佳：需要透過 CloudFormation 才容易，可是會 CloudFormation 的人屈指可數
    • 效能問題如何追蹤？
    • 部署流程、測試方法
    • 如何把這東西，放到既有的架構、系統，而不會造成額外的問題？

系列文章

一路上斷斷續續整理的一些實際應用與功能的學習筆記。

延伸閱讀

站內延伸

參考資料

API Gateway 新功能紀錄

  • 2019/06/20: Amazon API Gateway Adds Configurable Transport Layer Security Version for Custom Domains
  • 2019/06/04: Amazon API Gateway Now Supports VPC Endpoint Policies
  • 2019/05/23: Amazon API Gateway Now Supports Tag-Based Access Control and Tags on Additional Resources
  • 2019/01/02: Amazon API Gateway announces service level agreement
  • 2018/11/16: Amazon API Gateway Enables API Publishers to Deploy the Serverless Developer Portal from the AWS Serverless Application Repository
  • 2018/11/05: Amazon API Gateway Adds Support for AWS WAF
  • 2018/10/05: Amazon API Gateway adds support for multi-value parameters
  • 2018/09/27: Amazon API Gateway adds support for OpenAPI 3.0 API specification
  • 2018/09/06: Amazon API Gateway Adds Support for AWS X-Ray
  • 2018/07/14: Amazon API Gateway Increases API Limits
  • 2018/07/12: Amazon API Gateway Supports Request/Response Parameters and Status Overrides
  • 2018/07/11: Amazon API Gateway Usage Plans Now Support Method Level Throttling
  • 2018/06/14: Amazon API Gateway Supports Private APIs
  • 2018/04/03: Amazon API Gateway Supports Resource Policies for APIs
  • 2018/04/02: Amazon API Gateway Supports Cross-Account AWS Lambda Authorizers and Integrations
  • 2017/12/19: Amazon API Gateway Supports Tagging API Stages
  • 2017/12/19: Amazon API Gateway Supports Content Encoding for API Responses
  • 2017/12/19: Amazon API Gateway Supports API Keys in Custom Authorizer Responses
  • 2017/12/15: Amazon API Gateway Supports Amazon Cognito OAuth2 Scopes
  • 2017/11/30: Amazon API Gateway Supports Endpoint Integrations with Private VPCs
  • 2017/11/28: Amazon API Gateway Supports Canary Release Deployments
  • 2017/11/21: Customize Integration Timeouts in Amazon API Gateway
  • 2017/11/21: Amazon API Gateway Supports Access Logging

更新紀錄

  • 2018/11/24: Overview API Gateway 概念，解構成獨立文章，整理主要概念，本文保留 Amazon API Gateway 的介紹。

Comments

2018/01/24 14:35:00
Table of Content
Categories
Tags

About

  • 全站索引
  • 學習法則
  • 思考本質
  • 一些領悟
  • 分類哲學

    • 著作

  • 個人著作：SRE實踐與開發平台指南
  • 共同著作：軟體測試實務 (2023)
  • 譯著：分散式系統設計 (2019)

    • 演講

  • 演講錄影 @ Youtube
  • 探索職涯、複利人生 - AWS Career Exploration Day 2023
  • 個人著作 SRE 書友見面會
  • 軟體測試實務 - 新書發表會
  • 探索職涯、成就未來 - AWS Career Exploration Day 2022
  • 從理想、到現實的距離，開啟品味軟體測試之路
  • 91APP 在 AWS 上的 SRE 實踐之路
  • 在矩陣型組織裡，如何有效管理 AWS 的成本結構與系統架構
  • 災難演練 @ AWS 實戰分享
  • 導讀持續交付 2.0 - 談當代軟體交付之虛實融合
  • 聊聊軟體交付的濫觴 談產出物管理
  • 從緊急事件 談 SRE 應變能力的培養
  • 邁向 API 經濟 - API Gateway 導入之旅
  • Monitoring Tools 大亂鬥 - AWS CloudWatch
  • Ops as Code using Serverless
  • 淺談系統監控與 CloudWatch 的應用

    • Facebook

    Complete Think

    AWS Certifications

  • 全站索引
  • 學習法則
  • 思考本質
  • 一些領悟
  • 分類哲學
    • ▲ TOP ▲