Categories
AWS

AWS User Group: 談 AWS 容器與 Serverless 最佳實踐 心得筆記

今年 2016/4/19 參加 AWS User Group in Taiwan Meetup #10 的心得紀錄。講者 Pahud 聽得出來對 AWS 非常熱情,而且非常實務地分享了 AWS ECSAWS Lambda 的各種適用情境。

  • old school 作法: ELB/ASG + 2 subsets + RDS mutil-AZ
    • challenges
    • ec2 instances 太花錢 for micro services (都要 x2 才能HA)
    • complexity in infrastructure (VPC, routing-table, NAT, NACL, security groups, ELB…etc)
    • complexity in A/B testing and B/G deployment
    • deploy
  • Want to have self-healing, auto-scaling, AZ-balancing, log consolidation, immutable and stateless architecture, cost optimisation and resource optimisation
    • 今天的主題: AWS ECS
  • ECS Cluster best practices
    • 用 ec2 組成一群機器
    • ASG on demand 註冊到 cluster
    • ASG spot instance 也註冊到 cluster
    • cloudwatch 用來監控這兩個 ASG
  • Auto scaling policy design
    • scale out spot on 30% ~ 60% (cpu usage?)
    • scale out on-demand when 60%
    • scale in on-demand when 60%
    • scale in spot when <= 30%
    • with minimal 1 on-demand or RI (reserved instance)
    • spot fleet 功能可以一次標多台 instances
  • 不要用 SSH 進去機器管理,讓 ECS 控管
  • ECS
    • 設定 web, app, worker 需要幾台 instance,就會自動開 instance,如果不夠就會開新的 (?)
    • internal ELB 功能可以對內做 balance,是對內 microservice 的 end-point
    • SQS 也可以用,分配到 instance 去執行
    • 用 cloudwatch 監控,並分不同維度,例如分 container
    • deployment and rolling update with revisions
    • consolidate logs: 不要用 Docker 的 logger driver,要用 AWS log。container 指定 log file 路徑就會收集到 cloudwatch
    • 可以推 docker image 到 ECR (讓開發、測試、Production 都從這裡拉docker image)
  • 如果 microservice 多到非常多

AWS lambda + AWS API Gateway

Cloud native 開發、event-driven cloud computing: 完全沒有 server 需要管理!

  • AWS API Gateway
    • 提供 REST 端點,去觸發 lambda
    • service proxy 功能無須寫 lambda,就可以存取操作 AWS 資源(用 IAM role)
    • 可以轉發到你自己的 EC2
    • 設定 API Gateway Cache (但不便宜)
    • 只能 https
  • 案例
    • S3 -> 縮圖
    • device -> kinesis -> 觸發 lambda -> 放 s3 或 dynamodb
    • dynamodb 每一筆更新 (stream) -> 觸發 lambda
    • AWS CloudTrail 可以 log AWS API 操作 log 進到 s3 -> lambda -> 觸發 SNS 通知
  • 手機和瀏覽器的 AWS SDK 就可以觸發 AWS Lambda (不需要 REST API 端點進 ELB)
    • 有 sync 也有 async 呼叫法
  • API Gateway call flow 會先經過 cloudfront (e.g. 台北)
    • 因為可以保證最佳路由到 API Gateway (e.g. 東京)
  • 認證可以用 HTTP header,加上一個自己寫的 lambda 去檢查自己的認證系統
  • API Gateway 比 lambda 貴。lambda 非常便宜。
  • cost comprising: requests 超過某個級別,是可能比 ec2 還貴。他的 cost 是線性的。
  • Lambda limit
    • soft limit: concurrency is 100 (要寫信給 AWS 如果要調高)
    • hard limit: 300s max duration per invocation
    • VPC restriction (lambda 可以訪問你內網的資源)
      • private IP addresses (用掉一個 private IP)
      • ENIC limit (用到一張虛擬網卡) 20*5=100 有限制 (一個 VPC subset 通常只能開 20 個 instances, ENIC 最多開五倍)
  • API Gateway
    • 500-1000 QPS per AWS Account
    • 5M requests/month = $18.79
    • 100 QPS = $974.07 / month 就貴了,自己開 ec2 寫code可能比較划算
    • No async or parallel invocation(同時平行呼叫多個 lambda) with Lambda
  • lambda 缺點
    • SNS -> Lambda 是 push invocation 效能極好
    • kinesis or dynamodb stream 是 pull invocation,效能慢跟不上
      • 解法: delegation,多開一個過水 lambda 調高 higher memory,抓到資料再另 innovate lambda 處理
    • no connection pooling
      • 內部 lambda sandbox 機器可能會保留20分鐘來 reuse
      • 因此連線的 code 要放 handler scope,不能放 header scope,不然 reuse 時會沒有被執行到
    • 只能用 cloudwatch 做 debugging,很痛苦,甚至會 delay 30s 才出來
    • deployment 工具還不成熟, 目前很多在開發中,例如 serverless
    • lack of PHP, ruby and golang
    • re-deploy the whole bundle 很苦。只改一點東西也需要整包 deploy,很慢
      • workaround: 先傳到 s3,然後另寫一個 lambda 做打包,部署主 lambda。這樣就可以只傳部份的更新 code 到 s3 即可。不用整包傳。

