AWS 推出 Route 53 Resolver Query Logs

AWS 推出可以讓你 debug 的功能:「Log your VPC DNS queries with Route 53 Resolver Query Logs」。

這個功能可以記錄 VPC 內的 DNS query:

然後也可以統計與分析:

主要是很多 debug 會需要 DNS query,但 AWS 上不太容易看到 DNS query 資訊 (常見的方式是自己另外架 DNS Resolver),這個功能可以緩解這個問題...

Chromium (Google Chrome) 實做對 Root DNS 的影響

前幾天在 APNIC 上的這篇文章受到社群注意:「Chromium’s impact on root DNS traffic」,在 Hacker News 上也有對應的討論:「Chromium's Impact on Root DNS Traffic (apnic.net)」。

文章作者 Matthew ThomasVerisign 的員工 (Verisign Labs),可以看出來主力在 DNS 的部份。

Chromium (以及 Google Chrome) 會隨機產生一組 hostname,確認所在的網路是否有 DNS hijack:

這導致了在 Root DNS 上會看到大量不存在網域的 DNS query,這點隨著 Google Chrome 的市占率愈來愈高,在 Root DNS 上這些 DNS query 甚至佔到 40% 以上:

不過 Root Server 有上千台在跑,就目前的效能來說應該是還 OK:

As of 2020-08-27, the root server system consists of 1097 instances operated by the 12 independent root server operators.

把這個問題丟到 bugs.chromium.org 上翻,看起來有三張票在進行中:

瞄了一下裡面的討論,目前的方向有兩類,一種是主張完全關掉,這樣確定可以大幅減少對 Root DNS 的壓力,另外一種是設計 cache,使得 Root DNS 的 loading 降低。

這次有不少新聞都有報導,受到 PR 壓力看起來是動起來了... (這三張票看起來之前都沒什麼人有動力要處理)

Amazon Route 53 增加了即時的 Query 數量資訊

AWSRoute 53 增加了 Query 數量的資訊 (加到 CloudWatch 內):「Amazon Route 53 Now Publishes Query Volume Metrics for Public Hosted Zones」。

下午的時候連進去看沒看到,回家後想起來 Route 53 是全球性服務,切到 us-east-1 上就看到了...

算是很基本的功能,這樣可以很方便的看一下使用情況,然後就可以透過這些資料調整 TTL,有些為了要快速切換的可以設短一點,有些不太變動但 query 量很大的則是要設長一點...

PostgreSQL 裡的 B-tree 結構

在「Indexes in PostgreSQL — 4 (Btree)」這邊看到講 PostgreSQLB-tree 結構以及常見的查詢會怎麼使用 B-tree。

裡面講了三種查詢,第一種是等號的查詢 (Search by equality),第二種是不等號的查詢 (Search by inequality),第三種是範圍的查詢 (Search by range)。再後面講到排序與 index 的用法。

雖然是分析 PostgreSQL,但裡面是一般性的概念,其他使用 B-tree 結構的資料庫也是類似作法...

RFC8482 廢掉 DNS 查詢的 ANY query 了...

看到 Cloudflare 的「RFC8482 - Saying goodbye to ANY」這篇,裡面提到 RFC8482 廢掉了 ANY 查詢:「Providing Minimal-Sized Responses to DNS Queries That Have QTYPE=ANY」。

The Domain Name System (DNS) specifies a query type (QTYPE) "ANY". The operator of an authoritative DNS server might choose not to respond to such queries for reasons of local policy, motivated by security, performance, or other reasons.

對 Cloudflare 的痛點主要在於營運上的困難,因為 ANY 回應的 UDP packet size 很大,很容易造成放大攻擊:

把拒絕 ANY 查詢變成標準後,讓 DNS provider 手上多了一把武器可以用。

從二月開始不回應 EDNS 的 DNS server 將會無法查詢

在「DNS flag day」這邊看到 EDNS 的 workaround。

目前的 workaround 是在 DNS server 對於 EDNS 查詢沒有回應時,就改用不帶 EDNS 的查詢再問一次,以確保相容於不支援 EDNS 而且會直接過濾掉這些封包的環境。

而從今年二月開始,這個 workaround 將會被拿掉,當帶 EDNS 的查詢沒有回應時就直接當作伺服器死掉,不會再用沒有 EDNS 的查詢問一次:

