2 năm sau khi chuyển từ AWS sang bare metal: giải đáp các câu hỏi về việc rời AWS

 (oneuptime.com)
16 điểm bởi GN⁺ 2025-10-30 | 3 bình luận | Chia sẻ qua WhatsApp
  • Báo cáo tổng hợp các câu trả lời tiếp theo cho nhiều câu hỏi từ cộng đồng sau khi chia sẻ kinh nghiệm chuyển từ AWS sang bare metal và tiết kiệm 230.000 USD mỗi năm cách đây 2 năm. Nhóm cũng công bố dữ liệu vận hành thực tế trong 2 năm và cho biết đã đạt mức tiết kiệm hơn 1,2 triệu USD mỗi năm
  • Qua vận hành thực tế, số tiền tiết kiệm đã tăng lên hơn 1,2 triệu USD mỗi năm, và khoản này được tái đầu tư vào máy chủ phục vụ tóm tắt sự cố bằng AI và tự động sửa mã, qua đó nâng cao chất lượng dịch vụ
  • Dựa trên stack MicroK8s + Ceph, hệ thống duy trì 99,993% khả dụng, đồng thời cấu hình hai datacenter để loại bỏ điểm lỗi đơn
  • Các vấn đề chính như chi phí vận hành thực tế, ứng phó sự cố, tuổi thọ phần cứng, chứng nhận bảo mật, dịch vụ thay thế đám mây được giải thích bằng các số liệu cụ thể
  • Kết quả là cả độ ổn định lẫn hiệu quả chi phí đều được cải thiện, và bài viết đi đến kết luận rằng với các hệ thống có tải thường trực ở một quy mô nhất định thì bare metal hợp lý hơn

Tóm tắt kết quả vận hành trong 2 năm

  • Trong 24 tháng, họ vận hành stack MicroK8s + Ceph trong môi trường production và đạt 99,993% khả dụng
    • Để xử lý vấn đề một rack duy nhất, họ bổ sung rack thứ hai tại Frankfurt và thiết lập kết nối kép DWDM với rack chính ở Paris
    • Nhờ NVMe cục bộ và loại bỏ nhiễu do độ ồn, độ trễ phía khách hàng giảm 19%
  • Chi phí tiết kiệm được được tái đầu tư vào việc mua máy chủ AI bare metal, giúp mở rộng tính năng tóm tắt cảnh báo và tự động sửa mã dựa trên LLM của OneUptime

Hiệu quả tiết kiệm và so sánh chi phí

  • Mức tiết kiệm ban đầu được dự đoán là 230.000 USD/năm, nhưng nay đã tăng lên hơn 1,2 triệu USD
    • Tương đương tiết kiệm khoảng 76% so với AWS
    • Theo mặt bằng chi phí nhân sự toàn cầu, con số này tương đương mức lương năm của 2 đến 5 kỹ sư
  • Ngay cả khi áp dụng Savings Plans / Reserved Instances, bare metal vẫn có lợi hơn
    • Savings Plans không áp dụng cho chi phí S3, egress, Direct Connect
    • Các chi phí như control plane EKS 1.260 USD/tháng hay NAT gateway 600 USD/tháng cũng không thể cắt giảm
    • Với workload steady chạy 24/7, hiệu quả của reserved instance bị hạn chế

Chi phí migration và vận hành

  • Migration ban đầu hoàn tất với khoảng 1 tuần công việc kỹ thuật
    • Phần lớn là các việc vốn đã cần làm từ trước như chỉnh lại IaC, tăng cường chính sách backup
  • Chi phí vận hành hiện tại như sau:
    • Tự quản lý: khoảng 24 giờ mỗi quý (bao gồm vá lỗi và cập nhật firmware)
    • Remote Hands: trong 24 tháng chỉ cần can thiệp 2 lần (chủ yếu do lỗi ổ đĩa), thời gian phản hồi trung bình 27 phút
    • Tự động hóa: PXE boot (Tinkerbell), quản lý image Talos, tự động hóa cấu hình bằng Flux/Terraform
  • So với thời còn ở AWS, đội ngũ vận hành hiện thậm chí còn tăng tốc độ phát hành, đồng thời loại bỏ gánh nặng của các cuộc họp “tối ưu chi phí”

