Netflix 把金流相關的系統轉移到 AWS 上跑 MySQL 的故事...

這次要提的是「Netflix Billing Migration to AWS」、「Netflix Billing Migration to AWS - Part II」與「Netflix Billing Migration to AWS - Part III」這三篇。

Netflix 先前的金流相關系統跑的是 Oracle 的資料庫:

然後換成 MySQL

系統上是採用 DRBD,然後底層是 5 個 4TB 的 EBS 組成的 RAID 0,跑 LVM

High performance with respect to reads and writes was achieved by using RAID0 with EBS provisioned IOPS volumes. To get more throughput per volume, 5 volumes of 4TB each were used, instead of 1 big volume. This was to facilitate faster snapshots and restores.

LVM to manage two Logical Volume’s (DB and DRBD Metadata) within single Volume Group.

可以看到裡面用的都是很經過時間考驗的技術,像是 DRBD、標準的 Replication 架構...

Amazon EBS 推出新磁碟種類

Amazon EBS 推出了新的磁碟種類,都是比現在更經濟 (白話文:更便宜) 的方案:「Amazon EBS Update – New Cold Storage and Throughput Options」。

第一種是 Amazon EBS Throughput Optimized HDD,代號是 st1;第二種是 Amazon EBS Cold HDD,代號是 sc1,兩種都是傳統磁頭硬碟。

第一種 st1 重視 sequential 的 throughput:

Starts at 250 MB/s for a 1 terabyte volume, and grows by 250 MB/s for every additional provisioned terabyte until reaching a maximum burst throughput of 500 MB/s.

第二種 sc1 則是重視堆資料的費用:

Designed for workloads similar to those for Throughput Optimized HDD that are accessed less frequently; $0.025 / gigabyte / month.

要注意的是,IOPS 是可以累計的,而未滿 1MB 的 access 會計算成 1MB,所以只適合大量 sequential access 的應用,像是 Hadoop 這類 big data 類的應用:

For both of the new magnetic volume types, the burst credit bucket can grow until it reaches the size of the volume. In other words, when a volume’s bucket is full, you can scan the entire volume at the burst rate. Each I/O request of 1 megabyte or less counts as 1 megabyte’s worth of credit. Sequential I/O operations are merged into larger ones where possible; this can increase throughput and maximizes the value of the burst credit bucket (to learn more about how the bucket operates, visit the Performance Burst Details section of my New SSD-Backed Elastic Block Storage post).

另外 sc1 也是目前每單位裡面最便宜的價錢,不知道拿來當 root 會底多慢 XDDD

EC2 instance Auto Recovery 功能全區開放

Twitter 上看到公告:「Announcement: EC2 instance Auto Recovery now available in 8 more AWS Regions」。

也就是 C3、C4、M3、R3、T2 這五種 instance 都可以開 Auto Recovery,而且必須在 VPC 內的 EBS-only instance。

在某種程度上的 High Availability 機制可以直接用這個功能解決掉。

用 EBS-SSD 開機的 Ubuntu

前幾天 AWS 推出 EBS-SSD (參考「AWS 推出 SSD EBS」),然後今天看到「EBS-SSD Boot AMIs For Ubuntu On Amazon EC2」。

Canonical 正式的說明在「[ubuntu-cloud] Amazon SSD backed EBS volumes」這邊可以看到,而「Amazon EC2 AMI Locator」上也新增了 EBS-SSD 的部份。

AWS 推出 SSD EBS

EBSAWS 上的 block-level storage,除了空間本身要收費以外,I/O 本身也要收費。到今天為止,EBS 只提供 Magnetic volume,也就是與傳統硬碟性質接近的 EBS。

而今天 AWS 推出了 SSD 的 EBS:「New SSD-Backed Elastic Block Storage」,價錢上當然就比傳統硬碟建立的 EBS 貴,但看起來是個可以接受的數字?

另外傳統硬碟的 Provisioned IOPS volume 也降價了,約 35% off:

We are also announcing that we are reducing the price of IOPS for Provisioned IOPS volumes by 35%.

需要效能的應用又多了一項武器...

AWS EC2 更新以及降價,以及 EBS 降價...

AWS 官方公告這一波改善:「AWS Update - New M3 Sizes & Features + Reduced EBS Prices + Reduced S3 Prices」。

首先是 EC2 多了 m3.medium 與 m3.large,與 m1.medium 與 m1.large 相比很有競爭力?

