Khi nào nên cân nhắc rời một dịch vụ managed của AWS

Dịch vụ managed của AWS tồn tại vì một lý do chính đáng: chúng lấy đi phần việc vận hành mà phần lớn các đội không muốn và không nên tự làm. Tuy vậy, mức phí trả cho sự tiện lợi đó tăng theo quy mô, và tới một lúc nào đó, tự vận hành có thể rẻ hơn đáng kể mà rủi ro vẫn nằm trong tầm kiểm soát. Bài viết này trình bày cách chúng tôi so sánh hai lựa chọn một cách công bằng, một vài ví dụ cụ thể, và cả những trường hợp nên ở lại với dịch vụ managed.

So sánh công bằng bắt đầu từ tổng chi phí sở hữu

Sai lầm phổ biến nhất khi so sánh là đặt giá dịch vụ managed cạnh giá EC2 rồi kết luận tự vận hành rẻ hơn nhiều lần. Phép so sánh đó bỏ qua phần lớn chi phí thật. Một bảng so sánh đáng tin cần có ít nhất các dòng sau:

• Hạ tầng: instance, storage, data transfer, và các thành phần đi kèm như load balancer hay bản sao ở nhiều AZ để đạt cùng mức sẵn sàng.
• Thời gian kỹ sư: dựng hệ thống, viết automation, nâng cấp phiên bản, vá lỗi bảo mật. Hãy ước tính theo giờ mỗi tháng và quy ra tiền theo chi phí thật của đội.
• On-call: ai sẽ thức dậy lúc 3 giờ sáng khi cluster gặp sự cố, và đội có đủ người để chia ca hay không.
• Rủi ro: chi phí của một lần mất dữ liệu hoặc gián đoạn kéo dài, nhân với khả năng điều đó xảy ra khi đội tự vận hành.
• Chi phí chuyển đổi: thời gian migrate, chạy song song hai hệ thống, và rủi ro trong giai đoạn chuyển.

Một vài ví dụ thường gặp

NAT Gateway và NAT instance. Đây là ví dụ đơn giản nhất. NAT Gateway tính phí theo từng GB đi qua, trong khi một NAT instance (chẳng hạn dựng bằng dự án mã nguồn mở fck-nat) chỉ tốn tiền instance. Chúng tôi đã viết riêng một bài về trường hợp này. Điểm chính là nên đưa traffic tới dịch vụ AWS qua VPC Endpoint trước, rồi mới xét tới NAT instance cho phần còn lại.

Amazon MSK và Kafka tự vận hành. MSK lo phần quản lý broker, ZooKeeper hoặc KRaft, và việc thay thế node lỗi. Với các cluster lớn và ổn định, chi phí broker của MSK cộng với storage có thể cao hơn nhiều so với Kafka chạy trên EC2. Tuy vậy, Kafka là hệ thống khó vận hành: rebalance partition, nâng cấp phiên bản và xử lý ổ đĩa đầy đều đòi hỏi kinh nghiệm thật. Trước khi rời MSK, nên kiểm tra xem cluster có đang dư broker, retention có dài hơn cần thiết, hay MSK Serverless có phù hợp hơn không.

Amazon OpenSearch Service. Chi phí thường đến từ việc giữ quá nhiều dữ liệu trên node nóng. Các tầng UltraWarm và cold storage, cùng với Index State Management để tự chuyển và xóa index cũ, thường giảm được phần lớn chi phí mà không cần rời dịch vụ. Tự vận hành OpenSearch chỉ đáng cân nhắc khi đội đã có kinh nghiệm vận hành cluster tìm kiếm và khối lượng dữ liệu đủ lớn.

ElastiCache và Redis hoặc Valkey tự vận hành. ElastiCache hiện hỗ trợ Valkey, một bản fork mã nguồn mở của Redis, với giá node thấp hơn Redis OSS trên cùng dịch vụ. Với nhiều đội, chuyển engine sang Valkey trong ElastiCache là bước nên thử trước khi nghĩ tới tự vận hành. Cache thường dễ tự vận hành hơn database vì dữ liệu có thể dựng lại, nhưng nếu bạn dùng Redis như nơi lưu dữ liệu chính thì cần cẩn trọng hơn nhiều.

