Amazon RDS for PostgreSQL 可以掛 155 台 Read Replica

看到 AWS 推出的新「功能」,可以讓 Amazon RDS for PostgreSQL 的 read replica 掛到 155 台:「Amazon RDS for PostgreSQL supports cascaded read replicas for up to 30X more read capacity」。

作法是透過三層架構,每台機器可以堆五台 replica:

Amazon Relational Database Service (Amazon RDS) for PostgreSQL announces support for PostgreSQL 14 with three levels of cascaded read replicas, 5 replicas per instance, supporting a maximum of up to 155 read replicas per source instance.

需要 PostgreSQL 14.1 或是之後的版本:

Starting with Amazon RDS for PostgreSQL 14.1 and higher, read intensive workloads such as data analytics can now benefit from up to 155 cascaded read replicas that offer up to 30 times higher read capacity versus previous versions of PostgreSQL, thereby reducing the load on source instance.

我記得 Amazon RDS for PostgreSQL 的 replica 是 EBS block-level replication,這種搞法還蠻有趣的 XDDD

Amazon SESv2 的 Deliverability Dashboard

其實是看到「Amazon SES V2 now supports email size of up to 40MB for inbound and outbound emails by default」這篇才注意到寄信的 Amazon SES 服務有了 SESv2,原文主要是講放寬信件的大小限制:

With this launch, the default message size limit in Amazon SES V2 increases from 10MB for email sending and 30MB for email receiving, to 40MB for both sending and receiving .

不過我跑去「Amazon SES pricing」看的時候意外翻到這個貴貴的東西:

The Deliverability Dashboard (via the SES API V2) is available for a fixed price of USD $1,250 per month. This charge includes reputation monitoring for up to five domains and 25 predictive email placement tests.

然後我試著去找 Deliverability Dashboard 是什麼,卻沒有專文介紹?(還是我找錯關鍵字...)

倒是在 2018 年的時候 Amazon Pinpoint 有個公告提到 Deliverability Dashboard,價錢也是 US$1,250/mo:「Amazon Pinpoint Announces a New Email Deliverability Dashboard to Help Customers Reach their Users' Inboxes」。

本來以為是 Amazon Pinpoint 的服務轉移掛到 SESv2 下,但看「Amazon Pinpoint Pricing」這邊,好像還是在啊...

雖然用不太到,但還是一頭霧水 XDDD

Slack 在 2022/02/22 發生的 downtime 說明

Slack 針對今年年初的爆炸提出了說明:「Slack’s Incident on 2-22-22」,但真正的重點都在 Hacker News 的討論串上:「Slack’s Incident on 2-22-22 (slack.engineering)」。

大概有三件事情可以講,第一個是掛掉的原因,第二個是剛發出來的時候,一堆人對於標題用的「2-22-22」很感冒,第三個是剛剛 (一個小時前),Cal Henderson (Slack 的 CTO) 跑到 Hacker News 的討論串上回應...

Downtime 的部份

這次的 downtime 主要是發生在 Group Direct Message (GDM) 的部份:

A significant element of the datastore load appeared to be from a query that listed Group Direct Message (GDM) conversations by user. This operation is fronted by our cache tier, so the high query load seemed to indicate something was wrong with our caches.

這個 GDM 的查訊效率不高,而是靠 cache layer 撐住的,加上二月 22 日那天他們在更新 Consul 的 agent,導致 hit rate 的下降,以及遇到一個比較大的 peak time,接著就壓垮了資料庫。

oh,這中間還有 Vitess 一起進來打架,原文講的比較清楚,但需要花一些時間看。

2-22-22

剛發表出來的時候,其實大多數的討論反而是在討論「2-22-22」這件事情,這的確是很差的表示方法,尤其對於一份公告來說,不過這個問題本來就是個 flame war 等級的話題...

Slack CTO (Cal Henderson) 的回應

