Tag: service

FreeBSD 的 Amazon EC2 Image 打算自動使用本機空間當作 Swap

Twitter 上看到 Colin Percival 說計畫將 FreeBSD EC2 image (AMI) 自動偵測並使用 ephemeral disk 的空間當作 swap：

就算是使用 EBS 的 gp2 或是 gp3，甚至是其他 VPS，我也很習慣開一點點的 swap 空間來用 (通常是用 file swap 的方式開 512MB，無論記憶體有多大)，這算是我自己的 best practice 了，這可以把一些完全沒用到的 daemon 塞進 swap。

不過對於已經把 ephemeral disk 規劃拿來用的人可能會不太開心，需要去改設定...

Amazon EFS 的 file lock 限制

看到「Amazon EFS now supports a larger number of concurrent file locks」這篇提到：

This Amazon EFS update increases the number of simultaneous file locks an NFS mount can acquire to 65,536 (from 8,192 previously), enabling Amazon EFS to be used for a broader set of applications that heavily leverage file locking (including message broker and distributed analytics applications).

所以 NFS 的部份先前有 8192 個的上限在，現在則是拉 65536 個了。

不過提到 message broker，應該是以前的應用利用 NFS file lock 來做一些事情？

Cloudflare 的 D1 (SQLite as a service)

在 Hacker News Daily 上看到 Cloudflare 推出了新產品 D1：「Announcing D1: our first SQL database」，在 Hacker News 上對應的討論在「D1: Our SQL database (cloudflare.com)」這邊可以看到。

就如同 Hacker News 上的討論提到的，這篇文章不像一般的 Cloudflare 文章會帶有很多技術上的說明 (尤其是在描述技術產品)，這篇算是非常的行銷導向的文章，目前大家只能靠「猜」的去理解：

For a Cloudflare article, this one is surprisingly light on technical details. And for the product where it most matters.

翻了一下這兩個屬名的作者，Rita Kozlov 是 Director of Product at Cloudflare，而 Glen Maddern 是 Systems Engineer at Cloudflare。

目前知道的是，D1 是架構在 SQLite 上面：

D1 is built on SQLite.

然後從範例的程式碼內可以看到，在 JavaScript 裡面的用法是透過 await env.DB.get() 操作：

export default {
  async fetch(request, env, ctx) {
    const { pathname } = new URL(request.url)
    if (pathname === '/num-products') {
      const { result } = await env.DB.get(`SELECT count(*) AS num_products FROM Product;`)
      return new Response(`There are ${result.num_products} products in the D1 database!`)
    }
  }
}

然後從 screenshot 上沒有看到 region，但是 class 那邊出現了一個 tokyo3 不知道是什麼東西：

目前看到的就這些，沒提到 replication 機制 (這其實還蠻重要的，某些資料是有法規限制的)，另外開發者會很在意的 performance 或是 latency 也沒提到 (所以可以預期應該不會太好？)。

另外在 RDBMS 內很重要的 ACID 特性與分散式系統中 CAP theorem 的性質也都沒有分析。

可以先放著看看就好...

Amazon RDS for PostgreSQL 可以掛 155 台 Read Replica

看到 AWS 推出的新「功能」，可以讓 Amazon RDS for PostgreSQL 的 read replica 掛到 155 台：「Amazon RDS for PostgreSQL supports cascaded read replicas for up to 30X more read capacity」。

作法是透過三層架構，每台機器可以堆五台 replica：

Amazon Relational Database Service (Amazon RDS) for PostgreSQL announces support for PostgreSQL 14 with three levels of cascaded read replicas, 5 replicas per instance, supporting a maximum of up to 155 read replicas per source instance.

需要 PostgreSQL 14.1 或是之後的版本：

Starting with Amazon RDS for PostgreSQL 14.1 and higher, read intensive workloads such as data analytics can now benefit from up to 155 cascaded read replicas that offer up to 30 times higher read capacity versus previous versions of PostgreSQL, thereby reducing the load on source instance.

我記得 Amazon RDS for PostgreSQL 的 replica 是 EBS block-level replication，這種搞法還蠻有趣的 XDDD

Ptt 信件伺服器 node.ptt.cc 查不到反解的問題

就如同標題所說的，Ptt 對外寄信的伺服器 node.ptt.cc 查不到反解的問題：

$ host node.ptt.cc
node.ptt.cc has address 140.112.172.16
$ host 140.112.172.16
Host 16.172.112.140.in-addr.arpa not found: 2(SERVFAIL)

