Tag: s3

EFS 上可以掛 AWS Transfer Family 了

先前 AWS Transfer Family 的後端只能是 Amazon S3，現在則是宣佈可以掛 Amazon EFS 了：「New – AWS Transfer Family support for Amazon Elastic File System」。

EFS 跟 S3 都是沒有空間限制，但 EFS 可以直接在系統上掛起來當作一般的檔案系統用，基本上就是更方便，不過代價就是單位儲存成本貴不少...

這次支援 EFS 對於一些量不大的處理又方便不少，也就是處理完後的檔案另外丟，而上傳上來的檔案可以砍掉的... 如果是上傳上來的檔案需要保留的，用 S3 會比較適合。

Amazon S3 現在變成 Strong Read-After-Write Consistency 啦...

看到 Amazon S3 宣佈 Strong Read-After-Write Consistency 了：「Amazon S3 Update – Strong Read-After-Write Consistency」。

這個問題從很久前就被討論過：

所以到這次更新之前，只有新增的 object 會保證馬上出現。現在則是 update 也會：

Effective immediately, all S3 GET, PUT, and LIST operations, as well as operations that change object tags, ACLs, or metadata, are now strongly consistent. What you write is what you will read, and the results of a LIST will be an accurate reflection of what’s in the bucket. This applies to all existing and new S3 objects, works in all regions, and is available to you at no extra charge! There’s no impact on performance, you can update an object hundreds of times per second if you’d like, and there are no global dependencies.

要注意這邊沒有提到 DELETE，所以有可能 DELETE + GET 的操作還是沒有到 strong consistency，不過句子本身意思不是很清晰，也許這幾天會有人在 forum 上面問然後有答案...

另外從公告裡面提到 Amazon EMR 團隊，看起來是 Amazon EMR 團隊一直在內部戳 Amazon S3 的團隊改善：

We’ve been working with the Amazon EMR team and developers in the open-source community to ensure that customers can take advantage of this update with their big data workloads. As a result of that you no longer need to use EMRFS Consistent View or S3Guard, further reducing the cost to run big data workloads in AWS.

AWS 推出了 Amazon S3 Storage Lens 可以看 S3 使用的概況

AWS 推出了 Amazon S3 Storage Lens，可以看 S3 使用的概況：「Introducing Amazon S3 Storage Lens – Organization-wide Visibility Into Object Storage」。

要使用者個功能需要授權 Amazon S3 Storage Lens 一些權限，照著說明去 IAM 開就可以了，開好後要等他一陣子，他需要去分析記錄才能產出 dashboard。

有免費版與付費版可以用，付費版的部份目前看到都是「$0.20 per million objects monitored per month」，但沒把所有的區域都翻完，所以不確定。

我自己看了一下免費版提供的預設 dashboard，就已經給出不少好用的資訊了，像是 30 天內的物件數與空間使用率變化，可以抓到一些成長數量的感覺。

可以建議至少免費版的部份就先開起來丟著...

MariaDB 的 S3 Engine 效能測試

Percona 對 MariaDB 在 10.5 (目前的最新穩定版) 裡出的 S3 Engine 給出了簡單的測試報告：「MariaDB S3 Engine: Implementation and Benchmarking」。

這個 engine 顧名思義就是把資料丟到 Amazon S3 上，目前是 alpha 版本，預設是不會載入的，需要開 alpha flag 才能用：

The S3 engine is READ_ONLY so you can’t perform any write operations ( INSERT/UPDATE/DELETE ), but you can change the table structure.

另外這是從 Aria 改出來的 read-only engine，而 Aria 是從 MyISAM 改出來的：

The S3 storage engine is based on the Aria code and the main feature is that you can directly move your table from a local device to S3 using ALTER.

測出來發現在 read-only 的情境下，COUNT(*) 超快，看起來就是跟 MyISAM 體系有關，直接撈 MyISAM 內的資料，所以本地要 18 秒，但放到 S3 反而秒殺 XDDD

整體看起來還不錯？算是一種 Data warehouse 的方案，主要是要用到 row-based format 儲存的優點，遇到一些冷資料可以這樣玩。

從「Using the S3 Storage Engine」這邊的設定方式看到 s3_host_name，看起來有機會接其他家的 S3 API，或是本地的 Storage。

話說 Aria 這個引擎當初最主要的重點就在 crash-safe，在有了 crash-safe 之後，DRBD 這種 block-level replication 機制就可以硬幹上去，後來主力就在擴充其他型態了，像是 GIS 與 virtual column 的功能，不過這些功能本家在 InnoDB 上好像也都陸陸續續跟上來了，單純的 Aria engine 好像還好...

