Tải xuống một cách có trách nhiệm

• Nhờ nâng cấp hạ tầng máy chủ tải xuống trong tháng này, trải nghiệm tải xuống sẽ nhanh hơn
• Cách yêu cầu tệp “…latest” đã được chuyển sang chuyển hướng HTTP
• Nỗ lực giúp mọi người dùng có thể truy cập dữ liệu OSM mới nhất một cách thuận tiện
• Các trường hợp sử dụng bất thường lặp đi lặp lại việc tải quá mức các tệp dung lượng lớn đang làm giảm hiệu năng của toàn bộ dịch vụ
• Đưa ra ba khuyến nghị cụ thể để tải xuống hiệu quả và có trách nhiệm

---

Cập nhật máy chủ tải xuống và khuyến nghị sử dụng có trách nhiệm

Trong tháng này, chúng tôi đã tiến hành tăng cường hạ tầng cho máy chủ tải xuống.
Nhờ đó, đã có thể xây dựng môi trường cung cấp tải xuống nhanh hơn, sớm hơn.
Về thay đổi kỹ thuật, khi yêu cầu tệp “…latest”, thay vì truyền trực tiếp như trước đây, hệ thống sẽ dùng HTTP redirect để đưa tới tệp của phiên bản mới nhất.

Vì sao cần tải xuống có trách nhiệm

Máy chủ đang được vận hành để mọi người dùng có thể dễ dàng truy cập dữ liệu OSM (OpenStreetMap) mới nhất.
Tuy nhiên, đã xuất hiện trường hợp một số người dùng lặp lại việc tải cùng một tệp dung lượng lớn (ví dụ: 20GB) hàng trăm đến hàng nghìn lần mỗi ngày.

• Ví dụ, đã có trường hợp một người dùng tải tệp italy-latest.osm.pbf gần 10.000 lần trong vòng 24 giờ
• Một số trường hợp khác thì lặp lại hành vi tải toàn bộ mọi tệp trên máy chủ mỗi ngày

Những hành vi này gây ra tình trạng chậm cho toàn bộ người dùng do giới hạn băng thông của máy chủ.
Nếu buộc phải chặn dải IP, cả những người dùng không liên quan cũng có thể bị ảnh hưởng.

Ba khuyến nghị cụ thể dành cho người dùng máy chủ

1. Nếu cần dữ liệu toàn cầu, thay vì tải chia nhỏ từ máy chủ này, nên tải một lần tệp planet từ planet.openstreetmap.org
2. Nếu muốn cập nhật hằng ngày dữ liệu cấp châu lục hoặc khu vực rộng (ví dụ: Europe, North America), hãy dùng pyosmium-up-to-date để chỉ tải phần thay đổi; cách này giúp giảm 98% lưu lượng và còn nhanh hơn
3. Nếu sử dụng script tự động, cần giám sát nội dung đang được tải xuống hoặc thêm xử lý lỗi phù hợp để tránh các sai sót như tải lặp vô hạn cùng một tệp

Kết luận

Hãy cùng tham gia xây dựng môi trường để mọi người đều có thể sử dụng dữ liệu mới nhất một cách thuận tiện hơn thông qua thói quen tải xuống có trách nhiệm.

[GN⁺]

Ý kiến trên Hacker News

