本文是 AWS ElastiCache overview 的 implementation-layer deep article。選型層（為何用 managed、engine 選擇、跟自管取捨）見 overview；本文只處理「決定用 ElastiCache 後，哪些是 AWS 的責任、哪些仍是你的」。CLI 與計費以 AWS ElastiCache 官方文件、ElastiCache 定價 為準、最後檢查日 2026-06-16（managed 服務的引數與價格會變、以官方為準）。

managed 不等於 hands-off

把 cache 換成 ElastiCache 之後，最危險的心態是「現在 AWS 全包了」。AWS 確實接走了一大塊運維——它幫你做 failover、patching、snapshot、跨 AZ 複製，你不用再自己部署 Sentinel、不用半夜起來手動切 master。但有一類問題 ElastiCache 一個都沒幫你解，而且因為「以為 AWS 會處理」，這些問題在 managed 環境反而更容易被忽略到上線才爆。

Tinder 的配對引擎跑在 ElastiCache for Valkey 上、4700 萬月活、sub-millisecond 延遲——這證明 managed 撐得起極大規模，但 Tinder 仍要自己設計 key、處理 cache miss、控制 client 行為。ElastiCache for Redis 7.1 在 r7g.4xlarge 上單 node 可達約 100 萬 RPS、單 cluster 約 5 億 RPS（引自 AWS Database Blog）——這個吞吐是 AWS 給的，但用不用得好取決於你的 key 分布與 client 設計。

理解 ElastiCache 就是劃清這條責任邊界。本文按 shared responsibility 展開：AWS 管什麼、你管什麼、邊界上的踩坑在哪。

核心概念：shared responsibility 的兩側

ElastiCache 的責任劃分可以列成一張清楚的表，這張表是判讀所有 ElastiCache 事故的起點：

左欄是用 managed 換到的，右欄是用 managed 換不掉的。2.C9 cache stampede 的雪崩、連線風暴、eviction 選錯 在 ElastiCache 上跟自管 Redis 一模一樣會發生——因為這些是 cache 使用方式的問題，不是運維的問題。

engine 選擇與 cluster mode

ElastiCache 的兩個結構性決策：

engine：2024 起 default 是 Valkey（成本約低 20%、OSI 開源、Redis 7.2.4 fork、API 相容）；Redis OSS 仍可選但 AWS 不推；Memcached 是另一條線（純 KV、無 cluster mode 概念）。新部署或既有 Redis 遷移都走 Valkey（相容、便宜），純 cache 才考慮 Memcached。

cluster mode：disabled 是 1 primary + 最多 5 replica、單 shard、上限約 340GB；enabled 是多 shard（最多 500）、自動 sharding、橫向擴展。判讀：dataset < 300GB 且不需 sharding 用 disabled（簡單），> 300GB 或要橫向擴展用 enabled（但 client 要 cluster-aware）。

配置：建立與治理的設定路徑

 1# 建立 Valkey replication group（Multi-AZ、auto failover、cluster mode disabled）
 2aws elasticache create-replication-group \
 3  --replication-group-id prod-cache \
 4  --replication-group-description "prod cache" \
 5  --engine valkey \
 6  --cache-node-type cache.r7g.large \
 7  --num-cache-clusters 3 \           # 1 primary + 2 replica
 8  --automatic-failover-enabled \
 9  --multi-az-enabled \
10  --snapshot-retention-limit 7 \     # 自動 snapshot 保留 7 天
11  --at-rest-encryption-enabled \
12  --transit-encryption-enabled
13
14# 自訂 parameter group（maxmemory-policy 等仍是你的責任）
15aws elasticache create-cache-parameter-group \
16  --cache-parameter-group-name prod-params \
17  --cache-parameter-group-family valkey8 \
18  --description "prod cache params"
19aws elasticache modify-cache-parameter-group \
20  --cache-parameter-group-name prod-params \
21  --parameter-name-values "ParameterName=maxmemory-policy,ParameterValue=allkeys-lru"

配置判讀：

• --automatic-failover-enabled + --multi-az-enabled 是 HA 的核心，把 Sentinel 那條 failover 時序鏈託管掉
• maxmemory-policy 透過 parameter group 設定——AWS 給旋鈕、選哪個是你的責任（見 eviction 調校）
• --transit-encryption-enabled 加 TLS，但 TLS 增加 client 建連成本，連線池更重要
• IAM authentication（Redis 7+）取代 AUTH password，對應 security 模組

Production 故障演練

Case 1：failover 期間 client 持續 error

徵兆：ElastiCache 觸發 failover（看 describe-events），AWS 端 replica 晉升完成，但 application 持續 30 秒到幾分鐘大量連線 error。

根因：failover 時 primary endpoint 的 DNS 切到新 primary，但 client 的連線池還握著舊 primary 的連線、DNS 也可能有快取。AWS 完成了 failover，但 client 重連是你的責任——ElastiCache 不會幫你的 application 重連。

修法：

1. client 用支援自動重連的 library，設合理的 socket timeout 與 retry（見 連線調校）
2. 連到 primary endpoint（會跟著 failover 更新 DNS），不要連到特定 node 的 endpoint
3. 縮短 client 的 DNS 快取 TTL，讓 failover 後的 DNS 切換更快被看到
4. failover 期間的寫入中斷無法完全避免（非同步複製 + 重連時間），latency-sensitive 服務要設計降級

Case 2：跨 AZ replication lag 造成 stale read

徵兆：寫入 primary 後立刻從 replica 讀，偶爾讀到舊值；CloudWatch 的 ReplicationLag 在高寫入時段上升。

根因：ElastiCache 的跨 AZ 複製是非同步的，replica 有 lag。AWS 保證複製會發生，但不保證即時——read-from-replica 在寫後立即讀的場景會看到 stale window。這跟自管 Redis 的 replica 行為一致，managed 沒有消除它。

修法：

1. 寫後需要立即一致讀的路徑，強制 read from primary
2. 監控 CloudWatch ReplicationLag，持續高代表寫入超過複製能力，要 scale up node 或降寫入
3. 接受 cache 的最終一致性——這是 cache copy 的本質，不是 bug（見 cache copy boundary）
4. 需要強一致 + durability 走 MemoryDB（見本文 Capacity / cost 邊界段）

Case 3：Serverless 計費超出預期

徵兆：用了 ElastiCache Serverless 想省容量規劃，月底帳單遠超預期。

根因：Serverless 按 ECPU（運算）+ storage 計費，流量尖峰或低效的 access pattern（大量小命令、大 value）會推高 ECPU 消耗。Serverless 解的是「不想規劃容量」，不是「一定更便宜」——可預測的穩態流量用 node-based + Reserved Instance 通常更省。

修法：

1. 流量可預測、穩態高的 workload 用 node-based + Reserved Instance（1/3 年承諾、折扣約 30-60%）
2. 流量不可預測、有大量閒置時段的才適合 Serverless
3. 監控 ECPU 消耗，找出推高成本的 access pattern（用 pipeline 合併小命令降 ECPU）
4. 成本模型對比要算實際 workload，不要假設 Serverless 一定划算

Case 4：cluster mode enabled 但 client 不是 cluster-aware

徵兆：建了 cluster mode enabled 的 cluster，application 連線報 MOVED redirect 或連不上某些 key。

根因：cluster mode enabled 把 keyspace 分到多 shard，client 必須 cluster-aware（懂 CLUSTER SLOTS、處理 MOVED/ASK redirect）才能正確路由。普通 standalone client 連 cluster mode enabled 會失敗。

修法：

1. cluster mode enabled 一律用 cluster-aware client（連 configuration endpoint 不是單一 node）
2. 確認 application 的多 key 操作用 hash tag 把相關 key co-locate 同 slot（見 cluster re-sharding）
3. dataset < 300GB 且不需 sharding，用 cluster mode disabled 省掉這層複雜度
4. 從 disabled 升 enabled 是有成本的架構變更，初期規劃就要決定

Case 5：snapshot 期間記憶體尖峰、node 不穩

徵兆：自動 snapshot 時段 node 延遲上升、DatabaseMemoryUsagePercentage 衝高，偶爾 snapshot 失敗。

根因：Redis engine 的 snapshot 靠 fork（見 persistence / fork latency），fork 期間 copy-on-write 推高記憶體。如果 node 記憶體已吃緊，snapshot 的 fork 把它推爆。AWS 託管了 snapshot 排程，但 fork 的記憶體成本仍在 engine 層存在。

修法：

1. node 記憶體留 headroom（不要長期 > 80%），給 snapshot 的 fork copy-on-write 空間
2. snapshot window 設在低流量時段，減少 fork 期間被改的 page
3. 監控 CloudWatch DatabaseMemoryUsagePercentage，> 80% 考慮 scale up node type
4. Valkey engine 繼承 Redis 的 fork 模型，這個成本換 engine 到 Valkey 也還在（fork-less 要 DragonflyDB、但 ElastiCache 不提供）

Capacity / cost 邊界

ElastiCache 的容量判讀，混合了 AWS 的 metric 與 engine 層的行為：

撞牆後的路由判斷：