The main change is that DNS software from vendors named above will interpret timeouts as sign of a network or server problem. Starting February 1st, 2019 there will be no attempt to disable EDNS as reaction to a DNS query timeout.

This effectivelly means that all DNS servers which do not respond at all to EDNS queries are going to be treated as dead.

往下可以看到會做出改變的廠商包括了 GoogleCloudflare,可以預期 8.8.8.8 (8.8.4.4) 與 1.1.1.1(1.0.0.1) 都會進行更新。

網站上面有可以查詢的工具,剛剛查了一下以前的公司與競爭對手,發現 1111.com.tw 看起來會掛掉,不知道二月前會不會修正這個問題... XD

Mixnode:又一個可以搜尋整個 Web 的服務

看到「Turn the web into a database: An alternative to web crawling/scraping」這篇,在介紹自家 Mixnode 這個產品,看起來是提供 SQL 界面分析整個 Web 的服務...

這類服務最重要的反而不是搜尋界面 (有可以讓程式接的 API 其實就 ok 了),重要的是後面的資料庫有多豐富...

在「用 PublicWWW 分析網站」這邊有提到類似的服務 PublicWWW,而且也一樣有提供 API,先把 Mixnode 丟著記錄起來就好,等有需要的時候再去申請 trial account...

Amazon Aurora 支援 Parallel Query 加速

Amazon Aurora 推出了 Parallel Query,可以加速計算速度:「New – Parallel Query for Amazon Aurora」。原理是利用 Aurora 把 storage 層打散的前提,所以有機會透過螞蟻雄兵處理:

官方給的範例可以連到原文去看,可以看到有打開 aurora_pq 與沒打開的效能差異:

15 rows in set (1 min 53.36 sec)
15 rows in set (1 hour 25 min 51.89 sec)

打開後大約是原來的 1/45 時間,提昇超多...

不過還是有些限制,我最在意的就是目前只支援相容於 MySQL 5.6 的版本 (居然不是先支援 5.7):

Engine Support – We are launching with support for MySQL 5.6, and are working on support for MySQL 5.7 and PostgreSQL.

然後沒有多餘費用,只是 i/o cost 可能會增加:

Cost – You can make use of Parallel Query at no extra charge. However, because it makes direct access to storage, there is a possibility that your IO cost will increase.

MySQL 版本的 Amazon Aurora 會將各種記錄丟到 CloudWatch Logs 了...

剛好今天才被問是不是可以在 Amazon Aurora (MySQL-Compatible Edition) 裡面翻出有哪些 Slow Query,剛好想到這幾天發表了這個功能:「Amazon Aurora Publishes General, Slow Query and Error Logs to Amazon CloudWatch」。

You can now configure the MySQL-compatible edition of Amazon Aurora to publish general logs, slow query logs, and error logs to Amazon CloudWatch Logs. Previously, you could only publish audit logs.

看起來是要另外開 (畢竟 CloudWatch Logs 不是免費的 XD),不過以這類型的 log 產生速度與數量來說應該還行...

Amazon Aurora (MySQL) 提供 Parallel Query 讓人申請使用

AWS 宣佈了 Amazon Aurora (MySQL) 支援 Parallel Query:「Amazon Aurora Parallel Query is Available for Preview」。

這邊提到的 Parallel Query 比較像是 Amazon Athena,直接把單一 Query 打散到多台機器上跑:

Amazon Aurora Parallel Query improves the performance of large analytic queries by pushing processing down to the Aurora storage layer, spreading processing across hundreds of nodes.

也就是說,這算是單一 SQL Query 平行運算的進階版本。

在這之前,AWS 都已經支援單一 Query 在單台機器上利用多 CPU 平行運算。其中 PostgreSQL 是 9.6+ 本身就有支援。Amazon Aurora (MySQL) 則是在 2016 時透過 Parallel Read Ahead 支援某些情境下的的單一 Query 多 CPU 運算了 (發現之前沒寫到...):「Amazon Aurora Update – Parallel Read Ahead, Faster Indexing, NUMA Awareness」。

這個功能目前是 Preview 階段,然後開在這些地區讓大家測試使用:

The preview is available for the MySQL-compatible edition of Amazon Aurora, and is currently available in the US East (N. Virginia), US East (Ohio), US West (Oregon), and Europe (Ireland) Regions. Sign up to get access.

這個功能提供了想要提昇效能,但懶得改架構的人可以用錢直接硬換出來...