Category Archives: Service

日本圍棋界使用 AWS 分析棋局的情況

看到「圍棋AI與AWS」這篇譯文,原文是「囲碁AIブームに乗って、若手棋士の間で「AWS」が大流行 その理由とは?」。

沒有太意外是使用 Leela Zero + Lizzle,畢竟這是 open source project,在軟體與資料的取得上相當方便,而且在好的硬體上已經可以超越人類頂尖棋手。

由於在 Lizzle 的介面上可以看到勝率,以及 Leela Zero 考慮的下一手 (通常會有多個選點),而且當游標移到這些選點上以後,還會有可能的變化圖可以看,所以對於棋手在熟悉操作介面後,可以很快的擺個變化圖,然後讓 Leela Zero 分析後續的發展,而棋手就可以快速判斷出「喔喔原來是這樣啊」。

網路上也有類似的自戰解說,可以看到棋手對 Lizzle 的操作與分析 (大約從 50:50 開始才是 Lizzle 的操作):

不過話說回來,幹壞事果然是進步最大的原動力... 讓一群對 AWS 沒什麼經驗的圍棋棋手用起 AWS,而且還透過 AMI 與 spot instance 省錢... XD

Mac 上讓 SSH 走 Socks5 的方式

在泰國住的飯店提供頗快的網路:

不過到 HiNet 看起來應該是有繞到美國之類的地區?

gslin@Gea-Suans-MacBook-Pro [~] [08:16/W4] mtr --report 168.95.1.1
Start: 2019-04-07T08:16:33+0700
HOST: Gea-Suans-MacBook-Pro.local Loss%   Snt   Last   Avg  Best  Wrst StDev
  1.|-- 10.10.20.1                 0.0%    10    1.8   2.0   1.3   3.1   0.6
  2.|-- node-iyp.pool-101-108.dyn  0.0%    10    3.9   3.6   2.7   4.5   0.6
  3.|-- 172.17.36.105              0.0%    10    3.2   4.1   3.2   8.3   1.5
  4.|-- 203.113.44.205             0.0%    10    6.5   5.3   3.9   6.7   1.0
  5.|-- 203.113.44.177             0.0%    10    5.4   4.8   4.0   7.2   1.0
  6.|-- 203.113.37.194             0.0%    10    4.6   6.5   3.0  11.1   2.5
  7.|-- in-addr.net                0.0%    10    3.9   4.4   3.1   5.6   0.8
  8.|-- ???                       100.0    10    0.0   0.0   0.0   0.0   0.0
  9.|-- pcpd-4001.hinet.net        0.0%    10  355.4 356.9 355.1 365.4   3.0
 10.|-- pcpd-3212.hinet.net        0.0%    10  215.6 216.6 214.2 225.4   3.4
 11.|-- tpdt-3022.hinet.net        0.0%    10  219.4 215.9 214.0 221.5   2.5
 12.|-- tpdt-3012.hinet.net        0.0%    10  218.9 217.2 215.0 218.9   1.4
 13.|-- tpdb-3311.hinet.net        0.0%    10  212.5 212.9 211.9 214.1   0.6
 14.|-- 210-59-204-229.hinet-ip.h  0.0%    10  213.5 212.7 212.0 213.7   0.6
 15.|-- dns.hinet.net              0.0%    10  214.4 214.5 213.7 216.0   0.7

這樣有些影音服務只吃台灣 IP 就沒辦法用了,所以就得找方法來解決... 想法是透過我在 GCP 上開的機器繞回 HiNet,所以就得找 Mac 上 SSH 要怎麼設定 Socks5。

本來以為要用 tsocks 之類的工具 (i.e. 用 LD_PRELOAD 處理 connect()),但意外的在「SSH through a SOCKS Proxy? (client = OpenSSH OS X)」這邊看到可以用內建的 nc 處理,因為 nc 有支援 Socks5。

所以就變成兩包 ssh 指令:

ssh -D 1081 gcp.server
ssh -D 1080 -o "ProxyCommand nc -X 5 -x 127.0.0.1:1081 %h %p" hinet.server

然後 127.0.0.1:1080 就是打通的版本了,可以讓瀏覽器直接掛上去使用。

至於後來想起來不需要用 Socks5,可以用 ssh -L 而笑出來又是另外一件事情了 :o

Open Distro for Elasticsearch 的比較

先前提到的「AWS 對 Elastic Stack 實作免費的開源版本 Open Distro for Elasticsearch」,在「Open Distro for Elasticsearch Review」這邊有整理了一份重點:

可以看到主要重點都在安全性那塊...

Packagist.org 要搬到 AWS 上...

Packagist 打算把服務丟上 AWS:「An Update on Packagist.org Hosting」。

We decided to migrate the packagist.org website to AWS as well, including the database, metadata update workers, etc. This makes it much easier to build a highly-available setup, where machines can be rebooted or even rebuilt safely without bringing down the whole site.

不知道會搬多少上去... 目前 .compackagist.com 已經上 AWS 了,但 packagist.org 與主要的流量來源 repo.packagist.org 看起來都還沒。

Amazon Transcribe 增加許多客製化功能

