本文是跨 vendor migration playbook、cross-link 到 MySQL 跟 Aurora。走 Migration playbook methodology Type C operational hybrid 結構。每階段切換用 migration gate 把關。

從 MySQL 角度 看 Aurora MySQL：wire protocol 一致、SQL 一致、ORM 不必改、application 連 endpoint 字串以外幾乎不必動。從 Ops 角度 看 Aurora MySQL：所有 storage / replication / failover knob 都 看不到也改不了、整個 ops 心智模型重寫。

這是 Type C operational hybrid 的典型 signature — schema / paradigm 接近、operational 完全不同。

為什麼是 Type C（operational 為主）

跑 6 維 diff dimension audit：

Operational = High（其他 Low） → Type C operational hybrid。Migration 路徑用 4-phase drop-in cutover + operational re-onboarding。

Driver：TCO + Multi-AZ HA + AWS integration

從自管 MySQL 遷到 Aurora MySQL 的核心 driver：

• TCO：自管 MySQL 真實 cost = EC2 + EBS + ops headcount（1-3 個 FTE 撐大 MySQL deployment）。Aurora per-GB / per-IOPS 比 EC2+EBS 貴 30-50%、但省 ops headcount、總帳通常 break-even 或更便宜
• Multi-AZ HA：Aurora storage 自動 6 份跨 3 AZ、failover < 30 秒、不需要自管 Orchestrator + VIP + fence script
• AWS ecosystem integration：跟 Lambda / SAM / CloudFormation / IAM / Secrets Manager 整合、給 cloud-native architecture 加分
• Read scaling：Aurora 最多 15 個 read replica、storage layer 共享（不 replicate data、僅 replicate page cache）、read latency < 10ms inter-replica

不適合 已用 Percona Server fork 或 需要 cross-cloud portability 的 org — Aurora MySQL 是 AWS-only、且 fork 自 MySQL 5.7/8.0、跟 Percona 特性不完全一致。

4-phase migration

Phase 1：Aurora cluster 起來作為 read replica

最低風險入口：建 Aurora cluster、用 MySQL binlog 把 production 資料 stream 進 Aurora。Application 仍寫自管 MySQL primary、Aurora 作為 external read replica。

 1# 1. 在 AWS 建 Aurora MySQL cluster
 2aws rds create-db-cluster \
 3  --db-cluster-identifier prod-aurora \
 4  --engine aurora-mysql \
 5  --engine-version 8.0.mysql_aurora.3.04.0 \
 6  --master-username admin \
 7  --master-user-password ... \
 8  --database-name production \
 9  --vpc-security-group-ids sg-xxx \
10  --db-subnet-group-name prod-subnet
11
12# 2. 用 mysqldump 或 Percona XtraBackup 拿 baseline
13mysqldump --single-transaction --master-data=2 --triggers --routines --events \
14  --all-databases > baseline.sql
15
16# 3. Restore 到 Aurora
17mysql -h prod-aurora.cluster-xxx.us-east-1.rds.amazonaws.com -u admin -p < baseline.sql
18
19# 4. 設定 Aurora 從自管 MySQL 接 binlog
20CALL mysql.rds_set_external_master(
21  'self-managed-primary.example.com', 3306,
22  'replication_user', 'password',
23  'mysql-bin.000123', 12345, 0
24);
25CALL mysql.rds_start_replication;

完成標準：Aurora replica lag < 1 秒、跟 production primary 同步。

Phase 2：Application read 切到 Aurora reader endpoint

Application 仍寫自管 primary、但讀 query 切到 Aurora reader endpoint：

• Aurora reader endpoint：prod-aurora.cluster-ro-xxx.us-east-1.rds.amazonaws.com
• 自動 round-robin 多個 read replica
• ProxySQL 或 application config 改 read connection string

跑 1-2 週、確認：

• Aurora read latency 跟自管 replica latency 接近（通常 Aurora 略好）
• Aurora replication lag 穩定 < 1 秒
• Aurora query 結果跟自管 primary 一致（spot-check critical query）

完成標準：所有 read traffic 都進 Aurora、no application bug。

Phase 3：Cutover — promote Aurora primary

Cutover window 內：

 1# 1. 停 application 寫入（feature flag / scheduled maintenance）
 2
 3# 2. 等自管 primary 跟 Aurora 同步完成（檢查 Aurora replica lag = 0）
 4
 5# 3. 把 Aurora 從 external replica 提升為獨立 primary
 6CALL mysql.rds_stop_replication;
 7CALL mysql.rds_reset_external_master;
 8
 9# 4. Application 寫 connection string 切到 Aurora writer endpoint