在重刷頁面的時候發現 iamcal 這個帳號的回應,而 Cal Henderson (Slack CTO) 的個人網站是 www.iamcal.com,雖然不確定這是不是本人帳號,但看起來之前在 2011 註冊後都沒動...

這個帳號回了兩個訊息,一個是提到 AWS 上其實很常看到 failure,需要靠本身架構的穩定性來撐:

Our underlying hardware (AWS) is nothing like this reliable. We see regular (several times a year) failure of racks of machines or whole DCs.

Across the whole fleet (all services), we lose 1-10 servers per day as a baseline. Major events are then on top of that and can impact thousand of hosts at once.

另外一個是反駁自以為的量級估算:

> Even the largest Slack instance probably has under 100,000 users and less than 1000 peak messages per second.

This is not true, by an order of magnitude.

好像還可以繼續在盯一下,不知道還會不會有回應...

AWS Lambda 可以直接有 HTTPS Endpoint 了

AWS 宣佈 AWS Lambda 可以直接有一個 HTTPS Endpoint 了:「Announcing AWS Lambda Function URLs: Built-in HTTPS Endpoints for Single-Function Microservices」。

如同文章裡面提到的,先前得透過 API Gateway 或是 ALB 才能掛上 Lambda:

Each function is mapped to API endpoints, methods, and resources using services such as Amazon API Gateway and Application Load Balancer.

現在則是提供像 verylongid.lambda-url.us-east-1.on.aws 這樣的網域名稱給你用,而且看說明似乎是直接包含在本來的 Lambda 價錢內?就不用另外搞 API Gateway 或是 ALB 了:

Function URLs are included in Lambda’s request and duration pricing. For example, let’s imagine that you deploy a single Lambda function with 128 MB of memory and an average invocation time of 50 ms. The function receives five million requests every month, so the cost will be $1.00 for the requests, and $0.53 for the duration. The grand total is $1.53 per month, in the US East (N. Virginia) Region.

這讓我想到可以用 Lambda 當特製的 HTTP proxy 的專案,好像可以拿來整到 feedgen 裡面用?

PHP (以及 Laravel) 下使用 DynamoDB 的 ORM 工具

Twitter 上看到「Laravel DynamoDB Eloquent Models and Query Builder」這篇文章,裡面講「Laravel DynamoDB」這個套件,可以在 PHP (以及 Laravel) 下存取 DynamoDB

雖然套件提到了 Laravel,但文件裡面也有提到支援非 Laravel 的 PHP 環境下使用,單獨拿出來用也沒問題,比較重要的反倒是 DynamoDB 對各種 key 的概念。

如果是從零開始設計,但又不想要自己管資料庫,我會偏好先用 RDS 設計,無論是 MySQL 或是 PostgreSQL 的版本都行,畢竟 RDBMS 上面能做的事情比較多,對開發者比較友善,除非是第一天上線你就預期量會大到連 db.m5.24xlarge 都擋不住之類的情況...

AWS 將會把超過兩年的 EC2 AMI 自動設為 Deprecated

AWS 的公告,超過兩年的 EC2 AMIs (Amazon Machine Images) 將會被標為 deprecated:「Amazon EC2 now reduces visibility of public Amazon Machine Images (AMIs) older than two years」。

標成 deprecated 後主要的差異會是在 DescribeImages 這隻 API 上,除了 image 的擁有人外,其他人都不會顯示出來:

Once an AMI is deprecated, it will no longer appear in DescribeImages API calls for users that aren’t the owner of the AMI.

不過知道 AMI 的 id 還是可以直接開:

Users of a deprecated AMI can continue to launch instances and describe the deprecated AMI using its ID.

沒有特地說明原因,但應該是考慮到安全性,這年頭超過兩年不更新的系統大概都有一堆洞?不過馬上就想到 OpenBSD 好像未必...

Amazon RDS 的 Free Tier 方案包含了 db.t3.micro 與 db.t4g.micro

