AWS Auto Scaling 自動擴展(二)

延續上篇：AWS Auto Scaling 自動擴展(一)，auto scaling 除了可以根據 EC2 instance 狀態，或是 ELB 的健康狀況做擴展，還可以搭配 CloudWatch 使用，CloudWatch 可以 monitor 的狀態有更多了，CPU、disk I/O、network I/O。

Scale up

Create auto scaling policy

$ aws autoscaling put-scaling-policy \
--policy-name as-policy-scale-up \
--auto-scaling-group-name as-group \
--adjustment-type ChangeInCapacity \
--scaling-adjustment 1 \
--cooldown 300

{
    "ResponseMetadata": {
        "RequestId": "4411e437-9b6a-11e2-933c-010eb2f029e6"
    },
    "PolicyARN": "arn:aws:autoscaling:us-east-1:332100208493:scalingPolicy:c534dcbe-91c1-4714-907a-b4974bac7c57:autoScalingGroupName/as-group:policyName/as-policy-scale-up"
}

把 PolicyARN 記下來，下一步會用到

Create cloud watch to monitor the CPU utilization
When the average CPU usage more than 60% and keep 600 seconds, then scale up

$ aws cloudwatch put-metric-alarm \
--evaluation-periods 1 \
--namespace "AWS/EC2" \
--comparison-operator GreaterThanThreshold \
--alarm-name alarm-high-cpu \
--statistic Average \
--threshold 60 \
--period 600 \
--metric-name CPUUtilization \
--alarm-actions arn:aws:autoscaling:us-east-1:332100208493:scalingPolicy:c34f62a8-bb82-4430-9390-67468a7a65f9:autoScalingGroupName/as-group:policyName/as-policy-scale-up

可以做個實驗，用 shell script 寫個 while loop 把 CPU 拉高，果然 10 分鐘後 alarm 就發生了，也會順便執行 scale-up 的 action

Scale down

Create auto scaling policy

$ aws autoscaling put-scaling-policy \
--policy-name as-policy-scale-down \
--auto-scaling-group-name as-group \
--adjustment-type ChangeInCapacity \
--scaling-adjustment -1 \
--cooldown 300
{
    "ResponseMetadata": {
        "RequestId": "c58093f7-9b6b-11e2-82fc-2bb2a883e37c"
    },
    "PolicyARN": "arn:aws:autoscaling:us-east-1:332100238493:scalingPolicy:141d692b-9ae8-4ef8-8d98-7de605c3fe04:autoScalingGroupName/as-group:policyName/as-policy-scale-down"
}

Create cloud watch to monitor the CPU utilization
When the average CPU usage less than 40% and keep 600 seconds, then scale down

$ aws cloudwatch put-metric-alarm \
--evaluation-periods 1 \
--namespace "AWS/EC2" \
--comparison-operator LessThanThreshold \
--alarm-name alarm-low-cpu \
--statistic Average \
--threshold 40 \
--period 600 \
--metric-name CPUUtilization \
--alarm-actions arn:aws:autoscaling:us-east-1:332100238493:scalingPolicy:141d692b-9ae8-4ef8-8d98-7de605c3fe04:autoScalingGroupName/as-group:policyName/as-policy-scale-down

有一些疑問
Scale-up 會增加到多少台？Scale-down 會減至多少台？
CloudWatch 不會重複 trigger，除非狀態從 alarm 回到 normal。


參考資料
Llovizna: Auto Scaling With Amazon EC2

實現網頁即時傳訊 Web instant message (IM)

最近想弄一個Web IM，在web上做即時聊天有一定的困難，因為受限在http協定原生的特性：

client:request -> server:response -> 結束
傳輸一定要從client開始，而且一來一往誰也不能多，想做到server push有一定的難度，不像tcp raw socket自由度那麼高。


早期的聊天室會使用polling的方式定期 refresh (post back) 來更新頁面，同步的時間取決於refresh的頻率，但server loading也隨著頻率上升而增加。後來有了Ajax，頁面更新不用再一直閃爍，但還是有原本耗資源的問題。

近期較廣泛被使用的是Ajax搭配long polling，做到省資源又可以與server同步的效果。
Polling就是client定期的發request，long polling就是定期發request，但server不馬上response，而是等到有需要的時候再response (例如有人傳新訊息給你時)，通常browser timeout都蠻長的，所以這段等待的期間相對polling就很省資源。如果還不是很懂，可以參考這一篇：Browser 與 Server 持續同步的作法介紹。

要做到long polling這個效果需要server support，server必需要把request object先keep住，等到有需要的時候再抓出來回應給client。用Tornado來舉例，就是RequestHandler被call時，先把Handler存起來，等到時機到了再執行finish() function。


下面列出幾種IM的 model，我想實現的是最後一種 ── 跨平台而且server可以隨著loading scale-up。