• 需要 source-of-truth 的 Redis API（不是 cache）：ElastiCache 是 cache 語意（資料可重建）。需要 durability 走 AWS MemoryDB——Redis-compatible 但有 multi-AZ transaction log、提供 source-of-truth 語意，成本約 ElastiCache 的 2-3 倍。判讀：Tubi 把 feature store 從 ScyllaDB 遷到 ElastiCache 的前提是「feature 可重新計算」——可重建選 ElastiCache，不可重建選 MemoryDB 或 database。
• 跨雲 / 不在 AWS 生態：ElastiCache 綁 AWS，跨雲走自管 Redis / Valkey 或 GCP Memorystore / Azure Cache。
• 極端單機 throughput：要榨單機多核走自管 DragonflyDB（ElastiCache 不提供 Dragonfly engine）。
• 跨 region active-passive DR：ElastiCache 的 Global Datastore（1 primary region + 多 secondary read replica、跨 region lag < 1 秒），不支援 active-active multi-master。

整合 / 下一步

ElastiCache 的 deep article 本質是「劃清 managed 邊界」，它跟 engine 層的調校知識緊密相連：

• 跟 Redis 全系列 deep article：eviction、persistence/fork、連線的調校在 ElastiCache 上仍適用（engine 是 Redis/Valkey），AWS 託管的是 failover/patching/snapshot 排程，不是這些 engine 行為。
• 跟 Valkey 相容性：ElastiCache 的 default engine 就是 Valkey，相容性與 io-threads 的判讀直接適用。
• 跟 Netflix EVCache：EVCache 是 Netflix 自管的 Memcached-based 全域 cache，對照 ElastiCache for Memcached + Global Datastore——展示了自管跨區 vs managed 跨區的取捨。
• 跟 Tinder / Tubi：兩個 ElastiCache 規模化案例，一個是 sub-ms 配對引擎、一個是 ML feature store p99<10ms，都展示了「AWS 給吞吐、你給設計」的邊界。

相關連結

• 上游 vendor 頁：AWS ElastiCache
• engine 層 deep article：Redis 記憶體與淘汰、persistence 與 fork latency、Sentinel 與 failover 時序、Valkey 相容性
• 上游能力：0.6 成本取捨、cache copy boundary
• Methodology：Vendor 深度技術文章寫作方法論

本文是跨 vendor migration playbook、cross-link 到 MongoDB 跟 MongoDB Atlas。本文是 Migration playbook methodology Type C operational redesign hybrid 的標準形態實證。每階段切換用 migration gate 把關 — 4 phase 之間的驗證條件就是 gate。

Atlas 不是 MongoDB + managed、是另一個 product

「MongoDB Atlas 是 MongoDB 的 managed 版本」這個 framing 看似合理、實際誤導：

• Protocol 相容：MongoDB wire protocol 一致、driver 不改、mongosh 連線跟 self-managed 一樣
• Storage 一致：WiredTiger storage engine 一樣、document model 一樣
• API 一致：Aggregation framework、indexing、change stream 都一樣

但 operational surface 完全不同：

Migration 主要工作不在 資料層 — protocol drop-in 已 cover；是 operational stack 全換：SRE runbook、monitoring dashboard、access control、IAM 整合、cost 預估全要重做。「Atlas 是 managed MongoDB」這個 framing 低估了 operational 工作量。

跑 diff dimension audit：

主導維度 Operational = High、Schema / Paradigm 都 Low — 對映 Type C operational redesign hybrid。

結構：4-phase operational + drop-in cutover

跟 PostgreSQL → Aurora 結構對齊（同 Type C）：

 1Phase 0：Pre-migration audit（1-2 週）
 2  - Workload sizing（IOPS / connection / storage）
 3  - Application connection pattern audit
 4  - Compliance requirement audit
 5
 6Phase 1：Operational infrastructure 準備（2-3 週）
 7  - Atlas cluster 建立
 8  - VPC peering / private endpoint
 9  - IAM role + Atlas Database User
10  - Monitoring + alert
11  - Backup retention 設定
12
13Phase 2：Data migration（取決於 dataset 大小）
14  - mongomirror / Atlas Live Migration tool
15  - 或 mongodump → mongorestore（小 DB）
16
17Phase 3：Cutover 跟 verification
18
19Phase 4：Cleanup（self-managed decommission）

整體 4-12 週、依 dataset 大小跟 organization 流程複雜度。

Phase 0：Pre-migration audit

Workload sizing → Atlas tier

 1Self-managed observations:
 2- Peak IOPS: 8000
 3- P99 read latency: 5ms
 4- Connection count peak: 1500
 5- Storage: 800GB
 6- Cross-region replication needed: yes
 7
 8Atlas tier mapping:
 9- M40 (8 vCPU, 16GB RAM): IOPS 3000、不夠
10- M60 (16 vCPU, 64GB RAM): IOPS 6000、邊界
11- M80 (32 vCPU, 128GB RAM): IOPS 9000、安全（選此）
12- Storage: 1TB tier（足夠 800GB + 25% buffer）
13- Cross-region replication add-on

Atlas 不是 自由 instance class、是 固定 tier；workload 跨 tier 邊界時要選 上一級 而不是 push 下一級。

Connection pattern audit

1// Application connection pool config
2const client = new MongoClient(uri, {
3  maxPoolSize: 100,     // ← Atlas 端 tier-specific connection limit
4  minPoolSize: 10,
5  maxIdleTimeMS: 60000,
6});

Atlas tier 對 single user connection 有限制（M40 ~1500、M80 ~3000）；多 application instance 跑同帳號連 Atlas 可能撞 limit。預先計算 total connection = pod_count × maxPoolSize、對照 tier limit。

Compliance audit

• Data residency：Atlas 部署 region 是否符合 GDPR / 客戶合約
• Encryption at rest：Atlas 預設 enable、但 encryption key 是 Atlas-managed — 合規嚴格要用 CMK / BYOK
• Audit log：Atlas 提供 audit log、export 到 S3 / Splunk

Phase 1：Operational infrastructure 準備

Atlas cluster 配置

 1# 用 Terraform mongodbatlas provider
 2resource "mongodbatlas_cluster" "production" {
 3  project_id   = var.project_id
 4  name         = "production-cluster"
 5  cluster_type = "REPLICASET"
 6
 7  provider_name         = "AWS"
 8  provider_region_name  = "US_EAST_1"
 9  provider_instance_size_name = "M80"
10
11  backup_enabled         = true
12  pit_enabled            = true   # PITR
13  mongo_db_major_version = "7.0"
14
15  advanced_configuration {
16    javascript_enabled                   = false
17    minimum_enabled_tls_protocol         = "TLS1_2"
18    no_table_scan                        = false
19    oplog_size_mb                        = 51200
20  }
21}
22
23# Backup retention
24resource "mongodbatlas_cloud_backup_schedule" "production" {
25  project_id   = var.project_id
26  cluster_name = mongodbatlas_cluster.production.name
27
28  reference_hour_of_day    = 3
29  reference_minute_of_hour = 0
30  restore_window_days      = 7
31
32  policy_item_daily {
33    frequency_interval = 1
34    retention_unit     = "days"
35    retention_value    = 7
36  }
37}

VPC peering / private endpoint

 1Pattern A: VPC Peering
 2  AWS VPC <──peering──> Atlas project VPC
 3  - 跨 region 跑、routing table 對齊
 4  - 適合中型 / 大型 workload、stable network topology
 5
 6Pattern B: Private Endpoint (Atlas private link)
 7  AWS VPC ──private link──> Atlas
 8  - 不需要 routing table 改
 9  - 適合 multi-account / multi-region 複雜場景
10  - Cost 略高

production default 走 Private Endpoint、設定簡單跟 IAM 整合好。

Atlas Database User 跟 IAM 整合

1Pattern A: 傳統 username / password
2  - 設 Database User、application 用 SCRAM-SHA-256 連
3  - 適合 legacy application
4
5Pattern B: AWS IAM authentication（推薦）
6  - Atlas Database User type: "AWS IAM"
7  - Application 用 AWS IAM role + Atlas SDK
8  - Token 15 分鐘輪換、application 自管 refresh

cutover 時間表內加 IAM authentication migration、不要事後補。

Phase 2：Data migration

Atlas Live Migration tool（小到中型）

Atlas UI 內建 Live Migration tool：

1. Source cluster URI（self-managed MongoDB）
2. Atlas target cluster
3. tool 自動 full sync + oplog tailing
4. Cutover window 內 final cutover

支援 dataset < 100GB 簡單；100GB-1TB 需要分批 / collection 順序設計。

mongomirror（大型）

1# Mongomirror: source → atlas
2mongomirror \
3  --host source-replicaset/host1:27017,host2:27017 \
4  --destination atlas-cluster-host:27017 \
5  --destinationUsername admin \
6  --destinationPassword $ATLAS_PASSWORD \
7  --ssl

mongomirror 分兩段：

1. Initial sync（full dump + restore）
2. Oplog tailing（continuous CDC）

Cutover 期間 application 切 connection string、mongomirror 跟著 stream 收尾。

Phase 3：Cutover + verification

11. Application 端設 maintenance mode（block write）
22. Wait mongomirror catch up（oplog gap → 0）
33. 驗證 Atlas 端 collection count + sample query
44. Application connection string 切到 Atlas
55. 解除 maintenance、monitor 24-48 小時
66. Self-managed mongo read-only standby 1-2 週

Production 故障演練

Case 1：Atlas tier connection limit 撞牆

徵兆：cutover 後 application 流量高峰時大量 Connection refused、Atlas 端顯示 connection limit reached；self-managed 階段沒有這問題。

根因：M80 tier connection limit ~3000、application 100 個 pod × maxPoolSize=50 = 5000 connection；超出 limit。