AWSdb.t3.microdb.t4g.micro 都放進 free tier 了:「Amazon RDS Free Tier now includes db.t3.micro, AWS Graviton2-based db.t4g.micro instances in all commercial regions」。

Customers new to AWS in the past 12 months and who were in regions where db.t2.micro was not available can now create free tier db.t3.micro or db.t4g.micro instances for the remainder of their first 12 months.

看說明是註冊的 12 個月內有這個方案可以用,可以拿來跑一些小東西...

昨天在 AWS User Group Taiwan 上分享的「High Availability Vault Service on AWS Environment」

昨天在「AWS User Group Taiwan Meetup 2022-03 線上 / 下小聚」這邊分享的主題,在講如何在 AWS 上弄出一個高可靠性的 Vault 服務。

投影片在 https://bit.ly/3igUbgh 這邊可以抓到,我另外傳到 Speaker Deck 上面了:(好久沒用這個網站了?)

其實這類架構的設計有點像是 AWS 的 Solution Architect 在做的事情,如果一般的客戶開出類似的需求,應該也是會設計出類似的東西...

另外畢竟是在 AWS 的會議室裡面講,有些東西還是會避免提到,但裡面有很多概念是可以互換的,像是 Microsoft Azure 或是 GCP 上面都有可以抽換的服務,Vault 也都有支援。

AWS KMS 與 AWS ACM 支援 post-quantum TLS ciphers

AWS 宣佈 AWS KMSAWS ACM 支援 post-quantum TLS ciphers:「AWS KMS and ACM now support the latest hybrid post-quantum TLS ciphers」。

全區支援 Kyber、BIKE 與 SIKE 這三個演算法:

The three PQC key encapsulation mechanisms (KEMs) offered are Kyber, BIKE, and SIKE. Hybrid post-quantum TLS combines a classical key agreement, such as ECDHE, with one of these KEMs. The result is that your TLS connections inherit the security properties of both the classical and post-quantum key exchanges.

Hybrid post-quantum TLS for AWS KMS and ACM is available in all public AWS Regions.

不過這是 NIST Post-Quantum Cryptography Standardization 裡 Round 3 裡面其中幾個演算法而已:

AWS Key Management Service (KMS) and AWS Certificate Manager (ACM) now support hybrid post-quantum key establishment for transport layer security (SSL/TLS) connections using the latest post-quantum ciphers from Round 3 of the NIST Post-Quantum Cryptography (PQC) selection process.

順便補一下隔壁棚 Cloudflare 的研究:「Making protocols post-quantum」。

Route 53 支援 DNS64,以及 NAT Gateway 支援 NAT64

AWS 宣佈了一套機制,讓 IPv6-only 的機器可以連到 IPv4-only 的服務:「Let Your IPv6-only Workloads Connect to IPv4 Services」。

首先是 DNS64,針對只有 IPv4-only 的 A record 自動加上 AAAA record (如果已經有 AAAA record 的則不變),這邊提到的 64:ff9b::/96 是來自 DNS64 標準內的規範:

The DNS resolver first checks if the record contains an IPv6 address (AAAA record). If it does, the IPv6 address is returned. The IPv6 host can connect to the service using just IPv6. When the record only contains an IPv4 address, the Route 53 resolver synthesizes an IPv6 address by prepending the well-known 64:ff9b::/96 prefix to the IPv4 address.

再來就是 NAT Gateway 可以把 64:ff9b::/96 透過 NAT64 轉到 IPv4 network 上:

You may configure subnet routing to send all packets starting with 64:ff9b::/96 to the NAT gateway. The NAT gateway recognizes the IPv6 address prefix, extracts the IPv4 address from it, and initiates an IPv4 connection to the destination. As usual, the source IPv4 address is the IPv4 address of the NAT gateway itself.

由於有些 protocol 會帶 IP address 資訊,所以不能保證 NAT64 一定會動,但大多數的情況應該是可以解決,至少提供了 IPv6-only server 連到 IPv4-only network 上的方法...