Google SRE 團隊整理出過去二十年的十一條心得

Google 的 SRE 團隊整理出過去二十年的心得,當看故事的心態在看的:「Lessons Learned from Twenty Years of Site Reliability Engineering」,在 Hacker News 上也有討論:「Lessons Learned from Twenty Years of Site Reliability Engineering (sre.google)」。

裡面的項目大多都會在公司成長時不斷的導入,都是夠大就會遇到的。

比較有趣的是第六條,這是唯一一條全部都用大寫字母列出來的:

COMMUNICATION CHANNELS! AND BACKUP CHANNELS!! AND BACKUPS FOR THOSE BACKUP CHANNELS!!!

到 Google 這個規模的架構,這邊就會規劃找完全獨立於 Google 架構的方案來用;我猜應該是傳統的 colocation 機房 (像是 AT&T 之類的),上面跑 IRC server 之類的?

在 Hacker News 上面也有其他人提到 Netflix 也有類似的規劃,需要有一個備援的管道是完全獨立於 AWS 的;另外同一則 comment 裡也有提到 Reddit 的作法是在辦公室裡面放 IRC server 備援:

Yes! At Netflix, when we picked vendors for systems that we used during an outage, we always had to make sure they were not on AWS. At reddit we had a server in the office with a backup IRC server in case the main one we used was unavailable.

IRC 還是很好用的 XD

GCP 的 IPv4 也要漲價了

前幾天收到 GCP 的信件,提到 2024/02/01 開始 IPv4 address 要漲價了,在「External IP address pricing」這邊也可以翻到這些資訊。

External IP 的部分,漲 25%:

Static and ephemeral IP addresses in use on standard VM instances will go from $.004 to $.005.

Static and ephemeral IP addresses in use on preemptible VM instances will go from $.002 to $.0025.

用一個月 720 小時算,一般 VM 的費用等於是從 $2.88/mo 漲到 $3.6/mo 左右的費用。

Cloud NAT 吃的 IPv4 address 的部分,從本來沒有收變成要收費:

Static and ephemeral IP addresses mapped to Cloud NAT Gateway will go from No Charge to $0.005.

GCP 提供每個區域的 Standard Tier Networking 每個月 200GB 的免費頻寬

GCP 提供每個區域 Standard Tier Networking 每個月有 200GB 的免費頻寬:「Announcing 200 GB free Standard Tier internet data transfer per month」。

這類優惠應該是要給練習或是試用的人用的,吸引他們放一些量上來...

另外雖然是每個區域都有 200GB/mo 的 free bandwidth,但通常也只會用一個或兩個區域,以台灣的 asia-east1 來說,如果有量在上面跑的話,省下來的會是 $0.07/GB 這個部分,大概就是 $14/mo 左右?

SQLite 官方自己搞的 Cloud Backed SQLite

SQLite 自己搞了一套使用雲端空間為儲存空間的技術:「Cloud Backed SQLite」,對應的 Hacker News 討論可以看「Cloud Backed SQLite (sqlite.org)」這邊。

他說目前支援 Azure Blob StorageGoogle Cloud Storage,這點比較有趣,沒有提到 Amazon S3

The system currently supports Azure Blob Storage and Google Cloud Storage. It also features an API that may be used to implement support to other cloud storage systems.

跟之前的 sql.js 專案不太一樣,sql.js 的作法是用 HTTP range 存取現有的 SQLite 資料庫檔案,而這次的這個專案則是改變底層架構,去配合雲端環境的特點。

雲端的 storage 因為每個 access 都會有很高的 latency (相比於本地的空間),所以要避免太多 random access,儘量以 sequential access 為主,這個特性像是以前在處理傳統磁頭硬碟時的技巧。

另外一個特點是雲端空間有多檔案的概念,所以也可以利用這個方式設計資料結構。

還蠻有趣的計畫,而且是官方搞的...

AWS Aurora Xanadu?

在「Why PostgreSQL High Availability Matters and How to Achieve It (yugabyte.com)」裡面看到 AWS 也在研發類似 GCP 提供的 Spanner 的服務,計畫名稱叫做 Aurora Xanadu:「36328981」。

franckpachot

Google has Spanner. AWS is working on something similar (project Aurora Xanadu). And both have YugabyteDB in their marketplace. Those are Distributed SQL (Global ACID), not Citus. For DataWarehouse which doesn't need ACID, there are other services.

