RESTFul API 的 mock server 解決方案

會寫這一篇主要是最近在公司上有遇到我們需要快速迭代與試錯,但在前後端是不一樣的團隊,但在快速迭代的情況下,為了避免不要互相影嚮進度,一個常見的作法就是架設json mock server,也就是設定對應的api 只回應對應的假資料…

這類型的工具也很多,只是最近剛好摸到一個工具覺得是我目前碰過的類似工具之中,最容易上手的,而且可以有GUI可以使用…

Mockoon

這個工具與其它類似工具的主要差異是,它有GUI界面,可以直接在界面上設定要開哪些endpoint與對應的response以後,就可以直接在local 端跑起mock server了。

而且GUI 界面類似於 Postman,所以上手難度很低,稍微摸一下界面就知道它可以做哪些工具了…

Mockoon routes view
reference: https://mockoon.com/docs/latest/gui-cheat-sheet/

其它更多好用的功能像是

  • Proxy configurations

這個是當api request 打進時,mockoon上如果有沒設定的endpoint時,可以指定它轉發到特定的機器。

  • Support openapi/swagger config import

這個顧名思義是可以直接把我們寫的api 文件檔直接丟到mockoon上,這樣對應的endpoints 就被設定好了。

  • Rule based responses

這我覺得也算是蠻客製化的功能,我們可以針對一個endpoint設定多個responses,然後透過一些客製化的規則(rules)來設定mockoon 要回哪個response。

  • Support CLI based runtime

除了gui 界面以外,官方也有支援cli (用npm包的),所以我們可以把local端的mockoon設定檔丟到cloud上的機器,然後就可以在機器上用cli跑起一個對應的mock server。

像是下面一個簡單的 restart.sh 就可以讓重啟linux 上的mockcoon 並且讀取對應的設定檔。

!/bin/bash
 pkill -f "mockoon-cli"
 mockoon-cli start --data mockoon_api_config.json -p 9000 > /dev/null 2>&1 &

TrinoDB cli 中將query 結果輸出成csv 的方式

剛好工作上用到,記錄一下…. 這樣以後再用到時就只要稍微改一下相關的參數就好了XD

trino --server localhost:8080 \
 --user george \
 --execute 'SELECT * FROM A as a
  LEFT JOIN b ON a.id = b.id
  WHERE a.id > 0' \
 --output-format CSV > ~/workspace/mds_object.csv

Reference:

透過Dehydrated來設定Let’s encrypt

之前是使用Certbot來更新我這個網誌的Let’s encrypt certificate,運作上也還算正常,但自動更新cert這邊常常更新不了(這部分感覺應該是我設定上的問題)…

後來在公司上, DK有提到了dehydrated這個輕量化的Let’s enrypt 設定工具,實際上去快速看了一下它的repoistory以後,真的覺得對於一般的Linux 環境使用上蠻友善的(因為它所需要的工具通常都是Linux 系統預設的工具)。

快速掃完以後,直接進入正題關於設定上的相關指令… (這邊直接參考 DK 的 wiki上的設定)

安裝Dehydrated

# using a temporary directory to download the dehydrated
cd ~/tmp
wget "https://raw.githubusercontent.com/dehydrated-io/dehydrated/master/dehydrated"
chmod +x dehydrated
sudo mv dehydrated /usr/local/bin/

Dehydrated環境設定

# create directories that dehydrated will need
sudo mkdir -p /etc/dehydrated /var/www/dehydrated

#change to the dehydrated dir
cd /etc/dehydrated

# setup the config
echo 'OCSP_MUST_STAPLE=yes' | sudo tee -a config
echo 'KEYSIZE=2048' | sudo tee -a config
echo 'WELLKNOWN=/var/www/dehydrated' | sudo tee -a config

# setup the domain file
echo 'blog.gechen.org' | sudo tee -a domains.txt
 

設定Nginx

這邊的範例主要是透過Nginx來當做之後dehydrated 執行時,用來回應Let’s encrypt 的challenge…

下面就直接貼Nginx 的對應domain的範例設定檔

server {
     listen 80;
     server_name blog.gechen.org;
     rewrite ^(.*) https://$host$1 permanent;
 }

server {
     listen 443 ssl;
     server_name blog.gechen.org;
     
     index index.php;
     ssl_certificate /etc/dehydrated/certs/blog.gechen.org/fullchain.pem;
     ssl_certificate_key /etc/dehydrated/certs/blog.gechen.org/privkey.pem;


     # ... skip some configs

   
     # this part is for dehydrated
     location /.well-known/acme-challenge/ {
        alias /var/www/dehydrated;
     }
 }