Backblaze B2 支援相容 Amazon S3 的 API

Backblaze 宣佈支援相容 Amazon S3 的 API：「Backblaze B2 Cloud Storage Now Has S3 Compatible APIs」。

Amazon S3 的 API 算是 object storage 這個領域的 de facto standard 了，支援 Amazon S3 相容層可以讓現有的工具直接套用上去。

很多 client 軟體都藉著設定 API endpoint 的方式來支援 (通常預設會是 Amazon S3 的 s3.amazonaws.com)，這次的 endpoint 可以從 B2 的文件「S3 Compatible API」裡看到：

The format for endpoints for the Backblaze S3 Compatible API:

https://s3.<region>.backblazeb2.com

The Backblaze S3 Compatible API endpoints only accept connections over HTTPS. Non-secure connections will be rejected. The AWS SDKs and most integrations only require an Endpoint URL like the above (without the bucket name included).

另外也支援使用 bucket name 的形式操作：

If making the HTTP calls directly, the Backblaze S3 Compatible API supports specifying the bucket name in the hostname of the URL or in the path section of the URL. Both URLs below are valid examples of an endpoint calling a bucket:

https://bucketname.s3.us-west-001.backblazeb2.com

https://s3.us-west-001.backblazeb2.com/bucketname

B2 的另外一個優勢是 2018 的時候就跟 Cloudflare 合作 (參考「Backblaze 與 Cloudflare 合作，免除傳輸費用」)，從 B2 到 Cloudflare 的流量是不收費的，再加上 Cloudflare 的流量也可以是免費的，組合起來就變成一個很便宜的方案 (只有 B2 的 storage cost)。

Amazon Elasticsearch Service 可以利用 S3 當作二級儲存空間了

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 S3 的 Replication 也給出 SLA 了

Amazon S3 的 cross-region replication 與 same-region replication 也提供 SLA 了：「S3 Replication Update: Replication SLA, Metrics, and Events」。

  • Most of the objects will be replicated within seconds.
  • 99% of the objects will be replicated within 5 minutes.
  • 99.99% of the objects will be replicated within 15 minutes.

對應的賠償是：

When you enable this feature, you benefit from the associated Service Level Agreement. The SLA is expressed in terms of a percentage of objects that are expected to be replicated within 15 minutes, and provides for billing credits if the SLA is not met:

  • 99.9% to 98.0% – 10% credit
  • 98.0% to 95.0% – 25% credit
  • 95% to 0% – 100% credit

不過只保證 99% 的物件在五分鐘內會被 replicate 有點低，應該跟底層的網路 latency 有關？

Amazon S3 推出同一個區域的同步複製功能

Amazon S3 推出了 Same-Region Replication：「Amazon S3 introduces Same-Region Replication」。

先前的功能只有 Cross-Region Replication，可以當作異地備份的功能，現在則是推出讓同一區也可以複製...

不過就這個功能的目標來說，看起來主要是避免被刪除而已？因為還是同一個區域。另外就是公司內因為組織架構的問題，也有可能會用這個功能...

Replicated objects can be owned by the same AWS account as the original copy or by different accounts, to protect from accidental deletion.

操作 S3 Command Line 的工具

在朋友的 Facebook 上看的東西：「S5cmd for High Performance Object Storage」。會想要寫這篇是因為看到 s4cmd 跟 s5cmd 這兩個工具的命名而笑出來：

不過這篇也可以看到差異，s3cmd 是自己用 Python 刻所有東西，s4cmd 還是用 Python，但是因為 boto3 而快了不少，而 s5cmd 則是改用 Golang 寫，並且採用多個 TCP connection 操作而讓效能大幅提昇。

AWS Cloud 的用法

Hacker News Daily 上看到這則，分享了 AWS (他的前東家，超過八年) 的使用經驗：

除了可以在 Twitter 上看以外，也可以用 Thread reader 直接讀整條 thread，應該也還算清楚：「This is how I use the good parts of @awscloud, while filtering out all the distracting hype.」。

這邊的經驗談主要是在 web 與 app 相關的服務這塊：

有講到 AWS 的業務其實圍繞在 scalability 上發展，但這對 startup 可能反而是扣分，因為暴力法解反而可以大幅簡化架構換得 agile (而讓 startup 存活下來)。

另外從團隊的開發成本來看，這些 scale 的技術增加了開發成本，產生了很多開發上的限制，這些觀點也有點帶到「Premature optimization is the root of all evil」在講的事情：

最後的結論可以看到一些列表：

除了 DynamoDB 的意見不同外 (這邊提到的 DDB)，其他的我都可以接受...