10# prod-aurora.cluster-xxx.us-east-1.rds.amazonaws.com
11
12# 5. 開始 application traffic

完成標準：寫入流量 100% 進 Aurora、自管 primary 變 idle。Cutover 通常需要 30-60 分鐘 maintenance window。

Phase 4：Decommission 自管 MySQL

跑 1-2 週確認 Aurora 穩定後 慢慢退役自管：

• 自管 primary 保留作 cold backup（1-3 個月）、不接 traffic、可隨時 rollback
• Replica 一個一個關掉
• 監控 Aurora cost vs 預估、確認 break-even

完成標準：自管 EC2 instance terminate、EBS volume snapshot 後 delete、cost 對比驗證符合預期。

5 個 Production 踩雷

1. Parameter group 沒對齊 — innodb_flush_log_at_trx_commit 等行為差

Aurora 的 parameter group 取代 my.cnf。預設 parameter group 不一定跟自管 MySQL 一致：

• innodb_flush_log_at_trx_commit：自管常設 1（zero loss）、Aurora 預設仍 1 但走 Aurora storage durability（行為等價但不同 mechanism）
• sync_binlog：自管 1、Aurora 沒有 binlog 寫 disk 概念（Aurora 不用 binlog 做 replication、binlog 是 optional output）
• time_zone：Aurora 預設 UTC、自管常設 local time、TIMESTAMP query 行為可能不同
• character_set_*：自管常設 utf8mb4、Aurora 預設可能是 latin1（看 cluster create 命令）

修法：

• Phase 1 完成後 逐 row 對比 parameter group：

  1SELECT @@global.variable_name FROM ...

• 建 custom DB cluster parameter group、匹配自管設定

• 重啟 Aurora primary 套 parameter group 改變（部分 parameter 需要重啟）

2. IAM authentication — application 沒準備

Aurora 提供 IAM authentication（不用 password、用 AWS IAM role + temporary token）。Application 用 IAM auth 不必管 password rotation、但程式碼必須 call AWS SDK 取 token、放 connection 設定。

如果 Phase 2-3 期間沒 reverse engineer application connection logic、cutover 後 application 仍試用 password auth、Aurora 拒絕、production down。

修法：

• 評估是否啟用 IAM auth — 簡單情況保留 password、整合 AWS Secrets Manager 自動 rotation
• 啟用 IAM 必須 application code 改：
  • Java：com.amazonaws.services.rds.auth.RdsIamAuthTokenGenerator
  • Python：boto3.client('rds').generate_db_auth_token(...)
  • Go：aws-sdk-go-v2/feature/rds/auth
• Phase 2 期間 application 對 Aurora 用 IAM token、self-managed 仍 password — 雙 path code

3. Aurora-only feature 寫進 application、rollback 成本升高

Migration 過程開發發現 Aurora 有 Aurora-only feature（Backtrack、Performance Insights、Aurora Global Database）、誘惑使用。一旦 application 用了 Aurora-only feature、要 rollback 自管 MySQL 變不可能（feature 不存在、query 失敗）。

常見 Aurora-only feature：

• Backtrack：72 小時內 in-place rollback 整個 DB（不同於 PITR）
• Aurora ML：SQL function 內接 SageMaker / Comprehend
• Aurora Parallel Query：analytical query 跨 storage node 並行
• Aurora Auto Scaling：read replica 數量按 CPU 自動加減

修法：

• Phase 1-3 期間禁用 Aurora-only feature、保留 rollback option
• Phase 4 完成後 才開始 evaluate Aurora-only feature、加進來時 明確記錄不可 rollback decision
• 把 Aurora-only feature 跟 Aurora 特定 cluster 綁定，避免 application 邏輯依賴 Aurora-only

4. Read replica endpoint behavior — Application 不知道 reader endpoint round-robin

Aurora reader endpoint（prod-aurora.cluster-ro-xxx）是 DNS-based load balancer、每次 DNS query 給不同 replica IP。Application connection pool 連續開 10 個 connection、可能全部連同一個 replica（DNS cache）、不均勻。

修法：

