사용자가 업로드 한 데이터, 특히 분산 환경에서 S3를 사용하는 경우 S3가 '결국 일관성'(일부 지역은 쓰기 후 읽기 일관성이 있음)이라는 사실을 고려해야합니다. 그 결과 파일을 성공적으로 업로드 할 수 있지만 그 이후에 해당 파일이 있는지 확인하면 해당 파일이 존재하지 않을 수 있습니다. 이 문제는 쓰기 후 읽기 일관성이 도움이되지 않는 업데이트 또는 삭제와 같은 시나리오에서 더욱 두드러집니다.
위의 방법은 사용자의 접근 방식에 관계없이 S3에 업로드 할 때 적용됩니다. 실제로 이것은 S3에 대해 예상 할 수있는 대부분의 문제에 해당됩니다. 데이터를 저장하는 데 사용되는 접근 방식은 S3의 한계이므로 가장 문제가 될 수 있습니다.
S3fs는 PHP (또는 다른) SDK와 마찬가지로 S3 API를 사용합니다. 또한 S3는 상당히 높은 수준의 동시성을 처리하도록 설계되었으므로 일관성 문제를 제외하고 여러 인스턴스에 마운트하는 데 문제가 없어야합니다 (전통적인 파일 시스템이 아니라는 점을 명심하십시오) 등은 S3 쪽에서 처리됩니다).
즉, 각 구현에는 몇 가지 잠재적 인 장점과 단점이 있습니다.
S3fs :
- 부분 / 청크 다운로드 (내가 아는 한)는 지원하지 않으므로 전체 파일을 다운로드하여 파일의 일부를 읽어야합니다. 업로드를 저장하고 제공하기 위해 파일을 사용하는 경우에는 문제가되지 않습니다.
- C ++로 가능한 성능 향상으로 작성
- s3fs에 대한 모든 업데이트로 응용 프로그램의 이점
- 캐싱 (전체 파일 및 파일 정보 모두)을 구현합니다. 속도를 약간 향상시키고 비용을 절감 할 수 있습니다
- 퓨즈가 노출하는 기능으로 제한
SDK :
- S3가 제공해야하는 모든 기능을 제공합니다. 사용 사례에 따라 SDK를 사용할만한 가치가 있습니다.
- 잠재적으로 응용 프로그램과의 긴밀한 통합-반환 된 오류 등으로 인해 응용 프로그램에서보다 정확한 정보를 얻을 수 있으므로보다 정확한 선택이 가능합니다.
- 가능한 모든 이점을 코딩해야합니다. 응용 프로그램은이를 활용하고 향후 S3를 변경하여 최신 상태를 유지해야합니다.
- 더 복잡하고 코드 오버 헤드
'안전성'측면에서 '데이터 손상 방지'또는 '무단 액세스 방지'를 의미 할 수 있습니다. 전자와 관련하여 SDK는 최종 일관성 (더 자세한 오류의 형태로)을 처리하는 데 약간 도움이 될 수 있지만 기본 저장소는 동일하며 차이가 적을 것으로 예상합니다. 액세스 제어와 관련하여-IAM을 사용하여 제한된 계정을 만들 수 있지만 해당 계정에는 여전히 S3 파일에 대한 읽기 / 쓰기 액세스 권한이 필요합니다. 두 경우 모두 S3 버킷에 액세스하려면 시스템이 손상되어야합니다. 그러나 S3fs를 사용하는 것이 좋습니다 (자격 증명은 일반적으로 웹 루트 외부에 저장되므로 모든 방법으로 액세스 할 수 없기 때문에). PHP) 약간 더 나은 보안이 있습니다.
개인적 견해 : 단일 업로드 디렉토리 (예 : 하나의 사이트를 사용하는 사이트)가 있고 액세스가 상당히 간단한 경우 (파일을 업로드하고 가끔 업데이트 / 삭제해야하는 경우)에는 s3fs를 선호합니다. 좀 더 복잡한 액세스 (예 : 부분 다운로드, 여러 버킷 등)가 필요하거나 다른 용도로 S3 SDK를 사용하려는 경우 업로드 용 SDK도 사용합니다.