更快更安全: 每個網站都應該升級到 HTTP/2

(本文 crossposting 於 ALPHACamp Blog)

如果說有一項技術可以讓你的網站瀏覽起來更快、更安全、SEO 加分，而且網站工程師不需要改 code 就可以全站使用。更重要的是，還不用額外花錢，天底下有這麼好的事情嗎？

話說 HTTP 通訊協定是全球資訊網(WWW)的基礎，是瀏覽器和網站伺服器之間的通訊協定。而 HTTP/2 是 HTTP/1.1 從 1999 年發布以來，十六年來的最重要的一次升級，這次升級的主要目的，就是為了改善瀏覽器的網頁下載速度(Page Load Time)。

眼見為憑，以下是一些測試網站，比較 HTTP/1.1 和 HTTP/2 的速度差異，這在圖多的情況最為明顯：

閱讀全文〈更快更安全: 每個網站都應該升級到 HTTP/2〉

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

今年 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 多到非常多

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

edX: Scalable Machine Learning 上課心得

延續 Introduction to Big Data with Spark 課程，紀錄 2015/7 月在 edx 的 Scalable Machine Learning 上課心得紀錄。

除了 Machine Learning 之外，有 1/3 的內容在強調跟講解 large scale 的情況跟需求，也就是 distributed algorithm。當資料很大、維度很大時，演算法只能用逼近解，不能用 closed-form 解會太慢。

閱讀全文〈edX: Scalable Machine Learning 上課心得〉

edx: Introduction to Big Data with Spark 上課心得

紀錄 2015/6-7 月間，在 edx 上 Introduction to Big Data with Spark 的上課心得紀錄。(竟然拖了一年才整理到 blog 上… XD)

這堂課著重在 Data Processing 部分，特別是熟悉 map reduce 技能。除了看錄影之外，精華其實在 lab 實作，透過作業走過 Big data 的重要流程。

閱讀全文〈edx: Introduction to Big Data with Spark 上課心得〉

Coursera: 台大資工 Machine Learning 上課心得

整理記錄一下在 Coursera 修台大資工林軒田老師的機器學習課程心得，分成兩門課上下兩個學期。

2016年2月9日 21:12 UTC+08

拿到台大機器學習技法的證書啦 t.co/AwlAdFgkj0 #coursera # 努力了半年終於解開 Machine Learning 的成就，在技法課中實作了 SVM、AdaBoost、Decision Tree 和 NNet 演算法。

2015年12月28日 21:33 UTC+08

接連兩個機器學習作業實作出 AdaBoost 和 Decision Tree(CART) 及 Random forest (我用Ruby寫)，跟其他模型相比，難得不需要太多數學，感覺簡單多了 XD 另外發現 Python scikit-learn 的 Decision Tree 也是用 CART 演算法，所以也拿來測了一下自己寫的對不對，它還可以把決策樹匯出 Graphviz 圖真是太棒了。 接下來要進入類神經網路了。

2015年11月11日 0:02 UTC+08

交了 Coursera 台大機器學習基石最後一次作業，收穫頗豐，每次作業都寫好久。這堂課比較偏理論，上到第二次作業最理論的時候，差點就要放棄了，好險撐了下來後面講 overfitting 的部分我認為是這堂課最精彩的部分。為什麼做 feature transform 和 regularation，如何用 validation 等等，理論貫穿前後。這些其實之前在修 edX Spark ML 課的時候，也有照著用這些技巧，但是都不知道為什麼，現在知道理論之後超有感覺。 接著就是機器學習技法了，感覺又是一整個超難，SVM 我來了!