Chuẩn bị cho sự cố và đảm bảo khả dụng

  • Việc bổ sung rack thứ hai tại Frankfurt và kết nối kép DWDM đã loại bỏ điểm lỗi đơn
    • Cấu hình Ceph mirroring dựa trên replication bất đồng bộ cùng với control plane kép
    • Bổ sung đường quản trị dựa trên 4G/vệ tinh để vẫn có thể truy cập từ xa khi sự cố mạng xảy ra
  • Đang chuyển từ MicroK8s → Talos
  • Vẫn duy trì cluster backup failover trên AWS và thực hiện diễn tập khôi phục thảm họa hàng quý
  • Nhờ Ingress dựa trên Anycast + BGP, độ trễ khi chuyển DNS cũng được cải thiện xuống dưới 1 phút
  • Duy trì 99,993% khả dụng trong 2 năm và không bị ảnh hưởng bởi các sự cố region AWS gần đây

Quản lý phần cứng và CapEx

  • Máy chủ được vận hành theo chuẩn khấu hao 5 năm (2×EPYC 9654, 1TB RAM, cấu hình NVMe)
    • Khi hiệu năng bão hòa, máy sẽ được chuyển sang cụm phân tích rồi thay bằng máy chủ mới
    • Nhờ khoản tiết kiệm này, họ có thể refresh 40% hạ tầng mỗi 2 năm mà vẫn tiếp tục tiết kiệm chi phí hàng năm so với AWS
  • Gia hạn bảo hành Supermicro và giữ sẵn 3 máy chủ dự phòng
    • Tuổi thọ thực tế là 7–8 năm, nhưng họ tính toán thận trọng theo mốc 5 năm

Lý do thay thế managed service

  • Triết lý sản phẩm của OneUptime là có thể self-host, nên cần duy trì cùng một stack
    • Giữ tính nhất quán của open stack như Kubernetes, Postgres, Redis, ClickHouse
  • Kiến trúc đã phát triển từ Terraform + EKS + RDS → MicroK8s + Argo Rollouts + Ceph
    • Sử dụng open source thuần túy, không duy trì fork riêng
  • Họ vẫn tiếp tục dùng đám mây song song: AWS Glacier (backup), CloudFront (edge caching), instance tạm thời cho kiểm thử tải
  • Đám mây phù hợp với tính đàn hồi, còn bare metal phù hợp với tải nền tảng cơ bản

Mạng và bảo mật

  • Có 2 đường truyền 5Gbps (95th percentile), rẻ hơn 8 lần so với egress của AWS
  • Phòng vệ DDoS được xử lý bằng cách đặt Cloudflare ở phía trước toàn bộ hệ thống
  • Có mạng quản trị độc lập dựa trên 4G/vệ tinh để có thể truy cập từ xa khi xảy ra sự cố

Tuân thủ và ứng phó kiểm toán

  • Duy trì chứng nhận SOC 2 Type II, ISO 27001
    • Tận dụng tài liệu chứng nhận Tier III, log ra vào, CCTV của trung tâm colocation
    • Sử dụng log cấu hình Terraform/Talos làm bằng chứng lịch sử thay đổi
  • Kiểm toán viên đánh giá họ tin tưởng các tài liệu này hơn cả ảnh chụp màn hình console AWS

So sánh các lựa chọn thay thế đám mây

  • So sánh Hetzner, OVH, Leaseweb, Equinix Metal, AWS Outposts
    • Các hyperscaler vẫn có chi phí egress cao
    • Các nhà cung cấp tại châu Âu khó đáp ứng yêu cầu về cluster Ceph quy mô lớn và SLA
    • Equinix Metal có mức premium 25–30% so với CapEx
    • Vận hành phần cứng tự sở hữu có lợi thế hơn về mật độ điện năng và mức độ tự do nâng cấp
  • Kết quả là nhờ cấu hình rack 15kW và khả năng tái sử dụng linh kiện, colocation vượt trội cả về chi phí lẫn hiệu năng

