很久沒寫部落格了，因為現在在 AI 時代，其實有點覺得找不到寫部落格的動機 XD…不過因為去年到今年持續使用 Vespa 的 groups 時，遇到一些問題而因此跟 Vespa 團隊有不少討論，簡單紀錄一下這些經驗和結論。然後先承認這篇是我寫完簡單的草稿之後給 AI 幫我補細節的，因為我懶得再自己去找範例跟畫表格 XDDD。
Vespa 的 flat mode、group mode 與 scaling 策略
首先是什麼時候應該使用 flat mode，什麼時候應該使用 group mode？
大體上的經驗是，content node 開到 50 個以上時，就應該開始考慮轉成 group mode。group mode 下，每個 group 都保存一份完整資料，而 Vespa 會把一個 query 只送到其中一個 group，再由該 group 內的 content nodes 平行處理。因此，增加 group 可以增加 query throughput，同時避免每個 query 都要 fan-out 到整個 cluster。
再來，使用 group mode 時，應該要：
- 依 group 數量 scaling
- 依 group 內 node 數量 scaling
- 兩者同時啟用
簡要答案是：看情況，但幾乎沒有理由使用 (3)，大致上是 (1) 或 (2) 選一個。
不使用 (3) 的主要原因是難以預測。當 scaling 行為觸發時，增加 group 或增加 group 內 node，都有可能改善當前資源壓力；但很難預測 Vespa 最後會採用哪一種拓撲。因此 query latency、資料重分布量，以及成本的變化都會比較不穩定。
以下範例以 Vespa Cloud 的 services.xml 為例：
| 策略 | Vespa 設定範例 | Scaling 時發生什麼事 | 對 query latency 的影響 | 對 memory / 資料容量的影響 | 適合情境 |
|---|---|---|---|---|---|
| (1) 只依 group 數量 scaling | <nodes groups="[2, 4]" group-size="8"> |
每個 group 固定 8 台 node；Vespa 在 2 到 4 個 group 之間擴縮。 | 最穩定。新增一個 group 後，每個 query 仍只會查固定的 8 台 node。 | 現有 group 的 node memory 使用率不會下降，因為每個新 group 都必須保存完整資料；只是整體 memory 與成本會隨 group 數增加。 | query 流量變動大、希望擴縮後 latency 行為可預期的情境。 |
| (2) 只依 group 內 node 數量 scaling | <nodes groups="3" group-size="[8, 32]"> |
group 數固定為 3；總 node 數在 8 到 32 台之間變動，因此每個 group 的 node 數會增加或減少。 | 有些微影響。group 變大時，query 要 fan-out 給更多 content node；scale-out 幅度越大，影響通常也越明顯。 | 每個 group 的資料被分到更多 node，單一 node 的 memory、disk 與 CPU 壓力都會下降。 | query 流量相對穩定，但資料量、index size 或 memory 壓力會持續變動的情境。 |
| (3) 同時依 group 與 group 內 node 數量 scaling | <nodes groups="[2, 4]" group-size="[8, 32]"> |
Vespa 可以同時改變 group 數與每組 node 數。 | 最難預測：可能是增加 group，也可能是增加每組 node，兩者對 latency 的效果不同。 | 同樣難預測：可能新增完整資料副本，也可能只是把既有 group 的資料分散到更多 node。 | 通常不建議。除非已經理解 autoscaler 的實際行為，並可接受 topology 變動的不確定性。 |
(1) 的 group 組成是固定的，scaling 是增加或減少 group。因為每個 group 都要包含完整資料，所以增減 group 不會降低既有 node 的 memory 使用率；scale-out 的本質是增加一整份資料副本。不過 query 每次面對的 node 數不變，因此 latency 表現最穩定。
(2) 的 group 個數不變，但增加或減少 group 內的 node 個數。Vespa 會把 query 送給被選中的 group 內所有 content node，所以 group 內 node 越多，query 的 fan-out 對象也越多，對 latency 會有些微影響。不過相對地，資料會分散到更多 node，單一 node 的 memory 與 disk 壓力會下降，因此比較適合查詢流量穩定、但資料量變動大的情境。
最後一個實務上的提醒：如果最終確實需要同時改變 group 數與 group size，建議拆成兩次調整，中間等資料重分布完成。這樣比較容易維持完整 query coverage，也比較容易觀察每次 topology 變動帶來的影響。
參考資料：
