Năm 2023, vinh quang chỉ cách 11MB/giây

Sự thật về chi phí đám mây

• Có nhận thức rằng dịch vụ đám mây là rẻ, nhưng trên thực tế người dùng có thể đang trả chi phí quá mức.
• AWS tạo ra phần lớn lợi nhuận của Amazon, nhưng điều đó có thể đồng nghĩa rằng dịch vụ đám mây thực sự đắt đỏ.

Tính toán từ những nguyên lý đầu tiên

• Nếu muốn xây dựng một website thuộc top 1000, chẳng hạn như businessinsider.com, thì cần khoảng 200M lượt truy cập mỗi tháng và 400M lượt xem trang.
• Chỉ riêng tài liệu HTML cũng cần 30TB băng thông mỗi tháng, nhưng con số đó chỉ tương đương 11MB/giây, một mức rất thấp đối với phần cứng hiện đại.

Hiểu về độ trễ

• Xét theo tốc độ ánh sáng, một chuyến khứ hồi đến phía đối diện của Trái Đất cần khoảng 200ms, nhưng trên thực tế mất khoảng 300ms.
• Nếu dùng CDN để phân phối JS, CSS và media, có thể cắt giảm 300ms thời gian xử lý phía máy chủ, tạo ra hiệu quả tương tự như đặt máy chủ ngay cạnh người dùng.

Giới hạn của công nghệ edge

• Công nghệ edge, dù đã có những tiến bộ của thế hệ serverless thứ hai, vẫn không giải quyết được bài toán cơ sở dữ liệu.
• Hầu hết các trang phức tạp đều cần truy vấn cơ sở dữ liệu, và điều này có thể làm tăng độ trễ.

Cân nhắc về chi phí

• Hetzner.com cung cấp chi phí máy chủ và băng thông rẻ hơn rất nhiều so với AWS EC2.
• Các nhà cung cấp đám mây ban đầu cho rất nhiều thứ miễn phí, nhưng khi mở rộng thì chi phí tăng mạnh.

Tình hình thực tế

• Trừ những trường hợp sử dụng đặc biệt, phần lớn website hoặc SaaS có thể chạy trên một máy chủ duy nhất, rẻ hơn và dễ bảo trì hơn.
• Có thể dùng SQLite cục bộ, cache CSS, JS và hình ảnh qua CDN, đồng thời cải thiện hiệu năng bằng render phía máy chủ.
• Ngay cả khi không có Docker hay ảo hóa phức tạp, hệ thống vẫn có thể mở rộng đủ tốt, đồng thời dễ quản lý và tiết kiệm chi phí hơn.

Ý kiến của GN⁺

• Bài viết này thách thức niềm tin phổ biến về hiệu quả chi phí của dịch vụ đám mây, và chỉ ra rằng người dùng có thể đang trả nhiều hơn nhu cầu thực tế.
• Khi so sánh với cấu trúc chi phí của dịch vụ đám mây, bài viết cho thấy mô hình hosting máy chủ đơn truyền thống vẫn có thể là một lựa chọn thay thế hiệu quả.
• Bài viết nhấn mạnh rằng các công nghệ như serverless, Docker hay khả năng mở rộng theo chiều ngang không phải lúc nào cũng cần thiết; đôi khi cách tiếp cận đơn giản hơn lại mang đến hiệu năng tốt hơn và tiết kiệm chi phí hơn.
• Bài viết nhấn mạnh tầm quan trọng của tối ưu hóa cơ sở dữ liệu và triển khai theo khu vực, cho thấy có thể đạt được hiệu năng tương đương hoặc tốt hơn so với những gì dịch vụ đám mây cung cấp.
• Khi lựa chọn công nghệ, cần đánh giá lưu lượng truy cập và yêu cầu hiệu năng thực tế, đồng thời cân nhắc hiệu quả chi phí để xem xét hosting máy chủ truyền thống thay vì đám mây.

[GN⁺]

Ý kiến trên Hacker News

• Kinh nghiệm trong lĩnh vực kinh doanh hosting

  • Trước đây, trong mảng hosting, công ty đã cung cấp các hệ thống phức tạp theo yêu cầu của khách hàng.
  • Để cạnh tranh với AWS, họ đã phát triển một nền tảng cloud hosting dựa trên API, nhưng doanh thu đạt đỉnh vào năm 2012.
  • Khách hàng muốn các giải pháp phức tạp hơn dựa trên AWS và không tin tưởng vào các máy chủ đơn giản.
  • Công ty được vận hành theo kiểu bootstrap và đã không hiểu được sự cần thiết phải chấp nhận rủi ro chi phí của AWS.
  • AWS được ưa chuộng vì thứ "sự khéo léo" đã ăn sâu vào cả một thế hệ lập trình viên phần mềm.

• Sai lầm trong phân tích lưu lượng truy cập

  • Lưu lượng truy cập không phân bố đồng đều, và nhu cầu băng thông vào giờ cao điểm cao hơn rất nhiều so với mức trung bình.
  • Trong dịch vụ thực tế, việc thiết lập kết nối TCP và TLS cần nhiều vòng khứ hồi, và thời gian phản hồi ảnh hưởng đến trải nghiệm người dùng là rất quan trọng.

• Lỗi máy chủ và lưu lượng truy cập

  • 500 Internal Server Error cho thấy máy chủ đang phải xử lý nhiều lưu lượng hơn dự kiến.

• Cách tiếp cận với việc mở rộng dịch vụ

  • Nên tránh mở rộng không cần thiết và chỉ xây dựng khi thực sự cần.
  • Khi phát sinh vấn đề về hiệu năng thì lúc đó xử lý sẽ tốt hơn.

• Lợi thế của AWS

  • Dùng AWS sẽ tạo ra một cái cớ khi dịch vụ gặp sự cố.

• Thảo luận về kiến trúc cloud

  • Đây không phải là cuộc tranh luận về việc kiến trúc cloud có cần thiết hay không, mà là một cách để đưa ra phương án thay thế.
  • Vấn đề về tính sẵn sàng khi máy chủ bị sập có thể được giải quyết theo những cách khác.

• SQLite và mở rộng theo chiều dọc

  • Thay vì SQLite, có thể dùng Postgres tự host, nhưng việc này đòi hỏi nhiều công sức thiết lập hơn.
  • Có thể xây dựng một kiến trúc giữ toàn bộ trạng thái toàn cục trong bộ nhớ và lưu snapshot xuống đĩa.

• Kết hợp API và cơ sở dữ liệu SQLite

  • SQLite có thể xử lý nhiều truy vấn trên một luồng đơn.
  • Có thể dùng cache trong bộ nhớ ở phía API và bỏ qua cơ sở dữ liệu đối với các trang tĩnh để cải thiện hiệu năng.

• Vấn đề tính sẵn sàng của máy chủ đơn

  • Vận hành dịch vụ trên một máy chủ đơn có thể dẫn đến downtime ngoài kế hoạch.
  • Cần cân nhắc thời gian khôi phục dữ liệu và lượng dữ liệu có thể bị mất.

• Việc chuyển sang cloud và tính sẵn sàng

  • Việc chuyển sang cloud thường mang lại cảm giác như áp lực từ đồng nghiệp.
  • Xét về tính sẵn sàng, một máy chủ đơn có thể là rủi ro, và tốt hơn nên kết hợp CDN với cloud một cách khôn ngoan.