昨天在 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 也都有支援。

台灣 5G 網路偵測「分享」的方式

Twitter 上看到 zmx 分享的 tweet:

原始文章在「[教學]讓5G網路分享不被限速 —— 更改TTL」這邊,目前已經自刪,但已經有人在 Internet Archive 上面先 archive 起來了:「[教學]讓5G網路分享不被限速 —— 更改TTL」。

技術上是偵測 TTL 的數字來決定要怎麼擋 (一般機器的預設是 64),而 TTL 在過 router (像是分享器) 時會自動減一,所以可以用這點來偵測。另外找了一下資料,看起來這個方式應該很久前就有在傳:「[問題] 5G熱點分享問題 (USB分享算不算?) (2020)」、「[問題] 5G熱點分享限制有可能破解嗎? (2021)」。

另外 Nahcoroyk 有提到要關掉 IPv6:

如果你5G是C/F/T家的記得把電腦的ipv6關掉,因為ipv6還是可以分辨你是不是有做分享,剛實測某家ipv6下載一樣會扣 但ipv4就列入行動網路了XD (我用iphone13pro分享給電腦)

在猜之前有些手機不限流,但分享只有 1GB 的海外 SIM 卡應該也是類似的方法在偵測?之後能出國的時候可以研究看看...

在 AWS Summit Taiwan 2021 上講的 HashiCorp Vault

今年的 AWS Summit Taiwan 2021 是線上的形式,早在前一個月前就先預錄好,但開始的時候就忘記要宣傳一下了... 結果是在找資料的時候發現其他人有提到:「AWS實作紀錄 #2:高可用性保管服務 (2021 AWS Summit Taiwan)」。

投影片與影片如果有興趣的人可以去 AWS 活動頁面上看,或者上面提到的那篇。

這次講的主題是想要在雲端上面搭建 Vault,但又不希望自己搞一堆 High Availability 的架構,最好是雲端服務本身就有提供... 而既然是在 AWS 的場子,主要都還是以 AWS 的服務來搭建。

在這次的設計裡,Vault 的資料是放在 DynamoDB 上,然後透過 KMS 管理加密用的,這兩個服務本身都有 High Availability,所以直接用就可以了。

接下來是跑 Vault 程式的部份,這部份得自己處理 High Availability 的架構,我是用兩台很小台的 EC2 instance (t4g.nano) 在跑,這邊也可以換成 ECS 或是 EKS 的 container。

接下來把這兩台 EC2 instance 掛起來的也都是 High Availability 服務:在 EC2 instance 前面用 ELB 擋住提供 HTTP API 服務,另外這邊即使是內部用,也可以上 HTTPS (透過 ACM 掛上 HTTPS 的憑證)。

在 ELB 上看到只有一台機器活著是正常的,因為兩台機器之間是 active-standby 架構,同時間只會有一台機器在運作,而 lock 的機制是 Vault 透過 DynamoDB 實做的,不需要另外處理。

其實裡面大多數的元件都可以抽換,像是 DynamoDB 也可以用其他的服務來當儲存層,馬上可以想到的是 RDSMySQL 或是 PostgreSQL

概念上不算困難,所以投影片上主要就是給設定檔,這樣方便大家抄,不用在自己摸指令摸半天...

Amazon Transcribe 支援台灣的中文辨識了

Amazon TranscribeAWS 的服務,可以把聲音轉成文字 (speech to text),先前最接近台灣用的中文應該是「Mandarin Chinese (Mainland China)」,兩年前曾經試著用過:「Amazon Transcribe (語音轉文字) 支援中文」,但效果不怎麼樣...

剛剛在「Amazon Transcribe now supports speech to text in 6 new languages - Afrikaans, Danish, Mandarin Chinese (Taiwan), Thai, New Zealand English, and South African English」這邊看到消息,Amazon Transcribe 支援台灣的中文辨識了,晚點可以用同一部影片測試看看...

疾管署的 COVID-19 每日送檢數的 Open Data

記者會上有提到現在疾管署的網站上有公開每日送檢數的資料,花了些時間找,在「台灣COVID-19冠狀病毒檢測每日送驗數」這邊可以看到,網站提供的 preview 的界面沒辦法看到最新的資料,但下載後可以看到檔案格式是 UTF-8 的 CSV 檔,應該還算能處理...

