Category: Azure

AWS DataSync 支援 GCP 與 Azure 上的 Storage 上的資料了

AWS DataSync 宣佈支援 GCP 與 Azure 上的 Storage 了：「New for AWS DataSync – Move Data Between AWS and Other Public Locations」，比較特別的是，文章的 URL 有提到這兩家的產品，但在標題上反而就沒提到...

這測的重點就是支援 Google Cloud 與 Microsoft Azure 的 object storage 產品：

Today, we added to DataSync the capability to migrate data between AWS Storage services and either Google Cloud Storage or Microsoft Azure Files.

之前大家都是自己開機器手動搬，現在可以直接付錢 (依照 GB 計費) 用服務搬了，不過要注意網路頻寬的流出部份還是有費用...

關於 Hacker News 上在討論 Microsoft Teams 的一些有趣的發現

在 Hacker News 上看到「Ask HN: Why is MS Teams so slow, do devs test Teams on less powerful machines?」這串討論，發起的作者提到了超級吃資源的問題：

I have a laptop with an i5 processor and 8G of RAM. Hard drive is an SSD. It sometimes takes me a full minute and a half to get Teams open and ready to join a meeting. It is driving me crazy.

可以預期下面本來就會有一堆人在抱怨，不過意外看到有趣的回應：

Ex office dev here. Actual dev work is done on i9 workstations running 64 gb of ram, and usually located very near an Azure data center, regardless of where the dev works. The result is that it's fast for us.

Everyone knows that it runs like poop, but there are other priorities, and no performance regression tests.

所以你應該只要電腦夠暴力 + 離機房夠近就會快了 XDDD

的確像是最上面的 comment 提到的，開發者因為都用 MBP，至少還能動 (因為機器夠快)，但其他團隊則是一直幹勦：

At my company, the developers are all on fairly powerful MacBook Pros, and everyone else in the company has Windows laptops (I think generally Surface devices)

For the developers, Teams works... as good as Teams can. So not great, but it works most of the time (for me, anyway). For everyone else though, I hear nothing but issues. Constantly having to restart to make Teams work. And again, this is on Surface devices, so Microsoft is making the app, the OS, and the hardware!

用 Ephemeral Storage 加速 MySQL over ZFS 的效能

在 Percona 的「MySQL/ZFS in the Cloud, Leveraging Ephemeral Storage」這篇裡面在探討是不是可以看看 ZFS 在 Ephemeral Storage (機器附的本地硬碟) 上的效能。

一開始測試是直接當主力硬碟來測，可以看到跑 ZFS 的情況下，本地的 storage 還是會比 SSD Premium (這是 Azure 的產品線) 還快不少：

但把資料放在本地的 storage 上其實有點刺激，至少在 production 應該不太會這樣搞，所以後面用 L2ARC 的方式來測，可以看到效率提昇相當明顯，甚至接近本來直接把資料放在本地的 storage：

另外測了 ext4/bcache，看起來效率就沒那麼好：

這樣看起來是個不錯的選擇...

這幾天 blog 被掃，用 nginx 的 limit_req_zone 擋...

Update：這個方法問題好像還是不少，目前先拿掉了...

這幾天 blog 被掃中單一頁面負載會比較重的頁面，結果 CPU loading 變超高，從後台可以看到常常滿載：

看了一下是都是從 Azure 上面打過來的，有好幾組都在打，IP address 每隔一段時間就會變，所以單純用 firewall 擋 IP address 的方法看起來沒用...

印象中 nginx 本身可以 rate limit，搜了一下文件可以翻到應該就是「Module ngx_http_limit_req_module」這個，就設起來暫時用這個方式擋著，大概是這樣：

limit_conn_status 429;
limit_req_status 429;
limit_req_zone $binary_remote_addr zone=myzone:10m rate=10r/m;

其中預設是傳回 5xx 系列的 service unavailable，但這邊用 429 應該更正確，從維基百科的「List of HTTP status codes」這邊可以看到不錯的說明：

429 Too Many Requests (RFC 6585)
The user has sent too many requests in a given amount of time. Intended for use with rate-limiting schemes.

然後 virtual host 的設定檔內把某個 path 放進這個 zone 保護起來，目前比較困擾的是需要 copy & paste try_files 與 FastCGI 相關的設定：

    location /path/subpath {
        limit_req zone=myzone;
        try_files $uri $uri/ /index.php?$args;

        include fastcgi.conf;
        fastcgi_intercept_errors on;
        fastcgi_pass php74;
    }

這樣一來就可以自動擋下這些狂抽猛送的 bot，至少在現階段應該還是有用的...

如果之後有遇到其他手法的話，再見招拆招看看要怎麼再加強 :o

疾管署的 COVID-19 每日送檢數的 Open Data

記者會上有提到現在疾管署的網站上有公開每日送檢數的資料，花了些時間找，在「台灣COVID-19冠狀病毒檢測每日送驗數」這邊可以看到，網站提供的 preview 的界面沒辦法看到最新的資料，但下載後可以看到檔案格式是 UTF-8 的 CSV 檔，應該還算能處理...

找到這個資料花了一些功夫 (因為用 DuckDuckGo 與 Google 都沒直接找到)，後來是靠這樣的步驟找到的：

本來點選熱門資料那邊的「COVID-19台灣最新病例、檢驗統計」結果發現只有一筆資料，而且看起來最後更新時間是 2020/04/24，所以得往其他地方翻。

首先點了上面的「最新消息」發現是個系統公告區，不是我要的，接下來才又找到正確的路線...

這時候就會看到最前面提到的「台灣COVID-19冠狀病毒檢測每日送驗數」了。

然後 data.cdc.gov.tw 這個網站看起來是放在 Microsoft Azure 的日本區？

花最多錢的 API call

昨天看到這個有趣的討論，要怎麼樣在一個 API call 裡面花最多錢：「How to burn the most money with a single click in Azure」。

主要是這篇開始，在 AWS 上面買 RDS 的 RI，這一個 API call 可以花三百多萬美金：

然後作者試著在 Azure 上找到 Cosmos DB 可以花到九百多萬美金：

另外一個是用 Blob Storage 撐量出來，一億六千多萬美金：

然後最終極的方法是 999 台 instance 的 RI，可以到八億 XDDD：

不過後面這些方法應該買不下去，雲端服務預留的 capacity 應該不夠這樣搞...