修法：

1. Pre-migration 計算：total connection 對照 Atlas tier、超出選上一級 tier
2. 降 maxPoolSize：100 pod × 30 = 3000、剛好 cap；但 burst 仍可能撞
3. 加 connection proxy：在 application 跟 Atlas 之間放 connection pooler（如 mongos sharded 或 ProxySQL-style proxy）

Case 2：IP whitelist 漏 application VPC、cutover 後完全連不上

徵兆：cutover 後 application 直接報 connection timeout、Atlas dashboard 顯示 zero traffic；troubleshooting 1 小時才發現是 IP access list 漏掉某 application VPC CIDR。

根因：Atlas IP access list 預設 deny all、必須明示加 application VPC；Phase 1 設定漏看某個 VPC（如 multi-account organization 內的 staging account）。

修法：

1. Pre-cutover 連線測試：每個 application VPC 跑 sample MongoDB 連線、確認 ping 通
2. 改 Private Endpoint：不靠 IP whitelist、用 PrivateLink 自動 routing
3. Backup access：保留 bastion host with whitelisted IP、incident 期間能直連

Case 3：Backup retention 設不夠、compliance audit 抓到

徵兆：cutover 3 個月後 SOX audit 發現 backup retention 設 7 天、合規要求 90 天；急忙改 Atlas config 設 90 天、但 過去 3 個月 backup 已不可恢復。

根因：Atlas backup retention 是 向前生效、不能回追加；Phase 1 預設配置漏對合規 review。

修法：

1. Pre-Phase 1 跑 compliance review：跟 legal / security team 確認 retention / data residency / audit log
2. 預設 retention 設保守值（30 / 60 天）、之後可降不能升
3. PITR 跟 backup retention 分開設：PITR window 7-30 天、full backup 90-365 天

Case 4：IAM token 過期、application 端 reconnect storm

徵兆：production 切到 IAM authentication 後、每 15 分鐘出現一波 connection failure；Atlas log 顯示「auth token expired」。

根因：AWS IAM token 15 分鐘輪換、application 用舊 token 重連失敗；token refresh 邏輯沒寫對。

修法：

1// 用 Atlas SDK + AWS SDK 整合、自動 token refresh
2const { MongoClient } = require('mongodb');
3const { fromIni } = require('@aws-sdk/credential-providers');
4
5const credentials = fromIni({ profile: 'production' });
6const client = new MongoClient(uri, {
7  authMechanism: 'MONGODB-AWS',
8  // SDK 自動 refresh token
9});

不要自管 token rotation、用 vendor SDK 抽象掉。

Case 5：Billing 暴漲、IOPS 跟 backup storage 超預估

徵兆：第一個月 Atlas 帳單 $15K USD、預估 $8K；Atlas dashboard 顯示 backup storage 跟 IOPS 各超 1.5-2x 預估。

根因：

• Atlas backup 預設 跨 region replicated、storage cost 2x
• IOPS-heavy workload 在 M tier 內可能撞 burst credit、auto-tier-up 暫時觸發更貴 tier
• Data transfer 跨 region / 跨 cloud 計費沒算

修法：

1. Pre-migration cost estimate：用 self-managed metrics 估 IOPS / bandwidth、套 Atlas pricing
2. Backup region 設單一：若不要跨 region DR、設 same-region backup 省 50%
3. Reserved Instance：穩定 workload 預付 1-3 年、省 30-40%
4. Performance Advisor 早用：第一週就跑、找 inefficient query 降 IOPS

Capacity / cost

Break-even：~200GB / 中型 workload、Atlas operational savings 平攤 1-2 年後比 self-managed cheaper；TB+ 大型 workload self-managed 仍可能便宜、但需要 ops team。

整合 / 下一步

跟 PostgreSQL → Aurora migration 對照

兩篇都是 Type C operational redesign hybrid、模板共用、細節差：

• Aurora 端 RDS Proxy 是推薦做法、Atlas 端 Private Endpoint 更標準
• Aurora 端 IAM authentication 是 optional best practice、Atlas IAM 是 推薦預設
• 兩家 cost model 都複雜、I/O cost 是 surprise 主要來源

跟 Application 端 IAM token rotation 整合

Vault dynamic credential 可 issue Atlas Database User credential、lease lifecycle 對齊 application；對 high-stakes workload 是好做法、但 setup 複雜。

下一步議題

• Atlas Data Federation：跨 Atlas 集群 query S3 / 跨 region；如果走 multi-region 評估這 feature
• Atlas Online Archive：cold data 自動 archive 到 S3、查 query 透明；對 retention 重的 workload 省 storage cost
• Atlas Serverless：burst workload 適合、steady 不划算

相關連結

• Source vendor：MongoDB
• 平行 migration playbook (Type C)：PostgreSQL → Aurora
• 平行 migration playbook：Splunk → Elastic（Type A schema 差） / Kafka ↔ NATS（Type E paradigm shift）
• Methodology：Migration playbook methodology（本文驗證 Type C 標準形態）

本文是跨 vendor migration playbook、cross-link Prometheus 跟 Grafana Stack（Grafana Cloud Metrics、Mimir-backed）。跑 migration-playbook-methodology 6 維 audit 後對映 Operational = High → Type C operational redesign hybrid。

Feature / ops / cost 三維對照

跑 6 維 diff dimension audit：

Operational = High → Type C standard。

為什麼遷：retention / ops / vendor consolidation 三條 driver

Operational redesign

Migration 4-phase

Phase 0：Audit

• 列所有 Prometheus job / scrape config
• 統計 active series 數（Mimir tier 計費基準）
• 估 retention 需求

Phase 1：Grafana Cloud setup

• Account + organization 設定
• API key for remote_write
• Grafana Cloud Mimir endpoint 啟用

Phase 2：Dual-write

 1# prometheus.yml
 2remote_write:
 3  - url: https://prometheus-prod-XX-prod-us-central-0.grafana.net/api/prom/push
 4    basic_auth:
 5      username: <INSTANCE_ID>
 6      password: <API_KEY>
 7    write_relabel_configs:
 8      # Optional: drop high-cardinality before sending
 9      - source_labels: [__name__]
10        regex: 'high_card_metric_.*'
11        action: drop

跑 4-8 週、確認 query 結果一致 + cost 在預期。

Phase 3：Cutover

• Dashboard / alert 切到 Grafana Cloud endpoint
• 應用層 / Grafana 自管 instance 關閉 query 對 self-managed Prometheus

Phase 4：Cleanup

• Self-managed Prometheus stop scrape
• 留 1-2 月歷史查詢能力（用 archive snapshot）
• Decommission

Production 故障演練

Case 1：Cardinality 爆、cost 暴漲

徵兆：dual-write 第 2 週 Grafana Cloud series 從預估 100K 漲到 800K、cost 翻 8 倍。

根因：application-level high-cardinality label（user_id / request_id）沒被 drop、scraped 進來。

修法：

1. write_relabel_configs drop unbounded label
2. Application metric 設計改 fixed-bucket histogram、不用 unbounded label
3. Mimir cardinality limit 設保護 + alert

Case 2：Recording rule 對應失效

徵兆：cutover 後 Grafana dashboard 某些 panel 顯示空；發現用了 Prometheus 端 recording rule (job:request_count:rate5m)、Grafana Cloud 端沒對應 rule。

根因：Prometheus 端 recording rule 是 server-side、不會跟著 remote_write 帶過去；Grafana Cloud 需要自己 setup recording rule。

修法：

1. Export 所有 recording rule、import 到 Grafana Cloud Mimir
2. 或改用 raw query + Grafana query template、不依賴 recording rule

Case 3：PromQL 微差行為

徵兆：某些 query 在 self-managed Prometheus 跑得好好的、切 Grafana Cloud Mimir 後 returns slightly different results。

根因：Mimir 對某些 edge case（empty result handling / staleness marker timing）行為跟 Prometheus 略不同；多數 query 一致、< 1% query 受影響。

修法：

1. Pre-cutover dual-query 驗證、用 critical dashboard 比對
2. Affected query 重寫、用更 robust PromQL pattern
3. 文件 known incompatibility list

Case 4：Alert routing 改變

徵兆：Cutover 後 PagerDuty / Slack 收不到 alert；發現 Alertmanager 端 webhook 沒切。

根因：alert 邏輯從 self-managed Alertmanager 搬到 Grafana Cloud Alerting、routing / contact 配置完全重做。

修法：

1. Pre-cutover 在 Grafana Cloud 端 rebuild alert + routing
2. 雙 alert pipeline 跑 1-2 週、確認 Grafana Cloud 收到
3. Cutover 切 routing、SOC drill 一次

Case 5：歷史資料查不到

徵兆：Cutover 後 SOC 想 query 6 個月前事件、Grafana Cloud 只有 2 個月（dual-write 後的）資料。

根因：Grafana Cloud 從 dual-write 開始才有資料、之前的 self-managed Prometheus historical data 沒 backfill。

修法：

1. Phase 2 期間用 promtool tsdb dump + mimirtool 把 self-managed historical 灌進 Mimir
2. 或保留 self-managed Prometheus read-only 6 個月（給 historical query）
3. Long-term：retention 從 cutover 開始算、historical 是 one-time backfill

Capacity / cost

整合 / 下一步

跟 Datadog → Grafana Stack migration 對位

兩條 Grafana Stack 路線：