情況大概是這樣，Ptt 使用的 140.112.172.0/27 這個網段 (尾碼從 0～31) 不是 /24 以上的範圍，而 140.112.172.0/24 是台大計中管轄範圍，所以台大就把 140.112.172.x 這段的反解 PTR record 用 CNAME 的方式指到 x.0-31.172.112.140.in-addr.arpa，像是 140.112.172.16 這樣：

;; ANSWER SECTION:
16.172.112.140.in-addr.arpa. 86400 IN   CNAME   16.0-31.172.112.140.in-addr.arpa.

然後再針對 0-31.172.112.140.in-addr.arpa 設定 NS RR 到 ns0.ptt.cc 與 ns1.ptt.cc 兩台 NS server：

;; AUTHORITY SECTION:
0-31.172.112.140.in-addr.arpa. 86400 IN NS      ns1.ptt.cc.
0-31.172.112.140.in-addr.arpa. 86400 IN NS      ns0.ptt.cc.

但是 ns0.ptt.cc 與 ns1.ptt.cc 都不見了：

$ host ns0.ptt.cc
Host ns0.ptt.cc not found: 3(NXDOMAIN)
$ host ns1.ptt.cc
Host ns1.ptt.cc not found: 3(NXDOMAIN)

導致反解查不到對應的資料 (會是 SERVFAIL)：

;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 58463

猜了一下，看起來 ns0.ptt.cc 還活著，只是 Cloudflare 上面的 DNS record 沒設定過去：

$ dig ns0.ptt.cc @140.112.172.16

;; ANSWER SECTION:
ns0.ptt.cc.             300     IN      A       140.112.172.16

不過 ns1.ptt.cc (140.112.172.10) 看起來就沒服務了，但至少在 Cloudflare 上補個 DNS record 上去應該就會動了 (只是沒有兩台互相備援)。

關於自己架設 E-mail server 的事情

自己架設 E-mail server 的難處算是每過一陣子在 Hacker News 上就會冒出來討論的題目：「Ask HN: Why can't I host my own email?」。

收信只要有固定 IP，加上 ISP 沒有擋 TCP port 25 就倒不是問題，整個最難的點在於怎麼送信，因為會常常被標成 spam...

最基本要設定的東西大概是 SPF，但通常還是建議連 DKIM 一起搞定。另外 DMARC 也弄一下會比較好。

然後依照經驗，Gmail 擋信的機率低不少，微軟家擋信的情況就多很多 (包括免費的 E-mail 服務與付費的 Microsoft 365)...

目前一般建議是自用就過 Amazon SES，沒有低消所以個人用起來不貴...

Amazon SESv2 的 Deliverability Dashboard

其實是看到「Amazon SES V2 now supports email size of up to 40MB for inbound and outbound emails by default」這篇才注意到寄信的 Amazon SES 服務有了 SESv2，原文主要是講放寬信件的大小限制：

With this launch, the default message size limit in Amazon SES V2 increases from 10MB for email sending and 30MB for email receiving, to 40MB for both sending and receiving .

不過我跑去「Amazon SES pricing」看的時候意外翻到這個貴貴的東西：

The Deliverability Dashboard (via the SES API V2) is available for a fixed price of USD $1,250 per month. This charge includes reputation monitoring for up to five domains and 25 predictive email placement tests.

然後我試著去找 Deliverability Dashboard 是什麼，卻沒有專文介紹？(還是我找錯關鍵字...)

倒是在 2018 年的時候 Amazon Pinpoint 有個公告提到 Deliverability Dashboard，價錢也是 US$1,250/mo：「Amazon Pinpoint Announces a New Email Deliverability Dashboard to Help Customers Reach their Users' Inboxes」。

本來以為是 Amazon Pinpoint 的服務轉移掛到 SESv2 下，但看「Amazon Pinpoint Pricing」這邊，好像還是在啊...

雖然用不太到，但還是一頭霧水 XDDD

Slack 在 2022/02/22 發生的 downtime 說明

Slack 針對今年年初的爆炸提出了說明：「Slack’s Incident on 2-22-22」，但真正的重點都在 Hacker News 的討論串上：「Slack’s Incident on 2-22-22 (slack.engineering)」。

大概有三件事情可以講，第一個是掛掉的原因，第二個是剛發出來的時候，一堆人對於標題用的「2-22-22」很感冒，第三個是剛剛 (一個小時前)，Cal Henderson (Slack 的 CTO) 跑到 Hacker News 的討論串上回應...

Downtime 的部份

這次的 downtime 主要是發生在 Group Direct Message (GDM) 的部份：

A significant element of the datastore load appeared to be from a query that listed Group Direct Message (GDM) conversations by user. This operation is fronted by our cache tier, so the high query load seemed to indicate something was wrong with our caches.