Đo gánh nặng vận hành (TOIL)

  • Hàng tuần: vá kernel/firmware và kiểm tra Ceph (1 giờ)
  • Hàng tháng: nâng cấp canary cho Kubernetes control plane (2 giờ)
  • Hàng quý: diễn tập DR, lập kế hoạch dung lượng, rà soát hợp đồng nhà mạng (12 giờ)
  • Tổng cộng khoảng 14 giờ mỗi tháng, tương đương thời ở AWS, nhưng trọng tâm đã chuyển từ “theo dõi chi phí” sang “tự động hóa vận hành”

Những trường hợp đám mây vẫn phù hợp

  • Khi workload có kiểu tăng vọt hoặc mang tính mùa vụ
  • Khi phụ thuộc nhiều vào managed service như Aurora Serverless, Kinesis, Step Functions
  • Khi không có đủ năng lực để tự vận hành Kubernetes, Ceph, monitoring, ứng phó sự cố
  • Nói cách khác, với doanh nghiệp ở giai đoạn đầu hoặc có tải biến động lớn, đám mây vẫn có ưu thế

Kế hoạch sắp tới

  • Dự kiến công bố module Terraform và runbook để dự báo ngân sách colo
  • Cũng đang chuẩn bị một bài viết kỹ thuật chuyên sâu về kinh nghiệm vận hành với Talos
  • Sẽ tiếp tục phản hồi feedback trên HN·Reddit và chia sẻ các trường hợp thực tế dựa trên số liệu cụ thể

Bài viết liên quan

3 bình luận

 
okxrr 2025-10-30

Tôi đang làm ở một công ty rất nhiệt tình dùng AWS dù hoàn toàn không sử dụng bất kỳ dịch vụ nào chỉ có AWS mới cung cấp.

Một câu chuyện vừa buồn cười vừa chua chát khi tôi thấy quyết định này bị chi phối rất nhiều bởi tham vọng rất cá nhân là phát triển sự nghiệp của một vài lãnh đạo..
 
