幹壞事是進步最大的原動力
以往用 Amazon EBS Snapshot 需要用 Lambda 當 cron job 建立 snapshot，以及管理要存的數量 (要刪掉舊的)，現在 AWS 直接提供服務幫你處理：「New – Lifecycle Management for Amazon EBS Snapshots」。文章的截圖就說明了這個新功能：
不收另外的費用，不過目前只有開放三區，東京不在裡面：
You can create and use Data Lifecyle Manager policies at no charge; you pay the usual storage charges for the EBS snapshots that it creates.
Data Lifecycle Manager is available in the US East (N. Virginia), US West (Oregon), and EU (Ireland) Regions.
先繼續用 Lambda，等東京有的時候再換過去...
AWS 宣佈可以動態擴充 EBS (Magnetic Volume) 的大小了：「Amazon EBS Extends Elastic Volumes to Support EBS Magnetic (Standard) Volume Type」。EBS (Magnetic Volume) 被歸類到前個世代的產品，意外的把這個功能支援了前個世代的產品...
前世代的 Magnetic Volume 與 Throughput Optimized HDD (st1) & Cold HDD (sc1) 來比較起來貴了一些，但可以當作開機空間，另外低消只有 1GB (而 st1 與 sc1 是 500GB)，不過如果與 General Purpose SSD (gp2) 比的話，只要 I/O 有點量，整體的價錢就會超過 gp2，目前看起來還是用 gp2 會好一些...
去年年底的時候 Percona 的人在 AWS 上測試 Percona XtraDB Cluster 的效能，尤其是針對底層應該選擇哪種 EBS 的部分給了一些建議。可以參考先前寫的「Percona 分析在 AWS 上跑 Percona XtraDB Cluster 的效能 (I/O bound)」這篇。
當時的建議是用 io1，雖然是比較貴，但對於效能比較好。
而後來 Percona 的人收到 AWS 工程師的建議，可以用另外一個方式，可以在 gp2 上拉出類似的效能，但成本會比 io1 低不少：「Percona XtraDB Cluster on Amazon GP2 Volumes」。
這個方式是利用 gp2 會依照空間大小，計算可用的 IOPS。在官方的文件裡是這樣描述 gp2 的效能 (IOPS)：
General Purpose SSD (gp2) volumes offer cost-effective storage that is ideal for a broad range of workloads. These volumes deliver single-digit millisecond latencies and the ability to burst to 3,000 IOPS for extended periods of time. Between a minimum of 100 IOPS (at 33.33 GiB and below) and a maximum of 10,000 IOPS (at 3,334 GiB and above), baseline performance scales linearly at 3 IOPS per GiB of volume size. AWS designs gp2 volumes to deliver the provisioned performance 99% of the time. A gp2 volume can range in size from 1 GiB to 16 TiB.
在這個前提下，需要 10000 IOPS 的效能會需要 3.3TB 以上的空間，所以 Percona 就被 AWS 的工程師建議直接拉高空間重新測試：
After publishing our material, Amazon engineers pointed that we should try GP2 volumes with the size allocated to provide 10000 IOPS. If we allocated volumes with size 3.3 TiB or more, we should achieve 10000 IOPS.
首先是測出來的效能，可以看到沒有太大差異：
接下來就比較儲存成本，大約是 io1 版本的一半價錢：
如上面文件中提到的，gp1 不完全保證效能，但統計出來經常能夠提供出 3 IOPS/GB 的效能。而 io1 則是保證效能，不太需要擔心效能不穩定的問題。就是這個差異，反應到成本上面就有蠻大的差距。善用這點設計系統，應該會對整體成本有蠻大的幫助... (但對 latency 就未必了，尤其是 P99 之類的數值)
算是另外一種搞法讓大家可以考慮...
AWS 宣佈 Amazon EBS 可以提供的效能往上提高了 (這邊講的是 Provisioned IOPS SSD，代號 io1)：「Amazon EBS Improves Performance for io1 Volumes」。
單一 volume 的 IOPS 從 20K 變成 32K，thoughput 從 320MB/sec 變成 500MB/sec：
Today we are announcing an improvement in performance of Provisioned IOPS SSD (io1) Volumes from 20,000 IOPS to 32,000 IOPS and from 320 MB/s to 500 MB/s of throughput per volume.
應該是科技的進步帶動的 XD
Amazon Lightsail 推出了 Block Storage (11/14) 與 Load Balancer (11/29)：「Introducing additional block storage for Amazon Lightsail」、「Amazon Lightsail adds load balancers with integrated certificate management」。
兩個是不同時間點發表的，當時懶的寫所以這次一起寫...
Block Storage 有不少 VPS 都有提供了，像是 Linode 的「Linode Block Storage (Fremont beta)」(雖然還在 beta)、DigitalOcean 的「Storage on DigitalOcean | Highly available Block Storage」以及 Vultr 的「High Performance and Cheap Block Storage - Vultr.com」。
AWS 算是很早就有這個服務 (Amazon EBS)，這邊應該只是把系統整合進來...
另外一個是這幾天推出的 Load Balancer，目前應該只有 Linode 的「Ensure High-Availability with NodeBalancers - Linode」比較知名。AWS 上的 ELB 有不少選擇可以用 (ELB Classic、ALB 以及 NLB)，不過公告裡沒特別提到... 比較特別的是提供免費的 SSL Certificate 吧？這在其他家主要得靠 Let's Encrypt 來做，在 AWS 上應該是整合了 ACM？
AWS 主動提高 Amazon EC2 與 Amazon EBS 的 SLA：「Announcing an increased monthly service commitment for Amazon EC2」。
Amazon EC2 is announcing an increase to the monthly service commitment in the EC2 Service Level Agreement (“SLA”), for both EC2 and EBS, to 99.99%. This increased commitment is the result of continuous investment in our infrastructure and quality of service. This change is effective immediately in all regions, and is available to all EC2 customers.
之前是 99.95% monthly (參考前幾天的頁面：「Amazon EC2 SLA」)，現在拉到 99.99% 了。第一階的賠償條件也從 99.95%～99% 改成 99.99%～99% 了 (賠 10%)。
從「Linode Block Storage (Fremont beta)」這邊可以看到 Linode 推出 Block Storage 了，是 SSD-based，跟 Amazon EBS 的 gp2 也是 SSD-based 相同。
計價方式，價錢也相同，沒有 I/O fee：
They're affordable - $0.10 per GB (free during the beta) and no usage fees.
目前能從 1GB 開到 1TB：
How big of a Volume can I create?
Between 1 GB and 1024 GB for now. After the beta, the max volume size may be larger.
單台可以掛 8 個：
How many Volumes can I attach to a Linode at the same time?
Up to 8.
然後 2018 開始收費：
The beta is free through 2017. January 1, 2018 the meter starts running.
有了 Block Storage 後有些事情就比較好搭出來了，也不會受限於 local disk 的空間大小。
雖然只是 Amazon EC2 與 Amazon EBS 計價模式的改變，但這次 AWS 的改變對於許多開發流程有很大的影響 (重點在 EC2 的部份)：「New – Per-Second Billing for EC2 Instances and EBS Volumes」。
10/2 開始改變 (而不是 10/1)，低消一分鐘，Windows 機種以及需要額外收費的 Linux 機種不在範圍內：
This change is effective in all AWS Regions and will be effective October 2, for all Linux instances that are newly launched or already running. Per-second billing is not currently applicable to instances running Microsoft Windows or Linux distributions that have a separate hourly charge. There is a 1 minute minimum charge per-instance.
然後 Spot 與買 RI 後也是一樣以秒計價：
List prices and Spot Market prices are still listed on a per-hour basis, but bills are calculated down to the second, as is Reserved Instance usage (you can launch, use, and terminate multiple instances within an hour and get the Reserved Instance Benefit for all of the instances).
這次改變的影響很巨大。馬上可以想到幾個情境...
第一個是對於實踐 Release early, release often 的團隊來說，如果設計成每 deploy 一次就建一個新的 AMI (最乾淨的作法)，再開新機器換掉的話，成本就會增加不少。所以對於這樣的團隊，就會偏好朝著替換現有目錄內的東西後重啟...
現在改成以秒計費後，直接透過 Blue-Green Deployment 就可以了 (AWS CodeDeploy 年初也支援了：「AWS CodeDeploy 支援 BlueGreenDeployment」)：(如果不熟悉 Blue-Green Deployment 的話，更白話的說法就是「先建後拆」...)
同樣的理由，對於 Auto Scaling 的 policy 也有些改變。之前機器開起來都會想讓他跑一個小時，所以 scale down 的部份都會寫的比較鬆一點。現在就可以重新規劃了...
另外一個影響是對使用 container 的誘因少了不少。很多人用 container 的用法是開大台機器再裡面拆給不同服務用，讓資源利用率變高，現在變成用多少算多少後就不太需要這樣了...
當然也還是有缺點。以前 Spot Instance 如果被 AWS 收回時，最後的那個小時是不計費的。現在因為以秒計費，變成要收費了...
最後是 10/2 生效這件事情頗怪，該不會是財務部門不願意配合 10/1 星期天加班生效，所以只好變成 10/2 生效這種理由吧... XDDD
Amazon EBS 可以動態增加大小了，是個對不少人還蠻方便的功能：「Amazon Elastic Block Store (Amazon EBS) Enables Live Volume Modifications with Elastic Volumes」。
這邊講的沒有 downtime 當然還是得需要 filesystem 支援：
Today we are introducing the Elastic Volumes feature for Amazon Elastic Block Store (Amazon EBS). This new capability allows you to modify configurations of live volumes with a simple API call or a few console clicks. Elastic Volumes makes it easy to dynamically increase capacity, tune performance, and change the type of any new or existing current generation volume with no downtime or performance impact.
另外提到一個特殊的組合，是配合 CloudWatch 與 Lambda 調整：
You can streamline and automate changes using Amazon CloudWatch with AWS Lambda.
這方法頗有趣的 XDDD
這次要提的是「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 架構...