[COST] Enable to tune the estimation method of NetworkCost

[garyparrot]

Context: #1641 (comment)

因為 FifteenMinuteRate 的等待時間有點長，要在短時間內使用他當做判斷依據有點困難，如果在 Rate 還沒收斂時就拿來當判斷依據，會有誤差出現，詳情參見 #1641 的測試。

這個 PR 允許使用者調整 network cost 要使用的衡量方法，目前提供 One/Five/Fifteen Minute Rate，預設會使用 One Minute Rate，他收斂的速度會比較快，但相對來說也會比較難反映稍微長遠的變化。

另外，雖然 FifteenMinuteRate 可以反映更長的流量行為，但根據 #1641 的測試最長似乎也就 1 小時左右，如果真的要考量長遠的流量行為，可能 NetworkCost 不適合。

[chia7712]

@garyparrot 感謝patch，這個修正很有道理，幾個建議請看一下

[garyparrot]

在套用這個 PR 的修正的情況下，以 One Minute Rate 做了一次實驗：

這是 Initial Cost

Initial Cost: WeightCompositeClusterCost[
{"NetworkEgressCost" cost 0.07537467820969741 weight 3.0 description {
    466.94 MB/seconds,
    401.50 MB/seconds, 
    414.69 MB/seconds, 
    409.43 MB/seconds, 
    424.33 MB/seconds, 
    606.80 MB/seconds} }, 
{"NetworkIngressCost" cost 0.07341424084159019 weight 3.0 description {
    325.61 MB/seconds, 
    269.42 MB/seconds, 
    275.05 MB/seconds, 
    272.11 MB/seconds, 
    285.35 MB/seconds, 
    469.38 MB/seconds} }, 
{"ReplicaNumberCost" cost 0.003724957213329306 weight 1.0 description LongSummaryStatistics{
    count=6, 
    sum=9933, 
    min=1635, 
    average=1655.500000, 
    max=1672} }] = 0.06429881633817029

注意 Egress 的最大節點流量是 606 MB/s 大致上和圖上的符合。

這是 Final Plan 的 Cost

Final Cost: WeightCompositeClusterCost[
{"NetworkEgressCost" cost 3.713196969092253E-5 weight 3.0 description {
    453.91 MB/seconds, 
    453.92 MB/seconds, 
    453.95 MB/seconds, 
    453.98 MB/seconds, 
    453.93 MB/seconds, 
    454.01 MB/seconds} }, 
{"NetworkIngressCost" cost 0.021662362140926306 weight 3.0 description {
    318.42 MB/seconds, 
    303.17 MB/seconds, 
    305.67 MB/seconds, 
    303.16 MB/seconds,
    304.35 MB/seconds, 
    362.16 MB/seconds} }, 
{"ReplicaNumberCost" cost 0.04349139232860163 weight 1.0 description LongSummaryStatistics{
    count=6, 
    sum=9933, 
    min=1313, 
    average=1655.500000, 
    max=1745} }] = 0.015512839237207617

注意 Egress 全部都差不多一樣，優化出來的結果也是大家變成一直線。

裡面有提到節點的流量狀態，比對優化後的結果都有符合，看起來這個流量算不準的問題在

1. 使用 One Minute Rate
2. 等待 One Minute Rate 的 metrics 值穩定後

有解決了

[chia7712]

318.42 MB/seconds,
303.17 MB/seconds,
305.67 MB/seconds,
303.16 MB/seconds,
304.35 MB/seconds,
362.16 MB/seconds

請問一下 ingress 誤差比較大的原因是什麼？

裡面有提到節點的流量狀態，比對優化後的結果都有符合，看起來這個流量算不準的問題在
使用 One Minute Rate
等待 One Minute Rate 的 metrics 值穩定後

不好意思，這個結論我有點看不太懂。就我目前的了解是fifteen的問題是需要一段時間等待數字穩定，而現在 balancer 用法在 metrics是即時收集的狀態下，無法等待那個時間。反之 one minute 較快達到穩定，所以我們選擇使用 one minute

我的理解是正確的嗎？

[garyparrot]

請問一下 ingress 誤差比較大的原因是什麼？

我看起來 Ingress 這邊的誤差看起來沒有比較大，粗略看起來誤差都在 10 MB/s 之內，如果以最高的節點流量 362 MB/s 下去看的話大約是值本身的 ± 3% 附近

不好意思，這個結論我有點看不太懂。就我目前的了解是fifteen的問題是需要一段時間等待數字穩定，而現在 balancer 用法在 metrics是即時收集的狀態下，無法等待那個時間。反之 one minute 較快達到穩定，所以我們選擇使用 one minute

我的理解是正確的嗎？

是的，抱歉我原本那段沒有寫好

[chia7712]

LGTM

感謝修正，做得很好