• Mỗi khi thấy các vấn đề kiểu này, tôi lại tự hỏi vì sao BitTorrent không được dùng nhiều hơn; tôi nghĩ sẽ rất tốt nếu nó trở thành giao thức mặc định ở nhiều nơi hơn, ví dụ như registry container hay kho lưu trữ gói
  • BitTorrent có hình ảnh đại chúng khá xấu; đa số chỉ liên hệ nó với tải xuống bất hợp pháp<br>Thiết lập tường lửa cũng rắc rối hơn HTTP; nếu yêu cầu quản trị viên mạng mở các cấu hình kiểu đó, họ có thể nhìn bạn với ánh mắt kỳ quặc, nhất là vì ác cảm sẵn có với chính BitTorrent<br>Client BitTorrent phức tạp hơn nhiều so với client HTTP và thường không được cài trên máy tính công ty hay pipeline CI; nhiều người chỉ muốn xong việc bằng một lệnh curl duy nhất<br>Có rất nhiều hiểu lầm rằng dùng BitTorrent thì phải seed, và điều đó khiến người ta e ngại<br>Cuối cùng, thật đáng tiếc khi BitTorrent bị đánh giá thấp chỉ vì hình ảnh của nó và vì mọi thứ đều có thể làm chỉ với curl<br>Có những trường hợp như client game dùng BT để cập nhật hoặc PeerTube dùng webtorrent, nhưng vẫn tiếc là nó chưa được sử dụng rộng rãi hơn
  • Hàng chục công ty như Amazon, Esri, Grab, Hyundai, Meta, Microsoft, Precisely, Tripadvisor, TomTom... đang cung cấp miễn phí dữ liệu OpenStreetMap ở định dạng Parquet trên S3, cho phép truy vấn và phân tích đúng phần thông tin cần thiết chỉ với băng thông mức MB ngay cả trong bộ dữ liệu cỡ nhiều TB<br>Xem chi tiết<br>Người dùng ArcGIS Pro cũng có thể dùng plugin này
  • Tôi nhớ là vài năm trước từng thấy khái niệm "torrent có nội dung động", nhưng rồi trên thực tế nó không được dùng nữa<br>Tôi đã hy vọng chuyện này sẽ thành hiện thực, nên cũng tò mò không biết có vấn đề chí mạng nào như bảo mật đã cản nó lại hay không<br>Liên kết tham khảo
  • So với HTTP, tôi nghĩ BitTorrent thiếu một "client đa dụng" thực sự có thể dùng ở mọi nơi; nó cũng không quen thuộc như SSH hay SCP, lại còn phải cài đặt, cấu hình, thiết lập tracker các thứ khá tốn công<br>Thông thường chỉ khi có nhu cầu tải xuống tệp lớn với tần suất cao thì cấu trúc như vậy mới có ý nghĩa; nếu tính cả độ tin cậy và khối lượng seeding, cuối cùng câu hỏi vẫn là lợi ích có xứng với chi phí phát triển và bảo trì công cụ hay không<br>Tôi cũng tự hỏi liệu thứ như Git LFS có giúp được gì không, nhưng đó là hết những gì tôi biết
  • Ở công ty cũ của tôi, mỗi tuần phải phân phối một tệp lớn cho toàn bộ lập trình viên; ban đầu mọi người cùng kéo bằng rsync, nhưng sau khi chuyển sang BitTorrent thì tốc độ cải thiện cực kỳ lớn
• Tôi luôn biết ơn vì có những công ty như Geofabrik, nhờ đó chúng ta thỉnh thoảng mới có được những trải nghiệm tuyệt vời như vậy Khi trực tiếp vận hành API, nhiều lúc tôi thật sự kinh ngạc trước sự cẩu thả hay thiếu hiểu biết của các lập trình viên; yêu cầu kỳ quặc xuất hiện thường xuyên đến mức đó<br>Nếu chưa từng tự mình trải qua thì nghe ai kể chắc tôi đã nghĩ là họ nói quá<br>Nhưng ngược lại, các nhà phát triển API cũng thường không nghĩ đến nhiều trường hợp; đa số chỉ cung cấp thao tác trên một thực thể đơn lẻ, nên trong những use case thực tế cần thao tác hàng loạt, người dùng buộc phải bắn ra 700 request
  • Ở bất kỳ nghề nào cũng có thể có những người thiếu trách nhiệm hoặc thiếu hiểu biết nếu trình độ phát triển còn thấp<br>Tôi tin chắc không phải mọi lập trình viên đều spam API như điên<br>Lập trình giờ mở cho tất cả mọi người, gần đây còn có xu hướng "vibe-coding", nên nhìn ở tầm rộng thì có lẽ cũng là điều khó tránh<br>Nếu trả về 429 (Too Many Requests) hoặc áp dụng thuật toán leaky-bucket trong phản hồi thì ngay cả lập trình viên junior hay người mới bắt đầu cũng sẽ nhanh chóng tự nhận ra vấn đề
  • Tôi khó hiểu vì sao tính năng "downloader pays" của S3 không được áp dụng rộng rãi hơn; nếu ngoài AWS cũng có mô hình như vậy thì những người dùng kém hiệu quả sẽ phải tự chịu đúng phần chi phí mình gây ra<br>Nhược điểm là những ai không có phương thức thanh toán sẽ khó tiếp cận hơn, nhưng có lẽ vẫn có thể giữ một tùy chọn miễn phí với tốc độ giới hạn
  • Có người tải tệp 20GB hàng nghìn lần mỗi ngày; tôi thắc mắc vì sao không đơn giản kiểm soát bằng Rate Limit
  • Tôi nghĩ cả hai phía đều cần thêm sự đồng cảm: client phải tôn trọng hạ tầng, còn nhà phát triển API thì nên suy nghĩ rộng hơn từ góc nhìn người dùng