也先把這個連結備份起來,看看後面是不是直接拿這個名字來用?

GCP 的 Disks 與 AWS 的 EBS 的比較...

下午在升級 GCP 上面的跳板機的時候,發現機器用的是 Standard Persistent Disk (Standard PD),這是個 HDD 架構,跑起來超慢,研究了一下發現 AWS 與 GCP 兩邊的差異其實有點大,整理一下...

價錢的部分,AWS 的部分拿東京區 (ap-northeast-1) 的價錢來看,GCP 則是拿台灣區 (asia-east1) 來看。

先看 SSD 的部分:

AWS 最常用的 gp3 是 $0.096/GB,無論空間大小,效能上都提供 3000 IOPS 與 125MB/sec throughput,另外可以加價購買 IOPS 與 throughput。不過也因為這個性質,拿來當開機碟很好用。

早期的 gp2 則是 $0.12/GB,效能上提供 3 IOPS/GB,但最低會給 100 IOPS,所以當開機碟也還可以,不會到太慢。

GCP 如果是 Balanced Persistent Disk (Balanced PD) 是 $0.1/GB,效能上會提供 6 Read IOPS/GB + 6 Write IOPS/GB + 0.28MB/sec/GB throughput;以 10GB 的 disk 來說會是 60 Read IOPS + 60 Write IOPS + 2.8MB/sec throughput。

如果是 SSD Persistent Disk (SSD PD) 是 $0.17/GB,效能上是 30 Read IOPS/GB + 30 Write IOPS/GB + 0.48MB/sec/GB throughput;以 10GB 的 disk 來說會是 300 Read IOPS + 300 Write IOPS + 28MB/sec throughput。

再來是 HDD 的部分:

AWS 這邊代號是 standard,價錢是 $0.08/GB,另外 IOPS 每 1M 個 IOPS 也要收 $0.08,如果是拿來開機的話還好,但如果是有應用在上面操 IOPS 的話就不太便宜了。

GCP 這邊是 Standard Persistent Disk (Standard PD),價錢是 $0.04/GB,效能上提供 0.75/GB Read IOPS + 1.5/GB Write IOPS + 0.12MB/sec/GB throughput;以 10GB 的 disk 來說會是 7.5 Read IOPS + 15 Write IOPS + 1.2MB/sec throughput。

所以如果是不太在意效能的情況下要找 C/P 值 (但也不到完全不在意?),在 AWS 上用 standard 就不太划算,畢竟多一些些費用就可以用 gp3,對效能提升巨大;但在 GCP 上就會想用 Standard PD,從單價可以看到差了蠻多...

Google Cloud 宣佈明年關閉 IoT Core Services

Hacker News 上的「Google IoT Core will be discontinued on Aug. 16, 2023」這篇,大家在討論 Google Cloud 宣佈明年關閉 IoT Core Services 的事情,基本上討論的內容大概都想的到...

AWS 這邊的話,最近比較有印象的就是要淘汰 EC2 Classic (EC2-Classic 的狀態),但到現在還是在跑。

另外一個是把 Xen 架構 porting 到 Nitro 上 (AWS 將新的 Nitro 架構回過投來支援以前 Xen 的機種),讓原有的 Xen 應用可以繼續用。

久一點以前的 SimpleDB 到現在也還是活著,官方現在應該是主力在推 DynamoDB

兩種完全不同的作法...

AWS DataSync 支援 GCP 與 Azure 上的 Storage 上的資料了

AWS DataSync 宣佈支援 GCP 與 Azure 上的 Storage 了:「New for AWS DataSync – Move Data Between AWS and Other Public Locations」,比較特別的是,文章的 URL 有提到這兩家的產品,但在標題上反而就沒提到...

這測的重點就是支援 Google CloudMicrosoft Azure 的 object storage 產品:

Today, we added to DataSync the capability to migrate data between AWS Storage services and either Google Cloud Storage or Microsoft Azure Files.

之前大家都是自己開機器手動搬,現在可以直接付錢 (依照 GB 計費) 用服務搬了,不過要注意網路頻寬的流出部份還是有費用...

GCP 推出 AlloyDB,一套相容 PostgreSQL 協定的資料庫服務

