OpenTofu 釋出第一個 GA 版本 1.7.0

從去年八九月從 Terraform fork 出來並且改名後 (「OpenTF 宣佈從 Terraform 最後一個 Open Source 版本 fork 出來」、「OpenTF (Terraform 的 fork) 改名為 OpenTofu」),總算是推出第一個 GA 版本了:「OpenTofu 1.7.0 is out with State Encryption, Dynamic Provider-Defined Functions, and more」。

除了把 trademark 相關的東西換掉以外,還實作了一些功能,這樣化半年弄出個起頭,接下來看後續的能量?好像還行...

來分析這次地震的電力系統變化

Facebook 上看到 Wei-Chun HwangArduino.Taipei 上貼的文章:「幾周前剛好這裡有在討論自製地震儀,來給各位看一下資料剛剛發生的地震跟市電電壓還有週期的波形」,裡面剛好有很寶貴的資料,記錄下地震當下台北與彰化的電力資料。

最重要的是這兩張圖:(直接對圖片開新頁可以看到 full size)

這兩張圖記錄下電壓與頻率的變化,可以看到台北與彰化的頻率幾乎是一樣的,畢竟台灣本島大多數的區域是在同一個電網系統裡面。

從氣象署的「第019號 4月3日7時58分 規模 7.2 花蓮縣政府南南東方 25.0 公里 (位於臺灣東部海域)」可以查到地震發生在 07:58:09;另外從第一張圖可以看到電網的頻率有幾個不同的變化:

  • 第一波是 07:58:38 左右開始狂掉,然後到 07:58:48 差不多穩下來。
  • 接著的幾秒 (尤其是 07:58:56 這邊) 可以看到一些波動。
  • 然後是 07:59:00 開始掉,到 07:59:06 到低點 (應該是又有機組解聯?)。
  • 然後是 07:59:13 又一波下探,大約是 07:59:16 第一次觸發到 59.5Hz 的計時點。
  • 但沒過幾秒鐘 07:59:20 可以看到一波回拉。

維基百科有提到「P波」的速度,差不多解釋了第一張圖的一些狀況:

地震中P波速度典型值的範圍是5至8 km/s。精確速度以地球內部區域的不同而變化,範圍從地殼的不到6 km/s至地核的13 km/s。

解聯的機組從「為什麼這次地震沒跳電?綠能、電網發揮關鍵作用!」這邊可以查到,包括了台中電廠 (台中)、通宵通霄電廠 (苗栗)、國光電廠 (桃園)、和平電廠 (花蓮)、海湖電廠 (桃園):

根據台電說明,這次地震造成多座電廠機組跳脫、變電所停電,總共影響 320 萬瓩,受影響的包括台電台中電廠 8 號機、10 號機,通霄電廠 5 號機蒸汽輪機 ST 跳脫,民營電廠也有國光電廠 1 號機、和平電廠 2 號機、海湖電廠 2 部氣渦輪機 GT 跳脫。

計算一下桃園與震央的距離大約 130km (用 Google Maps 粗抓),苗栗大約 110km,台中大約 100km;看起來差不多就是 P 波到的時候就自動觸發降載 & 解聯?

接著應該是第二張圖的範圍了,可以看到 08:00 以後有兩波觸 59.5Hz 的情況,這應該就是在「台電4年電網投資3000億 地震當下維持供電韌性關鍵」這篇報導裡面提到:

台電表示,地震發生瞬間,機組一度跳脫達320萬瓩,也就是6部中型機組的量,電力系統頻率瞬間降至59.46Hz,當下將抽蓄機組解聯3台,減少用電;但同時間電池儲能系統瞬間放電提供約51萬瓩,讓系統頻率回升至59.5Hz,避免用戶因低頻卸載導致限電。

目前查不到 4/3 當天的情況,但從這幾個月的歷史資料可以知道台電電網大約在 30000MW 這個量級左右,掉了 3200MW 差不多是 10% 的量。

馬上可以做的是:電池供應 510MW 補了 1.7% 左右;抽蓄機組是 250MW (不確定當時是多少的負載在跑,假設在 50% 運作,約 125MW),三台解聯大約再空出 375MW,差不多是整體的 1.25%。

這兩個馬上切換可以空出大約 3% 的空間出來。

另外一個關鍵的時間點的資料可以從「日月潭抽蓄水力電廠 全台最大天然儲能電池」這邊讀到:

根據台電指出,這種抽蓄水力發電,特性是起動迅速,只要大約7到8分鐘就可啟動出力,每分鐘單一機組可調整出力約10萬瓩。

以最佳的情況來算 (從第一波地震就馬上開始自動切換,加上最短的七分鐘) 會是 08:05:09 左右才開始加入,會發現這無法解釋第二張圖兩個回拉的行為。

這邊不像是綠能突然加入 (因為太陽不會突然變超亮,同理風力也不會突然刮超大風),比較合理的解釋反而可以從 Ptt 上面看到的文章來解讀:「[問卦] 震到停電回報+1」。