• Self-host (Mimir + Loki + Tempo) on K8s：開源、自管
• Grafana Cloud：SaaS、operational simplification

本篇是「self-managed Prometheus → Grafana Cloud」、互補；如果跑兩階段（self-host → Cloud）跟「Datadog → Grafana Cloud」差不多。

跟 OpenTelemetry 整合

OTel Collector 可同時 ship 到 Mimir (metric) + Loki (log) + Tempo (trace)；Migration 順便升 OTel 化避免下次 vendor 切換重複。

相關連結

• Source vendor：Prometheus
• Target vendor：Grafana Stack
• 平行 migration playbook (Type C)：PostgreSQL → Aurora / Kafka → MSK / ELK → Elastic Cloud
• 平行 D-type 對位：Datadog → Grafana Stack
• Methodology：Migration playbook methodology

本文是跨 vendor migration playbook、cross-link 到 RabbitMQ 跟 AWS SQS。對照 Kafka ↔ NATS 的 paradigm shift、本篇主導差異維度是 operational model：source 跟 target 都是任務隊列、能力大致對得上、但運維責任從「自管 broker 叢集」整批交給 AWS managed 服務。

RabbitMQ → AWS SQS 的核心是把 broker 運維責任轉移給 managed 服務、同時接受 SQS 沒有 exchange routing 這個事實、把路由邏輯收斂回 application 或改用 SNS fan-out。這個遷移不是 protocol drop-in（AMQP client 不能直接連 SQS）、application 端需要改 delivery 控制機制（manual ack → visibility timeout + delete）；但它也不是 paradigm shift（兩端都是 at-least-once 任務隊列、DLQ / 重試 / 解耦的語意一致）。主導差異落在 operational 維度、所以本文走 Type C operational redesign hybrid 結構。

為什麼遷：不想再養 RabbitMQ 叢集

觸發評估 SQS 的最常見壓力是 broker 維運成本、不是功能缺口。自管 RabbitMQ 叢集要承擔的運維責任包含 Erlang cluster 拓樸維護、network partition（腦裂）處理、quorum queue 的 Raft 一致性調校、disk / memory alarm 的容量規劃、版本升級的 rolling restart。這些責任需要至少 0.5-1 FTE 的持續投入、且在 network partition 這類事故發生時需要熟悉 Erlang runtime 的人即時介入。

SQS 把這整層責任移除。沒有 broker 實例、沒有 cluster 拓樸、沒有 disk / memory watermark、沒有版本升級。換來的代價是 routing 能力消失（SQS 沒有 exchange）、application 要改 delivery 控制機制、以及 AWS 生態綁定。這個交換在三種情境下成立：

第一種是 AWS 生態原生服務。若 producer / consumer 已經跑在 Lambda、ECS、EKS 上、SQS 的 event source mapping 跟 IAM 整合讓 application 不必自管連線池跟認證。RabbitMQ 在 AWS 上要嘛自管 EC2 叢集、要嘛用 Amazon MQ（仍是 broker 模型、運維責任只是部分轉移）、都不如 SQS 的 serverless 整合直接。

第二種是 routing 邏輯本來就簡單。若 RabbitMQ 的用法是 direct exchange + 少數固定 routing key、或單純 worker pool 消費單一 queue、那 exchange 的靈活性本來就沒被用到、遷到 SQS 不損失能力。Airbnb 的 Dynein 分散式延遲任務系統就是這個形狀：用 SQS at-least-once + DLQ 取代原本受限於單 Redis 的 Resque、每 scheduler instance 達約 1000 QPS、水平擴展（見 3.C48 Airbnb Dynein）。任務排程對「不丟資料」的需求 at-least-once 足夠、不需要 broker 級 routing。

第三種是團隊規模不支撐 broker 專業。小團隊養一套 RabbitMQ 叢集、真正用到的是「可靠的任務隊列 + DLQ」、但要付出整套 Erlang 運維學習曲線。把這層交給 SQS、團隊把精力放回 application 邏輯。

6 維 diff dimension audit

遷移前先跑 diff dimension audit、對每個維度評估 source 跟 target 的差異程度、決定主導維度跟結構：

主導維度是 operational（高）：遷移的核心價值跟核心風險都在「broker 運維責任整批轉移」。Application change 維度評中高、因為 delivery 控制機制要改、但這是受控的 SDK 層改寫、不是 paradigm 重設計。Components 維度評中、因為 exchange routing 在 SQS 沒有對等物、要靠 SNS fan-out 或多 queue 補回來。其餘三維度低或中。

主導維度落在 operational、所以主結構走 Type C：以 operational redesign 對位開頭、phased 執行、故障演練聚焦在「以為對等其實不對等」的運維陷阱。Application change 跟 Components 兩個次高維度不硬塞進主結構、各自抽出獨立段（下面「application 改寫」跟「routing 收斂」兩段）。

Operational redesign 對位

Operational 維度差異最大、先逐項對位「原本自己做的事、現在誰做、怎麼做」：

前四列是純收益：責任消失、不需要對等實作。後三列是責任轉移、不是消失 — delivery 控制從 broker 移到 client、重試從 DLX 移到 redrive policy、routing 從 broker 移到 application。這三列正是故障演練聚焦的地方、因為「以為功能還在、其實機制換了」是這類遷移的主要事故來源。

監控這列值得展開。RabbitMQ 的 queue depth、unacked、consumer 數量是從 broker 直接讀；SQS 改看 CloudWatch 的 ApproximateNumberOfMessagesVisible（queue depth）跟 ApproximateAgeOfOldestMessage（lag 訊號）。差異在於 SQS 的 metric 是 approximate、且有分鐘級延遲、不適合用來做秒級的 backpressure 決策。原本靠 RabbitMQ Management UI 即時看 queue 狀態的 runbook 要改寫成 CloudWatch alarm 驅動。

Application 改寫：manual ack → visibility timeout + delete

Application change 維度的核心是 delivery 控制機制換了一套模型。RabbitMQ 是 broker-side 維護訊息狀態、consumer 用 ack/nack 回報處理結果；SQS 是 client-side 用 visibility timeout + 顯式 delete、broker 不維護「處理中」以外的狀態。

 1# RabbitMQ 端：manual ack pattern
 2channel.basic_qos(prefetch_count=10)  # 一次最多領 10 條未 ack
 3
 4def callback(ch, method, properties, body):
 5    try:
 6        process(body)
 7        ch.basic_ack(delivery_tag=method.delivery_tag)
 8    except Exception:
 9        # nack + requeue，或丟 DLX
10        ch.basic_nack(delivery_tag=method.delivery_tag, requeue=False)
11
12channel.basic_consume(queue="orders", on_message_callback=callback)
13channel.start_consuming()

 1# SQS 端：visibility timeout + delete pattern
 2while True:
 3    resp = sqs.receive_message(
 4        QueueUrl=queue_url,
 5        MaxNumberOfMessages=10,        # batch、對應 prefetch
 6        WaitTimeSeconds=20,            # long polling
 7        VisibilityTimeout=60,          # 處理中對其他 consumer 隱藏
 8    )
 9    for msg in resp.get("Messages", []):
10        try:
11            process(msg["Body"])
12            sqs.delete_message(           # 顯式 delete = ack
13                QueueUrl=queue_url,
14                ReceiptHandle=msg["ReceiptHandle"],
15            )
16        except Exception:
17            pass  # 不 delete、visibility timeout 後自動回 queue 重試

對應關係：

• RabbitMQ basic_ack → SQS delete_message：處理成功的訊息要顯式刪除、否則 visibility timeout 後重新可見。「不做事」在 SQS 等於「重試」、在 RabbitMQ 等於「卡住 unacked」。
• RabbitMQ prefetch_count → SQS MaxNumberOfMessages（上限 10）+ visibility timeout：併發控制從「broker 限制未 ack 數量」變成「一次 receive 的 batch 大小 + 隱藏時間窗」。
• RabbitMQ basic_nack(requeue=False)（丟 DLX）→ SQS redrive policy：失敗不再是 application 主動丟 DLX、而是「達到 maxReceiveCount 次數後 SQS 自動送 DLQ」。
• RabbitMQ push 模型（broker 主動推給 consumer）→ SQS pull 模型（consumer 主動 long polling）：consumer loop 結構不同、SQS 沒有 broker 主動推送、要嘛自己 poll、要嘛交給 Lambda event source mapping 代 poll。

application 邏輯改動集中在 consumer 的 receive / ack / 重試三段、producer 端從 basic_publish 改成 send_message 相對單純。整體改動量取決於原本用了多少 AMQP 特性、典型情境是 consumer 端 20-40% 改寫。

Routing 收斂：exchange 沒了、靠 SNS fan-out 或多 queue

Components 維度的核心是 SQS 沒有 exchange、RabbitMQ 的 routing 能力要在 broker 外重建。RabbitMQ 的 exchange 在 broker 內承擔分流：一條訊息經 routing key 跟 binding 決定進哪些 queue。SQS 是裸 queue、producer 直接指定 queue、沒有中間分流層。

判讀：

