幹壞事是進步最大的原動力
Meta 發佈了 Llama 3.1：「Introducing Llama 3.1: Our most capable models to date」，這本來就只是個發佈而已，但讓我注意到的是 AWS 與 GCP 都同時宣佈在雲端上支援 Llama 3.1 了：
這代表 Meta 在 Llama 3.1 發表前就先跟 AWS & GCP 合作了，這看起來是一個包圍 OpenAI (以及微軟) 的姿態，之前好像沒看到這樣？(單純印象...)
前幾天收到 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 的免費頻寬：「Announcing 200 GB free Standard Tier internet data transfer per month」。
這類優惠應該是要給練習或是試用的人用的，吸引他們放一些量上來...
另外雖然是每個區域都有 200GB/mo 的 free bandwidth，但通常也只會用一個或兩個區域，以台灣的 asia-east1 來說，如果有量在上面跑的話，省下來的會是 $0.07/GB 這個部分，大概就是 $14/mo 左右？
在「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 上面的跳板機的時候，發現機器用的是 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，從單價可以看到差了蠻多...
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 了：「New for AWS DataSync – Move Data Between AWS and Other Public Locations」，比較特別的是，文章的 URL 有提到這兩家的產品，但在標題上反而就沒提到...
這測的重點就是支援 Google Cloud 與 Microsoft 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 計費) 用服務搬了，不過要注意網路頻寬的流出部份還是有費用...
也是在清 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 靠攏的消息：「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 這個產品線，本來在推的 OpenCensus 與 OpenTracing 從網站上可以看到決定會再支援兩年，但重心會改放到 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 支援，但這一波沒看到新聞稿...
在台灣如果是透過 HiNet 連 Telegram 是沒什麼問題 (不需要翻牆)，不過連結的 preview 以及圖片影片讀取的速度實在很慢，試著在 GCP (彰濱機房) 跟 Vultr (東京機房) 上架 Proxy 測試看看，發現速度都改善很多...
這邊用的是官方提供的 MTProxy，我把安裝的懶人包放在自己的 wiki 上了：「MTProxy」，在 AWS 或是 GCP 上安裝時，因為網卡拿到的是 Private IP 而非對外的 Public IP，需要指定 --nat-info 告訴 MTProxy 要針對協定裡面的 IP address 另外處理。
跑一陣子再來看看有什麼可以調整的...