• Application connection pool 強制 DNS re-resolve（避免長時間 cache）
• 或用 RDS Proxy（managed connection pool）放在前面、不直接連 reader endpoint
• 或用 Route 53 latency-based routing 配 Aurora reader endpoint per AZ、application 連最近 AZ

5. Region failover — Aurora Global Database vs 自管 chained replication

自管 cross-region replication 是 chained replication（primary → region2 replica → region2 cascading replica）。Aurora Global Database 是 storage-level replication（storage page 直接 ship，而非 binlog）、跨 region < 1 秒 lag、failover < 1 分鐘。

但 Aurora Global Database 是 active-passive（primary region 可寫、secondary region 只讀）。如果原本自管已經 cross-region active-active write（用 multi-master 或應用層 sharding）、Aurora Global Database 的寫入模型會成為限制。

修法：

• 評估 cross-region 是 DR 用途還是 active write 用途
• 純 DR + read scaling：Aurora Global Database 直接 cover
• Active-active write：要 Aurora DSQL（2024 新推出、跟 Aurora 不同 product）或 distributed SQL（CockroachDB / Spanner）

Capability gap：自管 MySQL 有但 Aurora 沒有

評估時必須確認 當前自管功能 沒用到 Aurora 不支援的能力。如果在用 MyRocks 等 storage engine、Aurora migration 不可行。

容量與成本對照

對 100 GB DB、5K WPS、20 個 application instance 的 deployment：

Pure infra cost Aurora 貴 30-50%、但 ops cost 降幅大過 infra increase — 200 人 eng team 養 1.5 FTE DBA 是 $300K-400K/yr、Aurora 換成 0.3 FTE 是 $60K-100K/yr、差距 $200K+ 抵 infra increase。

小團隊 / 小 deployment Aurora 不一定划算 — 50 人 eng team 沒有 dedicated DBA、自管 MySQL 也只佔某人 20% 時間、Aurora migration 的 ops saving 不存在。

Production case：Netflix Aurora consolidation

MySQL → Aurora migration 的 production 責任是把自管 database operation 轉移成 managed SQL 的契約，而非只搬 schema 與資料。9.C23 Netflix Aurora consolidation 提供的工程訊號是多套 RDBMS 整併到 Aurora 後，效能、成本與操作責任一起改變。

這個案例要回收到三個操作判準。第一，migration driver 應寫成 operation transfer，例如 backup、failover、storage growth、patching 與 observability 由誰承擔。第二，效能與成本要一起看，因為 Aurora 的 storage / compute / I/O 計費會把原本藏在 DBA 操作裡的成本攤開。第三，整併多套 RDBMS 時要先做 feature inventory，確認 plugin、storage engine、charset、replication topology 與 SQL mode 都能落到 Aurora MySQL 支援範圍。

Netflix case 的 sibling 路由是 Aurora vendor page 與 PostgreSQL → Aurora。若 migration 目標從 managed SQL 變成 multi-region active-active write，應改接 1.11 全球分散式 OLTP。

何時維持原路線

• Cross-cloud portability 是 requirement：Aurora AWS-only、要 cross-cloud 用 PlanetScale 或 自管
• 用 Percona Server fork / MyRocks 等非標準 engine：Aurora 不支援
• 需要 OS-level customization：Aurora 完全 managed、無 SSH
• 規模太小：< 100 GB / < 1K WPS、自管 MySQL EC2 spot instance 已經夠便宜
• 規模太大：> 50 TB single DB / > 100K WPS、Aurora single-instance 仍是 ceiling、考慮 Vitess 或 Aurora DSQL

相關連結

• 平行 batch：→ PlanetScale migration playbook（同 MySQL backlog、不同 target paradigm）
• 上游：MySQL vendor overview / Aurora vendor page
• 跨章節：9.6 容量規劃模型 — Aurora cost forecast
• 既有 case：9.C23 Netflix Aurora consolidation — Netflix 從多套 RDBMS 統一到 Aurora 的 migration evidence
• 方法論：Migration Playbook Methodology（Type C operational hybrid 結構說明）
• 官方：Aurora MySQL Migration Guide

本文是跨 vendor migration playbook、cross-link 到 Vitess sharding 跟 PlanetScale。走 Migration playbook methodology Type C operational hybrid 結構。

這條 migration 跟 → Aurora MySQL 相似（self-managed → managed），但 target 是 Vitess-native managed、保留 sharding 能力。同時加上 → PlanetScale from self-managed MySQL 的 branch workflow paradigm。