• Direct exchange + 少數固定 key：最容易遷。routing 邏輯本來就是「key X 進 queue X」、改成 producer 直接 send_message 到對應 queue url。routing 從 broker 收斂進 application、程式碼多幾行 if/else 或 map 查表。
• Fanout（一條訊息給多個 downstream）：用 SNS-to-SQS。SNS topic 當 fan-out 點、每個 downstream 訂閱一個自己的 SQS queue。Twitch EventSub 就是這個形狀（見 3.C54 Twitch EventSub）：SNS fan-out 到多個 SQS、各 consumer 獨立消費。這比 RabbitMQ fanout exchange 多一層 SNS、但換來 managed 運維。
• Topic exchange（複雜層級匹配）：SNS 的 subscription filter policy 能做 attribute-based 過濾、但表達力不如 AMQP topic 的 * / # 通配。複雜 topic routing 是「不該遷」的訊號（見下節）。

關鍵取捨：SQS + SNS 把 RabbitMQ 的單一 broker（routing 內建）拆成兩個 managed 服務（SQS 排隊 + SNS 分流）。好處是各自 managed、壞處是 routing 從宣告式 binding 變成要管 SNS topic + subscription + filter policy 的組合、跨服務除錯多一層。

什麼不該遷：保留 RabbitMQ 的訊號

SQS 的 managed 簡潔有代價、三類用法遷過去會損失能力或增加複雜度：

複雜 topic routing。若 RabbitMQ 重度使用 topic exchange 的 * / # 層級通配、binding 規則數十條、那 routing 的表達力是核心價值。SNS subscription filter 的 attribute 匹配做不到對等表達、勉強遷會把 broker 內的宣告式 routing 拆成散落在 SNS filter policy + application 程式碼的命令式邏輯、維護成本反而上升。GoCardless 用單一 topic exchange 當服務 mesh（見 3.C26 GoCardless Hutch）這類設計、routing 就是架構本身、不該拆。

需要 broker 級 ordering。RabbitMQ 單 queue 預設 FIFO、consistent hash exchange 還能做 per-key ordering（見 3.C28 WeWork hash ordering）。SQS standard queue 無 ordering；要 ordering 只能用 FIFO queue、而 FIFO 吞吐受限（每 MessageGroupId 有序、整體 3000 msg/sec with batching）。若 workload 同時要高吞吐跟嚴格 ordering、SQS FIFO 兩者不可兼得、RabbitMQ 反而更適合。

RPC over messaging（request-reply）。RabbitMQ 的 reply-to + correlation-id 做同步 RPC 模式、SQS 沒有原生 request-reply、要自己用兩條 queue + correlation 拼、延遲也不適合（SQS 是 task queue 不是低延遲傳輸）。這類用法該考慮 NATS 的 request-reply 或直接 HTTP。

Migration 結構：漸進 cutover

operational redesign 的 cutover 走 dual-run、按 queue（不是按整個叢集）漸進切、每步都保留回退邊界：

1. Phase 0：scope 盤點 — 列出所有 exchange / queue / binding、標註 routing 模式（direct / fanout / topic）跟 ordering 需求。判斷哪些 queue 適合遷（簡單 routing、at-least-once 夠用）、哪些保留（複雜 topic、需 broker ordering、RPC）。
2. Phase 1：SQS / SNS 基礎建設 — 對適合遷的 queue 建對應 SQS queue + DLQ（設 redrive policy + maxReceiveCount）、fanout 場景建 SNS topic + subscription。設好 IAM policy、visibility timeout 對齊 consumer 最大處理時間。
3. Phase 2：consumer 改寫 + dual-consume — application consumer 改成 SQS pull 模型（或 Lambda event source）、先讓新 consumer 跟舊 RabbitMQ consumer 並存、producer 暫時雙寫到 RabbitMQ + SQS、驗證 SQS 端處理正確。
4. Phase 3：producer cutover — 逐 queue 把 producer 從 RabbitMQ 切到 SQS / SNS、停掉該 queue 的雙寫。這步可逆：發現問題切回 RabbitMQ producer 即可。
5. Phase 4：下線 RabbitMQ queue — 確認某 queue 在 SQS 穩定運行、且 RabbitMQ 端該 queue 已排空、才停掉 RabbitMQ 對應的 exchange / queue。這是不可逆步驟、不該過早。
6. Phase 5：叢集退役 — 所有適合遷的 queue 都切完、RabbitMQ 只剩保留的複雜 routing queue（或完全清空）、才縮編或退役叢集。

漸進 cutover 的關鍵是 按 queue 切、不按叢集切。每條 queue 是獨立的遷移單元、各自走 Phase 2-4、互不阻塞。複雜 routing 的 queue 可以永遠留在 RabbitMQ、形成 RabbitMQ + SQS 長期共存的混合架構。

Production 故障演練

Case 1：DLX 改 redrive policy，重試語意不對等

徵兆：RabbitMQ 端用 DLX 配 message TTL 做「延遲重試 + 多層 escalation」（如 3.C25 Indeed Delay + DLQ 的三層 retry）；遷到 SQS 後發現 redrive policy 只能設「失敗 N 次直接進 DLQ」、做不出原本的延遲重試階梯。

根因：RabbitMQ DLX 是 routing 機制、能配 TTL + 多個中繼 queue 組出任意 escalation 拓樸；SQS redrive policy 是單一規則（maxReceiveCount 到了就送 DLQ）、沒有中繼層。兩者都叫「DLQ」、但 RabbitMQ 的是可編程 routing、SQS 的是固定計數。

修法：

1. 指數退避用 visibility timeout 做：失敗時 application 主動 ChangeMessageVisibility 延長隱藏時間、實現退避、而不是依賴 DLX TTL。
2. 多層 escalation 用多 queue 串：若真需要 N 層、建 N 個 SQS queue、application 失敗時把訊息 send 到下一層 queue、每層設不同 redrive policy。複雜度比 DLX 高、是「複雜 routing 不該遷」的訊號之一。
3. 接受簡化：多數 task queue 的重試需求是「重試幾次後進 DLQ 人工檢視」、SQS redrive policy 直接對應、不需要重建 escalation 階梯。

Case 2：prefetch 改 batch + visibility，併發控制行為變了

徵兆：RabbitMQ 端 prefetch_count=1 確保 worker 一次只處理一條（公平派發、慢任務不囤積）；遷 SQS 後 consumer 一次 receive_message 領 10 條、其中一條慢任務拖累整批、且 visibility timeout 對整批同時計時、處理到一半超時導致前面已處理的訊息重複。

根因：RabbitMQ prefetch 是 per-message 的未 ack 上限、broker 逐條控制；SQS 的 batch 是一次領多條、visibility timeout 對 batch 內每條獨立計時、但 application 若同步處理整批、慢的那條會讓後面的訊息在處理前就接近超時。

修法：

1. 慢任務用 batch size 1：對等 RabbitMQ prefetch=1 就設 MaxNumberOfMessages=1、一次領一條、避免批內互相拖累。
2. visibility timeout 設成略高於最大處理時間：Capital One 的 SQS + Lambda 實務明示這點（見 3.C50 Capital One）— timeout 太短重複處理、太長延遲 retry。長任務處理中主動 ChangeMessageVisibility 續期。
3. 逐條 delete 不等整批：每條處理完立刻 delete_message、不要等整批做完才一起刪、降低整批超時導致部分重複的風險。

Case 3：fanout 改 SNS-to-SQS，漏訂閱導致部分 downstream 收不到

徵兆：RabbitMQ fanout exchange 廣播到所有 binding queue、新增 downstream 只要 bind 上去就收得到；遷成 SNS-to-SQS 後、某個新 downstream 的 SQS queue 沒訂閱到 SNS topic、或 subscription filter policy 設錯、導致該 downstream 靜默漏訊息。

根因：RabbitMQ fanout 的廣播是 broker 內建語意、binding 一建立就生效；SNS-to-SQS 的 fan-out 是「每個 downstream 各自建 SQS queue + 訂閱 SNS topic + 設 queue policy 允許 SNS 投遞」三步、任一步漏掉或 filter policy 寫錯就靜默漏。多一層服務 = 多一層配置出錯點。

修法：

1. 訂閱關係 IaC 管理：SNS subscription + SQS queue policy 用 Terraform / CloudFormation 宣告、避免手動建漏。
2. 驗證 fan-out 完整性：cutover 前發測試訊息、確認每個 downstream queue 都收到（對照 RabbitMQ 端 binding 清單逐一核對）。
3. filter policy 預設寬鬆：除非明確要過濾、subscription 不設 filter policy（全收）、避免「以為廣播、實際被 filter 擋掉」。

Case 4：訊息超過 256KB，SQS 拒收

徵兆：RabbitMQ 對單訊息大小無硬性低上限（受 frame_max / memory 限制、實務常見 MB 級 payload）；遷 SQS 後、原本能傳的大 payload 訊息被拒、SendMessage 報 message 超過 256KB 上限。

根因：SQS 單訊息上限 256KB（含 message attribute）。RabbitMQ 沒有這個低上限、application 可能習慣直接把大 payload（如完整文件、序列化大物件）塞進訊息體。

修法：

1. Claim-check pattern：大 payload 存 S3、訊息只放 S3 物件的引用（key / presigned URL）、consumer 收到後從 S3 取。FINRA 的大檔案處理是 S3 event notification → SQS（檔案上傳 S3 後由 S3 推通知），結果同樣讓訊息只帶 S3 物件引用，但機制是 S3 觸發、不是 producer 主動 offload（見 3.C53 FINRA Large File）。
2. SQS Extended Client Library：AWS 官方 library 自動把超過上限的 payload 透明存 S3、訊息存指標、consumer 端自動取回、application 程式碼幾乎不改。
3. 盤點 payload 大小分佈：Phase 0 audit 時量測現有訊息大小、超 256KB 的比例決定是否需要 claim-check、避免 cutover 後才發現大量訊息被拒。

