Migrate hệ thống IoT từ Heroku sang AWS - Bài toán thực tế và các lựa chọn kiến trúc

Tổng quát

Migrate hệ thống lên cloud hay giữa các cloud provider là một công việc khá phổ biến trong thực tế. Tuy nhiên mỗi hệ thống lại có những đặc thù riêng, do đó việc lựa chọn kiến trúc phù hợp là vô cùng quan trọng. Bài viết hôm nay mình sẽ chia sẻ một use case thực tế về việc migrate hệ thống IoT từ Heroku sang AWS, cùng với những cân nhắc và quyết định kiến trúc mà mình đã đưa ra.

Bối cảnh

Hệ thống mà mình đang phụ trách làm về IoT, cho phép người dùng thông qua mobile app để điều khiển các thiết bị thông minh trong nhà. Trước đây, hệ thống có sử dụng một API của một công ty bên Mỹ, đóng vai trò là connector trung gian để chuyển tiếp request đến API của các maker thiết bị IoT khác nhau.

Do công ty này không support phát triển API theo yêu cầu của công ty mình nữa, nên công ty đã quyết định mua lại toàn bộ hệ thống API của họ với giá 1 triệu đô để tự phát triển và vận hành. Mình sẽ tạm gọi đây là hệ thống Connector.

Các thành phần hệ thống hiện tại

Để hiểu rõ hơn về bài toán migration, mình sẽ mô tả các thành phần hệ thống hiện tại:

Kiến trúc tổng quát:

Hệ thống IoT (hệ thống chính)

Đang chạy trên Amazon EKS
Region: Tokyo (ap-northeast-1)
Kiến trúc microservices trên Kubernetes, phần này mình không đưa kiến trúc cụ thể vào đây vì nó không quan trọng

Hệ thống Connector (hệ thống cần migrate)

Platform: Heroku (US region)
Architecture: Microservices built trên Node.js
Message Queue: RabbitMQ (CloudAMQP)
Database: MongoDB Atlas
Một phần chức năng: Sử dụng AWS API Gateway và Lambda
Kiến trúc hệ thống Connector cụ thể hiện tại (đã lược bớt rất nhiều phần không liên quan). Mọi người có thể tập trung vào phần RabbitMQ, MongoDB Atlas và Heroku thôi, mấy cái còn lại không cần để ý cũng được.

Đánh giá:

Như vậy có thể thấy hệ thống hiện tại đang rất phân tán, một phần ở AWS Tokyo, một phần ở Heroku US, và sử dụng nhiều managed service từ các provider khác nhau.

Lý do cần migrate

Sau khi mua lại hệ thống Connector và vận hành khoảng 6 tháng, team nhận thấy các vấn đề sau:

1. Độ trễ cao (High Latency)

Đây là vấn đề nhất ảnh hưởng trực tiếp đến trải nghiệm người dùng.

Hệ thống Connector nằm ở Mỹ (Heroku US region)
Hệ thống IoT chính lại nằm ở Nhật (EKS Tokyo)
Mỗi request từ user phải: Mobile App → IoT System (Tokyo) → Connector (US) → IoT Device APIs
Round-trip latency rất cao, gây delay khi điều khiển thiết bị

2. Chi phí cao (High Cost)

Riêng chi phí Heroku đã lên tới hơn 3,000 USD/tháng
Chưa kể chi phí CloudAMQP, MongoDB Atlas
Với khối lượng công việc hiện tại, chi phí này là quá cao

3. Quản lý phức tạp (Management Complexity)

Công ty phải đăng ký và thanh toán cho nhiều vendor cùng lúc:

AWS (cho hệ thống chính)
Heroku (cho Connector)
CloudAMQP (cho RabbitMQ)
MongoDB Atlas (cho database)

Việc này tạo ra overhead trong quản lý, billing.

Các lựa chọn đặt ra và cân nhắc

Chiến lược tổng quát

Trước khi đi vào chi tiết từng component, mình đã xác định 2 nguyên tắc chính:

Di chuyển mọi thứ về trong VPC
- Hiện tại các thành phần đều expose ra internet và communicate qua public network
- Target: Đưa hết về trong VPC để tăng security, giảm latency, giảm data transfer cost
Migrate về cùng region Tokyo
- Đưa Connector từ US về Tokyo để giảm latency giữa IoT system và Connector
- Kiến trúc trước migrate:
- Kiến trúc sau migrate:

Quyết định cho từng component

Tiếp theo mình sẽ phân tích chi tiết quyết định cho từng thành phần của hệ thống.

1. Heroku: EKS hay ECS Fargate?

Đây là quyết định quan trọng nhất trong quá trình migration. Ban đầu mình có 2 lựa chọn chính:

Option 1: Migrate sang EKS (cùng cluster với IoT system)

Ưu điểm:

Dùng chung infrastructure với hệ thống IoT, dễ quản lý
Team đã có kinh nghiệm vận hành EKS
Sharing resource có thể giúp tối ưu chi phí

Nhược điểm:

Phải reorganize lại môi trường của Connector (hiện có 3 envs: dev, stg, prod) để match với IoT system (6 envs)
Phải migrate CI/CD pipeline từ CircleCI sang Jenkins
Khó release độc lập: khi release Connector phải cân nhắc ảnh hưởng đến IoT system

Option 2: Migrate sang ECS Fargate (cluster riêng)

Ưu điểm:

Phù hợp với kiến trúc microservices (tương tự Heroku dynos)
Không cần reorganize môi trường, giữ nguyên 3 envs
CircleCI đã có template sẵn cho ECS, chỉ cần customize nhỏ → ít effort hơn
Release độc lập hoàn toàn với IoT system

