Linode 推出 GPU Instance

所以 Linode 開始有 GPU Instance 產品線了:「Introducing Linode GPU Instances」。

用的是 Nvidia Quadro RTX 6000:

Linode GPU instances are built on NVIDIA Quadro RTX 6000 GPU cards.

查維基百科可以看到是 2018-08-13 推出的卡。價錢不算便宜:

去年十月的新聞可以看到 Quadro RTX 6000 的報價是 $6,300:「Nvidia Lists Quadro RTX 6000 GPU at $6,300」,這樣可以跟 EC2 那邊的規格與價錢比一下感覺...

Cloudflare 提供 IPFS 的 HTTPS Gateway

IPFS Gateway 基本上就是個 Proxy,這次 Cloudflare 直接提供 *.cf-ipfs.com 服務:「Continuing to Improve our IPFS Gateway」。

用把 hash 放進 subdomain 的方式讓我想起當年的 Coral CDN 計畫...

Anyway,我覺得對 IPFS 的幫助還是有限,畢竟本來 IPFS 官方就有提供 Gateway,現在只是一個比較快的 Gateway,能做的功能還是那些...

EC2 的 C5 系列機器推出 12x、24x 以及 metal 類別

EC2c5 系列主機推出了 12xlarge24xlarge 以及 metal 三種新的類別:「Now Available: New C5 instance sizes and bare metal instances」。

本來的 c5largexlarge2xlarge4xlarge9xlarge (這邊有一些不規則了),現在多了 12xlarge24xlarge,應該是大到需要依照硬體規格對齊數字了?

另外一個是,c5.24xlargec5.metal 其實是一樣的硬體規格 (以及價錢),主要的差異在 c5.metal 沒有虛擬化,所以除了壓榨效能以外,還可以看到很多硬體資訊:

  • do not want to take the performance hit of nested virtualization,
  • need access to physical resources and low-level hardware features, such as performance counters and Intel VT that are not always available or fully supported in virtualized environments,
  • are intended to run directly on the hardware, or licensed and supported for use in non-virtualized environments.

破 reCAPTCHA 的 Buster

在「用 Google 的 Speech Recognition API 破 Google 的 reCAPTCHA」與「reCAPTCHA 與語音辨識:以子之矛,攻子之盾」都提過用語音辨識功能破 reCAPTCHA,現在又有一套了,而且直接在各瀏覽器的 extension 平台上架:「Buster: Captcha Solver for Humans」。

說明可以看到一樣是透過聲音的部份辨識:

Buster is a browser extension which helps you to solve difficult captchas by completing reCAPTCHA audio challenges using speech recognition. Challenges are solved by clicking on the extension button at the bottom of the reCAPTCHA widget.

除了安裝很簡單以外,設定也弄得很簡單,這個套件支援多種不同語音辨識 API,包括 GoogleMicrosoft 以及 IBM 的服務,只要在套件的設定頁輸入 API key 就可以了...

另外剛好也跟 reCAPTCHA 有關,在 Hacker News 上的「Google's Captcha in Firefox vs. in Chrome (grumpy.website)」看到 Google Chrome 與 Mozilla Firefox 在跑 reCAPTCHA 的不同之處 (Chrome 的流程順很多,Firefox 卡很多),不過我覺得證據還有點弱,需要再看其他的測試...

另外裡面有提到一些奇怪的東西,像是 W3C 的替代方案 (這個組織提的東西...):「Inaccessibility of CAPTCHA」,找時間來研究一下...

CockroachDB 也拋棄 Open Source License 了

CockroachDB 的主力在於 PostgreSQL 的相容層 (包括底層資料結構,SQL 語法,以及 Protocol,所以原有的 client 不需要太多修改就可以用),並且提供橫向擴充的能力 (實作類似於 F1 與 Spanner 這些論文的功能)。

現在他們也宣佈拋棄 Open Source License 了,從本來的 Apache License 2.0 轉為他們自己定義的 Business Source License:「Why We’re Relicensing CockroachDB」。