對 已花心力建 Vitess team 但 ops cost 太大 的 org 來說、這條 migration 比 Vitess → distributed SQL 風險低、保留 sharding investment。

為什麼是 Type C（不是 Type A 或 Type E）

跑 6 維 diff dimension audit：

Operational = High（其他 Low / Medium） → Type C operational hybrid。Branch workflow 是 Medium paradigm shift 但不是 dominant — 主要工作量在 operational ownership 轉移。

跟 自管 MySQL → PlanetScale（Type E paradigm shift）對比：那條 path 是 no-Vitess → Vitess + branch、要學 Vitess 概念 + branch；本條是 已有 Vitess + 加 branch、只學 branch、複雜度低很多。

Driver：Ops headcount + Branch workflow + Vitess feature 加速

從自管 Vitess 遷 PlanetScale 的核心 driver：

Ops headcount 削減：

• 自管 Vitess 通常需要 2-5 個 SRE/DBA 撐 production —VTGate / VTTablet / VReplication / VSchema 各有議題
• PlanetScale 把這層全部 outsource、團隊 ops headcount 可降到 < 1 FTE
• 對 50-200 人 eng team、ops cost saving 是顯著 driver

Branch workflow paradigm：

• 自管 Vitess 仍用 gh-ost / pt-osc 或 Vitess online DDL 跑 schema migration、是 DBA 主導
• PlanetScale branch workflow 把 schema migration 變 developer self-service、開 branch / Deploy Request / merge、跟 git workflow 同節奏
• 對 high-velocity engineering culture 是文化升級

Vitess upstream feature：

• PlanetScale team 是 Vitess 的主要 contributor、新 feature 通常 PlanetScale 先 ship
• 自管 Vitess 升級慢、PlanetScale 用戶看到新 feature 早 3-6 個月

不適合 跨雲 portability priority high 或 strict on-prem deployment 的 org — PlanetScale 是 cloud-only。

4-phase migration

Phase 1：Topology + VSchema audit

把當前自管 Vitess cluster 完整盤點：

 1# Vitess cluster topology
 2vtctldclient GetKeyspaces
 3vtctldclient GetShards <keyspace>
 4vtctldclient GetTablets
 5
 6# VSchema
 7vtctldclient GetVSchema <keyspace>
 8
 9# 跨 keyspace VReplication workflow
10vtctldclient GetWorkflows

對每個 keyspace 檢查：

• Shard 數量：PlanetScale plan 對 shard 數量有 limit（Enterprise 才能超大規模）
• VSchema features：自管可能用 PlanetScale 不支援的 Vindex（custom Vindex）
• Foreign key：Vitess 18+（2023 末）才支援 FK、自管 Vitess 大多 < 18、cluster 內已 application-enforced；遷 PlanetScale 後可選擇啟用 native FK（同 shard 內）或繼續 application enforcement
• Stored procedure / trigger：PlanetScale 受限、確認是否 application 依賴

完成標準：寫 blocker list（PlanetScale 不支援的功能）+ compatibility list（功能對應）。

Phase 2：Dual cluster + binlog stream

PlanetScale 內建 Vitess Connector、從外部 MySQL（包括其他 Vitess cluster）binlog stream import：

1# 1. 用 PlanetScale CLI 建 cluster
2pscale database create production --region us-east
3
4# 2. Import schema（從自管 Vitess export）
5pscale shell production main < schema.sql
6
7# 3. 設 Vitess Connector 從自管 cluster import 資料
8# （透過 PlanetScale Console）

Vitess Connector 從自管 VTTablet 的 MySQL primary 讀 binlog、寫進 PlanetScale。Lag 通常 < 1 秒。

跑 1-2 週、確認：

• Schema 完整 migrate
• VSchema 對應正確（Vindex 行為一致）
• Lag 穩定

Phase 3：Application read 切 PlanetScale

跟 Aurora migration Phase 2 同概念。Application read query 切 PlanetScale endpoint：

• 連 PlanetScale connection string（xxx.connect.psdb.cloud）
• 仍寫自管 Vitess、Vitess Connector 同步 PlanetScale

跑 2-4 週、驗證：

• Query result 一致
• PlanetScale read latency 接近自管（PlanetScale Boost cache 可能加速）
• PlanetScale row read 計費跟預估一致