台電雖然沒有承認這件事情,但從時間軸上面來看,08:00:00 到 08:05:00 這邊應該是想辦法減輕負載撐過去,然後其他電廠拉高輸出,加上抽蓄併網進來後再恢復原來負載比較合理,不過這件事情政治不正確,大概就不會有太多討論...

不過目前大方向是好的,現代的新科技 (以及對應的新方法) 建立了更多的緩衝...

Trino Gateway

先前一直有在追蹤 TrinoHA 方案:「High Availability #391」,昨天看到有人更新消息,提到 Trino Gateway 這個專案,以及九月底的時候的公告:「Trino Gateway has arrived」。

主要是從 Presto Gateway 整理出來的:

The release is the result of many, many months of effort to move the legacy Presto Gateway to Trino, start a refactor of the project, and add numerous new features.

原始的 Presto Gateway 專案上面也已經標示後續請大家去看 Trino Gateway:

NOTE: This is a legacy version of Trino Gateway. Please refer to https://github.com/trinodb/trino-gateway for active development and updates moving forward.

然後 Release notes 這邊可以看到前幾天又出一個新版了,看起來是有能量在專案上的。

從「Design」這頁可以看到軟體本身分成 BaseApp、ProxyServer 與 Gateway 三個部分,架構面上可以看得出來是 Proxy 架構。

從「References」這頁可以看到一些組織使用前身 Presto Gateway 的心得:

目前應該會需要一些時間,把積在 backlog 的功能開發出來。之後如果還有遇到 Trino 的話可以拿出來重新研究發展到什麼地方...

OpenTF 開張

前陣子有提到因為 HashiCorp 沒有正面回應 (如預期的) 授權的爭議,所以決定將最後一個 open source 版本的 Terraform 給 fork 出來:「OpenTF 宣佈從 Terraform 最後一個 Open Source 版本 fork 出來」。

剛剛在 Hacker News 上看到「OpenTF repository is now public (github.com/opentffoundation)」這個,OpenTF 正式開張了。

瞄了一下 issues,初期還有蠻多雜事得處理的,但跨出第一步了,可以看看社群的能量到底有沒有超過 HashiCorp 自家的能量...

Amazon EBS 十五週年,以及一些數據

AWS 的 SVP James Hamilton 寫了一篇「Amazon Elastic Block Store at 15 Years」在講 Amazon EBS 的十五週年,裡面提到了一些數字。

目前的每天的 IOPS 是 100 trillion,如果攤平的話大約是 11.57 billion IOPS/sec,如果很單純以目前高階 NVMe 卡大約是 1M IOPS/sec 這個數量級來算的話,在沒有任何 redundancy 架構,需要的量大約是萬張?以 AWS 的量感覺好像是個合理的數字... 考慮到 IOPS 主力應該是 SSD 或 NVMe 類的應用,加上 redundancy 以及保留 burst 空間的架構,最少有個十萬張... 應該不算有問題。

I asked the EBS team to quantify customer usage in 2023, the 15th year of EBS. Focusing first on daily usage, EBS delivers more than 100 trillion input/output operations per day.

另外一個是傳輸量,每天有 13EB,攤平大約是 150.46TB/sec,如果用上面提到的十萬顆來攤的話大約是需要 1.5GB/sec 的速度,拿數量級來算應該是差不多。

Perhaps even more staggering is the fact that EBS transfers more than 13 exabytes of data for customers every day.

另外一個是百萬客戶 (也許是帳號) 每天會開出三億個 EBS storage,我猜這跟機器的起起落落有關,現在 EC2 開機主要都是要掛 EBS 的 boot disk 了:

Continuing to focus on daily usage, millions of customers use EBS daily, and these millions of customers create more than 390 million EBS storage volumes each day.

的確如同 James Hamilton 說的,EBS 現在已經變成一個蠻重要的基礎建設了,很多 AWS 上的服務都是架在他上面,像是 RDS 利用了 EBS 的 block replication 組出了 readonly repica,而非走傳統的 replication 路子。

Twitter 的 2022 年架構 (?)

Elon Musk 自己貼了以後,有人把白板圖整理成數位圖後好讀一些:

不過心裡可以先有底,這是解釋給大老闆聽的架構圖,底層可能還會有不少東西是沒有在這上面的,尤其是其他重要的子系統,像是圖片與影音怎麼處理之類的。

先把圖拉出來看原圖大小 (可以自己點),比較清楚一點:

從最前端往後看,可以看到 TLS-API 被標成淘汰中,照圖上寫的剩下 Android 版本在用,後續應該是往 GraphQL 靠;另外內部有使用到 Thrift,但沒有標 gRPC,我猜是這邊的主線上沒有 gRPC 而已,其他系統可能還是會有。

另外是有些東西有標 next-gen system,應該就是正在做而還沒上線的東西。

Ansible 的爭論

前幾天在 Hacker News Daily 上看到「Five Ansible Techniques I Wish I’d Known Earlier」這篇,裡面提到了一些 Ansible 的用法還蠻有用的,算是開始用 Ansible 後應該都會有幫助的用法... 不過 Hacker News 上的討論「Ansible Techniques I Wish I’d Known Earlier (zwischenzugs.com)」比較精彩...

