Mq-Stream on Tarragonhttps://tarrragon.github.io/blog/tags/mq-stream/Recent content in Mq-Stream on TarragonHugo -- gohugo.iozh-TWTarragon (CC BY 4.0)Tue, 12 May 2026 00:00:00 +00009.C9 Spotify：從自管 Kafka 遷移到 GCP Pub/Sub 的事件交付系統https://tarrragon.github.io/blog/backend/09-performance-capacity/cases/spotify-kafka-to-pubsub-migration-gcp/Tue, 12 May 2026 00:00:00 +0000https://tarrragon.github.io/blog/backend/09-performance-capacity/cases/spotify-kafka-to-pubsub-migration-gcp/<p>這個案例的核心責任是說明「事件交付系統的容量規劃，靠 managed service 卸載 vs 自管 broker」的長期成本對照。Spotify 從 Kafka 遷到 Pub/Sub 的驅動力是 <em>容量規劃的工程成本</em> 在 sustained growth 下變得不划算、Kafka 能力本身不是瓶頸。</p> <h2 id="觀察">觀察</h2> <p>Spotify 在 Google Cloud 的遷移敘述（引自 <a href="https://cloud.google.com/blog/products/gcp/spotifys-journey-to-cloud-why-spotify-migrated-its-event-delivery-system-from-kafka-to-google-cloud-pubsub">Spotify&rsquo;s journey to cloud</a>）：</p> <table> <thead> <tr> <th>指標</th> <th>內容</th> </tr> </thead> <tbody> <tr> <td>用戶規模</td> <td>7500 萬 + 用戶（遷移時期）</td> </tr> <tr> <td>遷移系統</td> <td>Event Delivery System（事件交付）</td> </tr> <tr> <td>遷出技術</td> <td>自管 Apache Kafka</td> </tr> <tr> <td>遷入技術</td> <td>Google Cloud Pub/Sub</td> </tr> <tr> <td>大數據生態</td> <td>BigQuery / Dataflow / Dataproc / Pub/Sub</td> </tr> </tbody> </table> <p>關鍵動機：「moving event delivery to a managed service」— 卸下 Kafka broker 的容量規劃與運維負擔。</p> <h2 id="判讀">判讀</h2> <p>Spotify 遷移揭露三個 broker 容量規劃的長期工程問題。</p> <ol> <li><strong>自管 broker 的容量規劃是長期 tax</strong>：Kafka cluster 需要 partition planning、broker 數量、副本因子、disk capacity、network bandwidth、ZooKeeper / KRaft 治理 — 每個維度都要持續規劃、每次擴容都是工程專案。對應 <a href="https://tarrragon.github.io/blog/backend/03-message-queue/" data-link-title="模組三：訊息佇列與事件傳遞" data-link-desc="整理 durable queue、broker、retry、outbox 與 idempotency 的後端實務">03 訊息佇列模組</a> 的 broker basics 與 <a href="https://tarrragon.github.io/blog/backend/09-performance-capacity/" data-link-title="模組九：效能工程與容量規劃" data-link-desc="把『目前配置能撐多少、要加多少機器』變成可量化、可驗證、可改進的工程流程">9.7 成本邊界與 efficiency</a> 的人力成本評估。</li> <li><strong>managed service 的容量是 trade-off、不是免費午餐</strong>：Pub/Sub 自動 scaling、但 vendor lock-in、cost-per-message 累積、message ordering / latency 特性跟 Kafka 不同。遷移本身要驗證 <em>業務語意</em> 跟 Pub/Sub 兼容。對應 <a href="https://tarrragon.github.io/blog/backend/03-message-queue/broker-basics/" data-link-title="3.1 broker 基礎與投遞模型" data-link-desc="先理解 broker、queue、consumer 與 delivery semantics">03.4 broker basics</a>。</li> <li><strong>遷移本身是容量規劃題目</strong>：把 7500 萬用戶的事件交付從 A 平台搬到 B 平台、不能停機、不能丟 message。這個遷移過程本身就是高併發容量工程。對應 <a href="https://tarrragon.github.io/blog/backend/01-database/schema-migration-rollout-evidence/" data-link-title="1.7 Schema Migration Rollout 證據（Schema Migration Rollout Evidence）實作示範" data-link-desc="以訂單付款狀態欄位演進示範 schema migration 如何產出 evidence、release gate 與 incident decision log。">01.3 schema migration rollout evidence</a> 的同類流程。</li> </ol> <p>需要警惕：Spotify 這個決定不是「Kafka 不好」、是「Spotify 規模下、自管 Kafka 的工程投入不划算」。對中小團隊、自管 Kafka 可能是更便宜的選項。讀案例時要看 <em>規模門檻</em> 跟 <em>團隊能力</em>。</p> <h2 id="策略">策略</h2> <p>可重用的工程做法：</p> <ol> <li><strong>broker 自管 vs managed 是長期 TCO 評估</strong>：算「平日運維 + 容量擴容 + 故障處理 + 升級遷移」的人力成本、不只算「broker 雲端費用」。對應 <a href="https://tarrragon.github.io/blog/backend/09-performance-capacity/" data-link-title="模組九：效能工程與容量規劃" data-link-desc="把『目前配置能撐多少、要加多少機器』變成可量化、可驗證、可改進的工程流程">9.7 成本邊界與 efficiency</a>。</li> <li><strong>遷移分階段：dual write → shadow → cutover</strong>：先寫兩邊、驗證一致性、再切流量。對應 <a href="https://tarrragon.github.io/blog/backend/01-database/schema-migration-rollout-evidence/" data-link-title="1.7 Schema Migration Rollout 證據（Schema Migration Rollout Evidence）實作示範" data-link-desc="以訂單付款狀態欄位演進示範 schema migration 如何產出 evidence、release gate 與 incident decision log。">01.3 schema migration rollout evidence</a> 的同類流程。</li> <li><strong>業務語意對映是遷移關鍵</strong>：Kafka 的 partition / offset / consumer group 在 Pub/Sub 對映成不同概念（subscription / ordering key / message attribute）、不是 1:1。</li> </ol> <p>跨平台等效：AWS SNS / SQS / Kinesis、Amazon MSK（managed Kafka）、Azure Service Bus / Event Hubs / Event Grid 都是對等候選。差異是 message ordering 保證、delivery guarantee、cost model。</p>這個案例的核心責任是說明「事件交付系統的容量規劃，靠 managed service 卸載 vs 自管 broker」的長期成本對照。Spotify 從 Kafka 遷到 Pub/Sub 的驅動力是 容量規劃的工程成本 在 sustained growth 下變得不划算、Kafka 能力本身不是瓶頸。