Phase 4：Write cutover + 自管 Vitess 退役

 1# 1. PlanetScale 把 cluster promote 為 primary（透過 Console）
 2# 透過 PlanetScale Console 啟用 production write 或用 `pscale` CLI 對應 promotion 命令
 3# （CLI 命令名稱隨 pscale 版本變動、以 pscale --help 為準）
 4
 5# 2. Application 寫 connection string 切 PlanetScale
 6# 自管 Vitess → PlanetScale
 7
 8# 3. Vitess Connector 反向（PlanetScale → 自管）作為 rollback buffer
 9
10# 4. 跑 1-2 週確認、開始 decommission 自管 Vitess

Decommission 自管 Vitess 是大工程：

• VTGate / VTTablet pods 一個個關
• VReplication workflow 停掉
• MySQL backend 保留作 cold backup 1-3 月、然後 EBS snapshot + terminate

完成標準：所有 traffic 在 PlanetScale、自管 Vitess 資源全 release、ops headcount confirm 下降。

5 個 Production 踩雷

1. VSchema 不完全兼容 — Custom Vindex 必須改

自管 Vitess 可能用了 custom Vindex（自寫 Go plugin）、PlanetScale 不支援 custom Vindex（只支援 built-in：hash / lookup_hash / unicode 等）。

修法：

• Phase 1 audit 出所有 custom Vindex
• 對每個 custom Vindex 評估能否用 built-in 替代
• 不能替代的、考慮 application 層 logic 取代 Vindex（application 自己算 shard key）
• 或 暫不遷該 keyspace、保留自管 Vitess 跑 custom Vindex keyspace、其他遷 PlanetScale

2. Branch workflow 訓練不到位 — DBA 仍用「Vitess online DDL」心智模型

自管 Vitess team 習慣 vtctldclient ApplySchema --strategy=vitess 跑 online DDL、遷 PlanetScale 後仍想直接這樣 — 但 PlanetScale production branch 禁止 schema change、必須走 Deploy Request。

修法：

• Phase 3 訓練步驟：team 每個 DBA / SRE 都跑過完整 branch + Deploy Request workflow
• 寫 team runbook：production schema change must 走 branch
• 緊急 schema change（事故中）也走 branch、PlanetScale 可加速 Deploy

3. SUPER privilege 移除 — 自管 admin tool 失效

自管 Vitess 用 SUPER privilege 跑 admin script、PlanetScale 沒給 SUPER。常見失效：

• 自寫 monitor script 跑 SHOW SLAVE STATUS、PlanetScale 抽象掉
• 自寫 backup script 跑 FLUSH TABLES WITH READ LOCK、PlanetScale 不允許
• 自寫 cleanup script 跑 KILL QUERY、PlanetScale 受限

修法：

• Phase 1 audit 所有 admin script
• 改用 PlanetScale Console / CLI / API 等價操作
• PlanetScale 提供的 monitoring 介面替代自管監控

4. Connection limit — PlanetScale plan 比預期緊

PlanetScale Scaler Plan: 10K connection、Enterprise: 100K。自管 Vitess VTGate 通常設 50K-200K connection、遷 PlanetScale 後 hit limit。

修法：

• Phase 1 connection forecast：peak hour 多少 active connection
• 升 PlanetScale plan（Scaler Pro / Enterprise）
• 或在 application 端加 connection pool（HikariCP / pgBouncer 等價）降低 connection count

5. Cost model 翻盤 — Per-row read 計費超預期

PlanetScale 計費是 per row read / written。自管 Vitess cost = EC2 + EBS（線性 with infrastructure scale）。遷 PlanetScale 後計費跟 application access pattern 直接相關。

常見 surprise：

• Heavy analytics query（COUNT *、aggregation）讀大量 row、計費高
• N+1 query pattern（application 跑很多小 SELECT）讀很多 row、計費高
• Read-heavy workload 沒 Boost cache、每次 query 都 hit billing

修法：

• Phase 1 cost forecast：用 pscale analytics 預估 row read / write 量、估算月帳
• Phase 2 期間實際對 PlanetScale 跑 traffic、看實際 billing
• Heavy analytics 改 材料化 view / async aggregation、不是每次 query
• 高 read frequency 開 Boost cache（額外 cost、但比 row read 便宜）

Capability mapping

容量與成本對照

對 200 人 eng team 用自管 Vitess（10 shard、20 TB 資料、50K WPS）：