以 {m1,m3}.medium 比較來看,m3 的 ECU 值比 m1 高 50% (3 vs 2),而且有 SSD 硬碟 (雖然只有 4GB),價錢又比較便宜... 拿來跑 CPU bound 的 server 看起來就很好用啊?

另外一個超大的降價是 EBS,空間費用與 i/o 的費用都直接降 50%...

該來找人討論 KKTIX 要不要 migrate 過去了...

AWS EBS 的改善...

AWS EBSAmazon Web Services 平台上的永久性儲存空間 (一般開起來的空間在 crash 後會消失),不過 EBS 的效能 (速度與 IOPS) 一直讓大家很頭痛,要硬撐 IOPS 的方式是透過四個 EBS volume,上面用 mdadm 跑 RAID0...

這幾個禮拜 AWS 丟出了兩個方案出來,提供不同的選擇...

首先是帶大容量 SSD 空間的 instance,參考「AWS 推出高速 I/O 的 EC2 instance」,這對於 cache 類的應用相當適合...

而昨天則是介紹了 Provisioned IOPS 與 EBS-Optimized instances:「Fast Forward - Provisioned IOPS for EBS Volumes」。

Provisioned IOPS 是保障 IOPS 的機制,每個 volume 最高可以到 1000 IOPS。除了每 GB 的價錢比較高以外,另外每個保障的 IOPS 要再收 USD$0.1/month。(本來 EBS 的 I/O 費用還是要計算)

標準的 EBS 約提供 100 IOPS,這個 Provisioned IOPS 架構讓使用者要在上面衝 IOPS 變得更容易...

EBS-Optimized instances 是把 EBS 使用的頻寬獨立出來,目前只支援 m1.large、m1.xlarge 以及 m2.4xlarge 這三種,其中 m1.large 跑到 500Mbps (理論值 62.5MB/sec),後面兩種可以上 1Gbps (125MB/sec),使得服務與 I/O 的頻寬不會互相干擾到...

Amazon 詳細說明 AWS EBS/RDS 故障的原因...

Amazon 在網頁上說明了在 4/21 美東地區 EBS/RDS 故障的原因:「Summary of the Amazon EC2 and Amazon RDS Service Disruption in the US East Region」。

整篇文章相當長,但整個連鎖反應是起於操作時的人為疏失。而 RDS 因為是基於 EBS 上,所以也跟著大爆炸...

另外文章最後面也提到賠償的方式:

For customers with an attached EBS volume or a running RDS database instance in the affected Availability Zone in the US East Region at the time of the disruption, regardless of whether their resources and application were impacted or not, we are going to provide a 10 day credit equal to 100% of their usage of EBS Volumes, EC2 Instances and RDS database instances that were running in the affected Availability Zone.

另外,AWS 的 SLA 中有要求當未滿 SLA 條件時,必須由使用者提出退款要求,但這次則是例外,符合條件的會主動在下次的帳單上,或是系統的頁面上看到:

These customers will not have to do anything in order to receive this credit, as it will be automatically applied to their next AWS bill. Customers can see whether they qualify for the service credit by logging into their AWS Account Activity page.

AWS EC2/EBS 用了三天半時間恢復...

AWS EC2/EBS 從星期四 21 日下午四點開始 (+8 時區),到剛剛在「Service Health Dashboard」上看到宣佈恢復 (亮綠燈),總共花了超過三天半的時間。有些人受到影響時間比較長,有些人比較短,我是在 24 號的凌晨恢復的,受到影響時間約兩天多。這幾天應該會有比較正式的說明...

手上本來沒打算這麼早設計 failover 機制的,現在都要拉到前面做了...

這次的 AWS EC2/EBS 問題...

這次的 AWS EC2/EBS 問題讓很多站台掛掉 (可以看「Who is affected by EC2?」這個站台,在發文的現在 US-East 還是沒完全恢復),但這次並不是每個使用 US-East 的站台都掛掉,像是 Netflix 因為一開始規劃就是「Cloud 也是會爛整片的」,所以服務並沒有中斷。在 Hacker News 上就有被提出來討論

討論裡面也有投影片說明 Netflix 選 AWS 的原因是因為「來不及建立 Data Center」,但在建立時也同時注意到「Cloud 有可能會大規模爛掉」的情況而設計了很多機制防範:「Netflix in the cloud 2011」。

利用 AWS 在多個不同地點都有機房把架構在 AWS 上所能提供的 HA 機制發揮到極致,不過這是建立在「Cheaper than cost of being down」的想法上 (因為 Netflix 已經算是某類型的電子商務公司了)。

話說回來,繼續等美東機房恢復...