GN⁺: S3는 파일 시스템이 아닌 파일 저장 기술

S3는 파일이지만 파일 시스템은 아니다

• Amazon S3는 2006년에 출시된 원래의 클라우드 기술로, "객체 저장소"로 불리지만 실제로는 파일을 위한 것임.
• S3가 "Amazon Cloud Filesystem"이라는 생각은 사람들이 S3를 채택하도록 유도하는 유용한 믿음이지만, 사실 S3는 파일 시스템이 아님.

파일 시스템이란 무엇인가, 그리고 모듈 "깊이"

• 유닉스 파일 API는 다섯 가지 기본 함수로 구성되어 있으며, 이는 파일 읽기와 쓰기에 필요한 모든 것을 제공함.
• 이러한 함수들은 버퍼링, 페이지 캐시, 조각화, 권한, IO 스케줄링 등 많은 문제를 다루지만 사용자에게 노출시키지 않음.
• 깊은 모듈은 사용자가 복잡성에 대해 생각하지 않고도 기능을 이용할 수 있게 해주는 장점이 있음.

S3의 특징(이것도 깊음)

• S3는 유닉스 파일 시스템 API를 재구현하지 않으며, 기본적인 호출 방식이 다름.
• S3 API는 유닉스 파일 API보다 간단하지만, 객체를 부분적으로 덮어쓸 수 없는 제한이 있음.

파일 시스템 소프트웨어, 특히 데이터베이스는 Amazon S3로 이전할 수 없음

• 데이터베이스는 데이터를 저장할 장소가 필요하며, 이는 일반적으로 파일 시스템의 다양한 파일에 저장됨.
• 데이터베이스는 부분적인 덮어쓰기 기능에 크게 의존하며, 이는 S3에서는 불가능함.

S3가 잘하는 것과 못하는 것

• S3의 장점은 읽기와 쓰기의 대역폭이 매우 높다는 것임.
• 그러나 S3에는 부분적인 덮어쓰기, 이름 변경 또는 이동 작업이 없으며, 파일 목록을 나열하는 것도 느림.
• 그럼에도 불구하고 S3는 유지보수가 적고, 백업 설정, 복제, 프로비저닝 등의 작업을 간소화함.

조직 간 모듈 깊이의 중요성

• S3가 인기 있는 첫 번째 클라우드 API가 된 것은 놀랍지 않으며, 조직 간 복잡성을 관리하는 데 깊은 API가 도움이 됨.
• SAP와 같은 복잡한 기업 소프트웨어를 통합하는 것은 고통스러운 작업이며, 이는 SAP가 깊은 모듈이 아니기 때문임.

기타 정보

• 이 기사는 S3가 과대평가되었다는 것을 제안하려는 것이 아니며, 깊은 모듈 대 비교적 얕은 모듈에 대한 개념을 설명함.
• 몇몇 데이터베이스는 S3 API를 사용하여 저장소로 설계되었으며, 이는 가능하지만 투명하지는 않음.
• S3에서는 많은 파일 형식이 디스크보다 성능이 떨어짐.

GN⁺의 의견

• S3는 파일 시스템의 대체재가 아니라 특정 사용 사례에 최적화된 스토리지 솔루션이라는 점을 이해하는 것이 중요함. 예를 들어, 대규모 불변 파일을 저장하고 전송하는 데 적합하지만, 데이터베이스와 같이 빈번한 부분적 업데이트가 필요한 애플리케이션에는 적합하지 않음.
• S3의 성능과 확장성은 매우 높지만, 비용 효율성과 관리의 복잡성을 고려할 때 모든 프로젝트에 적합한 것은 아님. 예를 들어, 오픈소스 프로젝트인 MinIO는 자체 인프라에서 S3 호환 스토리지를 구축하고자 하는 조직에게 좋은 대안이 될 수 있음.
• S3를 사용할 때는 데이터 일관성, 네트워크 비용, 접근 제어 등의 추가적인 고려 사항이 있으며, 이러한 요소들은 전체 시스템 설계에 영향을 미칠 수 있음.
• S3의 사용 사례가 제한적일 수 있지만, 데이터 레이크나 백업 솔루션과 같은 특정 애플리케이션에서는 매우 강력한 도구임. 데이터를 안전하게 저장하고 필요할 때 빠르게 검색할 수 있는 능력은 많은 비즈니스에 중요한 가치를 제공함.
• 이 기사는 S3의 기술적 세부 사항과 실제 사용 사례에 대한 깊은 이해를 제공함으로써, 기술적 결정을 내리는 데 도움이 될 수 있음.