對中型規模、PlanetScale 通常 break-even 或更便宜。對極大規模（> 200K WPS / > 100 TB）PlanetScale Enterprise 需要 commit pricing、不一定划算。

何時不要遷

• 跨雲 / on-prem 是 requirement：PlanetScale cloud-only
• Custom Vindex / 特殊 plugin 大量使用：兼容度低、改造工作量大
• 規模極大 > 500K WPS / > 200 TB：PlanetScale plan 對應 Enterprise commit、議價辛苦
• 強合規 / 資料主權限制：金融 / 政府 / 醫療場景、PlanetScale 不一定能 cover compliance
• 既有 Vitess team 強 + ops cost 低：如果 ops 已經精實、不必為 outsource 而 outsource

跟其他模組整合

跟 Vitess sharding

本 migration 保留 Vitess sharding 概念、application code 視角幾乎不變。Phase 1 audit 是 Vitess concept 對應 PlanetScale concept、不是 拆 Vitess 換 distributed SQL。

跟 → PlanetScale (from self-managed MySQL)

本 migration 是 Vitess → PlanetScale、前者是 MySQL → PlanetScale。差異：

• MySQL → PlanetScale (Type E)：要學 Vitess 概念 + branch workflow + FK 處理
• Vitess → PlanetScale (Type C)：只學 branch workflow + ops outsource、保留所有 Vitess investment

選哪條 path 取決於起點。

跟 Major Version Upgrade

從自管 Vitess 上 MySQL 5.7 遷 PlanetScale 也是 同時跨 major version（PlanetScale 跑 8.0+ Vitess）。Application 必須同時處理 5.7 → 8.0 paradigm shift（charset / auth）。

相關連結

• MySQL vendor overview
• Vitess Sharding（self-managed source）
• → PlanetScale from self-managed MySQL（不同起點）
• → Aurora MySQL（另一條 self-managed → managed path）
• Major Version Upgrade（5.7 → 8.0 同期考量）
• 方法論：Migration Playbook Methodology（Type C operational hybrid）
• 官方：PlanetScale Migration Guide / Vitess Operator

從 Pyroscope 遷出 Datadog Continuous Profiler 的本質是 operational ownership 從 self-host 轉手到 SaaS — pprof data model 跟 flame graph 視覺幾乎一樣、profile diff workflow 接近、差異 90% 在 ops 跟 ecosystem integration。schema / paradigm 差距小、operational 差距大、就是 Type C operational hybrid 的 signature。

為什麼是 Type C（operational 為主）

跑 6 維 diff dimension audit：

Operational = High（其他 Low） → Type C operational hybrid。Type C 結構是 operational audit prefix + 4-phase drop-in cutover — operational diff 集中在 ingest / cost / retention 三階段、其他階段是 schema-level drop-in。

Driver：TCO + Datadog ecosystem 內 deep linking

從 Pyroscope 遷出 Datadog Profiler 的核心 driver 有兩條：

TCO（total cost of ownership）：self-host Pyroscope 看起來免費（Apache 2.0）、但實際 ops 成本：

• Storage：profile sample 大、retention 與 storage cost 需要自己估（每 service 每天可能 1-10 GB）
• Scaling：profile ingestion 突增（deploy event / canary rollout 期間）要 storage / ingester 撐住
• On-call：Pyroscope server 自己會壞、要 on-call 帶
• Ops engineer time：規模成長後可能需要 0.5-1 個 FTE 維護 Grafana stack 內的 Pyroscope

對 已經有 Datadog APM 帳單 的 org、profiling 會跟 APM / profiled host 進同一個商務談判與 usage report，不需要額外 ops headcount。這條 TCO 拉力對 50-500 人 eng 規模最強 — 小於 50 人 self-host 也撐得住、大於 500 人 self-host 的 economy of scale 可能開始 favored Pyroscope。

Ecosystem deep linking：Datadog Profiler 跟 trace / log / metrics 在同一個介面、profile span 直接連到 trace span、deploy marker 直接顯示在 flame graph timeline、cross-signal query 不用 wire。Pyroscope 要透過 Grafana datasource correlation 達到類似效果、但需要 Tempo / Loki 已部署 + 手動配 correlation rule、整合精度跟自動程度都不如 Datadog 內建。

這條 driver 對 已是 Datadog-heavy org 強、對 Grafana-heavy org 弱（後者 Pyroscope 才是自然選擇、Datadog Profiler 反而 ecosystem misfit）。

Type C migration（4-phase）