Case 5：ordering 從 RabbitMQ 到 SQS FIFO，吞吐撞天花板

徵兆：RabbitMQ 單 queue 提供順序消費、原本靠這個保證同一筆訂單的事件有序處理；遷 SQS standard queue 後 ordering 消失、改用 SQS FIFO queue 恢復 ordering、但吞吐從原本的數萬 msg/sec 掉到 3000 msg/sec 上限、隊列堆積。

根因：SQS standard queue 無 ordering（為了吞吐跟可用性的設計取捨）；FIFO queue 提供 per-MessageGroupId 有序 + 去重、但整體吞吐上限 3000 msg/sec（with batching）。RabbitMQ 單 queue 的有序消費吞吐遠高於此。SQS FIFO 的吞吐上限是 300 TPS（不 batch）／ 3000 TPS（batch，後者為通用 SQS FIFO 數值）。Twilio 的 webhook buffer 文件特別點出 FIFO 300 TPS 這個限制（見 3.C58 Twilio webhook）。

修法：

1. 重新審視 ordering 粒度：用 MessageGroupId 把 ordering 限縮到真正需要的範圍（如 per-訂單、per-用戶）、不同 group 平行處理、整體吞吐 = group 數 × per-group 吞吐、繞過單 queue 3000 上限。
2. 拆分 ordered 跟 unordered 流量：只有真需要 ordering 的訊息走 FIFO、其餘走 standard queue 拿高吞吐。多數 workload 只有一小部分需要嚴格 ordering。
3. ordering 是「不該遷」的硬訊號：若 workload 整體都需要高吞吐 + 嚴格 ordering、SQS FIFO 兩者不可兼得、保留 RabbitMQ 或考慮 Kafka（per-partition ordering + 高吞吐）。

Capacity / cost 對照

判讀：低到中吞吐、簡單 routing、AWS 生態的 task queue、SQS 在運維成本上顯著划算（FTE 從 0.5-1 降到約 0.1）。高吞吐 + 嚴格 ordering、或重度 exchange routing 的 workload、SQS 的 per-request 成本跟能力限制可能讓 RabbitMQ（或 Kafka）反而合適。SQS 的 cost 是用量驅動、流量大時 per-request 費用要納入評估、對照 0.6 成本取捨。

整合 / 下一步

混合架構是常見終態

多數遷移不會把 RabbitMQ 完全清空。簡單 task queue 遷 SQS、複雜 topic routing / broker ordering / RPC 留 RabbitMQ、形成長期共存：

1[簡單 task queue / fanout]              [複雜 topic routing / RPC / ordering]
2        AWS SQS / SNS                              RabbitMQ
3        │                                            │
4   Lambda / ECS consumer                    自管叢集（縮編後）

按 queue 漸進切的結果就是混合架構 — 不需要為了「遷乾淨」勉強把不適合的 queue 也搬過去。

跟 RabbitMQ → Kafka 的對照

RabbitMQ 還有另一條遷移路徑是 RabbitMQ → Kafka（work queue → event streaming）。兩條路的差異：遷 SQS 是 交出運維、能力對等簡化（仍是 task queue）；遷 Kafka 是 換 paradigm、要 replay / 高吞吐 streaming（從任務隊列變 event log）。選哪條看的是「想擺脫運維」還是「需要 streaming 能力」、不是同一個決策。

跟前面 migration playbook 的結構對照

結論：兩篇都是 message queue 跨 vendor、但主導差異維度不同 — Kafka ↔ NATS 卡在 paradigm（不同抽象層）、RabbitMQ → SQS 卡在 operational（運維責任轉移）。結構由主導維度決定、不是 universal phased playbook。

相關連結

• Source / target vendor：RabbitMQ / AWS SQS
• 平行 vendor：Google Pub/Sub / NATS
• 平行 migration playbook：Kafka ↔ NATS
• 引用案例：3.C48 Airbnb Dynein / 3.C50 Capital One / 3.C54 Twitch EventSub / 3.C58 Twilio webhook
• Methodology：Migration Playbook 寫作方法論

本文是跨 vendor migration playbook、cross-link Elastic Stack 跟 Elastic Cloud。跑 migration-playbook-methodology 6 維 audit 後對映 Operational = High（self-managed → Elastic managed）→ Type C operational redesign hybrid。

5 年 ELK 集群的 lifecycle 收尾

跟前批 PostgreSQL → Aurora 同 Type C、本文用 lifecycle-driven entry — 看 5 年 ELK 集群典型壽命曲線：

多數中型 organization 在 lifecycle 第 4-5 年遇到 operational ceiling — SRE team 0.5-1.5 FTE 跑 ELK ops、新 feature 開發停滯、cost 跟 alternative observability vendor 比較。Elastic Cloud 把 operational stack 全託管、SOC 留在 Lucene query + dashboard + alert 層、不再管 cluster sizing。

為什麼遷：FTE / availability / version cadence 三條 driver

6 維 audit

Operational = High → Type C standard。

Operational redesign 對位

Migration 4-phase

Phase 0：Pre-migration audit

• 列 application 連線 endpoint (Logstash / Beats / SDK direct)
• 列 ILM policy + retention setting
• 估 deployment size（hot tier RAM / cold tier storage）

Phase 1：Elastic Cloud deployment 建置

• 選 region + provider（AWS / GCP / Azure）
• Hot tier RAM × N + cold tier S3-backed × N
• Snapshot lifecycle 配置

Phase 2：Data migration

• Cross-cluster replication (CCR) 從 self-managed → Cloud（推薦、incremental）
• 或 snapshot + restore（簡單但需要 maintenance window）

Phase 3：Cutover + cleanup

• Application 端切 endpoint
• Self-managed 端 read-only 1-2 月
• Decommission

Production 故障演練

Case 1：Application endpoint hardcode、cutover 失敗

徵兆：cutover 後 N 個 application 仍連舊 endpoint、log / metric 斷流。

根因：endpoint 寫死在 config file、deploy 時沒一起改。

修法：endpoint 用 ENV variable + service discovery、cutover 是 single deploy。

Case 2：CCR replication lag、cutover 時資料 gap

徵兆：CCR 跑 1 週、cutover 前 lag 200ms 看似 OK；application 切到 Cloud 後 search 顯示 缺最近 5 分鐘 data。

根因：CCR replication 不保證即時 catch up、cutover 期間仍可能 lag；且 follower index 對 write 不接受。

修法：

1. Cutover 流程加 drain window — 停 application write 5-10 分鐘、等 CCR catch up
2. 確認 follower index 已 promote 成 write-capable
3. 監控 CCR lag、< 100ms 才 cutover

Case 3：Auth 改變、SOC alert 失效

徵兆：cutover 後 SOC dashboard 顯示「authentication failed」、SIEM rule 全失效。

根因：self-managed 用 X-Pack basic auth、Cloud 用 API key + SSO；SOC tooling 沒改 auth。

修法：

1. Pre-cutover 列所有 tool 連線 ELK 的 auth
2. 改 API key、用 IAM-friendly token rotation
3. Cloud 端 enable SSO + 設 service account

Case 4：Cost 暴漲、cold tier 設定錯

徵兆：第一個月 Cloud 帳單比預估高 50%；cold tier 用 fast storage（hot-tier-level）而非 S3-backed。

根因：Cloud deployment template 預設 hot 是 fast、cold 也是 fast（slow 需要明示）；team 沒 review template。

修法：

1. Pre-cutover review deployment template、確認 cold tier = searchable snapshot to S3
2. Cost monitor 第一週密集 check
3. Hot tier RAM 估算 conservative

Case 5：Snapshot 跨 region 失效

徵兆：DR drill 切 region 失敗；Cloud 內建 snapshot 是 same-region、不跨 region。

根因：multi-region DR 需要 cross-region snapshot 或 multi-deployment、不是預設。

修法：

1. 評估 DR 需求、是否需要 cross-region
2. 配 additional deployment in DR region + CCR
3. Cost 增 50-100%、是 DR 投資不是 cost optimization

Capacity / cost

整合 / 下一步

跟 Splunk → Elastic Security migration 對位

兩篇都到 Elastic 生態、但 Splunk → Elastic Security 是 Schema 高差 Type A、本篇是 Operational 高差 Type C；如果同時跑兩個 migration、Splunk → Elastic Security 先、ELK Cloud 後（避免雙重變動）。

跟 Application observability stack 整合

Elastic Cloud + APM + OpenTelemetry：cutover 後可以 順便升 OTel 化 application、避免下次 vendor 切換重複工作。

相關連結

• Source vendor：Elastic Stack
• 平行 migration playbook (Type C)：PostgreSQL → Aurora / MongoDB → Atlas / Kafka → MSK
• Methodology：Migration playbook methodology

本文是跨 vendor migration playbook、cross-link Kafka 跟 AWS MSK。跑 migration-playbook-methodology 6 維 audit 後對映 Operational = High（self-managed → AWS managed）→ Type C operational redesign hybrid。

$15K/month operational cost 拆解

跟 Datadog → Grafana Stack（H cost variant）同 framing — 用 cost 拆解開頭、不是「為什麼遷」driver list：

最大成本塊是 operational FTE、不是 infrastructure。MSK 把 50-80% operational 工作轉嫁 AWS、留 application + cost monitoring 給 SRE。

跑 6 維 diff dimension audit：