這個 GDM 的查訊效率不高，而是靠 cache layer 撐住的，加上二月 22 日那天他們在更新 Consul 的 agent，導致 hit rate 的下降，以及遇到一個比較大的 peak time，接著就壓垮了資料庫。

oh，這中間還有 Vitess 一起進來打架，原文講的比較清楚，但需要花一些時間看。

2-22-22

剛發表出來的時候，其實大多數的討論反而是在討論「2-22-22」這件事情，這的確是很差的表示方法，尤其對於一份公告來說，不過這個問題本來就是個 flame war 等級的話題...

Slack CTO (Cal Henderson) 的回應

在重刷頁面的時候發現 iamcal 這個帳號的回應，而 Cal Henderson (Slack CTO) 的個人網站是 www.iamcal.com，雖然不確定這是不是本人帳號，但看起來之前在 2011 註冊後都沒動...

這個帳號回了兩個訊息，一個是提到 AWS 上其實很常看到 failure，需要靠本身架構的穩定性來撐：

Our underlying hardware (AWS) is nothing like this reliable. We see regular (several times a year) failure of racks of machines or whole DCs.

Across the whole fleet (all services), we lose 1-10 servers per day as a baseline. Major events are then on top of that and can impact thousand of hosts at once.

另外一個是反駁自以為的量級估算：

> Even the largest Slack instance probably has under 100,000 users and less than 1000 peak messages per second.

This is not true, by an order of magnitude.

好像還可以繼續在盯一下，不知道還會不會有回應...

社群維護的 YouTube Private API 套件

一樣是今天的 Hacker News Daily 上看到的東西，透過 YouTube 的 Private API 操作 YouTube 的套件：「Youtube.js – full-featured wrapper around YouTube's private API (github.com/luanrt)」。

這些 Private API 就是 YouTube 自己在網站上用的：

A full-featured wrapper around the Innertube API, which is what YouTube itself uses.

也因為這不是 Public API，也就不需要申請 key：

Do I need an API key to use this?

No, YouTube.js does not use any official API so no API keys are required.

當然可以預期他會無預警壞掉，所以可以自己衡量一下要怎麼搞...

比較有趣的是 Hacker News 的討論裡面反而有人在問要怎麼偵測這種 library 或是 bot XDDD

If you’re YouTube or any site, and want to stop these sort of wrappers - what’s the easiest way to do so without breaking your own site?

I find this task to be an interesting engineering problem.

A related question is if there’s an unspoofable way to detect a client.

不過掃了一下好像還好...

這次 Jira 雲端版相關的服務炸鍋的情況 (還在進行中...)

Atlassian 最近好像把 Jira 雲端版相關的服務給炸了，本來想等到差不多告一段落再來看看發生什麼事情，直到看到這則推說預估還要兩個星期，看起來還是先寫下來好了，不然會忘記...：

在「Multiple sites showing down/under maintenance」這邊可以看到從清明節開始炸，到昨天的報告裡面可以看到受到影響的客戶裡面他們只恢復了 35%：

A small number of Atlassian customers continue to experience service outages and are unable to access their sites. Our global engineering teams are working 24/7 to make progress on this incident. At this time, we have rebuilt functionality for over 35% of the users who are impacted by the service outage, with no reported data loss. The rebuild stage is particularly complex due to several steps that are required to validate sites and verify data. These steps require extra time, but are critical to ensuring the integrity of rebuilt sites. We apologize for the length and severity of this incident and have taken steps to avoid a recurrence in the future.

Posted 19 hours ago. Apr 11, 2022 - 08:27 UTC

所以炸掉一個禮拜後大概恢復 1/3，所以的確官方預估還需要兩個禮拜應該差不多？另外在 Hacker News 上也有炸鍋的討論：「Atlassian products have been down for 4 days (atlassian.com)」。

另外在 The Register 上也有一系列的報導，裡面透漏的比官方的更多：「Atlassian Jira, Confluence outage persists two days on」、「Atlassian outage lingers, sparking data loss fears」、「Day 7 of the great Atlassian outage: IT giant still struggling to restore access」、「At last, Atlassian sees an end to its outage ... in two weeks」。

第一篇的副標題有提到原因：

'Routine maintenance script' blamed for derailed service for unlucky customers

第二篇則是提到大約 400 個客戶受到影響：

We were also told that the incident affects a relatively small number of Atlassian customers: about 400. That's only 0.18 per cent of the company's 226,000 customers, which isn't much consolation to the several hundred who still can't access their data.

之後再回頭來看所謂的 routine maintenance script 是什麼好了...