Phase 1：Operational audit

確認 Datadog Continuous Profiler 能 cover Pyroscope 當前用途、且 ops ownership 轉移可接受：

• Language coverage：當前 Pyroscope 用哪些 SDK？Datadog Profiler 支援 Go / Java / Python / Node / Ruby / .NET / PHP / Rust / C / C++，但每個語言的 profiler type 與啟用方式不同；Erlang 等較小眾語言仍要逐項驗證
• Profile type coverage：Pyroscope 抓的 profile type（CPU / heap / allocation / goroutine / lock / wall time）在 Datadog Profiler 同語言是否都支援？Java 跟 Go 兩家都全、其他語言可能 partial
• Retention requirement：Pyroscope retention 可自管；Datadog Profiler retention 依產品資料保留政策與合約設定，要確認是否滿足既有 long-term baseline / audit 查詢需求
• 資料主權：profile data 包含 application function name / line number、有時帶 customer data hint（function 名字暗示 customer-specific 邏輯）— 是否能 send to SaaS？
• Cost forecast：Datadog public pricing 以 profiled host / APM tier 計費，估算時要用實際 host 數、container density、APM plan 與 commit discount 跟 Pyroscope self-host TCO 比

完成標準：寫出「Datadog 能 cover、不能 cover、不確定」三欄、不確定欄全部問過 Datadog SE / 用 trial 跑過 production-like load。

Phase 2：Agent parallel run（profile 雙寫）

Datadog Agent 多半已部署（如果在用 Datadog APM）。Phase 2 在現有 Datadog Agent 開 profiling flag、不關 Pyroscope agent、跑 2-4 週 parallel：

• 設定 DD_PROFILING_ENABLED=true（per service env var）
• 每個 service SDK init 加對應 profiling enable call（Go: profiler.Start()、Python: import ddtrace.profiling.auto、Java: agent flag 即可）
• Pyroscope SDK / Alloy 繼續跑、profile 雙寫到兩家
• 對比同一個 service / 同一個時間段在 Pyroscope flame graph 跟 Datadog Profiler flame graph、確認 hot path 一致

Parallel run 期間的 overhead：兩邊 agent 同時跑 profiling、CPU overhead 大致 2-4%（單一 profiler 通常 1-2%、雙寫 double）、production-acceptable but not free。Phase 2 不要超過 4 週、避免長期 double overhead。

完成標準：每個 production service 在 Datadog Profiler 都有 4 週連續 profile data、跟 Pyroscope flame graph 對比一致。

Phase 3：Tag schema reconcile + trace correlation

Pyroscope tag schema（自己設計）跟 Datadog standard tag（service / env / version / host）對齊：

• Pyroscope tag app=checkout-api → Datadog service:checkout-api
• Pyroscope tag env=prod-us → Datadog env:prod + region:us-east-1
• Pyroscope tag git_sha=abc123 → Datadog version:abc123（透過 DD_VERSION）
• Custom tag（team / business unit）→ Datadog custom tag（透過 SDK config 或 agent label）

Trace correlation：Datadog Profiler 自動跟 APM trace 關聯（透過 trace_id injection into profile sample）— Phase 3 要驗證這個 correlation 可用（在 Datadog APM 點 trace span、應該能跳到對應時段 profile）。

Deploy marker：CI 在 deploy 時打 Datadog deployment marker（datadog-ci deployment mark 或 API call）、讓 Profiler diff view 知道 baseline / candidate 邊界。

完成標準：tag schema 1:1 對應、trace → profile deep link 可用、deploy marker 自動推送。

Phase 4：Pyroscope agent 關掉 + server 退役

逐步關 Pyroscope agent（per service rollout）：

• 先關低重要性 service（dev / staging / non-critical prod）
• 觀察 1-2 週、確認沒事故再關下一批
• 最後關 critical service、留 Pyroscope server 跑 1-2 週空 ingest（rollback 緩衝）
• 取消 Pyroscope server（decommission storage、release K8s resource、關 on-call rotation）

Pyroscope 歷史 profile data 保留策略：

• 多數場景：直接 archive S3 / GCS、未來查得到但不維護 query UI
• 強合規場景：export Pyroscope flame graph data 為 pprof file 保存（pprof 是長期可讀格式）

完成標準：所有 production service 只走 Datadog Profiler、Pyroscope server 取消、TCO 對比驗證符合預期。

5 個 production 踩雷