觀察

Spotify 在 Google Cloud 的遷移敘述（引自 Spotify’s journey to cloud）：

指標 內容
用戶規模 7500 萬 + 用戶（遷移時期）
遷移系統 Event Delivery System（事件交付）
遷出技術 自管 Apache Kafka
遷入技術 Google Cloud Pub/Sub
大數據生態 BigQuery / Dataflow / Dataproc / Pub/Sub

關鍵動機：「moving event delivery to a managed service」— 卸下 Kafka broker 的容量規劃與運維負擔。

判讀

Spotify 遷移揭露三個 broker 容量規劃的長期工程問題。

  1. 自管 broker 的容量規劃是長期 tax：Kafka cluster 需要 partition planning、broker 數量、副本因子、disk capacity、network bandwidth、ZooKeeper / KRaft 治理 — 每個維度都要持續規劃、每次擴容都是工程專案。對應 03 訊息佇列模組 的 broker basics 與 9.7 成本邊界與 efficiency 的人力成本評估。
  2. managed service 的容量是 trade-off、不是免費午餐：Pub/Sub 自動 scaling、但 vendor lock-in、cost-per-message 累積、message ordering / latency 特性跟 Kafka 不同。遷移本身要驗證 業務語意 跟 Pub/Sub 兼容。對應 03.4 broker basics。
  3. 遷移本身是容量規劃題目：把 7500 萬用戶的事件交付從 A 平台搬到 B 平台、不能停機、不能丟 message。這個遷移過程本身就是高併發容量工程。對應 01.3 schema migration rollout evidence 的同類流程。

需要警惕：Spotify 這個決定不是「Kafka 不好」、是「Spotify 規模下、自管 Kafka 的工程投入不划算」。對中小團隊、自管 Kafka 可能是更便宜的選項。讀案例時要看 規模門檻 跟 團隊能力。

策略

可重用的工程做法：

  1. broker 自管 vs managed 是長期 TCO 評估：算「平日運維 + 容量擴容 + 故障處理 + 升級遷移」的人力成本、不只算「broker 雲端費用」。對應 9.7 成本邊界與 efficiency。
  2. 遷移分階段：dual write → shadow → cutover：先寫兩邊、驗證一致性、再切流量。對應 01.3 schema migration rollout evidence 的同類流程。
  3. 業務語意對映是遷移關鍵：Kafka 的 partition / offset / consumer group 在 Pub/Sub 對映成不同概念（subscription / ordering key / message attribute）、不是 1:1。

跨平台等效：AWS SNS / SQS / Kinesis、Amazon MSK（managed Kafka）、Azure Service Bus / Event Hubs / Event Grid 都是對等候選。差異是 message ordering 保證、delivery guarantee、cost model。

下一步路由

引用源

]]>