Tag: service

Amazon Lightsail 也推出 CDN 服務了...

Amazon Lightsail 也推出 CDN 服務了：「Amazon Lightsail now offers CDN distributions to accelerate content delivery」。

這個服務是用 CloudFront 為底：

This native service, called Lightsail CDN, is backed by Amazon CloudFront, Amazon Web Services’ CDN platform that uses a global network of servers in over 200 locations across 42 countries to store and deliver your content throughout the world. Lightsail CDN distributions can be created and configured with just a few clicks for a low, predictable monthly price, and you can get started for free.

看了一下價錢，免費方案可以有 50GB/month，一般自己架個 WordPress 之類的 blog 應該是可以涵蓋在內。

付費方案中，USD$10/month 可以給 200GB，但 USD$35/month 只能給 500GB？這邊是用愈多愈貴，沒看懂這個定價方式啊...

但看起來是有不少機會比 CloudFront 便宜 (如果非歐美的流量不少的話)，再來就是 Lightsail CDN 這邊沒有列出每個 request 的費用，所以應該是不算這塊？這樣小檔案很多的話應該也是個選擇？

Amazon Lightsail 一直拿 AWS 自家東西出來市場上打架，現有的 VPS 不知道會怎麼提供類似的方案，搭 Cloudflare 嗎？或是找 Fastly 這些服務搭？(不過話說回來，Fastly 的牌價好貴 XD)

拿 Cloudflare Workers 跑 Geolocation API

在 Hacker News Daily 上看到拿 Cloudflare Workers 跑 Geolocation API：「How to make simple Geolocation service」。

作者想要做一個很簡單的 Geolocation API，一開始的想法是在 AWS Lambda 上用 MaxMind 的資料，但 latency 偏高：

However, I quickly realized that the response time isn't what I've expected - on average the response took somewhere between from 200ms to 500ms. So I started looking for other options.

所以作者就想到是不是有有機會丟到 Cloudflare Workers 上，但發現 license 看起來是個問題，另外因為把 MaxMind 的資料庫丟進去，會超過 worker 的時間限制：

And for this case MaxMind offers GeoLite2 database, however you'll be in charge of hosting this database on your server and making regular updates of the database. You also need to make sure your project is compliant with MaxMind's License.

However, this solution had one really big caveat - MaxMind GeoLite2 database does not work on Cloudflare Workers due to some runtime limitations.

結果作者後來發現 Cloudflare Workers 上本身就會帶 Geoloation 資訊了，不需要另外拉 MaxMind 的資料查：

And after exploring their documentation, I realized that the Request object in function have an access to cf object, which contains some useful information about the visitor, including visitor's country!

另外我翻了一下價錢，主要是算次數的，看起來 Free Plan 就可以 100K/day (執行時間限制是 10ms)，而如果是付費方案的話則是 USD$0.5/M (50ms)，這樣對一些小專案來說，Free Plan 似乎是夠用了...

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 好像還好...

PHP 在 Amazon EC2 的 m5 (Intel) 與 m6g (ARM) 的效能差異

先前在「Amazon EC2 的 M6g 系列正式推出了」這邊提到了 AWS 在 Amazon EC2 上推出了以 ARM 為架構的 m6g 系列機器，剛剛看到有人拿 PHP 上的應用丟出測試的差異了：「Improving performance of PHP for Arm64 and impact on Amazon EC2 M6g instances」。

最先要注意的應該是這張：

在 PHP 7.3 的時候 Intel 平台的 m5 跑比較快，但到了 PHP 7.4 就變成 ARM 的 m6g 跑比較快了，不過這兩個版本的差異都不算太大，而到了還在開發的 PHP 8 則是出現了比較大的差距。

作者有提到主要的原因是在 PHP 7.4 之前 ARM 上不會啟用 Zend optimizer，而這個功能對效能的影響差很多，在 PHP 7.4 打開後就反轉了：

Zend optimizer is a component of the PHP runtime system that improves performance by up to 30% on a range of Zend micro-benchmarks. Before PHP 7.4 the Zend optimizer was not enabled for Arm.

而 PHP 8 的差距拉大，則是因為 PHP 有更多針對 ARM 平台的改善，像是這邊提到的 NEON 指令集：

PHP-8 plans to release in 2021 with more improvements for Arm64: an improved toupper/tolower function brings performance up by 16.5x. https://github.com/php/php-src/pull/4439

除此之外，AWS 也對 PCRE2 提供了使用 NEON 指令集的加速的 patch：

AWS has contributed changes to PCRE2 release 10.34. PCRE2 version 10.34 is used in PHP-8 to match regular expressions. PCRE2 accounted for about 8% of execution time in WordPress benchmark. The change contributed by AWS to PCRE2 vectorizes first character match and matching pairs of characters with NEON instructions: performance improves by up to 8x on M6g.

