紀錄一下最近解了幾天的問題，程式碼大體上類似 [1] 裡面的 MyRecordProcessor 和 MyRecordProcessorTest 那樣。因為本來是要建置環境比較簡單的測試來重現問題，而原本的問題是發生在開發 Kinesis 的 RecordProcessor 中遇到的，因此 [1] 的範例也沿用了這個關係。不過實際上最後發現的原因跟 Kinesis 沒有關係就是了。
問題的徵兆是，當要測試的標的內部改寫成有 parallel 的狀況時，Spock 這邊執行測試就可能會出現測試整個卡在某個地方的狀況。卡住時會完全沒有回應，但也沒有拋出錯誤或者停止執行。這個問題好像遇到的人並不是那麼多，所以可以找到的資料也非常少。不過主要參考了 [2-3]，最後確認的原因是因為測試時用了 Spy。Spy 好像存在某些限制（在 [3] 的回答中有提到，雖然他沒提到到底是什麼限制），實際上似乎導致在 parallel 的狀況時，Spy 的 dynamic proxy 似乎有時會生效、但有時會無效。所以最後解決方法就是～不要用 Spy。
因為在公司持續地在用 Vespa，所以打算寫個系列文章慢慢紀錄 Vespa 的一些使用、調校經驗。（雖然說過去寫的系列文章大多…寫到第二或第三篇就………。）
本篇會紀錄在本機啟動 Vespa 的 container 的方法，通常這麼做可以在開發階段用來測試 Vespa 的語法。可以參考 Vespa 官方文件 [1]。
依照 [1] 的描述，Docker 環境最重要的就是需要有至少 6GB 的記憶體。而在我的環境中，我是在 Windows 10 上跑 Docker 的，因此至少要是個有支援 Hyper-V 的 Windows 版本，才能夠執行 Docker。
首先，Vespa 有提供一些簡單的範例 Application，可以從以下的 Github 取得。裡面有很多資料夾，包含了數種在 Vespa 官方文件中會講到的例子。
git clone https://github.com/vespa-engine/sample-apps.git
這裡假設我把這個 repository 放在 G:\git 裡。
要啟動 Vespa 之前，我們需要執行兩個動作。第一個是先啟動一個 Vespa 的 container，這個步驟只會準備好 Vespa 需要的執行環境而已。接著第二個是部署 Vespa Application，這個動作就像是在 RDBMS 裡執行 CREATE DATABASE 一樣，是讓 Vespa 準備好 schema 並且真的啟動伺服器。
docker run --detach --name sample-vespa --hostname vespa-container --privileged --volume g:\git\vespa-sample-apps:/vespa-sample-apps --publish 8080:8080 vespaengine/vespa docker exec sample-vespa bash -c 'curl -s --head http://localhost:19071/ApplicationStatus'
首先如前所說，我們先以 vespaengine/vespa 的 image 啟動一個 Vespa container，這裡我們把這個 container 命名為 sample-vespa，並且把資料夾 g:\git\vespa-sample-apps 掛到 container 的 /vespa-sample-apps 路徑上，方便之後我們在這個 container 中部署與啟動 Vespa。
container 開好以後，可以透過第二行指令來確認 Vespa 的狀態。不過因為 container 雖然綁了 port，但卻還沒有啟動任何服務，因此我們要確認狀態只能利用在 container 裡執行 curl 指令來確認。如果正常的話會獲得類似這樣的回覆：
HTTP/1.1 200 OK Date: Sun, 01 Mar 2020 11:31:41 GMT Content-Type: application/json Content-Length: 9232
接著就是要在裡面部署和啟動指定的 Vespa Application 了。
docker exec sample-vespa bash -c '/opt/vespa/bin/vespa-deploy prepare /vespa-sample-apps/album-recommendation-selfhosted/src/main/application/ && /opt/vespa/bin/vespa-deploy activate' curl -s --head http://localhost:8080/ApplicationStatus
這邊我們先部署 album-recommentation-selfhosted 這個 Vespa Application。因為 Vespa 的 Search Definition 是放在 src/main/application 裡的，因此在部署的時候要指定路徑是這個資料夾。第一個指令會獲得類似這樣的反應，表示已經順利地啟用 Vespa Application。
Uploading application '/vespa-sample-apps/album-recommendation-selfhosted/src/main/application/' using http://localhost:19071/application/v2/tenant/default/session Session 3 for tenant 'default' created. Preparing session 3 using http://localhost:19071/application/v2/tenant/default/session/3/prepared WARNING: Host named 'vespa-container' may not receive any config since it is not a canonical hostname. Disregard this warning when testing in a Docker container. Session 3 for tenant 'default' prepared. Activating session 3 using http://localhost:19071/application/v2/tenant/default/session/3/active Session 3 for tenant 'default' activated. Checksum: 71cf99ec40a0a08c8edbd1aa3cee03ed Timestamp: 1583062394458 Generation: 3
再使用第二個指令確認 Application 狀態時，可以獲得：
HTTP/1.1 200 OK Date: Sun, 01 Mar 2020 11:34:39 GMT Content-Type: application/json Transfer-Encoding: chunked
最近因為一個蠻莫名的問題，花了點時間在研究依靠 tail 來把 log 輸出到 docker log driver，然後發現其實這個作法算是一種 anti-pattern。目前認知到的問題有兩個：
在 stackoverflow 上，有好幾篇問題都做了類似的事情：
FROM debian:latest RUN touch /var/log/mylog.log CMD ["tail", "-F", "/var/log/mylog.log"]
在上面的 Dockerfile 中，先 touch 產生一個 log 檔，接著就一直 tail –F 去看那個 log 檔，感覺上好像很普通。但實際執行起來，會發現 docker logs 裡面什麼也沒有，tail 指令好像根本沒有正常在工作。而這個問題的根本原因是在於 docker 中間有 image layer，每一行 RUN 指令都會覆蓋上一層 image layer，因此實際上 touch 指令和 tail 指令在 docker 中是存取到不同的 inode。建議的作法應該要改為：
CMD ["sh", "-c", "touch /var/log/mylog.log && tail -f /var/log/mylog.log"]
也就是說，產生檔案以及監看檔案應該要在同一個 CMD 裡進行，這樣才能避免被 image layer 隔開而看不到預期的結果。
這個問題主要是考量到能不能善用 container 本身的特性。在透過 Dockerfile 執行程序時，container 對程序的期待是如果程序執行完了，container 就會被認為不再需要了，於是 container 就會自動關閉。這個特性也可以用在如果程序執行有問題導致非預期地中斷，container 也一樣會自動關閉。此時如果外頭有 load balancer 的話，load balancer 就可以自動做一些反應，例如因為 container 數量減少了，因此自動做 scale-out 重新生出一個 container。但如果 container 的 main process 並非是在執行主要程序，而是在執行 tail 的話，那有可能會遭遇到主要程序出問題結束了，但 tail 沒有問題，這時就可能存在失敗的服務一直繼續留在那邊無法正確被關閉。當然這個動作也可以透過例如另外做一套 health check 的流程來處理，不過如果能夠很簡單地就利用 container 的天性來達成這個目的，也是可以考慮利用一下～。
花了好多天的時間在研究，然後終於稍微搞清楚想要將 AWS ECS 上的應用程式的 log 導去 Splunk 時，需要注意的地方有哪些，以及它導出時是怎麼做的。不過在紀錄之前要先提一下，這篇當中不會提到如何建置 Splunk 服務，因為在我的狀況中 Splunk 是其他公司內的團隊已經建好的。
Logback 預設通常是會輸出一行一行純文字的 log，不過如果想要輸出 JSON 格式的話，也有看起來應該是第三方貢獻給 logback 的 extension 可以使用。
<properties>
<slf4j.version>1.7.26</slf4j.version>
<logback.version>1.2.3</logback.version>
<logback.contrib.version>0.1.5</logback.contrib.version>
<jackson.version>2.9.9</jackson.version>
</properties>
<dependencies>
<dependency>
<groupId>org.slf4j</groupId>
<artifactId>slf4j-api</artifactId>
<version>${slf4j.version}</version>
</dependency>
<dependency>
<groupId>ch.qos.logback</groupId>
<artifactId>logback-core</artifactId>
<version>${logback.version}</version>
</dependency>
<dependency>
<groupId>ch.qos.logback.contrib</groupId>
<artifactId>logback-jackson</artifactId>
<version>${logback.contrib.version}</version>
</dependency>
<dependency>
<groupId>ch.qos.logback.contrib</groupId>
<artifactId>logback-json-classic</artifactId>
<version>${logback.contrib.version}</version>
</dependency>
<dependency>
<groupId>com.fasterxml.jackson.core</groupId>
<artifactId>jackson-databind</artifactId>
<version>${jackson.version}</version>
</dependency>
</dependencies>除了 SLF4J 和 logback 本身以外，還需要 logback-json-classic，以及因為它使用 Jackson 來做 JSON 處理，所以需要 logback-jackson 和 jackson。
<?xml version="1.0" encoding="UTF-8"?> <configuration> <appender name="JSON_STDOUT" class="ch.qos.logback.core.ConsoleAppender"> <encoder class="ch.qos.logback.core.encoder.LayoutWrappingEncoder"> <layout class="ch.qos.logback.contrib.json.classic.JsonLayout"> <timestampFormat>yyyy-MM-dd'T'HH:mm:ss.SSSX</timestampFormat> <timestampFormatTimezoneId>Etc/UTC</timestampFormatTimezoneId> <jsonFormatter class="ch.qos.logback.contrib.jackson.JacksonJsonFormatter"> <prettyPrint>true</prettyPrint> </jsonFormatter> </layout> </encoder> </appender> <root level="ALL"> <appender-ref ref="JSON_STDOUT" /> </root> </configuration>
這裡很單純就設定了輸出時要用 JSON，並且其中的時間格式應該要符合我設定的格式，然後要求它輸出時要 pretty print（做好縮排等格式化）。
{
"timestamp" : "2019-09-28T13:04:25.013Z",
"level" : "TRACE",
"thread" : "main",
"logger" : "test.App",
"message" : "test writing log.",
"context" : "default"
}在文件 [1] 上對於 keep-rank-count 的描述如下：
How many documents to keep the first phase top rank values for. Default value is 10000.
而對於 rerank-count 的描述則是如下：
Specifies the number of hits to be re-ranked in the second phase. Default value is 100. This can also be set in the query. Note that this value is local to each node involved in a query.
其實很難看懂這到底在說什麼…。
事實上，它們的功能是應該要放在一起看待的。Vespa 的 ranking 有分 first-phase 和 second-phase，其中 first-phase 會肩負減少資料量的工作，以確保當 Vespa 內存放的資料非常多的時候，不需要對所有資料都做完所有運算。keep-rank-count 和 rerank-count 都是適用在 first-phase 階段的參數，以下分別討論它們的效果，會比較好理解。
keep-rank-count 造成的影響是當 Vespa 的每一個 search node （a.k.a. content node） 在 first-phase 取資料時，最多只會依據 rank profile 的計算去取出 keep-rank-count 指定數量的分數（和 docid），例如預設值 10,000 代表的是每個 nonde 都會暫存 10,000 筆資料的分數（和 docid），而超出這 10,000 筆資料的部份，分數就會被忽略（即只會留下 docid ）。因此走到 second-phase 時就只會有 10,000 筆資料能夠被後續做更複雜的處理。這也會反應在 Vespa 最後回覆的資料中，如果是超出 keep-rank-count 的部份的資料，分數都會顯示 –infinite，代表因為分數已經在處理過程被丟棄，因此在結果中會不知道分數是多少。
rerank-count 則是決定離開 first-phase 進入到 second-phase 時，會留下多少筆資料。需要注意的是，這裡的數字一樣都是每個 search node 計算的。舉例來說，如果有 10 台 search node，rerank-count 設定為 100，那麼總共就會有 1,000 筆資料會被送進 second-phase。
keep-rank-count 和 rerank-count 兩個結合起來，假設我的 rank profile 設定是 keep-rank-count=100, rerank-count=500，同時現在有個搜尋的指令，會搜尋到 1,000 筆資料，那麼結果會是如何呢？…..結果會是 second-phase 會看到 500 筆資料，但這 500 筆當中，只會有 100 筆的 relevance score 存在，其他 400 筆的 relevance 會顯示 -infinite。
當我們想要快速地知道某個資料是否曾經在系統中儲存過的時候，基本的作法就是時間複雜度 O(n) 或者是空間複雜度 O(n) 的選擇。
而 Bloom Filter 就是屬於中間型的解法，需要略高於 O(1) 的時間複雜度以及低於 O(n) 的空間複雜度。白話來說，就是 n 個資料並不需要長度為 n 的空間來存放，就能夠用來檢查 n 個資料中的任意資料是否存在於系統中。
概念上，Bloom Filter 就是使用一個陣列，用多個 hash function 來決定某個資料的位置，然後把陣列上的這些位置全都標為 1。其中資料不一定要是什麼格式，要求只是使用的 hash function 能夠輸出一個數字，來代表在陣列上的位置。因此檢查資料在不在系統中，只需要檢查這些位置是否全都是 1 就能夠知道了。不過因為是用 hash function，因此可以想見應該存在 collision 的問題，也就是有可能有多個資料會同時使用某個相同的位置，只是不會每個位置全都一樣。另外這個檢查方式也可以想像到潛在的問題：當檢查出某個資料的位置都是 1，有可能只是這些位置剛好都是被其他不同資料標上 1，並不一定真的表示我們要找的這個資料就確實存在。因此 Bloom Filter 無法保證某個資料一定存在（可能有 False Positive）、但可以保證某個資料一定不存在（不會有 False Negative）。
另一方面，因為 Bloom Filter 在儲存時只會存 0 和 1，表示它其實不知道每個位置是由哪個資料標上的。反過來說就是，當我因為加入資料的動作，把某個位置的值從 0 改為 1 後，日後我就再也無法把那個位置改回 0 了，因為 Bloom Filter 沒辦法知道這個位置跟哪個資料有關係。這也就形成 Bloom Filter 這個結構只能夠增加資料，而無法移除資料的限制。
所以簡要來說，Bloom Filter 就是個用比較少的儲存空間，快速判斷某個資料是否曾經被存放過的結構。
以 Redia 文件 [4] 的範例來說，可以用來檢查像是帳號是否被使用過：
> BF.ADD usernames funnyfred (integer) 1 > BF.ADD usernames fredisfunny (integer) 1 > BF.ADD usernames fred (integer) 1 > BF.ADD usernames funfred (integer) 1 > BF.EXISTS usernames fred (integer) 1 > BF.EXISTS usernames fred_is_funny (integer) 0