S3 và các lựa chọn khác cho workload egress lớn. Với S3, chi phí lưu trữ thường không phải vấn đề. Vấn đề là phí data transfer khi dữ liệu được tải ra internet với khối lượng lớn, ví dụ phân phối file, ảnh hay video. Cloudflare R2 không tính phí egress, nên với những workload này, chuyển phần dữ liệu được tải nhiều sang R2 có thể giảm đáng kể chi phí. Trước đó, hãy kiểm tra xem CloudFront đã được đặt trước S3 chưa và cache hit ratio có tốt không, vì đó thường là bước đơn giản hơn và vẫn nằm trong AWS.

Dấu hiệu đã tới lúc cân nhắc

• Một dịch vụ managed chiếm tỷ trọng lớn và tăng đều trong hóa đơn, trong khi tải của hệ thống khá ổn định và dễ dự đoán.
• Phần lớn chi phí đến từ một cơ chế tính phí cụ thể, như phí theo GB hay theo request, mà kiến trúc khác có thể tránh được.
• Đội đã có người hiểu sâu công nghệ đó và đang vận hành những hệ thống tương tự.
• Bạn đã tối ưu cấu hình trong chính dịch vụ managed, như rightsizing, retention hay tầng lưu trữ, mà chi phí vẫn cao.

Dấu hiệu nên ở lại

• Đội nhỏ và không có người chuyên trách hạ tầng, hoặc on-call hiện đã quá tải.
• Hệ thống đó lưu dữ liệu quan trọng và yêu cầu sẵn sàng cao, nơi một sự cố có giá lớn hơn nhiều so với khoản tiết kiệm.
• Khoản tiết kiệm ước tính, sau khi tính cả thời gian kỹ sư, nhỏ so với tổng hóa đơn.
• Tải biến động mạnh, và khả năng tự mở rộng của dịch vụ managed đang thực sự được dùng tới.
• Bạn cần các chứng nhận tuân thủ mà dịch vụ managed đã có sẵn.

Migrate thế nào cho an toàn

Nếu quyết định rời một dịch vụ managed, cách làm của chúng tôi thường theo các bước sau:

1. Bắt đầu từ môi trường ít rủi ro nhất, thường là dev hoặc staging, để đội có thời gian làm quen với việc vận hành.
2. Viết toàn bộ hạ tầng bằng IaC cùng với runbook cho các sự cố thường gặp, trước khi đưa traffic production vào.
3. Chạy song song hệ thống cũ và mới trong một khoảng thời gian, so sánh dữ liệu và độ trễ, và chuyển traffic dần dần.
4. Giữ đường quay lui cho tới khi hệ thống mới đã chạy ổn định qua ít nhất một chu kỳ cao điểm.
5. Đo lại chi phí thật sau vài tháng, bao gồm cả thời gian đội bỏ ra, để biết quyết định có đúng không.

Tóm lại

Không có câu trả lời chung cho việc dùng dịch vụ managed hay tự vận hành. Dịch vụ managed thường là lựa chọn đúng cho đa số đội trong phần lớn thời gian. Tuy vậy, ở một số điểm cụ thể trong kiến trúc, nơi cơ chế tính phí không còn phù hợp với cách hệ thống được dùng, tự vận hành hoặc chuyển sang một dịch vụ khác có thể tiết kiệm đáng kể.

Khi làm Assessment, chúng tôi đưa ra cả hai phía của phép so sánh, bao gồm thời gian vận hành và rủi ro, để đội của bạn có đủ thông tin quyết định. Trong nhiều trường hợp, khuyến nghị của chúng tôi là ở lại và tối ưu ngay trong dịch vụ đang dùng.