비슷한 문제를 볼 때마다 왜 BitTorrent를 더 많이 사용하지 않는지 궁금함, 더 다양한 곳의 기본 프로토콜로 쓰이면 좋겠다고 생각함, 예를 들어 컨테이너 레지스트리나 패키지 저장소 등에서 말임
BitTorrent는 대중적으로 안 좋은 이미지를 가짐, 대부분 단순히 불법 다운로드와 연관시킴<br>방화벽 설정이 HTTP보다 까다로움, 네트워크 관리자에게 이런 설정을 요구하면 이상하게 볼 수 있음, 특히 BitTorrent 자체에 대한 거부감 때문임<br>BitTorrent 클라이언트는 HTTP 클라이언트보다 훨씬 복잡하고 대부분 회사 컴퓨터나 CI 파이프라인에 설치되어 있지 않음, 많은 이들이 단순히 curl 명령 한번으로 끝내길 원함<br>시드를 해야 한다는 오해가 매우 많고, 그 때문에 두려움을 느낌<br>결국 이미지와 curl만으로 모든 게 되기 때문에 BitTorrent가 저평가되고 있음이 아쉬움<br>비디오 게임 클라이언트가 업데이트에 BT를 활용하거나 PeerTube가 webtorrent를 사용하는 사례도 있지만, 여전히 많이 쓰이지는 않아 아쉬움
Amazon, Esri, Grab, Hyundai, Meta, Microsoft, Precisely, Tripadvisor, TomTom 등 수십 개 기업이 OpenStreetMap 데이터를 Parquet 포맷으로 S3에 무료로 제공함, 이는 수TB 데이터셋에서 MB 단위의 대역폭만 쓰며 원하는 정보만 쿼리하고 분석할 수 있도록 해 줌<br>자세한 내용 참고<br>ArcGIS Pro 사용자는 이 플러그인도 활용 가능함
몇 년 전에 "동적 콘텐츠를 가진 토렌트"라는 개념을 본 기억이 있음, 실제로는 잘 쓰이지 않게 됨<br>이게 현실화 되길 바랐는데 보안 문제 같은 치명적인 이슈가 있었던 건지 궁금함<br>참고 링크
HTTP에 비해 BitTorrent는 자체적으로 모든 곳에서 쓸 수 있는 "범용 클라이언트"가 부족했다고 생각함, SSH나 SCP처럼 친숙한 것도 아니고, 설치·설정·트래커 구성까지 손이 많이 감<br>일반적으로 대용량 파일의 잦은 다운로드 수요가 있어야 이런 구조가 의미 있음, 신뢰성과 시딩 볼륨 문제까지 고려하면 결국 도구 개발·유지비용 대비 이득이 얼마나 있는지에 귀결됨<br>Git LFS 같은 게 도움이 될까 싶은데 여기까지가 내가 아는 범위임
전에 다니던 회사에서 매주 모든 개발자에게 대용량 파일을 배포해야 했음, 초반엔 rsync로 동시에 떼쓰듯 받았는데, BitTorrent로 바꾼 이후 속도 향상이 엄청 컸음
Geofabrik같은 회사가 있어서 우리가 가끔 멋진 경험을 할 수 있음에 늘 감사함<br>API를 직접 운영하다보면 개발자들의 경솔함이나 무지에 정말 놀랄 때가 많음, 그 정도로 이상한 요청들이 잦음<br>이전에 경험하지 않고서는 누군가 이런 얘길 들려줬다면 과장이라 생각했을 것임<br>그런데 또 반대로, API 개발자들도 여러 건을 염두에 두지 않는 경우가 많음, 대부분 단일 엔티티 조작만 제공해서, 실제 유즈 케이스 상 다중 작업이 필요한 상황임에도 700번 요청을 날릴 수밖에 없음
개발 숙련도 낮은 사람에게는 어느 직업이든 무책임, 무지가 있을 수 있음<br>모든 개발자가 API를 마구 두들기는 건 아님을 확신함<br>프로그래밍이 모두에게 개방되었고 최근에는 "vibe-coding" 경향도 있어 큰 틀에서 보면 어쩔 수 없음을 느낌<br>응답에 429(Too Many Requests)를 반환하거나 leaky-bucket 알고리즘을 적용해두면 주니어나 입문 개발자들도 금방 스스로 문제를 인식할 것임
S3의 "다운로더 과금(downloader pays)" 기능이 왜 더 널리 도입되지 않는지 이해하기 어려움, AWS 외부에서도 이런 모델이 있으면 비효율적 사용자가 자기 비용만큼만 부담하게 할 수 있을 것임<br>단점은 결제 시스템이 없는 사람은 접근이 어려워질 수도 있는데, 이때는 무료지만 제한적 속도 옵션도 남길 수 있지 않을까 생각함
20GB 파일을 하루에 수천 번씩 받는 사용자가 있다는데, 왜 단순히 Rate Limit으로 제어하지 않는지 궁금함
양쪽 모두 공감 능력이 더 필요하다고 생각함: 클라이언트는 인프라를 존중해야 하고, API 개발자는 사용자 관점에서 더 넓게 생각해야 함
"한 사용자가 24시간 내에 italy-latest.osm.pbf 파일을 거의 만 번 다운로드했다"는 사례는 코드가 문제일 확률이 높음, IP당 제한을 두면 되는 일임, VPN 사용자라도 마찬가지임
아마 사람들이 CI 파이프라인에서 map 데이터 파일을 다운로드하고 있는 듯함, 종종 본인도 인식하지 못하는 본의 아닌 다운로드임<br>그래서 많은 서비스가 비회원의 자동 다운로드를 금지하게 되었음<br>cURL로 파일을 받으려면 먼저 회원가입을 유도하고, 과도하게 다운로드하는 사용자는 차단하거나 요금을 부과하는 것이 좋다고 생각함
CI라는 개념이 컴퓨팅 리소스를 낭비하는 최악의 발명품 중 하나라고 생각함, 다만 지도 데이터는 코드 라이브러리처럼 남용되는 식의 대량 다운로드가 왜 발생하는지는 잘 모르겠음
GPKG 파일을 웹앱이 "쿼리"하는 방식이 아닐까 의심됨, Parquet 포맷은 원하는 부분만 효율적으로 쿼리할 수 있지만 GPKG에서 똑같이 가능한지는 잘 모르겠음
CI 서버에서의 요청을 신뢰성 있게 판별할 수 있는지 궁금함
간단한 인증(예: API 키나 이메일 기반) 정도만 있어도 좋은 절충점일 것 같음
"동일한 20GB 파일을 수일간 하루에 수백 번 다운로드하는 유저가 있음(24시간 내 만 번 다운로드한 유저도 있음), 서버에 있는 모든 파일을 매일 다운로드하는 사람도 있다"는 사례는 rate-limiting만으로 쉽게 막을 수 있을 듯함<br>24시간 동안 파일 다운로드 횟수를 이미 세고 있으면서 제한을 두지 않는 이유가 뭔지 궁금함<br>이들이 (a) 서버 운영자의 경고글을 읽고 (b) 행동을 바꿀 거라 기대하진 않음
몇 년 전엔 "설마 누가 빌드 스크립트에서 매번 100MB 넘는 걸 다운받겠어?" 생각했었지만, Docker를 경험하고 나서는 그런 케이스가 매우 많음을 깨달았음
컨테이너 안에 들어가면 마법이라도 된 듯이 공짜라 착각하는 사례를 종종 봄
Docker는 레이어 캐시를 지원하니 모든 걸 매번 다 새로 받을 필요는 없는 것 아님?
그래서 나는 프로젝트 전용 이미지를 미리 CI에서 만들어놓고 CI에서만 사용함, 매번 apt-get으로 세팅하려면 시간 소모가 너무 큼
과도한 다운로드 유저에게는 따로 메일을 보내는지 궁금함, 2012년에 무료 Nominatim API를 사용할 때는 이메일이 필수였고, 캐싱 등으로 요청량을 줄이라는 안내 메일을 실제로 받은 적 있음
로그인이 없는 상황이라면 이메일 주소를 받지 못하니 메일을 보낼 수 없음
나는 italy-latest 파일을 8초마다 다운받는 그 유저는 아니지만, 내가 속한 이탈리아 스타트업이 GeoFabrik을 많이 활용하고 있음, 팀원 중 누군가가 컨테이너 실험을 하다 너무 많이 다운받았을 수 있음<br>예전에 geofabrik에서 차단(밴)을 당했는데, 아직도 원인이 뭔지 몰라서 앞으로 이런 일이 반복되지 않길 바람<br>geofabrik.de 연락처로 전화·이메일도 시도해봤지만 답이 없었음, 혹시 이 문제 해결 방법이나 연락 방법을 아는 분이 있으면 알려줬으면 함
이런 식으로 과도하게 파일을 내려받는 사람들은 정작 이런 블로그 글은 읽지 않을 거란 생각이 듦
bittorrent를 쓰면 좋을 유스케이스라는 생각임
데이터가 변경될 경우 토렌트 클라이언트가 어떻게 자동으로 변경점만 받아올 수 있을지가 궁금함
Hacker News 의견