Nhược điểm:

Phải quản lý 2 orchestration platform (EKS + ECS)

Cân nhắc: ECS Fargate

Trước mắt, mình thấy ECS Fargate hợp lý hơn vì các lý do sau:

Giảm effort migration: Không phải reorganize environment và CI/CD pipeline
Độc lập release: Hai hệ thống có release cycle khác nhau, có thể deploy độc lập
Risk management: Tách biệt hai hệ thống giúp giảm risk khi có incident
Chi phí tương đương: Ước tính sơ qua với use case của mình thì EKS, ECS Fargate có chi phí tương đương nhau

Lưu ý: Mình không chọn Lambda + API Gateway vì:

Cold start latency không phù hợp với yêu cầu low-latency
Kiến trúc microservices hiện tại khó refactor sang serverless

2. CloudAMQP: Migrate sang Amazon MQ

Đây là quyết định đơn giản nhất trong quá trình migration.

Lý do chọn Amazon MQ

CloudAMQP chạy RabbitMQ → AWS có service tương ứng là Amazon MQ for RabbitMQ
Chi phí tương đương với CloudAMQP
Fully managed, không cần maintain infrastructure
Có thể deploy trong VPC, giảm latency và tăng security

Không có nhiều cân nhắc phức tạp ở component này, Amazon MQ là lựa chọn tự nhiên nhất.

3. MongoDB Atlas: Tại sao không dùng DocumentDB?

Đây là quyết định thú vị nhất và có nhiều người có thể sẽ thắc mắc.

Lựa chọn hiển nhiên: Amazon DocumentDB?

Khi nghĩ đến migrate MongoDB lên AWS, ai cũng sẽ nghĩ đến Amazon DocumentDB (with MongoDB compatibility). Tuy nhiên ở đây mình lại không chọn DocumentDB.

Tại sao không dùng DocumentDB?

Vấn đề 1: Support MongoDB version rất chậm

Hệ thống Connector hiện đang dùng MongoDB 8.x (released cả năm nay rồi)
DocumentDB vừa mới support MongoDB 8.0 vào tháng trước (tháng 4/2026)
Hồi tháng trước khi mình mới check, thì DocumentDB vẫn chưa support MongoDB 8.0 → không tương thích với version hiện tại của Connector

Vấn đề 2: DocumentDB không phải native MongoDB

Đây là điểm quan trọng nhất mà nhiều người hay nhầm lẫn.

DocumentDB được build trên Aurora storage engine, không phải MongoDB native
Mặc dù compatible với MongoDB API, nhưng không phải tất cả features đều work 100%
Một số MongoDB native features có thể không tương thích hoặc hoạt động khác đi

Vấn đề 3: Risk cao do thiếu hiểu biết về hệ thống

Hệ thống Connector mới mua về 6 tháng, team chưa hiểu hết toàn bộ codebase
Chưa có effort để research kỹ xem code có sử dụng feature nào không compatible với DocumentDB hay không
Risk của việc migrate sang DocumentDB khá cao, có thể gây bug khó debug

Cân nhắc: MongoDB Atlas + AWS PrivateLink

Thay vì migrate sang DocumentDB, mình cân nhắc:

Giữ nguyên MongoDB Atlas, nhưng sử dụng AWS PrivateLink để kết nối private vào VPC

Lý do:

Giảm risk: Không cần thay đổi gì về database engine
Security: Data không đi qua internet, đảm bảo security tốt hơn
Performance: Giảm latency nhờ kết nối nội bộ, không phải public internet

Trade-off:

Vẫn phải manage thêm một vendor (MongoDB Atlas)

Tuy nhiên vẫn cần thảo luận thêm với team một chút xem liệu rằng như vậy có ổn hay không.

Tóm tắt các quyết định kiến trúc

Component	Hiện tại	Target	Lý do
Compute	Heroku (US)	ECS Fargate (Tokyo)	Giảm latency, giảm chi phí, dễ CI/CD
Message Queue	CloudAMQP	Amazon MQ	Service tương đương, trong VPC
Database	MongoDB Atlas (public)	MongoDB Atlas + PrivateLink	Giảm risk, private connection
Networking	Public internet	VPC (Tokyo)	Security, latency, cost

Kiến trúc dự tính:

Đây là kiến trúc phản ánh các điều mà mình cân nhắc ở trên
Có thể thấy kiến trúc này sẽ cần thêm một số các thành phần mới như ALB để cân bằng tải, NATGW cho traffic đi ra internet (kết nối đến API của maker)

Kết quả mong đợi

Sau khi hoàn thành migration, mình kỳ vọng sẽ đạt được:

Giảm latency: Từ US-Tokyo về same region (Tokyo) → giảm hơn 50% latency
Giảm chi phí:
- Heroku 3,000 USD/month → ECS Fargate ~1000 USD/month
- CloudAMQP → Amazon MQ: tương đương
- Giảm data transfer cost khi mọi kết nối đi trong VPC
Đơn giản hóa quản lý: Giảm từ 4 vendors xuống 2 vendors (AWS + MongoDB Atlas)
Tăng security: Tất cả communication trong VPC, không expose ra internet

Phần tiếp theo

Trong bài viết này, mình đã chia sẻ về các quyết định kiến trúc và lý do đằng sau mỗi lựa chọn. Ở phần tiếp theo, mình sẽ đi vào chi tiết về:

Ước tính chi phí cụ thể cho từng component sau migration
Migration plan chi tiết và các bước thực hiện
Kết quả thực tế sau khi migration (latency improvement, cost saving)

Stay tuned nhé các bạn!