ECS or Lambda?

  • 用 ECS
    • financial concern: 如果 100QPS+,用 ECS 比較划算
    • operation concern: long running process (300s+) or API service 用 ECS
    • ECS for long process, lambda for short
    • language concern
    • performance concern: CPU 等
    • 特別的 protocol
  • Lambda + API gateway
    • small project, simple business logic
    • focus on code only
    • stateless
    • quick micro service
    • simple integrate with other AWS services

Serverless 應該會是接下來幾年 DevOps 的熱門題目,只是整場聽下來,雖然講者很熱情推薦,但我還是覺得似乎還不到進場的時機,坑多又沒有比較便宜啊… XD

Categories
AWS 日記

Systems Operations on AWS 課

這禮拜去參加 Systems Operations on AWS 課程,上課的範圍其實跟上次的 Architecting on AWS 很接近,重點跟細節程度有些差異,操作 Labs 更多有九個,而且不少是用 CLI 操作而非 Management Console。上課也比較注重操作細節,連投影片字也比較多… XD

第一天教 VPC 跟 EC2,Lab1 是操作設定 Public Subsnet+Private Subnet+IGW+NAT,不像上次的課用 Wizard 設定,這次需要一個一個設定進行操作。 Lab2 練習用 AWS command line (CLI) 開 ec2 機器。

第二天教 EBS, Tagging, Monitoring, Backup 等等。Lab3 用 CLI 操作 EBS Snapshot、EBS Prewarn、合併兩個 EBS 成更大的 Logical Volumn。Lab4 用 CLI 操作 Tagging。Lab5 設定 Custom Metric 到 CloudWatch,並設定 Custom Alerm (這可以用來搭配 Auto scaling)、練習整合 Auto scaling 和 3-party Monitoring 工具(當新增或移除機器時,會通知 Monitoring server)。Lab6 則是資料庫的 Backup&Restore,使用 EBS Snapshot 和 RDS 不同方式練習。這裡它特別強調 Consistent snapshots 的概念,需要 pause write 和 flush to disk 並鎖住 DB 才作 Snapshot。Lab 7 是一個用 CLI 抓 RDS 重設密碼事件的小練習。

這一天最大的收穫應該是了解 CloudWatch 可以做 Custom Metric,以來它可以用來搭配 Auto Scaling 使用,以及如何整合 3-party monitoring 工具。

第三天教 Log 管理(因應 Auto Scaling,所以 Logs 有集中管理的需求)、Auto Scaling 跟 Cost 管理。Lab 8 練習設定 Logrotate 把 logs 傳到 s3,以及在 Auto Scaling 的情況下,記得關機前傳 log。Lab 9 練習建立一個 Auto Scaling 環境,也是一樣有一個做好的 PHP 會模擬操 CPU,然後就 scaling 自動開機器。這個練習跟上次上課的很像。最後還有一個不是 Lab 的練習是分析一個 Cost 成本 Excel 表。

對了,我會建議上課記得帶個平板 iPad,他的講義有 App 可以離線閱讀。這樣 Lab 操作時就可以邊看邊操作。

Categories
AWS 日記

Architecting on AWS 課

這禮拜去上了三天的 Architecting on AWSTraining 課。查了一下這課在美國要收 USD $1,800,不知道為什麼台灣這麼好是免費的,佛心。

