Architecting on AWS 筆記：Serverless

電商平台的 Serverless 架構

• serverless 是指使用者不用維護底層 server，例如 server 是起在 Fargate 上就可能為 serverless。
• 簡單的 serverless 架構，例如：上傳檔案 -> 觸發 Lambda 動作更新資料庫  -> …。

API Gateway

• API Gateway 提供對外的 endpoint 以供外界存取，是全託管的 API server。

API Gateway 簡單架構

• API Gateway + Lambda === ELB + EC2。
• 可以有 cache，cache 的 TTL 需要自行管理，預設不啟用。

Simple Queue Service (SQS)

• SQS 是批次處理，可避免 request 丟失，但也因此不會馬上拿到結果。
• 可當成 buffer，儲存暫時的資料。
• 是全託管的 queue service。
• 使用 SQS 的時機點
  • 不用馬上拿到結果。
  • 只能放文字，因此物件放 S3、字串放 SNS (注意訊息字串有大小限制)。
• 不用 ELB 或 ELB 無法做 queue 的處理。

SQS 的種類

• standard: 不保證處理的順序，也可能會重複回應訊息，意即 SQS server 有很多個，分散式處理，以確保不丟失任何訊息。
• fifo：保證處理的順序，不會重複回應訊息，常用於演唱會搶票。

Visibility Timeout

• visibility timeout 是指訊息被解鎖、其他 consumer 可處理的時間。
• 為了避免重複處理，因此訊息 A 在 consumer 處理時會鎖起來，處理好就回到 SQS server 刪掉已處理的訊息；若超過時間沒有回報處理進度，就會有其他 consumer 來解鎖再重新處理。

Dead-Letter Queue

• dead-letter queue 是指放置無法處理的訊息，因此不會丟失任何 request 並且方便 debug。
• dead-letter queue 是一個 SQS，可設定 max retry 次數，來決定會被丟到這個 error queue 的 threshold。

Simple Notification Service (SNS)

• SNS 專門用於發送訊息。
• 具有 Pub/Sub 機制，例如，Youtuber 上片檔頻道，Topic 是頻道，訂閱者訂閱頻道，會收到上片通知。

Fan-Out = SQS + SNS

用同一個事件來源，先暫存起來，再來由不同的 consumer 做不同的事情

SNS vs SQS

選用 SNS vs SQS 考量點，如下

• 需要即時收到回應？
  • Y：SNS
  • N：SQS
• 需要 buffer？
  • Y：SQS
  • N：SNS
• 訊息可以被丟失？
  • Y：SNS
  • N：SQS

Kinesis

Kinesis 是 realtime 串流服務，分為四種類型

• data streams：純串流、realtime、一定要經過 consumer 才能存到 S3。
• data firehose：經過資料處理 (convert process 轉格式、暫存 S3)，近乎 realtime，可以直接存到 S3。
• data analytics：複雜分析 (跑 sql)。
• video streames

Step Functions

• step functions 或稱 ASL，即是 state machine，定義各種狀態要呼叫的 lambda function，也就是可以組合一連串 lambda function。注意，不要在 lambda 裡面呼叫 lambda，這樣 debug 要看不同 lambda 的 error log，會導致過於複雜/麻煩。
• step function 架構範例：API gateway + step function or lambda 兩者皆可。