1. 兩家 agent 同時跑造成 production overhead

Phase 2 parallel run 期間 CPU overhead 2-4%、預期內。但有些 service 設定錯誤（例如 sampling rate 預設都拉高）變成 6-10% overhead、p99 飄升、誤判為 Datadog Profiler 自己的問題。修法是 parallel run 期間 Pyroscope sampling rate 降低 50%（已經有歷史 baseline、不需要全採）、且 Phase 2 不要在 peak event 期間跑。

2. Tag schema 不一致導致 historic baseline 對不上

Pyroscope tag app=checkout-api 跟 Datadog service:checkout-api 都指同一個 service、但 Datadog 內 historic profile 沒有 app tag、所以從 Pyroscope 視角看 baseline 跟 Datadog 視角看 baseline 是不同的時段切片。Release regression 比較時用錯 baseline、會誤判 release 沒問題（實際 baseline 不對應）。修法是 Phase 3 明確記錄 Datadog Profiler 的 baseline 起算時間是 Phase 2 開始日、Pyroscope 歷史不直接搬入比較。

3. Trace_id correlation 斷（Phase 3 最常見）

Datadog Profiler 自動關聯 trace 的前提是 同一個 Datadog Agent + APM SDK 注入 trace_id。如果 service 用 OpenTelemetry SDK + Datadog Agent（OTel-first 配置）、trace_id 注入方式不同、profile 跟 trace 可能無法自動 correlate。修法是 確認所有 service 用 Datadog SDK 或正確配 OTel-to-Datadog converter、在 Datadog APM 介面 random 抽 10 個 trace 驗證 profile correlation 是否 wire 通。

4. Cost 突增（Phase 4 後常見）

關掉 Pyroscope agent 後、Datadog Profiler 變成 sole profile source、ingest volume 上升、Datadog bill 比預估高 30-50%。原因通常是：

• Profile sampling rate 不小心開太高（部分 service config 沒對齊）
• Custom tag 太多（每個 unique tag combination 增加 indexing cost）
• Profile event 量比預估高（service count × sampling rate × profile types）

修法是 Phase 1 cost forecast 要保留 30% buffer、且 Phase 4 完成後立即跑 Datadog usage report 確認 actual 跟 forecast 對比。

5. Retention / baseline 政策變動造成歷史 query 斷層

Pyroscope 自管 retention 可以設成配合內部 storage 與 compliance policy；Datadog Profiler 的 retention 依產品資料保留政策與合約設定。真正的風險不是固定「7 天 vs 90 天」，而是 既有 baseline 查詢習慣是否還成立：原 Pyroscope user 可能習慣查特定 release 前後的 flame graph、Datadog 端則要看 profile tag、deployment marker 與保留政策能否支援同樣查詢。修法是 Phase 1 明確列出「要查多久前、用什麼 tag 找、誰有權限看」三個問題，超出 profile retention 的長期 trend 改用 Datadog metrics-derived signal（cumulative CPU% / memory growth rate）或保留 Pyroscope archive。

Capability 對照

何時不要切（保留 Pyroscope）

• 資料主權 / compliance 不允許 profile data 出境：金融 / 醫療 / 政府 / 國防、保留 Pyroscope self-host
• 內網 / air-gap 部署：物理上連不到 Datadog SaaS、保留 Pyroscope
• OSS-first / vendor neutrality policy：org 政策不允許 vendor lock-in profiling、保留 Pyroscope
• 規模超大（> 500 APM host）：Datadog Profiler add-on cost × host 數可能超過 Pyroscope self-host TCO、計算交叉點
• Long retention / 自訂 archive 強需求：若 profile data 必須照內部 retention policy 長期保存、保留 Pyroscope 或建立 export / archive 流程
• Datadog 不支援的語言或 profiler type：Erlang、特定 runtime 或特定 profile type 若 Datadog 無法覆蓋，保留 Pyroscope 為對應 service profiling

下一步路由

• 平行 batch：JMeter → k6（Type E paradigm shift）
• 同 batch Type C：（待補、本篇是 batch 唯一 Type C）
• 上游：9.8 Performance Observability / 4.9 Continuous Profiling
• 下游：9.9 Performance Improvement Loop（profile diff 接入 release regression workflow）
• vendor 對照：Pyroscope / Datadog Continuous Profiler / Parca
• 方法論：Migration Playbook Methodology（Type C operational hybrid 結構說明）