幹壞事是進步最大的原動力
Amazon Elasticsearch Service 的新功能，使用 Amazon S3 當作第二級儲存空間 (UltraWarm)：「Announcing UltraWarm (Preview) for Amazon Elasticsearch Service」。
UltraWarm 需要不同的機器 (跑不同版本？)，機器的規格 (vCPU 與記憶體的比率) 接近 Memory Optimized 的版本，但是貴了不少，所以需要夠大的資料量才會打平回來...
拿 us-east-1 來看，SSD EBS 的空間成本就是 USD$0.135/GB，而傳統磁性硬碟是 USD$0.067/GB (不知道收不收 I/O 費用？)，但 storage 的價錢是 USD$0.024/GB。這邊值得一提的是 Amazon S3 是 USD$0.023/GB，看起來是直接包括了 API 的呼叫費用？
Amazon EFS 有 IA 的儲存方案，儲存的價位便宜很多，但需要另外收存取費用。不過這對於丟 log 之類的倒是還算方便，很多現有的程式就可以直接往裡面丟...
不過系統的設計上不是讓你指定哪些檔案放到 IA，而是設定 Lifecycle Management Policy 以及時間，當超過指定的時間後就會安排搬到 IA 裡面。
先前最低的時間是 14 天，剛剛看到 AWS 宣佈有 7 天的選項了，從 web console 上就可以看到選項可以選了：「Amazon Elastic File System Infrequent Access Now Supports a 7-day Lifecycle Management Policy」。
這樣對於開始堆資料的人，一開始塞東西進去而需要付 Standard Storage 的時間可以少蠻多的...
在「A web performance issue」這邊講到 Mozilla 的系統產生效能問題，後續的 trouble shooting 以及解決問題的方案。
這個系統跑在 AWS 上，在一連串確認後發現是 RDS 所使用的 EBS 的 IOPS 滿了：
After reading a lot of documentation about Amazon’s RDS set-up I determined that slow downs in the database were related to IOPS spikes. Amazon gives you 3 IOPS per Gb and with a storage of 1 Terabyte we had 3,000 IOPS as our baseline. The graph below shows that at times we would get above that max baseline.
然後大家對於解法都差不多，因為 Provisioned IOPS 太貴，所以直接加大空間換 IOPS 出來 (因為 General SSD 裡 1 GB 給 3 IOPS)：
To increase the IOPS baseline we could either increase the storage size or switch from General SSD to Provisioned IOPS storage. The cost of the different storage type was much higher so we decided to double our storage, thus, doubling our IOPS baseline. You can see in the graph below that we’re constantly above our previous baseline. This change helped Treeherder’s performance a lot.
然後再設警告機制，下次就可以提前再拉昇：
In order to prevent getting into such a state in the future, I also created a CloudWatch alert. We would get alerted if the combined IOPS is greater than 5,700 IOPS for 6 datapoints within 10 minutes.
不過 General SSD 的 IOPS 是沒有 100% 保證的，只有這樣寫：
AWS designs gp2 volumes to deliver 90% of the provisioned performance 99% of the time.
大多數的情況應該是夠用啦...
Backblaze 開了歐洲機房，所以包括了一般性的 Computer Backup 與 B2 Cloud Storage 都可以選擇要放哪邊了...
歐洲的點是放在荷蘭：
Big news: Our first European data center, in Amsterdam, is open and accepting customer data!
價錢也都跟美國的相同：
Whether you choose EU Central or US West, your pricing for our products will be unchanged:
對於在意資料放美國機房的問題應該有緩解一些...
這篇是 StackOverflow 在講 cache 的文章，裡面不是什麼新東西，只是看到有趣的項目所以拿出來講：「How Stack Overflow Caches Apps for a Multi-Tenant Architecture」。
在講 cache 前通常都會說明各種儲存空間速度的差異，但裡面混了一個奇怪的東西：
裡面混了一個不是 storage 的東西進去比較，你們是對 Microsoft 的帳號系統有多不爽 XDDD
另外他們列出了目前 Redis 的使用情況：
For the curious, some quick stats from last Tuesday (2019-07-30) This is across all instances on the primary boxes (because we split them up for organization, not performance…one instance could handle everything we do quite easily):
- Our Redis physical servers have 256GB of memory, but less than 96GB used.
- 1,586,553,473 commands processed per day (3,726,580,897 commands and 86,982 per second peak across all instances – due to replicas)
- Average of 2.01% CPU utilization (3.04% peak) for the entire server (< 1% even for the most active instance)
- 124,415,398 active keys (422,818,481 including replicas)
- Those numbers are across 308,065,226 HTTP hits (64,717,337 of which were question pages)
然後更長的版本可以在作者自己的 blog 上讀到，裡面講到的 cache invalidate (purge) 這部份有談到一些他們的作法：「Stack Overflow: How We Do App Caching - 2019 Edition」。
Backblaze 的 B2 算是我還蠻愛用來丟一些東西的地方 (配合他們與 Cloudflare 合作的免費頻寬)。
先前 B2 一直沒有複製檔案的功能，如果要有同樣檔案，變成得自己再上傳一次，這對於網路沒有很快的使用者會很痛苦，現在總算是提供 API 可以直接複製了：「B2 Copy File is Now Public」。
這個功能主要的文件在「b2_copy_file」。
另外這次也推出了「b2_copy_part」，針對檔案的合併所提供的 API。
AWS 宣佈 EBS 的預設型態從 Standard 變成 GP2：「EBS default volume type updated to GP2」。
包括 web console 與 API 的預設值都改成 GP2：
The AWS console defaults to GP2 in all regions. On July 29th the default EBS volume type was updated in thirteen regions from Standard to GP2. Now AWS API calls for volume, image, and instance creation also default to GP2 in all regions.
GP2 是 SSD，所以可以提供比較低的 latency，而另外一個用 GP2 的好處是 i/o 的費用已經含在內了 (Standard 會另外收取費用)，對於成本估算會比較簡單一些，尤其是 i/o 量比較大的時候。
Amazon RDS 推出了 Storage Auto Scaling：「Amazon RDS now supports Storage Auto Scaling」。
看起來傳統 RDBMS 類的都支援 (也就是非 Aurora 的這些)：
Starting today, Amazon RDS for MariaDB, Amazon RDS for MySQL, Amazon RDS for PostgreSQL, Amazon RDS for SQL Server and Amazon RDS for Oracle support RDS Storage Auto Scaling.
仔細看了一下新聞稿，裡面都只有提到 scale up，沒有提到 scale down，這個功能應該是只會提昇不會下降，所以要注意突然用很多空間，再砍掉後的問題：
RDS Storage Auto Scaling automatically scales storage capacity in response to growing database workloads, with zero downtime.
RDS Storage Auto Scaling continuously monitors actual storage consumption, and scales capacity up automatically when actual utilization approaches provisioned storage capacity.
除了香港外的所有商業區域都提供：
RDS Storage Auto Scaling is available in all commercial AWS regions except in Asia Pacific (Hong Kong) and AWS GovCloud.
EBS 有選項可以預設開加密了：「New – Opt-in to Default Encryption for New EBS Volumes」。
不算太意外的，這個選項要一區一區開：
Per-Region – As noted above, you can opt-in to default encryption on a region-by-region basis.
也不太意外的，無法完全公開共用：
AMI Sharing – As I noted above, we recently gave you the ability to share encrypted AMIs with other AWS accounts. However, you cannot share them publicly, and you should use a separate account to create community AMIs, Marketplace AMIs, and public snapshots. To learn more, read How to Share Encrypted AMIs Across Accounts to Launch Encrypted EC2 Instances.
然後有些服務有自己的 EBS 設定，這次不受影響。而有些底層其實是用 EC2 的服務 (然後開 EBS) 就會直接套用了：
Other AWS Services – AWS services such as Amazon Relational Database Service (RDS) and Amazon WorkSpaces that use EBS for storage perform their own encryption and key management and are not affected by this launch. Services such as Amazon EMR that create volumes within your account will automatically respect the encryption setting, and will use encrypted volumes if the always-encrypt feature is enabled.
看到「UDS : Unlimited Drive Storage」這個專案，利用 Google Docs 存放資料。主要的原因是因為 Google Docs 不計入 Google Drive 所使用的空間：
Google Docs take up 0 bytes of quota in your Google Drive
用這個方法可以存放不少大檔案 (像是各種 ISO image)，讓人想起當年 Love Machine 的玩法 (不知道的人可以參考「愛的機器 Love machine」這篇)，切割檔案後傳到某些空間以提供下載？只是這邊是用 base64 放到 Google Docs 上...
base64 的資料會比原始資料大 33%，而 Google Docs 單篇的上限大約是 710KB：
Size of the encoded file is always larger than the original. Base64 encodes binary data to a ratio of about 4:3.
A single google doc can store about a million characters. This is around 710KB of base64 encoded data.
方法不是太新鮮，但是讓人頗懷念的... XD