GN⁺ 2025-10-30
Ý kiến trên Hacker News

  • AWS quá đắt. Thực ra hiếm khi có lý do để đặt toàn bộ hệ thống lên AWS. Trước đây ai cũng biết tự vận hành máy chủ bare metal, nhưng giờ có vẻ đã quên mất điều đó. Đội của chúng tôi đã duy trì 99,993% khả dụng trong hơn 730 ngày và cũng tránh được đợt sự cố khu vực AWS gần đây. Dù có dùng Cloudflare để chống DDoS, tôi vẫn hiểu vì sao quản lý DNS hay ingress có thể trở thành công việc toàn thời gian. Nhưng với vài microservice và một cơ sở dữ liệu thì tự vận hành vẫn là quá đủ. AWS đang tính phí quá mức với đa số công ty

    • Vấn đề thực sự của AWS là sự phụ thuộc của nhân sự vào AWS. Khi mọi người đi lấy chứng chỉ AWS và sống trong bầu không khí phải tuân theo AWS Well-Architected Framework, họ dần ngừng tự suy nghĩ. Các dịch vụ lock-in của AWS được định giá để trông như rẻ hơn có chủ đích, nhưng cuối cùng chỉ khiến bạn bị trói sâu hơn. Ví dụ, chuyển từ PostgreSQL sang DynamoDB có thể trông như tiết kiệm trong ngắn hạn, nhưng về dài hạn lại làm tăng mức độ phụ thuộc vào AWS
    • On-premise rẻ hơn, nhưng khó tìm được nhân sự chuyên môn. Nó hợp với sản phẩm đơn giản, nhưng với hệ thống phức tạp thì chi phí nhân sự và rủi ro vận hành có khi còn lớn hơn. AWS/Azure/GCP không hoàn hảo, nhưng giờ chuyên gia on-premise quá hiếm
    • Mỗi khi chỉ trích AWS lại có rất nhiều người phản ứng một cách kỳ lạ. Trên Reddit cũng có hiện tượng tương tự. Cảm giác như có ai đó đang được trả tiền để bảo vệ AWS vậy
    • Các câu chuyện thành công với self-hosting có thiên lệch xác nhận. Ban đầu tự vận hành máy chủ có vẻ ổn, nhưng sau khoảng 1 năm thì tài liệu và cấu hình thực tế bắt đầu lệch nhau, rồi khi người phụ trách nghỉ việc thì hỗn loạn tăng mạnh. Cuối cùng nhiều startup lại quay về AWS. Những câu chuyện thất bại kiểu này hiếm khi được chia sẻ
    • Để vận hành bare metal tốt thì cần kỹ sư dày dạn kinh nghiệm. Người mới vào nghề hay các “chuyên gia cloud” xuất thân từ công ty tư vấn thì rất khó làm được

  • Cloud thời kỳ đầu bắt đầu như một dịch vụ đơn giản và đáng tiền, nhưng giờ đã rối tung với hơn 200 dịch vụ phức tạp. Không quản lý kỹ thì hóa đơn sẽ bùng nổ

    • Thực ra ngay từ đầu AWS chưa bao giờ lấy “rẻ” làm trọng tâm, mà là “có thể mở rộng rất nhanh”. Đầu những năm 2010 nó đã đắt rồi, nhưng điểm mạnh là tính linh hoạt. Ngay cả bây giờ, giá trên hiệu năng vẫn còn đắt. Chỉ cần nắm vững cơ bản về quản trị máy chủ thì máy chủ dedicated vẫn tốt hơn rất nhiều
    • AWS giờ đã phình to quá mức với hơn 200 dịch vụ. Họ nên tập trung vào các chức năng cốt lõi
    • Mỗi lần mở AWS Console là lại bị cảm giác phức tạp và mệt mỏi ập tới. Nó đã trở nên quá đồ sộ
    • Mỗi dịch vụ AWS có mức độ đáng tiền rất khác nhau. Đặc biệt, các dịch vụ lõi cũ hơn vẫn còn nhiều giá trị

  • Chức năng thực sự của AWS là (1) cho phép mở rộng tổ chức và cấu trúc quyền lực, (2) giúp hạch toán dưới dạng OpEx thay vì CapEx, (3) che giấu các cấu trúc nhân sự kém hiệu quả. Trước đây có thể vận hành trung tâm dữ liệu với 5–10 người, còn giờ lại sinh ra các tổ chức DevOps 3.000 người

    • Tôi không hiểu vì sao khác biệt giữa OpEx và CapEx lại quan trọng đến vậy. Cuối cùng tiền vẫn là tiền mà?
    • Cloud hữu ích cho startup giai đoạn đầu. Có thể tăng trưởng nhanh mà không phải lo hoạch định năng lực. Nhưng với các công ty có tốc độ tăng trưởng thấp mà vẫn tiếp tục ở trên cloud thì lại kém hiệu quả
    • On-premise thường bị tùy biến quá sâu nên rất khó thay người. Trong khi đó nhân sự AWS thì ở đâu cũng tuyển được
    • Quản trị viên hệ thống giỏi thực sự khó tìm và đắt đỏ. Tôi từng thấy có nơi cố làm cho rẻ rồi thành ra 2 năm liền không có backup hoạt động

  • Cốt lõi của thành công này là mức tải ổn định 24/7. Thực ra phần lớn công ty cũng có mô hình tương tự

    • Thực tế việc bắt đầu từ một rack duy nhất, một trung tâm dữ liệu duy nhất là khá may mắn. Họ đã không phải trả trước chi phí cho độ tin cậy
    • Bài liên quan: One Big Server
    • AWS thường nói là “hết hàng” rồi ép khách dùng reserved instance. Cuối cùng chi phí cũng gần như vận hành liên tục thôi
    • Những nơi như Hetzner cung cấp cùng hiệu năng với giá rẻ hơn AWS 10 lần. “Tính đàn hồi” của cloud là một huyền thoại bị thổi phồng

  • Điểm mấu chốt là tính đàn hồi so với tải nền. Chỉ khi lưu lượng tăng bùng nổ, như trong các hệ thống thu thập dữ liệu, thì cloud mới có lợi. Còn trong đa số trường hợp thì bare metal tốt hơn

  • Trong thập niên 2010, phần cứng và mạng còn chậm, nhưng giờ hiệu năng và hiệu suất CPU đã tăng lên hàng trăm lần. Trước đây cần 64 máy chủ thì giờ 1 máy là đủ. Sau này tỷ lệ đó có thể lên tới 100:1. Trong bối cảnh này, lợi thế của cloud ngày càng giảm

  • Với tư cách là nhân viên Amazon, tôi thấy việc tự quản Kubernetes quá rủi ro. Những thành phần như etcd không ổn định và chúng tôi còn phải tự vá lỗi. Việc self-hosting được nói tới trong bài đã đánh giá thấp rủi ro

    • Ở các hyperscaler khác cũng từng có sự cố lớn vì quản lý Kubernetes thất bại. Những lựa chọn đơn giản hơn cho một rack đơn như Microk8s sẽ tốt hơn. Bài liên quan: Microk8s 6 Months Later
    • Môi trường phức tạp thì ở đâu cũng khó, và cuối cùng vẫn cần chuyên gia. AWS cũng không dễ hơn bao nhiêu. Ngay cả khi cloud gặp sự cố thì thế giới vẫn tiếp tục vận hành
    • Các bản nhẹ như k3 đơn giản hơn nhiều
    • Chỉ nên dùng Kubernetes khi thật sự cần. Dùng nó làm mặc định chỉ tốn thời gian và tiền bạc

  • Nhiều startup có lẽ đã không thể tồn tại chỉ vì hóa đơn AWS quá đắt. Ví dụ như tải GeoIP miễn phí (liên kết) có lẽ đã không thể làm được. Cloud chậm, và độ trễ đĩa cùng tình trạng CPU bị nhồi quá mức rất nghiêm trọng. Dưới 10.000 USD/tháng thì còn chấp nhận được, nhưng vượt mức đó thì bare metal hiệu quả hơn nhiều

    • Việc quen với hiệu năng chậm của cloud tạo ra một kiểu thích nghi kỳ lạ. Lúc nào cũng nên so sánh với chuẩn bare metal

  • Công ty tôi từng làm cũng có ít lưu lượng, nhưng vẫn định chuyển sang AWS. Lý do rất đơn giản — họ muốn thêm AWS vào CV. Không chỉ lập trình viên mà cả quản lý cũng vậy. “AWS migration lead” trông đẹp trên hồ sơ sự nghiệp. Cuối cùng công ty bị bán đi và văn phòng trống trơn. Có khi sau này “thoát khỏi AWS” lại trở thành một điểm cộng nghề nghiệp mới

    • Nếu lập trình viên muốn AWS, thì thế hệ tiếp theo sẽ chỉ biết mỗi AWS. Cuộc thảo luận sẽ bị lệch hướng
    • Cuối cùng quyết định vẫn phụ thuộc vào ý chí của ban lãnh đạo

  • Cuối cùng điều quan trọng là bạn đang muốn làm gì

    • Nếu là website nội bộ thiên về dữ liệu thì một rack máy chủ là đủ
    • Nếu là lưu lượng lớn, thất thường và không thể cache thì cloud có lợi hơn
    • Nếu DNS hay ingress phức tạp thì cách tiếp cận hybrid sẽ tốt hơn
    • Quy mô dữ liệu càng lớn thì cấu trúc khấu hao dài hạn của cloud càng có lợi