但這問題應該是每一家雲端服務平台都一樣吧?

想到以前無名時代都是說種花吸血，現在換成給外國人吸了 (然後再去買創新高的 AMZN (X))

而且所有的流量、CPU使用時數全都是 AWS 說了算，你連吵都沒得吵，他說多少就多少

AWS 是很貴沒錯，不過也是因為疫情的關係 Zoom 流量暴增才會差這麼多吧，一個月的流量是 217,000 terabytes...

AWS 吸血吸的太過份了，連 AZ 間的流量都收高價 (跟跨 region 一樣的錢)

所以如果你 deploy k8s 在 AWS，預設的情況都是 cross-AZ，然後你還搞 micro service 的話，流量一大就會看到帳單出現以前從沒見過的收費 - 那些你在 service/pod 間的呼叫通通要錢

microservice 就是要吃大流量才想用的架構，但你一上雲端就是吃光你的錢。

最近看同事在碰resharding...在 RDBMS 又是應用層內部做的。 好想加加新機器就搞定～

你的說的沒錯 哈

我覺得關鍵還是主事者熟悉哪一套技術吧，真的量大一定都還是要人下去 tune，就算用AWS黑科技 auroa/dynamodb一樣會爛。

例如之前 mongodb 很紅的時候很多人以為用了就無敵了，後來用下去也是該踩的雷都少不了 (雖然以這題來說感覺蠻適合的)

olap 能處理大資料, 但不能處理大量 request

你貼的那個範例應該不可能放在 quora站上讓一般用戶即時查看吧

對，算是可以用於OLAP的DB，但同時也可以針對數十億、甚至上百億筆的資料去運算。

這是剛剛查詢一個大約千億筆資料的performance: 1. 單純count - 112.97 billion rows/s 2. 使用DATE做group by - 4.94 billion rows/s

clickhouse 看起來是給分析用的啊

大table除了NoSQL，也可以考慮放到clickhouse，partition設計的好跟用MySQL幾乎一樣。

為了 sharding 所以資料都不 join

跟裡面的留言一樣，我也覺得這些大 table 搬到 NoSQL 才是。但他們回 HBase 不太行。啊本來就不該用 HBase 吧，大概是不想再增加技術門檻了才不想換，從他們選擇自己做 shard 就知道 (NIH...)。

其實我還以為 quora 已經死掉了，你 google 去找根本很少是 quora 的文章說

三大雲端廠商最常聽到主機不足的就是 Azure

想知道選擇 NodeBB 的原因

沒吧，這是兩年前的規定 (當時宣告免費)。

今年中會開收費

看英文比較準

漲價是這個?

注意事項：2017 年 11 月 28 日起，系統在計算 GKE 叢集管理費用時，已「不再」採用以「每個叢集每小時」為單位的「固定費率」計價方式 (不分叢集大小一律適用)。

跟 AWS 一樣一個月一個 cluster 要 70美金左右, 只有第一個免費

還好沒轉到 GKE

nginx cert-manager 大概只要是 bare metal 都是這樣做，在自己的主機玩都這樣。

一開始我們先用 ALB，因為 ALB controller 雖然現在沒有可以共用 path rule，但其實已經做好了，等待 alpha 測試完畢就可以用了。結果沒想到一等就等半年 (作者太忙，他們都 AWS 的人)。所以現在卡的不上不下的，如果打掉重練的話可以重新考慮 nginx 的作法。

不過， NLB 進來的封包，會先經過 kube-proxy (iptables 吧?)，再到 nginx pods，再到 app pods，一個封包在 nodes 間 bounce 兩次以上這種事我實在是受不了… 如果 node 是跨 Availability Zone 的話，每次 bounce AWS 都要收錢的

SSL Termination 可以用 cert-manager，用 let's encryption issuer1 其實挺無腦的。他好像沒有提到 ALB 比較貴的缺點，我怎麼看都覺得 NLB + nginx 比較好。話說我們用 GCP 也是用 L4 LB + nginx ingress 唷。

文中有寫到和 ALB 的優缺點，對我們而言比較重要的就是 ssl termination 了。NLB+nginx 的組合 ssl 就要自己管，有點麻煩

ingress 改用 nginx1 呢?

node 現在有 managed node & fargate 可以用

兩者都不支援 spot instances, 然後 fargate 不支援 EBS，暈倒

ingress 的話，我目前是用 ALB + traefik ingress，其實還是可以用一台 ALB 搞定一卡車小站

哎，就是麻煩啊，k8s 的難度已經很高了，還要自己搞一套。而且我個人不喜歡 traffic 在 node 間 bounce。純 ALB 可以直通 pods，這算是 EKS 的優點。

cloudsql 聽到有 downtime 是一兩年前的事了，現在還會遇到嗎？拿麼恐怖

恩恩 感謝回覆我的問題！！！ 不過我知道有些點有改善

• master 要錢 <--- 真的貴
• node 現在有 managed node & fargate 可以用 (心智成本又上升了)
• GKE 其實到最後還是要熟 VPC 的部分，我們家有踩到一些雷，最後還是自己重切過
• ingress 的話，我目前是用 ALB + traefik ingress，其實還是可以用一台 ALB 搞定一卡車小站
• EC2 網卡這個我認同， 這個東西每次都要查一下，蠻麻煩的 Link1

GKE 我覺得很棒，但是 GCP 的問題一直都是其他 managed service 沒 AWS 多且穩定， 像是 cloudsql 會有 downtime 就抖抖的，這方面可能再跟大家請教下 XD

Google GKE 大概是做最好的吧，這也是去年 GCP 用戶上升的原因。

EKS 就是個拼裝車，把 AWS 現有的服務硬裝上 k8s，所以變成用戶除了使用 k8s 外，還要處理 AWS 本身的服務，以及橋接的部份。

• EKS 的 master 要錢，mdfk
• EKS 的 node 要自己安裝升級，還要一台台自己手動升，mdfk
• EKS 還要先設好 VPC，VPC 除了設一堆 route table 外還要買固定 IP，然後超級難懂，mdfk
• EKS 的 ingress 是不能共用 Load Balancer (ALB) 的，所以每個對外的網址都要開一台 LB，你開十個小站就要花十台 LB 的錢，mdfk
• EKS node 延用 EC2 的網卡架構，舉例一台小 node 如果能配四張網卡，而一張網卡只能配四個 IP 的話，你一台 node 就只能裝 16 pods 左右，不論你 cpu/ram 還剩多少空間，mdfk