這樣可以看到 ARM 平常應該會愈來愈成熟，而更重要的是 m6g 系列機器比 m5 便宜不少：以作者測試的 {m5,m6g}.4xlarge 來看，分別是 USD$0.768/hr 與 USD$0.616/hr，大約是 20% 的差距，加上效能上的差距，C/P 值看起來是真的有到官方宣稱的 40%，這點在其他 Plurk 也測出了類似的結果：

未來除非是 binary-only 的東西，不然應該會朝著往 ARM 上面測過，再決定要怎麼選 instance type...

AWS 南韓區開第四個 AZ

AWS 南韓區開第四個 AZ 了，比想像中的快不少：「Now Open – Fourth Availability Zone in the AWS Asia Pacific (Seoul) Region」。

而且不像東京，新客戶只能看到三個 AZ：「Regions and Availability Zones」。

*New customers can access three Availability Zones in Asia Pacific (Tokyo).

雖然台灣過去的 routing 都還是沒改善...

AWS 推出直播服務 Amazon Interactive Video Service (Twitch-as-a-Service)

把直播系統包在一起的服務 Amazon Interactive Video Service：「Amazon Interactive Video Service – Add Live Video to Your Apps and Websites」。

這邊先抱怨一下，這個服務的網址是 https://aws.amazon.com/ivs/，但 Elastic Load Balancer (ELB) 卻是 https://aws.amazon.com/elasticloadbalancing/，這是差別待遇啊...

回到原來的主題，這個服務做了幾件事情。收到 RTMPS stream 後，他會轉成許多格式：

If you send the maximum 8.5Mbps, 1080p60 stream, Amazon IVS will create 8.5Mbps 1080p60, 3Mbps 720p60, 2Mbps 720p30, 1.2Mbps 480p30, 800Kbps 360p30, and 400Kbps 160p30 renditions in an ABR stream.

從這份列表可以看出他目前最高只支援 1080p60，而 1440p (2K) 或是 2160p (4K) 看起來都還不支援。

另外因為是包裝 AWS Elemental Media Services，所以有蠻多東西都一起可以拿進來用，像是廣告機制與 DRM，然後看起來可以選擇 CDN：

With AWS Elemental Media Services, you have a high level of control over all workflow components: transcoding and packaging configurations; levels of resilience; personalized ad insertion; and features like content protection for digital rights management (DRM). You also get to choose which video players and CDNs are used.

區域上只開了三區 (us-east-1、us-west-2 與 eu-west-1)，但我在看 AWS 上的標價時整個搞混：

一開始看的時候在找單位但發現沒標，後來研究了一下看起來應該是 per hour？這樣標看起來很像是前面一萬個小時只要 USD$0.32 啊？

另外一個比較有趣的事情是，看起來不像是用 CloudFront 做，因為收費區域的區分跟 CloudFront 不太一樣，實際開下去後發現似乎是用 Twitch 的架構？

我試著開了一個，給了 a9a09e285166.us-east-1.playback.live-video.net 這樣的 endpoint，實際測試發現的確是某種 CDN，指到台灣的機房：

;; ANSWER SECTION:
a9a09e285166.us-east-1.playback.live-video.net. 56 IN A 23.160.0.254
a9a09e285166.us-east-1.playback.live-video.net. 56 IN A 192.108.239.254

實際 traceroute 後發現不是 CloudFront，但反解後發現 dig 拋出了 Justin.tv 的資訊：

;; AUTHORITY SECTION:
0.160.23.in-addr.arpa.  300     IN      SOA     ib-ens.sjc02.justin.tv. admin.justin.tv. 44 10800 3600 604800 300

;; AUTHORITY SECTION:
239.108.192.in-addr.arpa. 300   IN      SOA     ib-ens.sjc02.justin.tv. admin.justin.tv. 49 10800 3600 604800 300

然後 traceroute 可以發現跟 video-edge-6ab612.tpe03.abs.hls.ttvnw.net (在 Twitch 上隨便找個實況抓的 hostname) 進到同一個機房 (在 router 還沒有擋下來的範圍)，看起來就是拿 Twitch 的頻寬做事 XDDD

Twitch-as-a-service XDDD

這包會不會是 Twitch 掛 AWS 牌推出的服務啊 XDDD

Onion Service 第二版的退場計畫

Tor 這邊給出了 Onion Service v2 的退場計畫：「Onion Service version 2 deprecation timeline」，關於 v2 與 v3 的差異，可以參考之前寫的「下一代的 Tor Hidden Service」，裡面有提到 v3 的 spec。

v2 與 v3 最大的差異就是本來 v2 的 hostname 是 16 個英數字 (大約是 80-bit security)，現在 v3 變成是 56 個英數字 (大約是 280-bit security)，大幅降低 collision 的機會。

目前公佈的時間表是在 2020 年九月先拋警告出來，2021 年七月拔掉 server 支援，2021 年十月拔掉 client 支援：

