Năm 2023, vinh quang chỉ cách 11MB/giây
(thmsmlr.com)- Ngay cả một website thuộc top 1000 với khoảng 200 triệu lượt truy cập mỗi tháng, nếu chỉ xét HTML thì cũng chỉ cần khoảng 30TB/tháng, tương đương lưu lượng truyền trung bình 11MB/giây, mức mà một máy chủ đơn lẻ có thể đảm đương
- Phép tính bắt đầu từ Business Insider, với giả định mỗi khách truy cập xem 2 trang, tổng cộng 400 triệu tài liệu HTML mỗi tháng, HTML nén khoảng 75KB, còn JS, CSS và hình ảnh được giao cho CDN
- Chạy ở edge có lợi thế là máy chủ gần người dùng, nhưng nếu trong lúc render phát sinh vòng khứ hồi tới cơ sở dữ liệu, độ trễ sẽ lại bị kéo về vị trí của DB gốc
- Chênh lệch chi phí cũng lớn: Hetzner cung cấp máy chủ 16 core, 64GB RAM, NVMe với giá $0.34/giờ, miễn phí 20TB truyền tải rồi tính $1.5/TB, trong khi AWS và Vercel có đơn giá băng thông cao hơn nhiều
- Nếu không phải tác vụ đặc biệt cần cloud, cấu hình một máy chủ + SQLite + Litestream + CDN đơn giản và rẻ hơn, đồng thời tránh mở rộng ngang không cần thiết
Quy mô thực tế của website top đầu nhìn từ 11MB/giây
- Sử dụng Business Insider làm ví dụ cho một website thuộc top 1000
- Theo SimilarWeb, website này đứng thứ 587 toàn cầu và có khoảng 200 triệu khách truy cập mỗi tháng
- Nếu mỗi khách truy cập xem trung bình 2 trang, cần phục vụ 400 triệu tài liệu HTML mỗi tháng
- Theo một bài viết mẫu, tài liệu HTML chuẩn sau khi nén có dung lượng khoảng 75KB
- Nhân lên, chỉ riêng HTML cần khoảng 30TB/tháng băng thông
- 30TB/tháng khi quy đổi trung bình là khoảng 11MB/giây
- Trong trường hợp Business Insider, mức này tương đương khoảng 150 requests/sec
- Đây là giả định không dùng CDN cho HTML, còn JS, CSS và hình ảnh có thể được phục vụ qua CDN
- HTML nén 75KB là khá lớn, nên tùy cách triển khai có thể điều chỉnh bằng cách giảm kích thước HTML hoặc tăng số request
- Với phần cứng hiện đại, việc mã ứng dụng tạo ra 11MB/giây HTML là một ngưỡng thấp
- Bộ xử lý máy chủ AMD mới nhất cung cấp 64 core và 128 thread
- Bộ xử lý máy chủ Zen 5 Turin được đồn là có 192 core; với máy chủ dual-socket, còn có cấu hình gần 400 core và tới 768 thread được nhắc đến
- Nhìn từ góc độ này, Docker, serverless và mở rộng ngang không phải lúc nào cũng là lựa chọn cần thiết
Chạy ở edge không phải lúc nào cũng giảm độ trễ
- Giới hạn vật lý tối thiểu của độ trễ khứ hồi tới phía bên kia Trái Đất, tính theo tốc độ ánh sáng, là khoảng 200ms
- Trên thực tế, tới một data center tốt ở phía bên kia Trái Đất thường mất khoảng 300ms
- Nếu JS, CSS và media được phục vụ qua CDN, chỉ cần giảm 300ms thời gian xử lý của máy chủ trong lần render ban đầu cũng tạo hiệu ứng tương tự việc đưa máy chủ lại gần người dùng
- Công nghệ serverless thế hệ thứ hai đã giảm đáng kể vấn đề trước đây khi cold boot dễ dàng ngốn hết ngân sách độ trễ 300ms, nhưng vòng khứ hồi tới cơ sở dữ liệu vẫn còn
- Nếu việc render trang cần dù chỉ một truy vấn cơ sở dữ liệu, edge server vẫn phải khứ hồi về nơi đặt cơ sở dữ liệu gốc, chẳng hạn us-east-1
- Độ trễ được chuyển từ giữa người dùng và máy chủ gốc sang giữa edge server và máy chủ gốc
- Các trang phức tạp thường cần từ 5 truy vấn cơ sở dữ liệu trở lên để render
- Nhiều web framework chạy truy vấn tuần tự theo kiểu single-thread, nên nếu phát sinh nhiều lần khứ hồi giữa các data center, kết quả có thể chậm hơn cả việc đi thẳng một lần tới origin
- Có một quy tắc kinh nghiệm rằng giao tiếp giữa các data center chậm hơn giao tiếp trong cùng data center 10 lần, và giao tiếp trong cùng data center chậm hơn giao tiếp trong cùng một thiết bị 10 lần
- Trong bối cảnh này, SQLite cục bộ trở thành một lựa chọn có lợi để giảm độ trễ
Chênh lệch chi phí giữa Hetzner, AWS và Vercel
- Máy chủ 16 core của Hetzner có 64GB RAM và ổ NVMe, giá $0.34/giờ
- AWS EC2 m5a.4xlarge, một máy chủ x86 tương tự được đem ra so sánh, có giá $0.68/giờ
- Chênh lệch giá băng thông còn lớn hơn
- Hetzner miễn phí 20TB truyền tải và sau đó tính $1.5/TB
- AWS miễn phí 100GB và sau đó tính $90/TB
- Vercel được nhắc đến như ví dụ tính $200/TB sau 1TB đầu tiên miễn phí
- Hạn mức miễn phí của các nhà cung cấp cloud giúp việc bắt đầu dễ dàng, nhưng khi quy mô tăng lên có thể quay lại thành chi phí cao
Vận hành đơn giản với cấu hình một máy chủ
- Nếu không có các trường hợp sử dụng cloud cụ thể như transcoding video, chạy mô hình AI riêng, hoặc các tác vụ thực sự tạo tải lớn cho hệ thống, website hay SaaS có thể chạy trên một máy chủ
- Đặt máy chủ ở Virginia có thể cung cấp độ trễ dưới 100ms cho người dùng nói tiếng Anh
- Cấu hình khuyến nghị xoay quanh một máy chủ duy nhất và giữ mọi thứ đơn giản
- Cơ sở dữ liệu dùng SQLite trên cùng máy
- Sao lưu SQLite liên tục bằng Litestream
- Cache CSS, JS và hình ảnh bằng CDN
- Render phía máy chủ ở gần SQLite để giảm vòng khứ hồi và tăng hiệu năng
- Việc triển khai cũng không cần làm phức tạp
- CI chỉ cần SCP mã lên máy chủ
- NGINX hỗ trợ triển khai không downtime
- Docker và ảo hóa được xem là các yếu tố làm chậm việc chạy mã và CI/CD
Khi nào cần và không cần mở rộng ngang
- Những câu chuyện cho rằng cần mở rộng ngang trong đa số trường hợp là phóng đại
- Tiền đề là hiệu năng máy chủ đang cải thiện nhanh hơn tốc độ tăng trưởng của Internet
- Nếu độ trễ thực sự quan trọng, có thể thêm máy chủ ở Đức và California
- Ghi được route về primary
- Đọc sử dụng read replica cục bộ
- Cấu hình như vậy có thể mở rộng đủ tốt, ít phức tạp trong quản lý và chi phí cũng khá rẻ
- Việc phục vụ HTML ở quy mô 11MB/giây không cần phải bị làm cho khó một cách không cần thiết
1 bình luận
Ý kiến trên Hacker News
Doanh nghiệp hosting nhỏ ngày xưa của tôi đã thăng trầm đúng ở điểm này, mà khi đó tôi không hiểu chuyện gì đang xảy ra
Khi tăng trưởng vào đầu những năm 2000, doanh thu lớn thường đến từ các stack phức tạp, với nhiều cấu hình thực ra vượt quá nhu cầu của khách hàng như load balancer và firewall dự phòng, nhưng khách hàng lại muốn như vậy
Failover thường có chi phí phức tạp vận hành lớn hơn lợi ích thu được khi máy chủ chết theo cách dự kiến; chúng tôi cũng đã làm một nền tảng cloud hosting dựa trên API để cạnh tranh với AWS, 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ùng một phần hoặc toàn bộ AWS, còn chúng tôi thì nghĩ rằng phần cứng đã mạnh hơn rất nhiều so với 10 năm trước nên ngay cả khách hàng lớn cũng sẽ muốn ít máy chủ hơn và đơn giản hơn
Nhưng đó không phải là bán sự thông minh, mà là bán giá rẻ; chúng tôi đã không hiểu tham vọng tài chính cần có cho một sự chuyển hướng như vậy. Không ai tin một máy chủ đơn lẻ giá rẻ, và ngay cả mua hai máy thì vẫn thiếu câu trả lời về khả năng mở rộng
Cuối cùng doanh thu vẫn trụ được, nhưng chúng tôi không thể xây dựng stack dịch vụ quản lý và hệ sinh thái phần mềm nhanh hơn Amazon; sau khi các thử thách kỹ thuật mới cạn dần, tôi đã bán công ty vào năm 2018
Vì lớn lên theo kiểu bootstrap nên hóa đơn hosting không giới hạn trông như một rủi ro điên rồ, và thiết kế sản phẩm cũng xuất phát từ lối nghĩ đó; chỉ về sau tôi mới thấy mọi người đều đang chấp nhận rủi ro ấy
Lý do AWS bám rễ không chỉ là vì VC khiến các sản phẩm đắt đỏ trở nên khả thi, mà còn vì kiểu thông minh đặc trưng của họ đã được cài vào cả một thế hệ lập trình viên phần mềm. Tuy vậy, cảm giác là kiến thức về khi nào không cần cloud và có lựa chọn thay thế nào giờ đã trở thành khá ngách
Có vài vấn đề với các con số
Thứ nhất, lưu lượng không phân bố đều. Con số 400 triệu lượt tải trang/tháng trong bài có thể chịu quy luật 80/20 đệ quy; nếu nhìn như vậy thì khoảng 205 triệu request sẽ dồn vào 5,8 giờ, tương đương khoảng 9,7 nghìn request mỗi giây
Một hệ thống đơn lẻ vẫn có thể làm được, nhưng không còn là chuyện nhỏ nữa, đặc biệt nếu còn muốn một DB đơn lẻ không có read replica. Dù tổng lưu lượng như nhau, giới hạn băng thông cần cho tải đỉnh sẽ cao hơn rất nhiều so với mức 11MB/s được tính trung bình một cách lạc quan
Thứ hai, độ trễ end-to-end một chiều chỉ áp dụng cho dữ liệu streaming. Trong cold start thực tế, nếu không có HTTP/3 thì cần 3 lượt khứ hồi cho kết nối TCP và ít nhất 2 lượt cho kết nối TLS, rồi sau đó mới đến HTTP request và response
Để phục vụ con người thật, mọi thứ quan sát được phải diễn ra trong dưới 1 giây; sau mốc đó, tỷ lệ người dùng cho rằng hệ thống bị hỏng và đóng tab tăng vọt
Trước đây tôi từng hỗ trợ vận hành một sàn giao dịch cá cược, lưu lượng tăng vọt cực đoan và yêu cầu độ trễ rất khắt khe; khối lượng giao dịch tập trung vào một phần rất nhỏ của toàn bộ cửa sổ sự kiện. Với giao dịch thời gian thực, kết quả phải hiện lên màn hình trong vòng 100ms kể từ lúc người dùng bắt đầu hành động, và độ trễ khứ hồi mạng đã ăn mòn ngân sách xử lý sự kiện
Tham khảo: https://www.nngroup.com/articles/response-times-3-important-...
Tải như vậy vẫn có thể xử lý bằng một cấu hình máy chủ đơn lẻ lớn, nhưng lúc này bạn không còn làm một web server đơn giản nữa, mà gần như đang làm một frontend load balancer khá mạnh có web server tích hợp
AWS có thu phí đắt, nhưng load balancer và hạ tầng mạng của họ chứa lượng kỹ thuật khổng lồ, nhờ đó phần còn lại của chúng ta không cần trở thành chuyên gia của toàn bộ mảng stack đó
Thực sự có bao nhiêu dịch vụ cần khả năng tiếp cận toàn cầu? Bạn có làm cả hỗ trợ đa ngôn ngữ không?
Nếu phục vụ trong phạm vi Mỹ hoặc EU, một máy chủ trung tâm đủ tốt cũng có thể đem lại độ trễ dưới 30ms cho toàn bộ khu vực đó
Edge khá bị thổi phồng, trừ khi bạn có nhu cầu toàn cầu thật sự và còn phải quản lý cả cơ sở dữ liệu toàn cầu
Thấy hiện
500 Internal Server Errorthì có vẻ tác giả đang nhận nhiều lưu lượng hơn 11MB/s. Bản lưu trữ ở đây: https://archive.is/UVpg0PR_END_OF_FILE_ERROR. Nhiều website nói lỗi này do proxy, VPN, DNS-over-HTTPS, nhưng trường hợp của tôi thì không phảiTôi nghĩ bài này nhìn sai hướng
Cách tiếp cận tốt hơn là đừng mở rộng quá sớm
Cứ xây theo mức cần thiết là được, và trong đa số trường hợp ngay cả CDN cũng là chi phí không cần thiết. Tất nhiên với điều kiện là không phải trả khoản thuế băng thông quá đáng của nhà cung cấp cloud
Khi vấn đề hiệu năng bắt đầu xuất hiện thì xử lý lúc đó; nếu con ngựa thồ bình thường đột nhiên trở thành kỳ lân ai cũng thèm muốn, thì đó là kiểu vấn đề đáng có
Nếu sản phẩm ổn, người dùng sẽ thử lại sau một giờ chứ không chuyển ngay sang đối thủ. Khi có vấn đề về khả năng mở rộng, chỉ cần chuyển các phần ngốn tài nguyên sang mô hình hybrid có thể mở rộng
Còn nếu bạn vẫn muốn web-scale ngay từ đầu, hàng chục microservice, các trạng thái lỗi bùng nổ giữa chúng, và đốt tiền VC bằng hóa đơn AWS trước cả khách hàng đầu tiên, thì cứ tùy ý
Tự vận hành máy chủ vật lý là chuyện sau này, không phải vấn đề bây giờ. Đến lúc phải chọn giữa hóa đơn AWS 1 triệu đô và một máy chủ đơn lẻ cỡ lớn, hẳn tôi sẽ không quyết định dựa trên một bài blog mà sẽ tự chạy kiểm thử
Dùng AWS cũng có nghĩa là mua kèm một vật tế thần. Một sự cố lớn của dịch vụ cloud rất dễ giải thích với sếp hoặc nhà đầu tư, nhưng sẽ khó hơn nhiều nếu phải giải thích rằng cùng mức downtime tích lũy đó là do lỗi con người trong đội
Vậy tôi tò mò cách diễn giải cloud là vật tế thần khớp với điều đó như thế nào
Nếu nhắm tới mở rộng theo chiều dọc thì tại sao lại là SQLite? Không có gì ngăn việc chạy Postgres tự host hoặc Supabase cùng với ứng dụng trên cùng một máy chủ, và ngoài việc tốn thêm công cấu hình thì cũng khó nghĩ ra nhược điểm nào
Nếu đi theo hướng không dùng DB, đặt toàn bộ trạng thái toàn cục trong bộ nhớ thực của một máy chủ lớn, giữ nó dưới dạng đối tượng nội bộ trong tiến trình mà không cần lượt đi-về Redis, thỉnh thoảng snapshot bộ nhớ xuống đĩa, và dùng một ngôn ngữ đa luồng có biên dịch, thì có thể làm bão hòa NIC trên 1Gbit và phục vụ cả thế giới từ một máy duy nhất
Tôi cũng ước có một trường hợp thực tế để dùng kiểu kiến trúc như vậy
Ngoài các mẫu lưu trữ quan hệ tiêu chuẩn thì khác biệt về tính năng có thể lớn đến mức Postgres phù hợp hơn, nhưng trong một số mẫu kiến trúc, SQLite cũng có thể vượt trội
Với các ứng dụng lấy nội dung làm trung tâm như BusinessInsider, mẫu Baked Data dựa trên SQLite có thể tốt hơn về chi phí và độ trễ
simonw(datasette) đã tạo nhiều công cụ và bài viết về việc dùng SQLite trong môi trường production cho các website lấy nội dung làm trung tâm hoặc giàu dữ liệu: https://simonwillison.net/2021/Jul/28/baked-data/
SQLite chạy trong cùng tiến trình và không cần tuần tự hóa, nên điều đó hợp lý. Nó còn có thêm lợi thế là có thể xử lý các thao tác theo kiểu tuần tự, khiến việc kiểm thử, suy luận và xây dựng tầng cache dễ hơn nhiều
Nếu không dùng Unix socket thì cũng có overhead mạng, nhưng vì đã nói là cùng một máy chủ nên tôi chỉ xem đó là điểm phụ. Trên thực tế, việc đặt Postgres trên một máy khác để cách ly là rất phổ biến, và đó cũng là một trong những lợi thế chính của DB qua mạng
Nó có đủ các tính năng cần thiết, đồng thời đơn giản và nhanh hơn. SQLite có thể xử lý dữ liệu cấp terabyte, nhiều lượt đọc, backup streaming thời gian thực, và nhìn chung là một triển khai SQL khá cân bằng
Có lẽ tôi chỉ cân nhắc Postgres/MySQL khi vượt quá khả năng mở rộng theo chiều dọc của một máy đơn
https://blog.cloudflare.com/introducing-d1
Có vẻ nhiều người thấy tác giả tập trung vào độ trễ, băng thông và chi phí nên cảm thấy cần bảo vệ hiện trạng bằng lý do tính sẵn sàng và độ tin cậy
Kết luận của tôi không phải là phủ nhận lợi ích của cloud trước các đánh đổi, mà là đặt câu hỏi liệu các mẫu kiến trúc cloud hiện có ở khắp nơi cùng những phụ thuộc đi kèm có thật sự bắt buộc hay không
Sự đối lập cái này với cái kia chỉ là một thủ pháp tu từ để giới thiệu lựa chọn thay thế, còn giải pháp nào đúng thì phụ thuộc vào vô số yếu tố theo từng mục đích sử dụng. Chính những yếu tố đó cũng là lý do kỹ sư có việc làm
Tuy vậy, ngay trong mẫu mà tác giả đề xuất cũng có thể xử lý các lo ngại của SRE. Câu “nếu một máy chủ chết thì tính sẵn sàng tính sao?” gần như là công kích người rơm, vì có thể giải quyết tính sẵn sàng theo cách khác với các hệ thống chúng ta quen thuộc, và giải pháp phải phù hợp với những gì thật sự quan trọng
Có một cách để chỉ thêm một bước với ngân sách tiết kiệm mà nhận được nhiều hơn rất nhiều: đặt API và DB SQLite cùng nhau
Lý tưởng nhất là API dùng định dạng tuần tự hóa nhị phân overhead thấp và kết nối duy trì, còn phần phục vụ web thì tận dụng gói miễn phí của các dịch vụ edge được VC hậu thuẫn đang đốt tiền. Hiện Cloudflare Workers khá hào phóng và traffic outbound cũng miễn phí
Điểm cốt lõi là SQLite có thể xử lý số lượng truy vấn mỗi giây khổng lồ ngay cả với một luồng. Có thể đẩy nhiều thao tác vào xử lý tuần tự nên dễ suy luận, và việc cache trong bộ nhớ phía API cùng invalidation cũng đơn giản hơn
Nếu tách riêng việc phục vụ web, ta có thể hưởng hiệu năng edge cho handshake và bỏ qua DB hoàn toàn với các trang tĩnh. Bài viết đã đánh giá thấp vấn đề thời gian đi-về; các ứng dụng thực tế cần nhiều lượt đi-về hơn tưởng tượng, nên đây là vấn đề khá thực tế
Phần lớn CPU dùng ngoài DB đến từ parsing, giải tuần tự hóa, sao chép dữ liệu và TLS, nên nếu bỏ bớt một mảng lớn, ngay cả máy phổ thông cũng dễ đạt hàng chục nghìn lượt ghi mỗi giây, còn đọc thì nhanh hơn nữa
Dù vậy, các nút thắt cổ chai điển hình, đặc biệt là I/O, luôn đáng để benchmark. Nhà cung cấp thường phóng đại hoặc gây hiểu lầm, nên cần tự chạy thử trên gói miễn phí. Cũng nên chuẩn bị integration test và benchmark để phòng khi cần chuyển đổi
Cách này khá tốt khi kết quả lớn, nhưng tôi hy vọng bản thân PostgreSQL không bị nghẽn trong quá trình tạo JSON từ tập dữ liệu lớn
Mọi người nói rằng phải ở edge, phải ở gần người dùng và phải giảm độ trễ
Nhưng thực tế độ trễ là vấn đề lớn đến mức nào?
Dự án gợi ý sách Gnooks, chạy trên máy chủ ở Đức, là một ví dụ: https://www.gnooks.com
Tôi tò mò liệu có ai cảm thấy nó quá chậm không
Trong vài năm qua, dự án này đã nhận được hàng nghìn góp ý từ người dùng, nhưng theo tôi nhớ thì chưa ai nêu vấn đề độ trễ. Dù nhóm người dùng lớn nhất là ở Mỹ
Vì vậy nó ít gặp vấn đề độ trễ hơn nhiều so với kiểu PWA hiện nay, nơi phần lớn logic được triển khai ở frontend rồi gửi nhiều truy vấn đến backend để lấy dữ liệu cần thiết
Dù vậy bản thân site vẫn ổn. Nếu site vốn đã chậm thì khi đó mới thành vấn đề
Nếu làm vậy từ châu Âu, độ trễ sẽ khoảng gấp đôi so với những gì người dùng Úc thấy, giúp ước lượng trải nghiệm tệ nhất
Điểm tốt là có thể kiểm thử điều này một cách đáng tin cậy để xem nó có thực sự quan trọng hay không. Khi đó sẽ có câu trả lời cụ thể
Bài viết hoàn toàn không đề cập đến tính sẵn sàng. Dịch vụ chạy trên một máy duy nhất sẽ có cả downtime theo kế hoạch lẫn downtime ngoài dự kiến
Cũng cần nghĩ đến RPO/RTO. Khi máy bị hỏng, hay đúng hơn là nếu nó hỏng, phải xem mất bao lâu để khôi phục và sẽ mất bao nhiêu dữ liệu
Về câu nói rằng nếu việc render trang có dù chỉ một truy vấn database thì phải quay về DB ở us-east-1, cũng có các lựa chọn như sau:
https://aws.amazon.com/rds/aurora/global-database/
https://aws.amazon.com/dynamodb/global-tables/
https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Conce...
https://docs.aws.amazon.com/AmazonElastiCache/latest/red-ug/...
Còn nhiều thứ tương tự khác, và nếu tự chắp vá cùng một thứ thì sẽ rất vất vả
Nếu là 10–20 năm trước thì tôi đã đồng ý. Internet khi đó còn mới, site sập thì người ta đổ lỗi cho site, và tình hình nhanh chóng trở nên căng thẳng. Nhưng bây giờ họ có nhiều khả năng đổ lỗi cho nhà cung cấp Internet trước, hoặc thử lại sau
Không phải ai cũng là Google, và hệ thống đơn giản hơn ngay từ đầu cũng ít có khả năng lỗi hơn. Cứ duy trì backup, và nếu thật sự lo lắng thì replicate DB sang một site khôi phục thảm họa lạnh. Như vậy là đủ cho phần lớn công ty và tình huống không phải FAANG
Miễn là không mất dữ liệu, với nhiều công ty thì đó chỉ là một lần chập chờn ngắn. Nếu truyền thông tốt và sự cố rất hiếm, thậm chí downtime vài ngày cũng có thể chịu được; trong một số trường hợp, mất dữ liệu cũng có thể chịu được
Từng có câu rằng mỗi khi thêm một số 9 vào độ tin cậy thì chi phí sẽ tăng gấp đôi, và khi tính ROI nhất định phải phản ánh điều đó. Doanh nghiệp thực sự cần độ tin cậy đến mức nào phụ thuộc vào thị trường mục tiêu, và tôi cho rằng câu trả lời mặc định của IT là tự động 100% là sai
Mô hình một máy chủ hoặc hai máy chủ cũng có độ phức tạp thấp hơn nhiều, vì vậy ngay cả các đội vận hành như LetsEncrypt cũng chọn kiến trúc hai máy chủ vật lý như vậy để chạy dịch vụ toàn cầu ở quy mô web: https://letsencrypt.org/2021/01/21/next-gen-database-servers...
Nhờ độ trễ nội bộ cực thấp của DB nằm trong cùng máy chủ hoặc ngay bên cạnh, phần mềm có thể thực hiện truy vấn DB nhanh hơn vài bậc độ lớn, dùng ít tài nguyên hơn cho mỗi người dùng và mang lại trải nghiệm người dùng nhạy hơn so với các dịch vụ DB được quản lý thực tế
Sự phức tạp tạo ra những cái bẫy riêng, và tôi cho rằng không có web service nào chưa từng làm hỏng chuyện này. Bản thân AWS đôi khi cũng gây ra sự cố
Không thể nói VPS tệ hơn ở điểm này