ihower { blogging }

今年 2016/4/19 參加 AWS User Group in Taiwan Meetup #10 的心得紀錄。講者 Pahud 聽得出來對 AWS 非常熱情，而且非常實務地分享了 AWS ECS 和 AWS 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 多到非常多
  • ELB -> ECS 不能動態 mapping port 端口(i.e. 80 port 到 container 的 80)
  • ELB -> ECS on random ports: workaround: 裝一個 golang 的服務
  • www.slideshare.net/JulienSIMON5/amazon-ecs-january-2016/02
  • Meteor Galaxy session-aware with random ports: 多一個 Proxy

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