[AWS] Amazon AWS 實戰筆記與心得

雲端正夯,所以說把工作上的事情丟到雲端上面去也是很合理的。至於為什麼不選種花電信的 HiCloud 呢?這種事情還是去擲筊會比較準。

別鬧了,沒有競爭力的台灣 IDC 們

電費是經營IDC的最大成本??? 搞錯了吧???

HiCloud 的頻寬計價現況與對比 Amazon AWS 的簡要分析

你看完再決定你要不要用 HiCloud...

Why Amazon?

跟傳統的 Hosting 比起來,當然可以自己控管的虛擬主機是比較有彈性的。那或許你會說,VPS 也不錯啊,的確,市面上還是有許多不錯的 VPS 服務商,在價格上也略顯優勢(AWS 是按時計費,而大多 VPS 則是按月計費,例如 C/P 值超高的 Linode)。

好處是什麼,

  • 五花八門的服務
  • 因為他是 Amazon

壞處是什麼,

  • 什麼都要自己來
  • 新的東西太多學不完

其實優缺點應該不會這麼少,不過這種事情其實是見仁見智,我覺得好的地方可能大家不那麼認為。總之也是,你用了才知道。

使用的服務

最近因為要把工作上的東西全數轉移到 AWS 上面,雖然之前已經有摸過一陣子,但是對於沒碰過得服務還是苦手了好一段時間。這裡就當作是筆記可能比較恰當一點(笑

Amazon S3, Amazon EC2

這個應該不用特別說明吧?Amazon S3 就是一個地方讓你可以放東西用的(籠統,而 Amazon EC2 則是提供虛擬主機的地方。好處是,在同一個區域(Amazon 把各種服務依照區域(Region)分割開來,S3 與 EC2 之間互相存取檔案是不收費的。

所以,我們就可以從 EC2 上面,利用 Amazon 提供的 SDK 來將檔案放到 S3 去作儲存的動作。而且,這個動作所需要的時間,以目前工作上最大檔案 12MB 來看,大概不用一秒。

另外附註一提的是,從 Flickr, Picasa, Facebook 爾等大型網站,利用 cURL 取得相片檔案(均取最大原始圖檔,透過 EC2 抓取,再轉存到 S3,大概一秒。

Dropbox 則例外,從 EC2 上傳到 Dropbox 並沒有想像中的快(笑

Amazon RDS

這是 Amazon 所提供的關聯式資料庫服務,說實在的,他的價格並沒有想像中的便宜。各位可以去參考 Amazon RDS價目表

雖然說 Amazon 也有提供 nosql 的資料表可用,不過目前實際工作需求,還是以關聯式資料表為主。RDS 的操作方式比較原始一點,你在 Console 開好一個 DB Instance 之後,你必須要先指定哪一個 Security Groups 可以連進去,或者是使用 CIDR/IP 去指定哪台機器可以連線。

當然,所謂的連線就是 mysql -u <Your RDS root> -p -h <Your RDS EndPoint> 這種方式。當然啦,你也可以在你的機器上面放 phpMyAdmin 來連線就是了。

至於說 RDS 的效能,這裡有篇有趣的文章可以參考一下,

MySQL on Amazon RDS part 1: insert performance
MySQL on Amazon RDS part 2: Determining Peak Throughput

或許你會想說,既然我已經有 EC2 了,那我架在 EC2 上面就好了嘛,關於這點,這裡也有一系列文章可以參考,我個人是覺得,這種事情沒有必要一定要用在哪裡,端看個人需求。像我就有弄一台 FreeBSD 專門跑 MySQL 這樣

作者好像還有 Part 6, 7 還沒寫,可以持續關注一下!

Amazon SES

這是 Amazon 比較新一點的服務,全名是 Amazon Simple Email Service,這樣說你應該就知道他是作什麼用的了,用來作為廣發大量謎樣廣告信的好工具,這個工具目前還在 beta,不過他也 beta 好一陣子了,不知道什麼時候會正式把 beta 拿掉。

使用方法其實蠻奇妙的,你要先設定認證過的送件者(Verified Senders),然後,可以透過 API 呼叫,或是經由 SES 裡面的 SMTP 的設定,來發送信件。

是的,只能透過 API 來發送而已喔(啾咪

Amazon Route 53

他就是一個 DNS,而且還不算是很便宜的 DNS(笑倒,選用他的原因很簡單,速度快,設定方便,而且也是 Amazon 的一環,而且當設定超過一個數量,價格還會有優惠。

實際應用

這是筆記文!真的!因為人老多忘事,所以一定要寫下來才行。

Amazon EC2 建立 AMI

以前要用 ec2 command line tool,現在在 Console 裡面按右鍵就做完了(喂。我們要建立 AMI 當然是會有特殊需求的,通常就是所需要的環境建立好之後,再把我們目前的主機(EC2)整台打包成一個私有的 AMI 來使用。

好處是,當我們同樣的機器有大量需求的時候,我們就只要打開打開打開,佈署佈署佈署,上線上線上線。當我們沒有用到的時候,就關機關機關機,甚至你要特密內特 Terminate 掉也可以。

通常 AMI 有分兩種,一種是 S3-backed,另一種是 EBS-backed。以前在作 AMI 的時候,只能作 S3-backed 的,所以過程上就相對的複雜很多(比較麻煩一點。現在 Console 有改了,可以用滑鼠右鍵在 Instance 上,點 Create Image(EBS AMI) 一鍵搞定,而且還是 EBS-backed 的呢。

當然,神人 Hank 也有特別寫文紀錄,強烈推薦!

creating EBS-backed AMIs from running instances

我昨天就是照著步驟作的啦,但是後來發現右鍵可以一鍵搞定讓我有股淡淡的哀傷。是的,一鍵搞定他也是照 Hank 所說的方式去作,一樣會有個 snapshot 在裡面。

後來我也實作了 S3-backed AMI,但是,啟動速度跟 EBS-backed 不能比啊(遮臉。雖然我已經不用 S3-backed AMI,不過這裡還是簡單紀錄一下,

首先你要有,

  • Access Key ID
  • Secret Access Key
  • cert-xxxxxxxxxx.pem
  • pk-xxxxxxxxxxx.pem

最後兩組 pem 要自己去建立,在 Security Credentials 裡面,X.509 Certificates 去建立一組。然後把他下載下來這樣。

然後,就去開一台 EC2,把你需要的環境全部建立好之後,然後切去 /mnt 底下(歐,mirco 的機器好像沒有 /mnt 這個地方,所以你可能需要自己開 EBS 掛一組 Volumes 來用,開 EBS 請注意區域問題,跨區不能讀取喔!

然後呢,你需要把剛剛的 pem 傳上去(用 scp 或是 sftp 隨你,接著,你的環境中需要安裝 ec2-api-tools 喔!

如果你的 Ubuntu 找不到 ec2-api-tools 的話,請加入此 PPA

ppa:awstools-dev/awstools

網址是,

awstools development team

建立 IMAGE

$ ec2-bundle-vol -d /mnt/ -c cert-xxxxxxxxxx.pem \
  -k pk-xxxxxxxxxx.pem -u <Amazon Account Number> \
  -r x86_64 -p MY_AMI

其中 -r x86_64 是指你的系統是 64bit 的,如果你是安裝 32bit 的作業系統,請使用 -r i386 這樣。然後 <Amazon Account Number> 在你的 Account Activity 可以看到,右上角的 Welcome XXXX 底下那一串數字就是了。

傳到 S3 上面去,請注意區域(Region)的問題!你的 EC2 如果在美東,你丟上 S3 就把 bucket 開在美東,畢竟傳輸不用錢嘛(笑

上傳 IMAGE 到 S3

$ ec2-upload-bundle -b <Your Bucket Name> \
  -m MY_AMI.manifest.xml -a <Access Key ID> \
  -s <Secret Access Key>

傳完之後呢,再去 S3 找你的 manifest 網址,大概會長這樣,

https://<Your Bucket Name>.s3.anazonaws.com/MY_AMI.manifest.xml

但是,當你要去 AMIs 註冊的時候,他要你提供的卻是長這樣,

http://s3.amazonaws.com:80/[____________________]

我當時是填入 <Your Bucket Name>/MY_AMI.manifest.xml 然後就完成了這樣。

Amazon Elastic Load Balancing

他叫做負載均衡(以下簡稱 ELB,通常這件事情在實體機器上,我們都自己作,像是利用 Nginx 的 backend/upstream 去作掉這樣。而 Amazon 所提供的 ELB,則是會依照伺服器的健康狀態,來幫你將流量轉向其他的 EC2 上面去。

當然,你就必須要有一台以上一模一樣的 EC2 來給他使用,不過,我們沒事當然不會開那麼多機器來用,所以,這件事情有沒有必要見仁見智。

不過!

如果你會使用到自動擴展(Auto Scaling)的話,你就得要設定 ELB,一來省事,二來他搭配 Cloud Watch 可以有比較彈性的變化。

關於 ELB 的說明,官方文件非常清楚,圖文並茂,大家可以參考一下,

Get Started with Elastic Load Balancing

自動擴展服務

剛剛說 ELB 來搭配 Cloud Watch 作自動擴展,這邊就來說一下。監控的部份,當我的服務負載過高的時候,需要增加機器來負荷突然增加的流量,所以會需要 Amazon Cloud Watch 來作 Auto Scaling 的觸發動作。

首先你需要下載 Auto Scaling Command Line Tool 還有 CludeWatch Command Line Tool 來幫你作一些設定。

首先是要建立一個啟動的設定檔(launch config

$ as-create-launch-config <my_scaling> \
  --image-id <ami-0009527> \
  --instance-type <m1.small> \
  --key <my_keypair> \
  --group <my_groups> \
  --monitoring-disabled

OK-Created launch config

其中要說明一下,

  • <my_scaling> 這個設定檔的名字,請自己取
  • --image-id 請用你自己建立的 AMI,不然你開一台空機器是沒有用的
  • --instance-type 你這台機器要開多大的 Instance
  • --key 這很重要,如果你要使用 SSH 連線的話
  • --group 這就是 Security Groups 啦,一些連接埠設定的那些東西
  • --monitoring-disabled 就是我開 Instance 把 monitoring 關掉的意思

然後我們可以用指令來查一下,

$ as-describe-launch-configs
LAUNCH-CONFIG  my_scaling  ami-0009527  m1.small

好了之後呢,我們要建立一下自動擴展的群組,

$ as-create-auto-scaling-group <my_scaling_group> \
  --launch-configuration <my_scaling> \
  --availability-zones <ap-northeast-1a> <ap-northeast-1b> \
  --min-size 1 \
  --max-size 5 \
  --load-balancers my_ELB

OK-Created AutoScalingGroup
  • <my_scaling_group> 就是群組名稱,自己取
  • --launch-configuration 這是剛剛你作的設定檔
  • --availability-zones 你的 Instance 要在哪些地區啟動
  • --min-size 最少開幾台
  • --max-size 最多開幾台
  • --load-balancers 指定你的 ELB

然後,在設定自動擴展的條件,

$ as-put-scaling-policy <my_scaling_policy> \
  --auto-scaling-group <my_scaling_group> \
  --adjustment=1 \
  --type ChangeInCapacity \
  --cooldown 300 
  • <my_scale_policy> 你的條件名稱,自己取
  • --auto-scaling-group 剛剛設定的群組名稱
  • --adjustment 當觸發這個條件的時候,要啟動幾台 Instance
  • --type 這裡的設定跟你的 Amazon Cloud Watch 設定有關
  • --cooldown 條件動作之間的冷卻時間(笑,單位是秒

上述的指令呢,會給你這些東西,

arn:aws:autoscaling:ap-northeast-1:889000449203:scalingPolicy:7c3658e4-cf5c-4275-8be9-d52802317a0b:autoScalingGroupName/my_scaling_group:policyName/my_scaling_policy

注意!當你做完 as-put-scaling-policy 的時候,你的 EC2 就會自動啟動機器,數量是你剛剛指定的 min-size,而使用的 AMI 也是你指定的那一個。

當然,我們要搭配 Cloud Watch 來作,所以,

$ mon-put-metric-alarm myHighCPUAlarm \
  --comparison-operator GreaterThanThreshold \
  --evaluation-periods 1 \
  --metric-name CPUUtilization \
  --namespace "AWS/EC2" \
  --period 600 \
  --statistic Average \
  --threshold 60 \
  --alarm-actions <arn:.....> \
  --dimensions "AutoScalingGroupName=<my_scaling_group>"

OK-Created Alarm

關於 mon-put-metric-alarm 的話,大抵上是這樣,

  • --comparison-operator 這個說明文件有,四個值這樣
  • --evaluation-periods 意思是當 n 次的比對成立時,去驅動 Alarm 動作
  • --metric-name 這個可以去 Console 裡面的 CloudWatch 新增一個 Alarm 看看(笑
  • --namespace 這個一定要設定,至於值,大抵上就是跟 EC2 或是 RDS 有關(端看你所使用的服務
  • --period 多少時間偵測一次,單位是秒
  • --statistic 有五種可以選,在 CloudWatch 裡也有
  • --threshold 比較值就是 CPUUtilization 如果大於這個值,就會執行 Alarm
  • --alarm-actions 就是當 Alarm 發生的時候,要作什麼動作
  • --dimensions 單純的說明(的樣子,就是類似這個 Alarm 的描述這樣

所以上面那個指令我們可以這樣來理解他,

  • 建立一個名稱為 myHighCPUAlarm 的警報
  • --comparison-operator GreaterThanThreshold 使用 GreaterThanThreshold 來比對
  • --evaluation-periods 1 當發生(觸發) 1 次事件的時候,啟動(執行)警報動作
  • --metric-name CPUUtilization 這個警報器要比對的標的叫做 CPUUtilization
  • --namespace "AWS/EC2" 使用 "AWS/EC2" 的命名空間
  • --period 600 每 600 秒檢測一次
  • --statistic Average 使用 Average 這個狀態來檢測
  • --threshold 60 當標的 CPUUtilization 超過這個數值的時候觸發事件
  • --alarm-actions <arn:.....> 這個警報器觸發的時候要執行的事件
  • --dimensions "A..." 這個警報器的警報訊息(描述)

這樣我們就做好自動增加機器的一個步驟了!結束了?不,我們很忙的時候開了機器,但是不忙的時候要關機啊,機器要算錢的嘛。

關機如法炮製,我們一樣設定一個 policy 上他去關掉一台機器,

$ as-put-scaling-policy <my_scaling_policy> \
  --auto-scaling-group <my_scaling_group> \
  --adjustment=-1 \
  --type ChangeInCapacity \
  --cooldown 300 

arn:aws:autoscaling:ap-northeast-1:885400449203:scalingPolicy:7c3658e4-cf5c-4275-8be9-d52802317a0b:autoScalingGroupName/my_scaling_group:policyName/my_scaling_policy

然後建立另一個 Alarm,差別只在於 --comparison-operator--threshold 而已,

$ mon-put-metric-alarm myHighCPUAlarm \
  --comparison-operator LessThanThreshold \
  --evaluation-periods 1 \
  --metric-name CPUUtilization \
  --namespace "AWS/EC2" \
  --period 600 \
  --statistic Average \
  --threshold 10 \
  --alarm-actions <arn:.....> \
  --dimensions "AutoScalingGroupName=<my_scaling_group>"

OK-Created Alarm

那麼這樣一來,他就會在 CPU 使用量高於 75% 時,增加一台 EC2,然後低於 10% 的時候關閉一台 EC2,這樣再搭配 ELB 的話,就能做到自動擴展囉!

然後,剛剛的 as 系列動作,如果你要針對你已經作過的 config 或是 group 作修改,必須先把已經啟動的東西停下來才行,這裡稍微簡單說明一下,

$ as-suspend-processes <my_scaling_group>
$ as-describe-auto-scaling-instances
INSTANCE  i-33caa533  my_scaling_group  ap-northeast-1b  InService      HEALTHY  my_scaling

$ as-terminate-instance-in-auto-scaling-group \
  --instance i-33caa533 \
  --no-decrement-desired-capacity -f

$ as-delete-auto-scaling-group <my_scaling_group>
$ as-delete-launch-config <my_scaling>

以上,是刪除 configuration 與 group 的流程,請先記得 suspend,不然你就算把 Instances 全部關掉,他還是會很貼心的幫你全部開回來喔(啾咪

提醒

要使用 ec2-api-tools 或是其他的 command line tools 的時候,請留意一下一些環境變數的問題。上述幾個工具,都會牽扯到區域(REGION)的問題,所以要小心。

這裡提供我在使用的環境變數設定,給大家參考一下,

export EC2_PRIVATE_KEY=`pwd`/pk-xxxxxxxxxxxxxxxxxxxxx.pem
export EC2_CERT=`pwd`/cert-xxxxxxxxxxxxxxxxxxxxx.pem
export EC2_REGION=ap-northeast-1
export AWS_ELB_HOME=`pwd`/ELB
export AWS_AUTO_SCALING_HOME=`pwd`/AutoScaling
export AWS_CLOUDWATCH_HOME=`pwd`/CloudWatch
export JAVA_HOME=/usr/lib/jvm/java-6-openjdk
export PATH=$PATH:$AWS_ELB_HOME/bin:$AWS_AUTO_SCALING_HOME/bin:$AWS_CLOUDWATCH_HOME/bin

其中,EC2_REGION 就是你自己的區域,請記得改。然後,我把 ELB, AutoScaling, CloudWatch 這三個工具下載下來,目錄換成那樣,如果你要照上面的用,也請記得修改。

另外,JAVA_HOME 大家可能不太一樣,也別忘記改。

結語

好 Amazon,不用嗎?

什麼 HiCloud 的,不要再相信沒有根據的說法了

Hina Chen
偏執與強迫症的患者,算不上是無可救藥,只是我已經遇上我的良醫了。
Taipei