Amazon TranscribeAWS 提供的語音辨識服務,最近發表了不少可以客製化的功能:「Amazon Transcribe enhances custom vocabulary with custom pronunciations and display forms」。

一個是可以增加字彙,包括他的發音 (不過得透過 IPA 標,這邊會需要學一些東西):

You can give Amazon Transcribe more information about how to process speech in your input audio or video file by creating a custom vocabulary. A custom vocabulary is a list of specific words that you want Amazon Transcribe to recognize in your audio input. These are generally domain-specific words and phrases, words that Amazon Transcribe isn't recognizing, or proper nouns.

Now, with the use of characters from the International Phonetic Alphabet (IPA), you can enhance each custom terminology with corresponding custom pronunciations. Alternatively, you can also use the standard orthography of the language to mimic the way that the word or phrase sounds.

另外是定義詞彙的標示方法:

Additionally, you can now designate exactly how a customer terminology should be displayed when it is transcribed (e.g. “Street” as “St.” versus “ST”).

這對於專有名詞的部份應該是很好用?像是人名...

Cloudflare 打算再推出 VPN 服務

去年在四月一日推出 1.1.1.1 服務的 Cloudflare 打算更進一步保護連線內容,提供 Wrap 服務 (就是 VPN):「Introducing Warp: Fixing Mobile Internet Performance and Security」。

不過這樣在 privacy 上的保護就變弱了,因為 Cloudflare 手上就拿到更多流量資訊可以交叉比對... 大概會申請起來放著在外面用,而不會平常就開著。

申請是透過 app 申請,Android 的在「1.1.1.1: Faster & Safer Internet」這邊,而 iOS 的在「1.1.1.1: Faster Internet」這邊。

目前申請後需看到排隊的編號,像是這樣:

Amazon Aurora with PostgreSQL 支援 Logical Replication

AWS 先前宣佈 Amazon Aurora (MySQL) 支援 GTID Replication (參考「Amazon Aurora with MySQL 5.7 支援 GTID」),現在則是宣佈 Amazon Aurora with PostgreSQL 支援 Logical Replication:「Amazon Aurora with PostgreSQL Compatibility Supports Logical Replication」。

如同預期的,要新版的才支援:

Logical replication is supported with Aurora PostgreSQL versions 2.2.0 and 2.2.1, compatible with PostgreSQL 10.6.

有 Logical Replication 可以多做很多事情,像是雲端與外部 PostgreSQL 服務的串接 (e.g. 即時拉一份到 IDC 機房)。另外有些 ETL 工具也可以透過這個方式取得資料庫上改變了什麼東西。

GitHub 的 Webhook IP 增加網段

GitHub 發出的 Webhook 的來源位置增加網段了:「Webhook IP addresses are changing」。

目前是 192.30.252.0/22,在 2019/04/09 後將會增加 140.82.112.0/20,如果有用防火牆的人需要修改設定,把多的這段加上去。

去年就把這個網段放進 API 裡,但一直都還沒啟用,所以如果你有透過 API 動態更新防火牆規則的話就沒問題,現在是最後登機廣播了:

This block of IPs has been in the /meta API endpoint since May 2018, but we wanted to announce this update in case you missed it.

AWS 推出更便宜的儲存方案 Glacier Deep Archive

AWS 推出的這個方案價錢又更低了:「New Amazon S3 Storage Class – Glacier Deep Archive」。

在這之前在 us-east-1S3 最低的方案是 Glacier Storage,單價是 USD$0.004/GB (也就是 $4/TB)。

而這次推出的 Glacier Deep Archive Storage 在同一區則是直接到 USD$0.00099/GB ($0.99/TB),大約是 1/4 的價錢。

Glacier Deep Archive 在取得時 first byte 的保證時間是 12 小時,另外最低消費是 180 天:

Retrieval time within 12 hours

先前就有的 Glacier Storage 則是可以在取用時設定取得的 pattern (會影響 first byte 的時間),而最低消費是 90 天:

Configurable retrieval times, from minutes to hours

Pricing for each of these metrics is determined by the speed at which data is requested based on three options. "Expedited" queries <250 MB are typically returned in 1-5 minutes. "Standard" queries are typically returned in 3-5 hours. "Bulk" queries are typically returned in 5-12 hours.

多一個更便宜的選擇可以用。

Amazon Aurora with MySQL 5.7 支援 GTID

雖然在 AWS 上服務的 HA 大多都不需要自己管理,但備份機制 (甚至異地備援) 還是要自己規劃,Amazon Aurora with MySQL 的 GTID 功能算是讓這塊多了一個選擇:「Amazon Aurora with MySQL 5.7 Compatibility Supports GTID-Based Replication」。

公告裡面有提到 Aurora 自己的 replication 還是用自己的機制,而非透過 GTID 做的:

This provides complete consistency when using binlog replication between an Aurora database and an external MySQL database. Your replication won’t miss transactions or generate conflicts, even after failover or downtime. (Note that replication within an Aurora cluster doesn't use binlog files, so the GTID feature doesn't apply.)

不過就 Aurora 的架構來說,整個 cluster 比較像是看作一個整體,用 binlog + position 應該是夠用的?也不會有 failover 時的 conflict 問題?不確定用 GTID 的好處會在哪邊,還得再想看看...