幹壞事是進步最大的原動力
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 另外處理。
跑一陣子再來看看有什麼可以調整的...
Google Cloud Platform 一開始是提供 Premium Network，會透過 Google 自家的網路骨幹連到最近的點，然後再透過當地的機房交換出去，這樣可以確保頻寬的穩定性，但成本當然也就比較高...
後來提供了 Standard Network 則是從機房出去後就直接交換，成本會比較低 (參考「Network Service Tiers - Custom Cloud Network」這篇)，但在台灣的機房一直都沒有提供 Standard Network (好像是需要另外申請？)，所以我每個月月底的時候都會測一下看看開放了沒... 然後剛剛發現可以開起來了，不確定是已經全開了還是分批開。
測了一下發現網路相當... 爛？是還在調整嗎...
像是 1.1.1.1 的 latency 很高 (自家的 8.8.8.8 當然就沒這個問題)：
PING 1.1.1.1 (1.1.1.1) 56(84) bytes of data. 64 bytes from 1.1.1.1: icmp_seq=1 ttl=49 time=48.9 ms 64 bytes from 1.1.1.1: icmp_seq=2 ttl=49 time=48.5 ms 64 bytes from 1.1.1.1: icmp_seq=3 ttl=49 time=48.5 ms --- 1.1.1.1 ping statistics --- 3 packets transmitted, 3 received, 0% packet loss, time 2003ms rtt min/avg/max/mdev = 48.554/48.691/48.964/0.193 ms
然後 168.95.1.1、139.175.1.1 也都很差 (61.31.1.1 不給 ping)：
PING 168.95.1.1 (168.95.1.1) 56(84) bytes of data. 64 bytes from 168.95.1.1: icmp_seq=1 ttl=239 time=21.2 ms 64 bytes from 168.95.1.1: icmp_seq=2 ttl=239 time=21.3 ms 64 bytes from 168.95.1.1: icmp_seq=3 ttl=239 time=21.4 ms --- 168.95.1.1 ping statistics --- 3 packets transmitted, 3 received, 0% packet loss, time 2003ms rtt min/avg/max/mdev = 21.276/21.367/21.454/0.072 ms
PING 139.175.1.1 (139.175.1.1) 56(84) bytes of data. 64 bytes from 139.175.1.1: icmp_seq=1 ttl=53 time=63.4 ms 64 bytes from 139.175.1.1: icmp_seq=2 ttl=53 time=62.9 ms 64 bytes from 139.175.1.1: icmp_seq=3 ttl=53 time=62.9 ms --- 139.175.1.1 ping statistics --- 3 packets transmitted, 3 received, 0% packet loss, time 2003ms rtt min/avg/max/mdev = 62.967/63.139/63.455/0.303 ms
不過學術網路倒是還不錯：
PING 140.112.2.2 (140.112.2.2) 56(84) bytes of data. 64 bytes from 140.112.2.2: icmp_seq=1 ttl=51 time=5.13 ms 64 bytes from 140.112.2.2: icmp_seq=2 ttl=51 time=4.40 ms 64 bytes from 140.112.2.2: icmp_seq=3 ttl=51 time=4.52 ms --- 140.112.2.2 ping statistics --- 3 packets transmitted, 3 received, 0% packet loss, time 2003ms rtt min/avg/max/mdev = 4.405/4.690/5.138/0.325 ms
PING 140.113.250.135 (140.113.250.135) 56(84) bytes of data. 64 bytes from 140.113.250.135: icmp_seq=1 ttl=55 time=5.87 ms 64 bytes from 140.113.250.135: icmp_seq=2 ttl=55 time=5.97 ms 64 bytes from 140.113.250.135: icmp_seq=3 ttl=55 time=6.11 ms --- 140.113.250.135 ping statistics --- 3 packets transmitted, 3 received, 0% packet loss, time 2002ms rtt min/avg/max/mdev = 5.872/5.987/6.119/0.135 ms
PING 140.117.11.1 (140.117.11.1) 56(84) bytes of data. 64 bytes from 140.117.11.1: icmp_seq=1 ttl=242 time=9.52 ms 64 bytes from 140.117.11.1: icmp_seq=2 ttl=242 time=9.17 ms 64 bytes from 140.117.11.1: icmp_seq=3 ttl=242 time=9.20 ms --- 140.117.11.1 ping statistics --- 3 packets transmitted, 3 received, 0% packet loss, time 2003ms rtt min/avg/max/mdev = 9.172/9.298/9.521/0.176 ms
有需要的人可以測試看看了...
收到信件通知，本來在 GCE 上使用的 Public IP address 是免費的，2020 年開始變成要收 USD$0.004/hr (Standard，約 USD$2.88/month) 或是 USD$0.002/hr (Preemptible，約 USD$1.44/month)：
First, we’re increasing the price for Google Compute Engine (GCE) VMs that use external IP addresses. Beginning January 1, 2020, a standard GCE instance using an external IP address will cost an additional $0.004/hr and a preemptible GCE instance using an external IP address will cost an additional $0.002/hr.
從 2020 年一月開始生效，但是前三個月會用 100% discount 的方式呈現在帳單上 (所以還是免費)，這樣你會知道你的 IP address 費用會吃多少錢：
We will fully discount any external IP usage for the first 3 months to help you quantify the impact of these pricing changes. Please take note of the following dates:
January 1, 2020: Although your invoice will show your calculated external IP-related charges, these will be fully discounted and you will not need to pay these.
April 1, 2020: You will need to pay for any incurred external IP-related charges shown on your invoice.
其實整體成本應該是還好，但看到漲價總是不開心... XD
在泰國住的飯店提供頗快的網路：
不過到 HiNet 看起來應該是有繞到美國之類的地區？
gslin@Gea-Suans-MacBook-Pro [~] [08:16/W4] mtr --report 168.95.1.1 Start: 2019-04-07T08:16:33+0700 HOST: Gea-Suans-MacBook-Pro.local Loss% Snt Last Avg Best Wrst StDev 1.|-- 10.10.20.1 0.0% 10 1.8 2.0 1.3 3.1 0.6 2.|-- node-iyp.pool-101-108.dyn 0.0% 10 3.9 3.6 2.7 4.5 0.6 3.|-- 172.17.36.105 0.0% 10 3.2 4.1 3.2 8.3 1.5 4.|-- 203.113.44.205 0.0% 10 6.5 5.3 3.9 6.7 1.0 5.|-- 203.113.44.177 0.0% 10 5.4 4.8 4.0 7.2 1.0 6.|-- 203.113.37.194 0.0% 10 4.6 6.5 3.0 11.1 2.5 7.|-- in-addr.net 0.0% 10 3.9 4.4 3.1 5.6 0.8 8.|-- ??? 100.0 10 0.0 0.0 0.0 0.0 0.0 9.|-- pcpd-4001.hinet.net 0.0% 10 355.4 356.9 355.1 365.4 3.0 10.|-- pcpd-3212.hinet.net 0.0% 10 215.6 216.6 214.2 225.4 3.4 11.|-- tpdt-3022.hinet.net 0.0% 10 219.4 215.9 214.0 221.5 2.5 12.|-- tpdt-3012.hinet.net 0.0% 10 218.9 217.2 215.0 218.9 1.4 13.|-- tpdb-3311.hinet.net 0.0% 10 212.5 212.9 211.9 214.1 0.6 14.|-- 210-59-204-229.hinet-ip.h 0.0% 10 213.5 212.7 212.0 213.7 0.6 15.|-- dns.hinet.net 0.0% 10 214.4 214.5 213.7 216.0 0.7
這樣有些影音服務只吃台灣 IP 就沒辦法用了，所以就得找方法來解決... 想法是透過我在 GCP 上開的機器繞回 HiNet，所以就得找 Mac 上 SSH 要怎麼設定 Socks5。
本來以為要用 tsocks 之類的工具 (i.e. 用 LD_PRELOAD 處理 connect())，但意外的在「SSH through a SOCKS Proxy? (client = OpenSSH OS X)」這邊看到可以用內建的 nc 處理，因為 nc 有支援 Socks5。
所以就變成兩包 ssh 指令：
ssh -D 1081 gcp.server ssh -D 1080 -o "ProxyCommand nc -X 5 -x 127.0.0.1:1081 %h %p" hinet.server
然後 127.0.0.1:1080 就是打通的版本了，可以讓瀏覽器直接掛上去使用。
至於後來想起來不需要用 Socks5，可以用 ssh -L 而笑出來又是另外一件事情了 :o
看到「Highly Available MySQL Clusters at WePay」這篇講 WePay 用 MySQL 的設計，本來以為是 WeChat 的服務，仔細看查了之後發現原來是 JPMorgan Chase 的服務...
架構在 GCP 上面，本來的 MySQL 是使用 MHA + HAProxy (patch 過的版本，允許動態改變 pool)，然後用 Routes 處理 HAProxy 的 failover。
他們遇到的問題是 crash failover 需要至少 30 分鐘的切換時間，另外就是在 GCP 上面跨區時會有的 network partition 問題...
後續架構變得更複雜，讓人懷疑真的有解決問題嗎 XDDD
改用 GitHub 推出的 Orchestrator 架構，然後用兩層 HAProxy 導流 (一層放在 client side，另外一層是原來架構裡面的 load balancer)，在加上用 Consul 更新 HAProxy 的資訊？
思考為什麼會有這樣設計 (考慮到金融體系的背景)，其實還蠻有趣的...
Google 總算提供把 Cloud SQL 放進內部網路的選項了，雖然目前還是 beta 版本在測試：「Introducing private networking connection for Cloud SQL」。
透過 VPC peering 把自己的網路與 Cloud SQL 的網路接起來，就不需要有 Public Endpoint，於是就有更低的 latency 與更好的安全性。