也是在清 RSS reader 的時候翻到的,看起來是在今年的 Google I/O 上發表的服務,AlloyDB:「AlloyDB for PostgreSQL under the hood: Intelligent, database-aware storage」,值得提的是這篇有中文版可以看:「適用於 PostgreSQL 的 AlloyDB 隆重登場:從此擺脫成本高昂的老舊資料庫」。

另外還有一篇比較偏 PR 的文章也可以看看:「Introducing AlloyDB for PostgreSQL: Free yourself from expensive, legacy databases」,這篇就比較針對的提到了與 AWS 的服務相比,但畢竟是 PR 稿沒有明講 (出事會比較好打模糊戰),但我猜測是與 Aurora 對比:

AlloyDB was also two times faster for transactional workloads than Amazon’s comparable service.

宣稱在 OLTP 上快了兩倍 (原來的三倍?),但應該都是以 PostgreSQL 下去改,猜測可能是底層的 storage 與 replication 比較好?

AlloyDB 設計上是考慮了 HTAP (Hybrid transactional/analytical processing) 的使用,所以同時可以提供 OLAP 與 OLTP 的應用:

[...] This makes AlloyDB a great fit for business intelligence, reporting, and hybrid transactional and analytical workloads (HTAP).

直接在一個資料庫內處理 OLAP 與 OLTP 這點的確會讓 AlloyDB 比 AWS 目前能提供的方案方便不少 (然後想一下 BigQuery 團隊...)。

目前在 AWS 對應的方案應該是透過 Redshift 來解決,另外一個方案是透過 Athena 來跑。

最後來看價錢,如果效能變成兩倍但價錢也是兩倍的話,就代表在價格上沒優勢。

先看機器的部份,如果是拿 Aurora 這邊 Intel-based 的 db.r5.24xlarge (96 vCPU + 768 GB RAM) 來算的話是 US$13.92/hr,而如果換算到 AlloyDB 的話是 US$14.94528/hr,相除是 0.9314,大約 7% 的差距,可以算是同一個級距。

如果 Aurora 這邊是拿 ARM-based 的 db.r6g.16xlarge (64 vCPU + 512 GB RAM) 來算的話是 US$8.306/hr,換算到 AlloyDB 的話是 US$9.96352/hr,相除是 0.8336,這邊就差超過 16% 了...

(這邊剛好回顧一下 "Amazon’s comparable service" 這段,不確定他是跟 Intel-based 比還是跟 ARM-based 比,畢竟 ARM 除了比較便宜外,還有效能的提昇)

但最大的差異應該是在 storage 相關的部份。其中 Aurora 這邊的空間與 I/O 是分開收費的,以 us-east-1 來說,storage 是 US$0.10/GB/mo,而 I/O 是 US$0.20/million-requests,在 AlloyDB 這邊來說,Regional cluster storage 是 US$0.0004109/GB/hr (us-east4),變成是 US$0.295848/GB/mo,兩邊相比後可以算出來對等的計價會是 AWS 的 storage 加上 AWS 給你 1.47M 的 I/O (per GB)。

這樣算起來把資料丟 S3 跑 Athena 可能不會比較貴... (當然效能是另外的主題了)

光就檯面上的資料來看,看起來是個不錯的東西,等後續有人跳進去用看看感想...

Google 與 AWS 都釋出往 OpenTelemetry 靠攏的消息

前幾天看到 GoogleAWS 都釋出往 OpenTelemetry 靠攏的消息:「OpenTelemetry's First Release Candidates」以及「Public Preview – AWS Distro for OpenTelemetry」。

AWS 這邊的 AWS X-Ray 看起來跟 OpenTelemetry 有點關係,找了一下果然發現之前有些計畫在跑:「AWS X-Ray SDK w/ OpenTelemetry API」,不過看起來後續應該是由「AWS Distro for OpenTelemetry」這個計畫接手了。

另外 Google 這邊看起來則是 Cloud Trace 這個產品線,本來在推的 OpenCensusOpenTracing 從網站上可以看到決定會再支援兩年,但重心會改放到 OpenTelemetry 上:

OpenCensus and OpenTracing have merged to form OpenTelemetry, which serves as the next major version of OpenCensus and OpenTracing. OpenTelemetry will offer backwards compatibility with existing OpenCensus integrations, and we will continue to make security patches to existing OpenCensus libraries for two years.

翻了一下 Azure 相關的消息,先前有一些稿子是會往 OpenTelemetry 支援,但這一波沒看到新聞稿...