講師是個印度人,英文口音一開始有點不太習慣,不過反正跟著投影片教材走,理解上不會有太大的困難。教材是要來上課現場才會開放讓你下載的,算是這課的精華所在吧。教材投影片包含了詳細的註解補充很不錯,Lab 教材則有一步一步的操作說明,照著作就可以完成練習。

第一天: 上架構原則跟安全知識,Lab 1 練習開 VPC 網路

第二天: 介紹 IAM,Lab 2 練習設定 IAM。接著介紹 Route 53, ELB, CloudFront, CloudWatch, Elastic Beantalk 跟 CloudFormation。介紹 Auto scaling 的觀念跟 Pattern、如何 bootstrapping ec2 instances、Storage scaling (EBS,S3…etc) 的策略跟使用情境。最後是 Lab 3 設定一個 Auto scaling 架構出來,它給了一個簡單的 web app 可以操CPU,然後自動開 EC2 instances 擴充上去。挺有意思。下課前分組討論一個模擬架構是跨 regions 的文件分享系統。

第三天: 介紹 Application services: SQS, SNS, SWF, SES, CloudSearch 等等、Cost 概念以及 HA(high availability) 跟 Disaster Recovery(DR) 概念跟策略,最後教如何說服老闆改用 Cloud 架構、如何寫搬家計畫等等。Lab 4 則是利用 SQS 跟 Auto scaling 設定一個 Batch Processing Cluster,它給了一個簡單的圖片處理 script 當作 worker instances,然後當 SQS 等待的訊息過多時,會自動開 ec2 instance 擴充上去,處理完的圖片丟上 S3,也是一個很有趣的練習。

內容雖然免不了有基本 AWS 功能介紹,不過有教一些架構策略跟 Lab 練習算是不錯的收穫。VPC 跟 auto scaling 我之前都是知道但沒實際操作過,這次跟著教材練習很快就完成了 :)

我還報名了兩週後的 Systems Operations on AWS 課,到時再來比較看看。

BTW,午餐是 Buffet 自助餐還不錯。

Categories
AWS DevOps

修改 AWS RDS 資料庫設定,以 max_allowed_packet 為例

記錄一下,以後肯定還會再用到。

因為 MySQL 預設的 max_allowed_packet 設定是 1M,對有些應用來說可能太小了。如果是自己架 MySQL 改 /etc/mysql/my.cnf 就是了,不過租用 Amazon RDS 就沒有這種事了。又它的 web console 也沒有提供介面可以改設定(parameters)除了可以用 AWS 的 web console 介面來改,也可以透過 Amazon RDS Command Line Toolkit 呼叫 API 來改,步驟如下:

  1. 下載 Amazon RDS Command Line Toolkit

  2. 參考 credential-file-path.template,編輯 credentials.txt 把 AWSAccessKeyId 和 AWSSecretKey 填上去

  3. 設定環境變數,例如:
    export AWS_RDS_HOME=/Users/ihower/RDSCli-1.12.001
    export JAVA_HOME=/System/Library/Frameworks/JavaVM.framework/Home
    export PATH=/Users/ihower/RDSCli-1.12.001/bin:$PATH
    export AWS_CREDENTIAL_FILE=$AWS_RDS_HOME/credentials.txt
    export EC2_REGION=ap-northeast-1

  4. chmod +x ${AWS_RDS_HOME}/bin/*

  5. rds-create-db-parameter-group <自定的parameters群組名稱> -d "群組描述" -f MySQL5.5 新增一個群組來放參數

  6. rds-modify-db-parameter-group <自定的parameters的群組名稱> -p "name=max_allowed_packet,value=2097152,method=immediate" 把參數放進你自定的群組裡 (這裡單位只能用bytes)

  7. rds-modify-db-instance <DB Instance Name> -g <自定的parameters群組名稱> 把群組綁到指定的 DB 上

  8. 這個設定似乎不需要 reboot 就生效了。要重開的話,在 web console 也可以 reboot。

完整的文件在 AWS Command Line Reference,例如


rds-describe-db-instances <DB Instance Name> 看這個 DB 套用了什麼 PARAMGRP 群組
rds-describe-db-parameters <自定的parameters的群組名稱> 看這個群組的 parameters