找到這個資料花了一些功夫 (因為用 DuckDuckGoGoogle 都沒直接找到),後來是靠這樣的步驟找到的:

本來點選熱門資料那邊的「COVID-19台灣最新病例、檢驗統計」結果發現只有一筆資料,而且看起來最後更新時間是 2020/04/24,所以得往其他地方翻。

首先點了上面的「最新消息」發現是個系統公告區,不是我要的,接下來才又找到正確的路線...

這時候就會看到最前面提到的「台灣COVID-19冠狀病毒檢測每日送驗數」了。

然後 data.cdc.gov.tw 這個網站看起來是放在 Microsoft Azure 的日本區?

詩篇的作者抱怨不知道自己詩篇考題的答案...

2017 年的文章,最近不知道為什麼冒出來,但還蠻有趣的...

看到「I Can’t Answer These Texas Standardized Test Questions About My Own Poems」這篇,Sara Holbrook 收到信件跑來問問題 (節錄前面的部份):

Hello Mrs. Holbrook. My name is Sean, and I’m an 8th grade English teacher in Texas. I’m attempting to decipher the number of stanzas in your poem, ‘Midnight’. This isn’t clear from the formatting in our most recent benchmark. The assessment asks the following question:

作者最後的抱怨也很有趣:

My final reflection is this: any test that questions the motivations of the author without asking the author is a big baloney sandwich. Mostly test makers do this to dead people who can’t protest. But I’m not dead.

I protest.

這邊其實也是在偷戳「作者之死」現象... 另外一則也有類似的情況,發生的早一點的台灣 (2016) XDDD

文學的過度解讀現象 XDDD

在 AWSUG Taiwan 上講的「用 AWS CodeDeploy 解決程式佈署」

前幾天在 AWSUG Taiwan 上講了「用 AWS CodeDeploy 解決程式佈署」,連結是投影片網址,因為在 Speaker Deck 上找不到 embed code 了,只好這樣連結過去。

話說回來,要上傳投影片的時候才發現,這兩個投影片 hosting 服務都跟微軟有些關係... 首先是 SlideShare 在 2012 被 LinkedIn 買下,然後 LinkedIn 在 2016 年賣給了微軟。

SpeakerDeck (或者說,Ordered List 這家公司) 本來在 2011 年賣給了 GitHub,但今年六月的時候被買回去了:

不知道買回去是不是跟微軟要買 GitHub 有關...

Tor Browser 繁體中文版

Twitter 上看到 Tor Browser 在宣傳繁體中文版,不過這篇的翻譯有點...:

不過這算是個里程碑啦...

AWS Direct Connect 在台北又增加可以接的機房了...

先前 AWS Direct Connect 在今年二月的時候公佈了台北第一個開放的接點,是方的麗源機房 (Chief Telecom LY, Taipei, Taiwan,參考「AWS 公開了在台北的 Direct Connect 接口」),現在公佈第二個點了:「New AWS Direct Connect locations in Paris and Taipei」。

第二個點在中華電信的機房 (Chunghwa Telecom, Taipei, Taiwan),但這樣只這樣標,不知道實際上是哪個,會不會是愛國東路的國分機房?那邊有不少非中華電信網路的客戶,只是租那邊的機房在用...

不過有需求的可以問一下 AWS,應該就會有答案了,畢竟總是得讓客戶知道要接到哪邊...

CloudFront 在台北增加第三個點...

Twitter 上看到 AWS 宣佈 CloudFront 加了四個點:

點進去後發現這四個點包括了台北:

Amazon CloudFront announces four new Edge locations: Cape Town, South Africa; Denver, Colorado; Frankfurt, Germany; and Taipei, Taiwan.

在 CloudFront 的列表裡也增加到三個點:

Bangalore, India; Chennai, India (2); Hong Kong, China (3); Kuala Lumpur, Malaysia; Mumbai, India (2); Manila, Philippines; New Delhi, India; Osaka, Japan; Seoul, South Korea (4); Singapore (3); Taipei, Taiwan(3); Tokyo, Japan (8)

這樣應該可以再減少被導去海外節點的機會 (通常是香港或日本),不過狀況會怎麼樣還要再觀察... 先前加第二個點後,觀察到的現象是有減少,但還是會發生。現在加到第三個後不知道會不會解決...