AWS 推出 EC2 Fleet:直接混搭標準 EC2、Spot、RI 的計算

AWS 將本來 EC2Spot Fleet 加上了 EC2 Fleet,計算的公式從本來只有 Spot Instace,變成把標準 EC2 Instance 與 RI 的計算全部都納進來:「EC2 Fleet – Manage Thousands of On-Demand and Spot Instances with One Request」。

Today we are extending and generalizing the set-it-and-forget-it model that we pioneered in Spot Fleet with EC2 Fleet, a new building block that gives you the ability to create fleets that are composed of a combination of EC2 On-Demand, Reserved, and Spot Instances with a single API call.

不過目前有些服務還沒整,主要是跟 auto scaling 有關的部份,這部份應該是一次上一大包:

We plan to connect EC2 Fleet and EC2 Auto Scaling groups. This will let you create a single fleet that mixed instance types and Spot, Reserved and On-Demand, while also taking advantage of EC2 Auto Scaling features such as health checks and lifecycle hooks. This integration will also bring EC2 Fleet functionality to services such as Amazon ECS, Amazon EKS, and AWS Batch that build on and make use of EC2 Auto Scaling for fleet management.

整完以後對於要省成本就更簡單了...

Google 開放 .app 註冊,是個 HSTS Preload TLD

Google 宣佈了 .app 的網域將開放註冊:「Introducing .app, a more secure home for apps on the web」。

整個 .app 網域都已經被 Google 設定 HSTS Preload 了:

A key benefit of the .app domain is that security is built in—for you and your users. The big difference is that HTTPS is required to connect to all .app websites, helping protect against ad malware and tracking injection by ISPs, in addition to safeguarding against spying on open WiFi networks. Because .app will be the first TLD with enforced security made available for general registration, it’s helping move the web to an HTTPS-everywhere future in a big way.

如果要註冊下來,開發的時候得注意...

台固的網域名稱轉出到 Gandi,以及 GDPR...

看到 othree 的「TFN 域名轉出」這篇,剛好前陣子把 git.tw 也轉到 Gandi 上,也遇到一樣的問題... 以往的經驗是網域註冊商會提供 authorization code,但台固的系統是讓你自己輸入,懂這點後就好處理了:

所以結論是,TFN 域名轉出時要輸入的移轉中密碼其實就是給使用者自訂 authorization code,而且還有個蠻短的長度限制 XD

另外是因為 GDPR 所以看不到 whois 資料了,像是 othree 提到的 markdown.tw

gslin@GSLIN-HOME [~] [14:32/W2] whois markdown.tw
Domain Name: markdown.tw
   Domain Status: clientTransferProhibited
   Registrant:
      
      Not displayed due to GDPR
      FR

   Administrative Contact:
      Not displayed due to GDPR

   Technical Contact:
      Not displayed due to GDPR

   Record expires on 2020-03-07 (YYYY-MM-DD)
   Record created on 2011-03-07 (YYYY-MM-DD)

   Domain servers in listed order:
      ns-171-a.gandi.net      
      ns-114-b.gandi.net      
      ns-144-c.gandi.net      

Registration Service Provider: GANDI SAS

我自己的 git.tw 也是:

gslin@GSLIN-HOME [~] [14:34/W2] whois git.tw
Domain Name: git.tw
   Domain Status: clientTransferProhibited
   Registrant:
      
      Not displayed due to GDPR
      FR

   Administrative Contact:
      Not displayed due to GDPR

   Technical Contact:
      Not displayed due to GDPR

   Record expires on 2019-05-23 (YYYY-MM-DD)
   Record created on 2008-05-23 (YYYY-MM-DD)

   Domain servers in listed order:
      kristin.ns.cloudflare.com      
      paul.ns.cloudflare.com         

Registration Service Provider: GANDI SAS

這樣就有點麻煩了,以後如果要聯絡的話只剩下 DNS 內的 SOA record

GitHub 透過 Let's Encrypt 提供自訂網域的 HTTPS 服務

以往在 GitHub 上如果要使用 HTTPS 只能使用 *.github.io 網域,現在 GitHub 宣佈透過 Let's Encrypt 的服務支援了:「Custom domains on GitHub Pages gain support for HTTPS」:

We have partnered with the certificate authority Let’s Encrypt on this project. As supporters of Let’s Encrypt’s mission to make the web more secure for everyone, we’ve officially become Silver-level sponsors of the initiative.

不過目前只支援 CNAME record (標準) 或是 ALIAS record 的方式 (非標準,也稱為 ANAME,有些 DNS provider 有支援,主要用在網域本身 (i.e. root domain) 無法使用 CNAME)。

如果是使用 A record,則是需要更新 IP 位置:

If you are using A records, you must update your site’s DNS records with new IP addresses. Please see our guide to setting up your custom domain with Pages and update any A records you might have set.

另外也提供 HTTP 轉 HTTPS 的選項:

以前 HTTPS 還得自己弄伺服器處理,現在可以直接往 GitHub 上丟了...

另外用查出來的 IP 看了一下架構,IP 是 Fastly 的,所以應該是跟 Fastly 合作,但不確定是 Fastly 自己搞定 Let's Encrypt 的憑證,或是 Fastly 提供 Port 80/443 的 TCP Proxy?

以 Google Chrome 的情況分析各種 script 的利弊與使用時機

在「Script Scheduling in Chrome」這邊看到關於各種 <script> 的時機,主要是以 Google Chrome 環境為主。作者在文章裡面有提到「Scheduling Scripts Intuitively and Performantly」這份文件,並且將最上面的表格取出來,光是這張表就給了不少想法:

文件裡面有更多細節可以看,而且有些討論其實是在思考要怎麼修改 spec 讓網站更容易設 script priority...

Intel 最新的 Ice Lake 系列對 AES 的加速

Twitter 上看到這篇,講 Intel 推出新的指令集,對 AES 的加速效果:

進去看以後發現是講四月推出的 Ice Lake,在上面新增的 VPCLMULQDQ 指令對效能的幫助:

The introduction of the processor instructions AES-NI and VPCLMULQDQ, that are designed for speeding up encryption, and their continual performance improvements through processor generations, has significantly reduced the costs of encryption overheads.

而他們發表出來的數據說 AES-GCM 的效率直接從 ~23 cycles/byte 降到 0.64 cycles/byte,大約是 35 倍的改進?

More and more applications and platforms encrypt all of their data and traffic. As an example, we note the world wide proliferation of the use of AES-GCM, with performance dropping down to 0.64 cycles per byte (from ~23 before the instructions), on the latest Intel processors.

就算不是 AES-GCM,而是其他的 AES 相關演算法,也是三倍以上的改善:

這效能差異...

Stripe 將 Redis 單機版轉到 Cluster 版本上降低了錯誤率

在「Scaling a High-traffic Rate Limiting Stack With Redis Cluster」這邊提到了 StripeRedis 單機版轉移到 10 個節點的 cluster 版本,然後錯誤率大幅下降:

Stripe’s rate limiters are built on top of Redis, and until recently, they ran on a single very hot instance of Redis. The server had followers in place for failover, but at any given time, one node was handling every operation.

We eventually solved it by migrating to a 10-node Redis Cluster.

另外也可以看出來,在轉移到 cluster 版本後有不少要注意的,像是因為 sharding 而需要調整平衡性。另外是 cluster 模式下寫入的 confirmation 跟一般預期的不太一樣,不過這對於 rate limit 的應用還好,可以接受某種程度的掉資料...