最大的差異就是擋提供服務:

The one and only thing that you cannot do is offer a commercial version of CockroachDB as a service without buying a license.

商業版本最終會以 open source license 釋出,但會有三年延遲 (以現在的社群速度,基本上就等於不提供了),不算太意外,但這樣的話也需要先從可用的列表上移除了...

在 AWS 強制使用 MFA 的情況下,透過 CLI 操作

AWS 可以設定 IAM 使用者強制使用 MFA (包括 API 的操作),在這種情況下如果要使用 AWS Command Line Interface 就得透過 AWS STS (AWS Security Token Service) 產生另外一組 key + secret + session key,然後這組通行時間預設是 12 小時。

相關的文章可以參考「How do I use an MFA token to authenticate access to my AWS resources through the AWS CLI?」這篇,然後我就寫了一段 shell script 來做這件事情。

首先是在 ~/.aws/config 內放入 MFA 的 ARN,像是這樣:

[profile mycompany]
mfa = arn:aws:iam::012345678901:mfa/gslin
region = us-east-1

然後就可以用 aws.mfa mycompany 指令產生出一個會把 key + secret + session key 包進去的 shell:

function aws.mfa() {
    local MFA_ARN
    local MFA_TOKEN
    local PROFILE="$1"
    local STSDATA

    MFA_ARN="$(python3 -c "import configparser; import os; c=configparser.ConfigParser(); c.read('{}/.aws/config'.format(os.environ['HOME'])); print(c['profile ${PROFILE}']['mfa'])")
"
    echo "Reading ${PROFILE} and going for token ${MFA_ARN} ..."

    echo -n 'MFA Password: '
    read -r MFA_TOKEN

    STSDATA="$(aws --profile "${PROFILE}" sts get-session-token --serial-number "${MFA_ARN}" --token-code "${MFA_TOKEN}")"
    export AWS_ACCESS_KEY_ID="$(echo "${STSDATA}" | jq -r .Credentials.AccessKeyId)"
    export AWS_SECRET_ACCESS_KEY="$(echo "${STSDATA}" | jq -r .Credentials.SecretAccessKey)"
    export AWS_SESSION_TOKEN="$(echo "${STSDATA}" | jq -r .Credentials.SessionToken)"

    echo 'Running an independant shell...'
    ${SHELL}
}

很明顯的裡面用到了 Python 3 與 jq,這兩個應該都可以直接裝系統的版本就可以了。

後續的操作就跟原來的用法都一樣,像是 aws --region=us-east-1 s3 ls 這樣的指令。

Cloudflare 改善了同時下載同一個檔案的效率...

在「Live video just got more live: Introducing Concurrent Streaming Acceleration」這邊 Cloudflare 說明他們改善了同時下載同一個 cache-miss 檔案時的效率。

本來的架構在 cache-miss 時,CDN 這端會先取得 exclusive lock,然後到 origin server 抓檔案。如果這時候有其他人也要抓同一個檔案,就會先卡住,避免同時間對 origin server 產生大量連線:

這個架構在一般的情況下其實還 ok,就算是 Windows Update 這種等級的量,畢竟就是一次性的情況而已。但對於現代愈來愈普及的 HTTP(S) streaming 技術來說,因為檔案一直產生,這就會是常常遇到的問題了。

由於 lock 機制增加了不少延遲,所以在使用者端就需要多抓一些緩衝時間才能確保品質,這增加了直播的互動延遲,所以 Cloudflare 改善了這個部分,讓所有人都可以同時下載,而非等到發起的使用者下載完才能下載:

沒有太多意外的,從 Cloudflare 內部數字可以看出來這讓 lock 時間大幅下降,對於使用者來說也大幅降低了 TTFB (time to first byte):

不確定其他家的情況...

Stripe 遇到 AWS 上 DNS Resolver 的限制

當量夠大就會遇到各種限制...

這次 Stripe 在描述 trouble shooting 的過程:「The secret life of DNS packets: investigating complex networks」。