• Trường hợp "một người dùng đã tải tệp italy-latest.osm.pbf gần mười nghìn lần trong vòng 24 giờ" rất có thể là do code có vấn đề; chỉ cần đặt giới hạn theo IP là được, kể cả với người dùng VPN cũng vậy
• Có lẽ mọi người đang tải các tệp dữ liệu bản đồ trong pipeline CI, và đôi khi đó còn là tải xuống ngoài ý muốn mà chính họ cũng không nhận ra<br>Vì thế mà nhiều dịch vụ đã cấm tải xuống tự động đối với người dùng không đăng nhập<br>Nếu muốn lấy tệp bằng cURL thì trước tiên nên yêu cầu đăng ký, còn người tải quá mức thì chặn hoặc thu phí sẽ tốt hơn
  • Tôi cho rằng CI là một trong những phát minh tệ nhất xét về việc lãng phí tài nguyên tính toán, nhưng với dữ liệu bản đồ thì tôi cũng không rõ vì sao lại phát sinh tình trạng tải hàng loạt kiểu lạm dụng như đối với thư viện mã nguồn
  • Tôi nghi là ứng dụng web đang "truy vấn" trực tiếp các tệp GPKG; định dạng Parquet có thể truy vấn hiệu quả chỉ phần cần thiết, nhưng tôi không chắc GPKG có làm tương tự được không
  • Tôi tự hỏi liệu có thể phân biệt một cách đáng tin cậy các request đến từ máy chủ CI hay không
  • Chỉ cần xác thực đơn giản thôi, ví dụ API key hoặc email, có lẽ đã là một điểm cân bằng hợp lý
• Trường hợp "có người dùng tải cùng một tệp 20GB hàng trăm lần mỗi ngày trong nhiều ngày liền (thậm chí có người tải mười nghìn lần trong 24 giờ), và cũng có người tải mọi tệp trên máy chủ mỗi ngày" có vẻ hoàn toàn có thể chặn dễ dàng chỉ bằng rate-limiting<br>Tôi thắc mắc tại sao đã đếm số lượt tải trong 24 giờ rồi mà lại không đặt giới hạn<br>Tôi không nghĩ họ sẽ (a) đọc bài cảnh báo của người vận hành máy chủ rồi (b) thay đổi hành vi
• Vài năm trước tôi từng nghĩ "đâu có ai đi tải lại thứ hơn 100MB trong script build ở mỗi lần chạy chứ?", nhưng sau khi tiếp xúc với Docker tôi mới nhận ra những trường hợp như vậy thật ra rất nhiều
  • Tôi thường thấy những trường hợp cứ như thể hễ chui vào trong container là thành phép màu và mọi thứ đều miễn phí
  • Docker có hỗ trợ layer cache, vậy chẳng phải không cần tải lại toàn bộ mọi thứ mỗi lần sao?
  • Vì vậy tôi tạo sẵn image riêng cho từng dự án trong CI và chỉ dùng chúng trong CI; nếu lần nào cũng phải thiết lập bằng apt-get thì quá tốn thời gian
• Tôi tò mò không biết có gửi email riêng cho những người dùng tải quá mức không; hồi 2012 khi tôi dùng API Nominatim miễn phí thì email là bắt buộc, và tôi đã thực sự nhận được email hướng dẫn giảm số lượng request bằng cách dùng cache, v.v.
  • Nếu không có đăng nhập thì sẽ không lấy được địa chỉ email để gửi thư
• Tôi không phải người dùng tải tệp italy-latest mỗi 8 giây, nhưng startup ở Ý nơi tôi làm việc dùng GeoFabrik rất nhiều; có thể ai đó trong nhóm đã thử nghiệm với container và tải xuống quá nhiều<br>Trước đây chúng tôi từng bị geofabrik chặn (ban), nhưng đến giờ vẫn không biết nguyên nhân là gì nên mong chuyện này sẽ không lặp lại nữa<br>Tôi cũng đã thử gọi điện và gửi email đến liên hệ của geofabrik.de nhưng không nhận được phản hồi; nếu ai biết cách giải quyết vấn đề này hoặc cách liên hệ thì mong được chỉ giúp
• Tôi có cảm giác những người tải tệp quá mức kiểu này lại chính là những người sẽ không đọc các bài blog như thế này
• Đây đúng là một use case mà dùng bittorrent sẽ rất hợp
  • Tôi thắc mắc nếu dữ liệu thay đổi thì client torrent sẽ tự động chỉ lấy phần thay đổi như thế nào