Operational = High（其他 Low-Medium）→ Type C operational redesign hybrid。

為什麼遷：FTE / availability / consistency 三條 driver

• Operational FTE：Kafka self-managed + ZooKeeper / KRaft + Prometheus 端到端 ops 是 0.5-1 FTE、MSK 把 patch / HA / backup 全託管
• Availability：MSK 自動 multi-AZ broker + auto-recovery、self-managed 自管 broker 故障 RTO 30 分鐘-2 小時
• Consistency with cloud stack：已 deep on AWS（RDS / S3 / Lambda）、MSK 進 same VPC + IAM auth、降低 cross-vendor 設置成本

反向 driver（MSK → self-managed）：

• Throughput / GB 規模大時 MSK 跨 broker cost 反轉（cost > self-managed）
• 需要 Kafka 客製化（custom plugin / kraft early adopter / 非 AWS region）
• Multi-cloud / hybrid 架構不想 vendor lock

Operational redesign 對位

跟 PostgreSQL → Aurora / MongoDB → Atlas 同 Type C pattern：

每行 operational concept 都需要 migration plan、application code 不變但 運維知識體系全換。

4-phase migration（Type C 標準流程）

Phase 0：Pre-migration audit

• Workload sizing → MSK broker class：當前 throughput / partition count / topic count
• Application connection pattern audit：客戶端 producer / consumer 用 SASL / mTLS / plaintext？哪個 application
• Topic config audit：retention / replication factor / cleanup policy
• Backup pattern audit：有 MirrorMaker / cross-cluster mirror 嗎

Phase 1：MSK cluster 建置（2-3 週）

 1resource "aws_msk_cluster" "main" {
 2  cluster_name           = "production"
 3  kafka_version          = "3.6.0"
 4  number_of_broker_nodes = 3
 5
 6  broker_node_group_info {
 7    instance_type   = "kafka.m5.large"
 8    client_subnets  = var.private_subnets
 9    security_groups = [aws_security_group.msk.id]
10    storage_info {
11      ebs_storage_info {
12        volume_size = 1000
13        provisioned_throughput {
14          enabled           = true
15          volume_throughput = 500
16        }
17      }
18    }
19  }
20
21  client_authentication {
22    sasl {
23      iam = true        # IAM auth (推薦)
24      scram = false
25    }
26  }
27
28  configuration_info {
29    arn      = aws_msk_configuration.main.arn
30    revision = aws_msk_configuration.main.latest_revision
31  }
32
33  encryption_info {
34    encryption_in_transit {
35      client_broker = "TLS"
36    }
37  }
38
39  logging_info {
40    broker_logs {
41      cloudwatch_logs {
42        enabled   = true
43        log_group = aws_cloudwatch_log_group.msk.name
44      }
45    }
46  }
47}

Phase 2：Data migration（MirrorMaker 2.0）

1Self-managed Kafka ──(MM2)──→ MSK
2                       │
3                consumer offset sync
4                       │
5                topic config sync

MM2 跑 1-7 天、依 topic 量 + retention 期間；replica.lag 對齊後進 cutover。

Phase 3：Cutover

• Application 端切 bootstrap.servers 從 self-managed → MSK
• Producer 漸進切（10% → 50% → 100%）
• Consumer 切換時 offset 從 MM2 sync 過的位置開始
• Self-managed cluster read-only standby 2 週

Production 故障演練

Case 1：IAM auth 沒設、application 連不上

徵兆：cutover 後 application 報 SaslAuthenticationException: Access denied；MSK 端 cloudWatch log 顯示 IAM principal 不認。

根因：MSK IAM auth 要求 client 跑 MSK IAM auth library（Java 用 aws-msk-iam-auth、Python 用 aws-msk-iam-sasl-signer-python）；application 端用 standard Kafka client、不知道怎麼 sign IAM signature。

修法：

 1# Python kafka-python + IAM auth
 2from aws_msk_iam_sasl_signer import MSKAuthTokenProvider
 3from kafka import KafkaProducer
 4
 5class AwsMskIamProvider(MSKAuthTokenProvider):
 6    def token(self):
 7        return self.generate_auth_token('us-east-1')[0]
 8
 9producer = KafkaProducer(
10    bootstrap_servers='b-1.mycluster.kafka.us-east-1.amazonaws.com:9098',
11    security_protocol='SASL_SSL',
12    sasl_mechanism='OAUTHBEARER',
13    sasl_oauth_token_provider=AwsMskIamProvider(),
14)

EKS pod 必須有 IAM role（IRSA）對 MSK cluster kafka-cluster:Connect action。

Case 2：Version pinning、3.6.0 跟 self-managed 行為差

徵兆：cutover 到 MSK 3.6.0 後、某些 consumer 跑舊 client 失敗；新 broker 改 default inter.broker.protocol.version 但 client 不認。

根因：MSK 升 Kafka version 後 broker config 變動、舊 client（< 2.8）跟新 broker 協議不對；self-managed 端可能用更舊 broker version 跑、看不出問題。

修法：

1. Pre-migration：所有 client 升 Kafka client library 2.8+
2. MSK kafka_version 對齊 self-managed：先建 MSK 3.0 / 3.5、跟 self-managed 一致、cutover 後再升
3. Phase rollout：用 Tiered Storage + retention 策略保留舊資料、新 producer / consumer 用新 version

Case 3：Metric pipeline 失效、SOC dashboard 無數據

徵兆：cutover 後 Grafana dashboard 顯示 MSK metric 0；舊 JMX exporter 抓不到 MSK；CloudWatch 有 metric 但 SOC 端不接 CloudWatch。

根因：MSK 不暴露 JMX、metric 走 CloudWatch / open monitoring (Prometheus + Grafana)、跟自建 JMX-based pipeline 不對等。

修法：

1. Open monitoring enabled：MSK config 設 open_monitoring.prometheus.jmx_exporter.enabled = true、跑 Prometheus 對 MSK broker 拉 metric
2. CloudWatch → Prometheus：用 cloudwatch-exporter 拉 CloudWatch metric 進 Prometheus
3. Dashboard refresh：Grafana dashboard 對 MSK-specific metric name 重寫（kafka_server_* → aws_kafka_* 或統一 alias）

Case 4：Cross-cluster mirror（MM2 → MSK）配置複雜

徵兆：MM2 跑了 1 週、self-managed 跟 MSK consumer offset 沒同步；application 切過去後 重新讀整批舊資料、duplicate processing。

根因：MM2 consumer offset sync 需要 跨 cluster mapping、source 端 offset 跟 target 端 offset 不直通；MM2 預設 offset sync 沒打開。

修法：

1# MM2 config
2source.consumer.bootstrap.servers=self-managed-kafka:9092
3target.consumer.bootstrap.servers=msk-cluster:9098
4target.security.protocol=SASL_SSL
5sync.group.offsets.enabled=true       # 必須打開
6emit.checkpoints.enabled=true
7checkpoints.topic.replication.factor=3

Architecture：consumer 切換時讀 MM2 checkpoint topic、不直接讀 internal offset；application 端用 idempotent + dedup key、avoid duplicate processing。

Case 5：MSK billing 暴漲、Tiered Storage / cross-AZ 沒控

徵兆：MSK 第一個月帳單比預估高 50%；breakdown 後發現 cross-AZ traffic（producer/consumer 跨 AZ）+ Tiered Storage 退到 S3 的 hot tier。

根因：

• MSK auto multi-AZ deployment 不可避免 cross-AZ traffic、producer 寫 partition leader 可能跨 AZ
• Tiered Storage 對 hot data（retention < 24 小時）會多 storage cost；cold data 才 cost-effective

修法：

1. Application AZ-aware routing：producer 走 same-AZ broker（用 rack-aware producer config）、降 cross-AZ
2. Retention 對齊 hot tier：< 24 小時 retention 用 broker local storage、24 小時+ 才走 Tiered Storage
3. Reserved instance：MSK 不直接 reserved、但 EBS / data transfer 可預付、降 10-20%

Capacity / cost

判讀：< 50 broker organization MSK ROI 通常 6-12 月持平、之後省 FTE；50+ broker 大 organization 自管 cost 可能反而低。

整合 / 下一步

跟 Kafka ↔ NATS migration 對位

兩條 Kafka 出路：

• MSK：operational simplification、protocol drop-in、cost 中等漲；適合 繼續用 Kafka paradigm 的 organization
• NATS：paradigm shift、application 必須改、適合 單純 messaging 不要 event sourcing 的 use case

多數 organization 不需要 paradigm shift、MSK 更合理；真正需要 lightweight messaging 才走 NATS。

跟 Confluent Cloud 對位

Confluent Cloud 是另一個 managed Kafka、跨 cloud（AWS / GCP / Azure）；MSK 是 AWS-only、但跟 IAM / VPC 整合更深。Multi-cloud organization 走 Confluent、AWS-deep organization 走 MSK。

跟 IAM / Secrets Manager 整合

MSK + IAM auth + Secrets Manager（連 Vault → AWS Secrets Manager migration）是 AWS-deep stack 的標準組合；short-lived credential + IRSA 是 production best practice。

反向 migration（MSK → self-managed）

少見、通常是 cost 反轉（大 scale）或 multi-cloud strategy；流程鏡像對稱、注意 MSK Tiered Storage data 不直接 export、需要 先 disable tiered storage + recall data。

下一步議題