其中一個頗有趣的架構是他們在每台主機上都有跑 Unbound,然後導去中央的 DNS Resolver,再決定導去 Consul 或是 AWS 的 DNS Resolver:

Unbound runs locally on every host as well as on the DNS servers.

然後他們發現偶而會有大量的 SERVFAIL

接下來就是各種找問題的過程 (像是用 tcpdump 看情況,然後用 iptables 統計一些數字),最後發現是卡在 AWS 的 DNS Resolver 在 60 秒內只回應了 61,385 packets,換算差不多是 1,023 packets/sec,這數字看起來就很雷:

During one of the 60-second collection periods the DNS server sent 257,430 packets to the VPC resolver. The VPC resolver replied back with only 61,385 packets, which averages to 1,023 packets per second. We realized we may be hitting the AWS limit for how much traffic can be sent to a VPC resolver, which is 1,024 packets per second per interface. Our next step was to establish better visibility in our cluster to validate our hypothesis.

在官方文件「Using DNS with Your VPC」這邊看到對應的說明:

Each Amazon EC2 instance limits the number of packets that can be sent to the Amazon-provided DNS server to a maximum of 1024 packets per second per network interface. This limit cannot be increased. The number of DNS queries per second supported by the Amazon-provided DNS server varies by the type of query, the size of response, and the protocol in use. For more information and recommendations for a scalable DNS architecture, see the Hybrid Cloud DNS Solutions for Amazon VPC whitepaper.

iptables 看到的量則是:

找到問題後,後面就是要找方法解決了... 他們給了一個只能算是不會有什麼副作用的 workaround,不過也的確想不到太好的解法。

因為是查詢 10.0.0.0/8 網段反解產生大量的查詢,所以就在各 server 上的 Unbound 上指定這個網段直接問 AWS 的 DNS Resolver,不需要往中央的 DNS Resolver 問,這樣在這個場景就不會遇到 1024 packets/sec 問題了 XDDD

Amazon EBS 的預設加密機制

EBS 有選項可以預設開加密了:「New – Opt-in to Default Encryption for New EBS Volumes」。

不算太意外的,這個選項要一區一區開:

Per-Region – As noted above, you can opt-in to default encryption on a region-by-region basis.

也不太意外的,無法完全公開共用:

AMI Sharing – As I noted above, we recently gave you the ability to share encrypted AMIs with other AWS accounts. However, you cannot share them publicly, and you should use a separate account to create community AMIs, Marketplace AMIs, and public snapshots. To learn more, read How to Share Encrypted AMIs Across Accounts to Launch Encrypted EC2 Instances.

然後有些服務有自己的 EBS 設定,這次不受影響。而有些底層其實是用 EC2 的服務 (然後開 EBS) 就會直接套用了:

Other AWS Services – AWS services such as Amazon Relational Database Service (RDS) and Amazon WorkSpaces that use EBS for storage perform their own encryption and key management and are not affected by this launch. Services such as Amazon EMR that create volumes within your account will automatically respect the encryption setting, and will use encrypted volumes if the always-encrypt feature is enabled.

EC2 簡化了 Hibernation 的需求

因為在記憶體內會有各種敏感資訊,所以 EC2 的 Hibernation 當初推出時要求在寫到 snapshot 時要有加密,而 EC2 的設計需要使用 encrypted AMI 啟動,才能產生 encrypted snapshot:

Hibernation requires an EC2 instance be an encrypted EBS-backed instance. This ensures protection of sensitive contents in memory (RAM) as they get copied to the EBS upon hibernation.

這點對一般人來說就比較麻煩了,因為 AMI 裡面可能沒有敏感資訊,所以當初都是設計成 unencrypted 狀態,變成要多一些步驟...

而現在 EC2 宣佈可以可以用一般的 AMI 啟動並且產生出加密的 snapshot:「Enable Hibernation on EC2 Instances when launching with an AMI without an Encrypted EBS Snapshot」。

這樣一來省掉不少前置作業...