目前在頂端的留言對 Ansible 幹到不行,尤其是那個 YAML 格式:

Ansible is abysmal. I don't know why anyone still chooses it. It's a mess of yaml and what feels like a million yaml files that is always extremely hard to follow. Honestly writing some python, or bash is a lot easier to follow, read, and understand. The only thing it has going for it is the inventory system. I wish ansible would die already.

然後講到 bash 與 python 之類的工具時有人提到 idempotent:

>bash and python
Neither of those of idempotent.

馬上就有人幹勦,大多數人在寫 Ansible playbook 時根本沒人在注意 idempotent,而且一堆 shell script 的東西被塞進 YAML 只能說痛苦 XDDD

Most of the ansible roles I come across written by my team are not idempotent either, its a huge lie that Ansible is idempotent. Its idempotent if you put the effort into make it be but if I see tons of shell or command module invocations without prerequisite checks to see if the work should be done. Most devs I see using Ansible treat it like a shell script written in YAML and to that purpose it sucks.

我自己目前會挑 Ansible 主要還是因為 server 不需要另外裝軟體,是個 production 為導向的設計,再更大的時候就要想一下要怎麼繼續搞下去了...

Terraform 進入 1.0 版

HashiCorp 的東西都還蠻有品質的 (相較於其他的類似方案),其中有一個觀察到的特性是,如果他門把版本維持在 0.x,代表他們自己對軟體的品質與成熟度都不算滿意。

Terraform 算是他們家對於基礎建設資源管理所提出的方案 (尤其是雲端時代的資源),不過之前最頭痛的,每次升級就會發現有些基本的概念會被改掉,所以不是改改關鍵字就可以解決。

這次 Terraform 推出 1.0 版,代表了他們認為產品有一定的成熟度:「Announcing HashiCorp Terraform 1.0 General Availability」,另外在 GitHub 上面的「Release v1.0.0 · hashicorp/terraform」也可以看到:

Terraform v1.0 is an unusual release in that its primary focus is on stability, and it represents the culmination of several years of work in previous major releases to make sure that the Terraform language and internal architecture will be a suitable foundation for forthcoming additions that will remain backward compatible.

另外也可以從他們對相容性的宣示「Terraform v1.0 Compatibility Promises」看出來他們覺得架構上成熟了:

For all future minor releases with major version 1, we intend to preserve backward compatibility as described in detail in the Terraform v1.0 Compatibility Promises. The later Terraform v1.1.0 will, therefore, be the first minor release with new features that we will implement with consideration of those promises.

總算是開始進入會考慮 backward compatibility 的週期了...

AWS 推出了與 5G 結合的 AWS Wavelength

看到「Announcing AWS Wavelength for delivering ultra-low latency applications for 5G」這篇,裡面提到了與 5G 結合的 AWS Wavelength

裡面提到的東西包括了把 AWS 的架構延伸到各家電信的架構裡面,看起來跟剛推出的 AWS Outposts 有關 (參考「AWS Outposts 總算要開始出貨了」這邊的介紹):

AWS Wavelength brings AWS services to the edge of the 5G network, minimizing the network hops and latency to connect to an application from a 5G device.

然後目前已經公佈的,會跟四家電信業者合作,包括北美、歐洲、日本與南韓:

AWS is partnering with leading telecommunications companies around the world, including Verizon, Vodafone, SK Telecom, and KDDI, to launch Wavelength across North America, Europe, Japan, and South Korea in 2020.

有點噱頭,但技術上還在想有什麼用...

各種對 AWS Managemenet Console 的抱怨...

Hacker News Daily 上看到 Reddit 上面有一篇對 AWS Management Console 的抱怨文,差不多是兩個月前開始累積的:「I am stupefied every day by the awfulness of the AWS web console」。

AWS 的主力開發因為是以 API 為主,而 AWS Management Console 能做的事情一直都少蠻多的 (看起來是一個團隊在開發,然後呼叫 API),而且的確是常常中 bug,所以會有這樣的抱怨其實不太意外...

然後就有人放火了:

[–]canadian_sysadmin 24 points 2 months ago
I see you've never used Azure...

[–]myron-semack 18 points 2 months ago
AWS’s console sucks because they don’t give a damn about UI. They are API-first.

Azure’s console sucks because they tried to make it nice but failed.

[–]ryantiger658 5 points 2 months ago
I was scrolling looking for this comment. Azures interface has made me appreciate AWS even more.

Azure 被偷戳了好幾下 XDDD 然後 GCP 也被偷戳了:

[–]edgan 1 point 2 months ago
It could br better, but it is far better than than Azure and GCP. Azure's old one was better than their new beta interface last I saw it. GCP has some interesting ideas, but the side bar centric design doesn't function well. It also tries to do too much, and is too JavaScript-y happy.

通常用 AWS 自己的 CloudFormation 或是第三方的 Terraform 管理還是比較常見的方式 (基於 Infrastructure as code 的概念),而 AWS Managemenet Console 當作是輔助,因為目前的雲端服務在設計上的確是希望你多用 API...