• MSK Connect：managed Kafka Connect、降 connector 運維、但 plugin ecosystem 比 self-managed Connect 少
• MSK Serverless：burst workload 適合、steady workload 反而貴
• Cost monitoring playbook：MSK billing 拆解每月跑一次、catch unexpected egress / tiered storage cost

相關連結

• Source vendor：Kafka
• 平行 migration playbook (Type C)：PostgreSQL → Aurora / MongoDB → Atlas
• 平行 H cost variant：Datadog → Grafana Stack
• 平行 paradigm shift：Kafka ↔ NATS
• Methodology：Migration playbook methodology

本文是跨 vendor migration playbook、cross-link Redis / Valkey（source、自管）跟 AWS ElastiCache（target、managed）。跑 migration-playbook-methodology 6 維 audit 對映 Operational model = High（自管 → managed）、其他 Low → Type C operational hybrid。ElastiCache 是 managed SaaS、AWS 操作依官方文件（未本機驗證、引數以官方為準）、最後檢查日 2026-06-16。

engine 不變、變的是誰運維

多數 vendor 遷移會換掉某個本質的東西——協定、data model、paradigm。自管 Redis/Valkey → ElastiCache 一個都沒換：ElastiCache 跑的就是 Redis 或 Valkey engine，同樣的 RESP 協定、同樣的 data types、同樣的 client library、同樣的命令。application code 幾乎不用動。

那遷的是什麼？運維責任的歸屬。自管時要自己部署、自己打 patch、自己設 replication、自己半夜處理 failover。ElastiCache 把這些接走——AWS 做 failover、patching、snapshot、跨 AZ 複製。這個遷移的全部工作量集中在「把運維交出去」這件事上：網路（VPC）、安全（IAM / Security Group）、cutover 的資料連續性，以及想清楚交出運維的同時、交出了哪些控制權（不再能 SSH 進機器、不能改任意 config、parameter group 限定可調項）。

這對映 migration 方法論 的 Type C operational hybrid——operational model 是唯一的 High 維度，其他全 Low。本文展開這個「engine 不變、運維轉移」遷移的實際工作與責任邊界。

6 維 diff dimension audit

唯一 High 是 operational model，對映 Type C operational hybrid。Type C 的結構是「operational audit 前置 + drop-in cutover」——因為 engine/API 不變，cutover 本身接近 drop-in（換 endpoint），重點在前置的網路/安全/責任邊界盤點。

operational audit：cutover 前要盤點的

ElastiCache 把運維接走，但也劃下新的邊界。cutover 前必盤：

audit 的關鍵 output：(1) 目前改了哪些 redis.conf 項、ElastiCache parameter group 是否支援；(2) client 是否有 failover reconnect 邏輯（managed failover 不會代為重連）；(3) 監控要從自管工具搬到 CloudWatch。這三項是 Type C 的核心工作。詳細的 managed 責任邊界見 ElastiCache 責任邊界 deep article。

cutover：資料連續性的兩條路

因為 engine/API 不變，cutover 接近 drop-in（換 endpoint）。資料連續性有兩條路：

 1路徑 A：re-warm（cache 可重建、最簡單）
 2  1. 建 ElastiCache cluster（空的、選 Valkey / Redis engine、設 parameter group）
 3  2. application 雙寫（自管 + ElastiCache）、讀仍走自管
 4  3. 讀切到 ElastiCache endpoint、cache miss 回源 warm up
 5  4. 命中率追上 → 停寫自管 → 下線自管
 6
 7路徑 B：RDB seed（要 cache 連續性、避免 warm-up origin 衝擊）
 8  1. 自管端 BGSAVE 產生 RDB
 9  2. RDB 上傳 S3、ElastiCache 從 S3 seed 建 cluster（依官方 restore 流程）
10  3. application 換 endpoint cutover
11  （ElastiCache 也提供 self-managed Redis online migration、見官方文件）

判讀：

• 純 cache、能接受短暫 warm-up → 路徑 A（最簡單、無資料遷移）
• 大 dataset、warm-up 會打爆 origin → 路徑 B（RDB seed 保連續性）
• AWS CLI 建 cluster 與 restore 細節依 ElastiCache 官方文件（未本機驗證）
• engine 選 Valkey（AWS default、約低 Redis 20%）除非有 Redis 商業 module 依賴

Production 故障演練

Case 1：parameter group 不支援自管時改的 config

徵兆：自管時改了某個 redis.conf 項（例如特定 client-output-buffer-limit 或某個進階參數），遷到 ElastiCache 後該設定無法套用或行為不同。

根因：ElastiCache 只允許改 parameter group 開放的項，部分 config 被 AWS 鎖死（為了 managed 穩定性）。自管時的任意 config 自由度在 managed 後收窄。

修法：

1. pre-migration 列出自管端所有非預設 config，逐項對照 ElastiCache parameter group 支援度
2. 不支援的項要評估影響——有些是 AWS 已用更好的方式處理、有些要調整 application 適應
3. 把這個盤點放在 operational audit（cutover 前），不要遷完才發現
4. 高度依賴特殊 config 調校的場景，managed 可能不適合、留自管

Case 2：failover 後 client 不重連（managed 不代為重連）

徵兆：ElastiCache Multi-AZ failover 完成，但 application 持續連舊 primary、寫入失敗。

根因：ElastiCache 接走了 failover（自動晉升 replica），但 application 的 client 重連仍是 application 端的責任——這是 managed 責任邊界 的核心：AWS 換 primary，client 要自己跟上。

修法：

1. client 連 primary endpoint（會跟著 failover 更新 DNS）、不寫死 node IP
2. client 設合理 socket timeout + retry + 縮短 DNS 快取
3. 遷移前就驗證 client 有 failover reconnect 行為（自管 Sentinel 時可能靠不同機制）
4. 對應 Redis Sentinel failover 時序：自管與 managed 的 failover 機制不同、client 處理要重驗

Case 3：endpoint 只在 VPC 內、cutover 後連不上

徵兆：cutover 後 application 完全連不上 ElastiCache、連線逾時。

根因：ElastiCache endpoint 只在 VPC 內可達、不對公網開放。Security Group 沒開 6379、subnet group 配置錯、或 application 不在同 VPC / 沒有 VPC peering，就連不上。

修法：

1. cutover 前確認 Security Group 開 6379 給 application 的來源、subnet group 正確
2. application 不在同 VPC 要設 peering / Transit Gateway
3. 從 VPC 內 EC2 先 redis-cli -h <endpoint> ping 驗證連通，再切 application
4. 這是自管（自己的網路）→ managed（AWS VPC 模型）最常見的卡點

Case 4：監控斷層（自管工具 → CloudWatch）

徵兆：cutover 後原本的 Prometheus / Grafana dashboard 全空、告警失效。

根因：自管時用 redis_exporter + Prometheus，ElastiCache 的指標在 CloudWatch、指標名與維度不同。直接搬 dashboard 不會動。

修法：

1. cutover 前把關鍵告警在 CloudWatch 重建（DatabaseMemoryUsagePercentage / ReplicationLag / CurrConnections 等）
2. 要保留 Grafana 可用 CloudWatch data source 接
3. 把監控遷移納入 operational audit、不要遷完才發現沒監控
4. 核心指標語意相同（記憶體 / 命中 / 連線 / 複製延遲）、只是來源與命名變了

Case 5：以為 managed 就不會 OOM / stampede / 熱 key

徵兆：遷到 ElastiCache 後仍然 OOM、cache stampede、熱 key 打爆單 shard。

根因：ElastiCache 接走的是運維（failover/patch/snapshot），不是 cache 使用方式的問題。記憶體淘汰、stampede、熱 key、key 設計仍是 application 端的責任——managed 不等於 hands-off。

修法：

1. 記憶體 / eviction 調校仍要做（透過 parameter group 設 maxmemory-policy），見 記憶體調校
2. stampede / 熱 key 的 application 端防護（jitter / singleflight / 兩層 cache）照舊
3. 釐清 managed 的責任邊界——左欄 AWS 管、右欄 application 端管，見 責任邊界 deep article
4. 遷 managed 是減運維、不是免設計

Capacity / cost 對照

判讀：在 AWS 生態、要把運維交出去、能接受 config 自由度收窄 → 遷 ElastiCache（engine 不變、Type C 低風險）；要極致控制 / 跨雲 / 依賴特殊 config → 留自管。engine 選 Valkey 省約 20%。

整合 / 下一步

self-managed → ElastiCache 是運維轉移，它跟 managed 邊界與 engine 調校交織：

• 跟 ElastiCache 責任邊界 deep article：遷過去後哪些 AWS 管、哪些仍 application 端管，是這個遷移的核心後果。
• 跟 Redis Sentinel failover：自管 failover（Sentinel）→ managed failover（Multi-AZ），client 重連邏輯要重驗。
• 跟 Valkey：ElastiCache default engine 是 Valkey，自管 Redis 遷 ElastiCache for Valkey 是「換授權 + 轉 managed」一次到位（見 Redis → Valkey 遷移）。
• 跟能力級買 vs 建：自管 vs managed 的上層取捨見該章，本文是「決定買（managed）之後」的遷移執行。

相關連結

• Source vendor：Redis / Valkey（自管）
• Target vendor：AWS ElastiCache
• 對應 deep article：ElastiCache 責任邊界
• 相關 migration：Redis → Valkey（換授權 + 可同時轉 managed）
• Methodology：Migration playbook methodology（Type C operational hybrid）