[neo]

Hacker News 의견

• S3의 내구성에 대한 문제를 들어본 적은 없지만, 이러한 주장이 테스트된 것을 본 적도 없다. 이 주장들에 대해 궁금하긴 하다.

  • S3의 내구성은 업계 선두이며, 전통적인 파일 시스템과는 비교할 수 없음.
  • AWS의 가용성 구역 분리는 다른 클라우드 제공업체보다 우수함.
  • S3는 데이터 무결성과 자연재해에 대한 걱정이 매우 큼.
  • S3는 '비트로트'를 감지할 정도로 큰 규모로 운영됨.
  • 중요 데이터는 S3 외에 다른 곳에 저장하지 않을 것임.
  • 출처: S3 배치 시스템을 작성한 사람.

• 파일 목록을 나열하는 것이 느리다. S3는 읽기와 쓰기는 매우 빠르지만, 파일 목록을 나열하는 것은 매우 느림.

  • S3의 빠른 읽기와 쓰기가 유용한 것이 아니라, 파일 목록을 나열하는 기능이 유용함.
  • 버전 관리되지 않은 버킷에서는 주어진 접두사를 나열하는 것이 사실상 일정 시간 내에 가능함.
  • 데이터를 다양한 방식으로 분할하고 성능에 대한 걱정 없이 필요한 식별자를 사용할 수 있음.

• 파일 목록을 나열하는 것이 느리다는 점에 최근 놀랐다. S3에서 자산을 관리하기 위한 스크립트 작업을 하면서, 파일 목록 캐시가 필요하다는 것을 깨달음.

  • 약 100,000개의 루트 레벨 디렉토리가 있으며, 각각에는 몇 개의 파일이 있는 몇 개의 디렉토리가 있음.
  • 파일을 재귀적으로 나열하는 데 15분이 걸림.
  • 아마존이 이 문제를 해결하지 않은 이유가 궁금함.

• Amazon S3는 원래의 클라우드 기술로, 2006년에 출시됨. "객체"가 당시 인기 있었고 S3는 "객체 저장소"로 불림.

  • S3는 파일 시스템이 아니라 객체 저장소임.
  • S3는 파일이 아니며, 파일 시스템도 아님.
  • 파일 추상화에서 기대하는 것은 가변성임.
  • S3는 불변 객체의 가변 목록을 제공함.
  • S3는 다른 문제를 해결하고, 파일 시스템처럼 보이게 하려는 시도는 고객의 오해에서 비롯됨.

• Apache Arrow의 object_store와 Apache OpenDAL 제공 API를 비교하는 논의가 있음.

  • Apache OpenDAL은 S3를 포함한 여러 클라우드 스토리지에 대한 FS와 같은 API를 제공하는 라이브러리임.
  • GreptimeDB와 Databend와 같은 몇몇 데이터베이스 시스템은 클라우드 스토리지에 데이터에 접근하기 위해 OpenDAL을 사용함.
  • Alluxio와 JuiceFS와 같은 다른 솔루션들도 S3 위에 파일 시스템과 같은 인터페이스를 관리함.

• 파일 시스템 소프트웨어, 특히 데이터베이스는 Amazon S3로 이식될 수 없다.

  • 그러나 이식될 수 있음.
  • INSERT/UPDATE/DELETE를 할 때마다 전체 DB 파일을 덮어쓸 필요는 없음.
  • SQLite의 경우 S3로 복제하고 복원을 지원하는 Litestream과 같은 도구가 있음.

• Minio를 로컬 "S3"로 사용하여 데이터셋과 모델 체크포인트를 저장함.

  • Minio에는 필요하지 않은 많은 기능이 있음.
  • CRUD 파일을 할 수 있고 목록을 볼 수 있는 최소한의 S3와 같은 "것"에 대한 현재 최선의 자체 호스팅, 단일 노드 옵션은 무엇인가?

• S3에 대해 이야기하는 동안 Backblaze B2를 언급할 가치가 있음.

  • S3보다 3배 낮은 가격에 매우 만족함.

• S3는 파일 시스템으로 잘못 사용될 수 있음.

  • S3는 객체를 원하며, 여기에 클러스터라고 불리는 512 또는 4096 바이트 객체가 있음.