1. September 15th, 2020
0.4.4.x: Tor will start warning onion service operators and clients that v2 is deprecated and will be obsolete in version 0.4.6.

2. July 15th, 2021
0.4.6.x: Tor will no longer support v2 and support will be removed from the code base.

3. October 15th, 2021
We will release new Tor client stable versions for all supported series that will disable v2.

差不多是十五個月的計畫...

Amazon SES 開東京區與新加坡區了...

Amazon SES 是 2011 年年初發表的服務，過了九年總算想起來這幾區也是需要 SES 的服務了...：「Amazon Simple Email Service is now available in the US East (Ohio), Asia Pacific (Singapore), Asia Pacific (Tokyo), and Asia Pacific (Seoul) Regions」。

這些年來大家應該都是用 us-west-2 或是 us-east-1 workaround 很久了，現在開這些區域主要還是讓 API 的整合會比較方便，如果本來就是透過 IAM user + username + password 的方式寄信的話就沒什麼差...

另外一種是寄比較大的信件 (產生的流量很大)，這次這樣可以避免降低跨區而被收兩次流量費用，不過這應該是比較少見的情況...

AWS 宣佈提昇 Amazon EFS 的最低效率

AWS 宣佈提昇 Amazon EFS 的最低效率：「Amazon Elastic File System increases file system minimum throughput」。

第一段裡的幾個數字差不多就是重點了：

Amazon Elastic File System (Amazon EFS) file systems using the default bursting throughput mode now have a minimum throughput of 1 MiB/s. All EFS bursting mode file systems (regardless of size) can drive 100 MiB/s of throughput, and file systems with more than 1TiB of Standard class storage can drive 100 MiB/s per TB when burst credits are available. This change increases the minimum throughput from 50KiB/s per GiB of Standard class storage to a fixed minimum of 1 MiB/s for file systems with less than 20 GiB of Standard class storage, when burst credits are exhausted.

本來最低保證效率是每 GB 提供 50KB/sec，也就是要使用到 20GB 才會提供 1MB/sec，現在對於不到 20GB 的使用者，直接拉高到固定 1MB/sec。

這對於剛開始用的使用者會方便一些，不過 EFS 主要還是方便在不同機器上共享，效率上還是本機掛 EBS 好很多 (因為 OS 可以 cache)。

先前在 AWS 上把 /home 丟到 EFS 上面，結果因為 i/o 都需要透過網路的關係，編 pyenv 超慢，後來找一天把東西都丟回 EBS 上，速度快多了...

雞肋功能：AWS 推出 Managed Prefix Lists 管理 IP 列表

AWS 總算推出可以管理 IP 列表的功能 Managed Prefix Lists，就不需要自己在 security group 裡面針對一堆 IP 設重複的設定：「Amazon Virtual Private Cloud (VPC) customers can now use their own Prefix Lists to simplify the configuration of security groups and route tables」。

目前這個功能在大多數的區域都開放使用了：

There is no additional charge to use the Prefix Lists. Support for Prefix Lists is available in all public regions with support in Africa (Cape Town), Europe (Milan), China (Beijing), and China (Ningxia) coming soon. For more information on prefix lists, visit our public documentation.

但實際測試後發現在 web console 的操作上不算好用，主要是因為這個功能還是會受到「How do I increase my security group limits in Amazon VPC?」這邊提到的限制影響，如果沒有開 support ticket 調高限制，預設值是：

  • 每個 network interface 可以設定 5 個 security group。
  • 每個 security group 可以設定 60 條規則。

在建立 prefix list 時，需要設定「裡面會包含的最大數量」(可以到 1000)，是一個你不知道為什麼要設定的東西，然後我就很開心設了 1000...

接下來開了一個純測試用的 security group (裡面是空的)，結果這個 prefix list 掛不上去...

後來測了幾次後發現 prefix list 在 security 內不是吃一條 rule，而是直接照剛剛設定的「最大數量」去展開。

所以重新砍掉建一個新的 prefix list，改成 15 條後，就可以在 security group 上面掛四次 prefix list (不同的 port)，剛好吃完 60 條規則，第五個設定就完全掛不上去... (無論是用 prefix list，或是設定 CIDR)

所以這些限制讓 prefix list 在 web console 上變得很不怎麼好用：

  • 一開始就要設計好 prefix list 內的最大筆數，如果不幸用完是沒辦法修改的。
  • 在 security group 裡不是吃一條規則，而是以最大筆數佔用，prefix list 內沒有射到最大筆數也還是得佔用。

但如果變成 Terraform 之類的工具用的話就還馬馬虎虎，因為你可以設計機制，改 prefix list 時可以開新的 prefix list (最大上限設成實際的數量，不會有浪費)，然後再把 security group 裡面的 prefix list reference 換掉。

不過又想到，都已經用 Terraform 這種工具了，加上你又不是只佔一條規則，我就自己展開就好了啊... 不需要這個功能就能處理了。

「雞肋」XD