執行Dehydrated 來更新Let’s encrypt certs

如果是第一次使用 dehydrated 則要額外執行下面指令

sudo dehydrated --register --accept-terms

透過下面的指令來做Let’s encrypt certificate的申請/更新

# the following command will apply/renew certificates for the domains in file: /etc/dehydrated/domains.txt
sudo dehydrated -c

# or we can also directly use command below to apply for specific domain certificate
sudo dehydrated -c -d blog.gechen.org

設定自動更新certificate的cron jobs

這邊直接引用DK 大大的wiki範例來設定 weekly 的憑證更新…

echo -e '#!/bin/bash\nexport PATH=/usr/sbin:/usr/bin:/bin:"${PATH}"\nsleep $(expr $(printf "%d" "0x$(hostname | md5sum | cut -c 1-8)") % 86400); dehydrated -c && ( service nginx reload )' | sudo tee /etc/cron.weekly/dehydrated; sudo chmod 755 /etc/cron.weekly/dehydrated 

References:

Database diff

從DK的blog上看到的分享工具 data-diff 後, 快速看了一下它的說明文件以後, 感覺這東西有需求的話應該會蠻不錯用的!

看起來可以比對多個data source的資料表, 而且預計支援的資料庫或相關服務也蠻多是市面上常見的… 蠻適合以後有需要時再來試看看.

Reference:

調低EBS 的磁碟大小

前言

最近收到AWS的個人帳單以後, 突然發現我帳單上的金額與我的想像有些落差, 也因為這樣子, 開始來對一下是哪些項目在吃錢…

大概對了一下, 發現主要的花費在EC2 instance 與 EBS 兩個項目上面, EC2 instance 這邊的花費就是題外話了, 但EBS這邊就慢讓我意外的… 細看了以後才發現當初不知道為什麼把使用的EBS 成 使用30GB, 但我實際上的使用也才6GB左右…
(雖然這也不是什麼大錢, 但每個月給它這樣扣也是覺得還不如把錢省下來去訂閱其他有用服務….)

第一次實驗

原本想說把root volume EBS 調低應該不是件難事, 結果沒想到AWS預設上是不支援這件是的, 它可以往上調高, 但不支援調低…

在網路上找了不少相關的教學文, 主要的作法都是, 大概都是…

  • 先建立一個較小的EBS volume
  • 再把這個新的 EBS volume 掛到我們的EC2上面以後, 做好格式化以及 rsync 的資料拷貝
  • 最後設定好 /boot 以後, 就可以把新的EBS volume來取代原有的 EBS root volume.
    (題外話, 要把EBS volume 設定為 EC2 上面的 /dev/sda1 才會成為那台EC2上的root volume)

第一次實驗結果

經由上述步驟的教學文實際嘗試以後, 都會卡再做出來的EBS volume是無法當成是原本這一台EC2的root volume, 它會直接讓那台EC2開不起來. (機器顯示 running, 但是ssh 連不到…)

上述的測試其實我參考了不少文章, 但最後卡的點都是一樣的, 做出來的 EBS volume是不能用的… (我這邊使用的EC2 t4g family, 不太確定跟ARM 版本的 grub-install 有關??? 也許今天使用的是x86的機器就可以? 之後有機會再來試試)

另一種Workaround的方式

因為上面測試也花了不少時間, 所以最後就自己做了一些流程上的調整如下:

  • 建立一台新的EC2, 並設定root volume為我想要的大小 (6GB), 並且OS的版本也是用與就機器一樣的 ubuntu 20.04
  • 接著, 將舊機器的EBS 掛到新的EC2機器上.
  • 透過 rsync 將舊的EC2 資料都複製到新的EC2上. (基本上除了 /boot, /tmp, /mnt, /dev以外, 都要sync 到新的EC2的對應資料夾)
  • 如果先前有設定route53, elastic IP 等等相關的設定, 最後都指定到這台新的EC2機器上.

最後靠這個方式成功把 EBS size降下來了, 不過靠這個方式比較像是duplicate出一台新的EC2, 而不是clone出一模一樣的機器…

Reference:

AWS Lambda的”冷啟動”時間

在Hacker News 上看到的一些相關比較,作者比較了現有AWS Lambda 的程式語言,並記錄每種語言在不同情境下的cold start的時間。

測試架構大概如下:

clients -> HTTP API -> Lambda function -> Dynamo DB

直接跳到測試結果

Cold start:

* All languages(except Java and .Net) have a pretty small cold start.
* Java even cannot start with 128Mb. It needs more memory. But GraalVM can help in this case.
* Rust beats all runtimes for all setups for cold start, the only exception is 128 MB where Python is the best.

AWS Lambda battle 2021: performance comparison for all languages (cold and warm start) | by Aleksandr Filichkin | Sep, 2021 | Medium

Warm start:

* Golang and Rust are the winners. They have the same brilliant performance.
* .Net has almost the same performance as Golang and Rust, but only after 1k iterations(after JIT).
* GraalVM has a stable great performance almost the same as .Net and a bit worse than Rust and Golang. But it doesn’t perform well for the smallest setup.
* Java is the next after GraalVM.The same as .Net, Java needs some time(1–3k iterations) for JIT(C1). Unfortunately for this particular use case, I was not able to achieve the expected great performance after JIT C2 compilation. Maybe AWS just disabled it.
* Python has stable good performance but works too slow for the 128 MB.
* Ruby has almost the same performance as Python, but we see some duration growing after 20 min invocations(after 15k iteration).
* NodeJs is the slowest runtime, after some time it becomes better(JIT?) but still is not good enough. In addition, we see the NodeJS has the worst maximum duration.

AWS Lambda battle 2021: performance comparison for all languages (cold and warm start) | by Aleksandr Filichkin | Sep, 2021 | Medium

Go與Rust是其中最穩定的且效能最好的,在幾乎所有的情境下,都是前2名。(唯一的例外是,Python在128MB RAM 的環境下是最快的)。

對我而言比較意外的是Node.js,沒想到會是最慢的!?

Reference:

AWS Lambda battle 2021: performance comparison for all languages (cold and warm start) | by Aleksandr Filichkin | Sep, 2021 | Medium

Cassandra 叢集狀態的計算機

網路上看到的一個Cassandra的簡易計算機,作者還有的提供原始碼在Github 上,所以如果有需要的話也可以自己fork一份自己架在自己的網頁上。

這個計算機的功能也很簡單,主要是提供使用者可以快速顯示在不同的cluster狀態下,根據keyspace的read/write 設定對於叢集的影響,像是:

  • 可以容忍多少個節點失效而不遺失資料。
  • 每個節點的資料分佈比例。
  • 每次寫入會連接到的節點數量。
  • 每次讀取時會連接到的節點數量。

reference:

  • https://github.com/jalkanen/cassandracalculator
  • https://www.ecyrd.com/cassandracalculator/

Incremental ETL

Databrick blog 上看到的一篇文章,剛好在提到一些資料處理概念,剛好也可以複習一下相關的知識。

et’s first dive into what exactly incremental ETL is. At a high level, it is the movement of data between source and destination – but only when moving new or changed data. The data moved through incremental ETL can be virtually anything – web traffic events or IoT sensor readings (in the case of append data) or changes in enterprise databases (in the case of CDC).

https://databricks.com/blog

https://databricks.com/blog

概念上,就是將原始收集到的資料,透過每個階段的ETL job,來整理與清洗資料,並且再存入下一個資料儲存的地方;而每個處理的階段就因組織而異了,但最終目的就是希望真的需要用某些資料時,它已經是處理好在那了。
另外,大量的原始/歷史資料其實就可以存在像Datalake 這類型的地方,以減少儲存成本。

對於Data driven的組織來說,這樣的架構設計可以讓資料的處理更有效率,且大量的原始資料若存放在Datalake 則又可以降低營運成本。

但相對的,也有些負面的取捨如下:

  • 每個資料處理階段,可能都會需要額外的ETL pipeline來處理,而這些都會是營運上的成本。
  • 當一筆原始資料進入時,對於最下游的服務來說,需要隔一段(ETL處理)時間才會反應再下游服務的資料中,所以對於資料有立即性的需求可能就會不太適合。
  • 若要更新原始資料,並且更新所有下游的資料會是非常困難的事情。

Cassandra 4.0

在Scylla Blog上看到的Cassandra 4.0 vs Cassandra 3.11的相關測試文章,沒想到會去測試Cassandra不同版本間的效能比較,還蠻意外的XD

從測試的數據來看,Cassandra 4.0的效能幾乎在各個測試情境下,都比Cassandra 3.11要好不少,看起來平均有20-30%的效能改進;等之後有機會再看看是否有更多相關的測試數據出來XDD

reference: