幹壞事是進步最大的原動力
前面在「AWS 的台北區 (Local Zone) 開了」這邊有提到機器開不起來，剛剛查價錢的時候才發現只能開 {c5,g4dn,m5,r5}.2xlarge：
改成 c5.2xlarge 然後就開起來了：
翻了目前所有的 local zone，看起來大多都是類似的情況，選擇性會很少... 目前只有邁阿密與洛杉磯的選擇比較多，這是邁阿密：
這是洛杉磯：
這樣目前要拿來當 VPS 取代品還不太好用，就真的是 local zone 的定位。
公司的人丟了訊息過來，AWS 要在台灣設 local zone 了：「AWS 宣布在台部署全新 AWS 本地區域，擴充本地基礎設施」。
Amazon Web Services（AWS）宣布將在台灣推出全新 AWS Local Zone（本地區域）。
沒看到確切的時間點... 不過 local zone 的功能都很少，可以參考「AWS Local Zones features」這邊的列表，看看目前已經啟用的 local zone 所支援的服務與機種，像是 RDS 都不一定會有。
不過對個人來說，拿來當 VPS 用還不錯？到時候來看看 routing 的調教如何...
在 Percona 的「MySQL/ZFS in the Cloud, Leveraging Ephemeral Storage」這篇裡面在探討是不是可以看看 ZFS 在 Ephemeral Storage (機器附的本地硬碟) 上的效能。
一開始測試是直接當主力硬碟來測，可以看到跑 ZFS 的情況下，本地的 storage 還是會比 SSD Premium (這是 Azure 的產品線) 還快不少：
但把資料放在本地的 storage 上其實有點刺激，至少在 production 應該不太會這樣搞，所以後面用 L2ARC 的方式來測，可以看到效率提昇相當明顯，甚至接近本來直接把資料放在本地的 storage：
這樣看起來是個不錯的選擇...
看到 PostgreSQL 官方站台上的介紹，可以直接用 Python 的 pip 指令安裝 PostgreSQL server：「Install a local, non-root PostgreSQL Server with Python "pip"」，專案在「postgresql-wheel」這邊。
照 GitHub 上面的說明跑了一下，還真的可以惡搞... 這樣如果真的要在 CI 裡面跑的話也簡單很多了？只要能 pip 裝軟體就能跟你拼 XDDD
也省掉需要設定一些權限跑 Docker-in-Docker...
AWS 開了 us-east-1 的 Local Zone 了，包括波士頓、邁阿密與休士頓：「AWS Local Zones Are Now Open in Boston, Miami, and Houston」。
Last December I told you about our plans to launch a total of fifteen AWS Local Zones in 2021, and also announced the preview of the Local Zones in Boston, Miami, and Houston. Today I am happy to announce that these three Local Zones are now ready to host your production workloads, joining the existing pair of Local Zones in Los Angeles.
The parent region for all three of these zones is US East (N. Virginia).
在「AWS Local Zones features」這邊可以看到 local zone 並不是所有服務都有，主要是提供 computing 能力，不過連 ELB 都沒有就有點...
不清楚是不是因為 us-east-1 真的很大，所以要透過 local zone 提供擴張... 這些區域對 us-east-1 北維吉尼亞的 latency 不算低，找機會玩一下確認 local zone 的情況好了...
AWS 大阪區開放給大家使用了，而且有標準的三個 AZ 可以用：「AWS Asia Pacific (Osaka) Region Now Open to All, with Three AZs and More Services」。
大阪區因為之前就已經有機房 (附加在東京區)，所以對應的 routing 看起來不算太差，但也沒有特別好... 剛剛測了一下從 HiNet 光世代過去的 latency，分別是 35.5ms (東京的 ap-northeast-1) 與 34.6ms (大阪的 ap-northeast-3)。
另外測了其他的 ISP，有些上日本的點是以東京為主，反而會多繞了一圈，大阪區的 latency 會比較高。
不過如果放遠來說，東京大阪的直線距離大約是 400km，光纖的傳輸速度大約是光速的 2/3，所以單趟大約差了 2ms，如果有機會最佳化的話應該有機會擠出 4ms 出來？
然後是 EC2 的 Pricing 頁面，上面還是寫 Asia Pacific (Osaka-Local)，無法確定是新資料還是舊資料，但以往的慣例應該是更新了...
對照文章裡有提到支援的機器，目前看起來還沒有很齊，像是目前都還沒有 AMD 與 ARM 架構的機器，另外也沒有 GPU 類型的機器：
The Asia Pacific (Osaka) Region supports the C5, C5d, D2, I3, I3en, M5, M5d, R5d, and T3 instance types, in On-Demand, Spot, and Reserved Instance form. X1 and X1e instances are available in a single AZ.
就支援的類型隨意挑了幾個 instance type 比較，翻了一下價錢看起來跟東京的一樣。
整體看起來，如果是有考慮到異地的需求是可以考慮，另外如果是新的服務的話也可以考慮看看 (畢竟各 ISP 應該有機會再把 latency 壓出來)，但既有的服務應該不需要急著搬...
在「Chrome exempts Google sites from user site data settings」這邊看到的新聞，引用的網頁是「Chrome exempts Google sites from user site data settings」，然後這篇也有上到 Hacker News Daily 上，所以 Hacker News 上的討論也蠻熱鬧的：「Chrome exempts Google sites from user site data settings (lapcatsoftware.com)」。
作者實際在 macOS 上拿最新版的 Google Chrome (86.0.4240.75) 測試，發現就算你針對 Google 自家的網站選了「Clear cookies and site data when you quit Chrome」，只有 cookie 會清掉，但 database storage、local storage 與 service workers 都不會被清掉：
然後 Brave 那邊前陣子時做完 Sync v2 了，又是個機會看看那邊如何了... 結果發現在 2019 年的時候意外修正了一部分：「"Keep local data only until you quit your browser" only deletes cookies, not local storage #1127」、「Fixes: #870 Replaced logic to clear data with WebKit api. #883」。
看到 AWS 公佈了大阪區要轉成正式區域的消息：「In the Works – AWS Osaka Local Region Expansion to Full Region」。
大阪區本來是東京區的 local region，主要是提供給東京區的用戶備份以及備援，現在如果變成 full region 的話可以觀察看看 routing，如果從日本西側進骨幹的話，有機會快個 4ms (直線約 400km)？
另外一個是價位不知道會跟東京差多少，畢竟東京週邊的各種物價與地價都算貴的，當然也有可能就全部照日本區的價錢算...
目前喊出來的目標是 2021 年年初會有 3 AZ，也就是標準 region 的架構：
Today, we are excited to announce that, due to high customer demand for additional services in Osaka, the Osaka Local Region will be expanded into a full AWS Region with three Availability Zones by early 2021.
AWS 宣佈 us-west-2 (Oregon) 開 Local Zone，這應該是 AWS 第一次在美國開 Local Zone，上次看到好像是 ap-northeast-1 (Tokyo) 的 Osaka 區：「AWS Now Available from a Local Zone in Los Angeles」。
控制都還是在 us-west-2 的範圍控制，但代碼會是 us-west-2-lax-1a (目前只有一區)，之後會開 us-west-2-lax-1b (第二區)：
In the fullness of time (as Andy Jassy often says), there could very well be more than one Local Zone in any given geographic area. In 2020, we will open a second one in Los Angeles (us-west-2-lax-1b), and are giving consideration to other locations. We would love to get your advice on locations, so feel free to leave me a comment or two!
剛剛登入進去 VPC 的 Subnets 想要增加看看，沒看到 us-west-2-lax-1a 的選項可以選，看起來還是需要另外申請？
另外算了一下 Oregon (用 Portland 算) 到 Los Angels 的直線距離，大約要 1300km 左右 (比台北到香港還遠不少)，光速單趟大約要 6.5ms？這樣對一些應用程式應該是會有感覺...
This Local Zone is designed to provide very low latency (single-digit milliseconds) to applications that are accessed from Los Angeles and other locations in Southern California.
看起來主要還是支援異地的需求...
mkcert 這個工具可以產生出讓系統 (包括瀏覽器) 信任的 https://localhost/：「mkcert: valid HTTPS certificates for localhost」。
先建立 CA 的 root key 與 root certificate，然後把 root certificate 塞到系統與各軟體的信任清單內，再產生 localhost 的 key 與 certificate 出來給前面的 CA root key 簽名。把這些事情包裝起來就是 mkcert 了。
拿來開發軟體時比較方便一點，HSTS 的程式碼就可以全環境共用了...