여러 EC2 애플리케이션 서버에서 사용자가 업로드한 콘텐츠를 공유할 수 있어야 합니다. 저는 이 데이터를 거의 실시간으로 공유할 수 있는 잠재적인 옵션으로 rsync, 마운트된 NFS 및 S3를 살펴보았습니다. 업로드 및 다운로드된 사용자 파일은 거의 항상 1-10MB 사이입니다. 일부는 많이 액세스되고 일부는 한 번만 액세스된 후 삭제됩니다.
나의 최신 접근 방식은 EC2 인스턴스를 애플리케이션 서버와 별도로 파일 서버로 엄격하게 시작하는 것입니다. 이 옵션을 사용하면 사용자가 파일을 다운로드하기 위해 다운로드하려는 파일에 대한 데이터가 있는 데이터베이스를 쿼리하는 응용 프로그램 서버 중 하나에 연결됩니다. 그런 다음 사용자에게 다운로드를 위한 파일 서버에 연결하는 다운로드 메시지가 표시됩니다.
이 옵션이 다른 옵션보다 더 빠를 것 같습니다. 내가 보기에 유일한 단점은 파일 서버를 자동으로 확장/축소할 수 없다는 것입니다. 그러나 확장하여 파일이 있는 파일 서버를 알려주는 데이터베이스 열을 만들 수 있습니다.
이것이 좋은 접근 방식입니까, 아니면 뭔가 빠졌습니까? 또한 서버 사양을 기반으로 파일 크기가 1~10MB인 파일 서버에서 동시 업로드/다운로드 수를 확인할 수 있는 좋은 방법은 무엇입니까? 아니면 부하 테스트를 통해 가장 잘 결정됩니까?
또한 확장성 측면에서도 단 하나의 파일 서버에 있는 하나의 특정 파일이 엄청나게 인기를 끌면 문제가 될까요? CDN을 사용하면 이 문제가 해결됩니까?
답변1
CloudFront와 함께 S3를 사용하면 CDN이 더 나은 옵션이 될 것입니다. 제가 권장하는 것은 애플리케이션 서버에서 사용자 생성 콘텐츠를 분산시키는 것입니다. 아키텍처 내에서 확장하거나 축소할 때 서버를 불안정하게 유지하는 것은 좋은 설계 방식입니다.
답변2
S3 및 CloudFront가 첫 번째 옵션이 될 수 있지만 지연 시간이 허용되지 않는 경우 다른 옵션도 있습니다.
단일 파일 서버가 잘 작동하는 경우 다음과 같은 확장 가능한 분산 파일 서버 플랫폼으로 전환할 수 있습니다.GlusterFS. 이를 통해 여러 EC2 인스턴스에 걸쳐 파일을 저장하고 단일 마운트로 표시되도록 할 수 있습니다. "복제본 2" 옵션을 사용하여 중복성을 위해 각 파일의 복사본 2개를 만들 수 있습니다. 그런 다음 서로 다른 가용 영역에서 두 개의 인스턴스를 사용하여 가용성을 높입니다. 파일 자체는 IOPS가 프로비저닝된 EBS 또는 임시 SSD가 포함된 모든 EC2 지원 디스크에 저장됩니다. (이전에 이 작업을 수행한 적이 있습니다. Gluster의 중복으로 인해 임시 파일의 변동성이 덜 걱정되므로 SSD의 이점을 얻을 수 있습니다. 중요한 데이터에 대한 빠른 IO).
답변3
고유한 데이터가 없도록 EC2를 설계하려면 단순히 컴퓨팅 시스템으로 생각하십시오.
몇 가지 옵션이 있습니다.
S3
파일을 저장하고 검색하는 확장 가능하고 안정적인 서비스입니다. 파일 시스템으로는 잘 작동하지 않으므로 많은 양의 읽기 및 쓰기를 수행하는 경우에는 훌륭한 솔루션이 아닙니다.
CloudFront(CDN)
정적 파일(css, js, 이미지)은 CloudFront(S3 또는 EC2에서 데이터를 소싱할 수 있음)에서 제공될 수 있습니다. 이렇게 하면 성능이 크게 향상되므로 S3를 사용하여 CloudFront에서 파일을 가져오고 제공할 수 있습니다.
GlusterFS
EC2 클러스터를 네트워크 연결 스토리지로 사용할 수 있습니다. 물론 이는 설정이 조금 더 복잡해지며 가장 빠른 솔루션은 아닙니다.
탄력성/Memecached
자체 memecached를 호스팅하거나 Elasticache 서비스를 사용할 수 있습니다. 이 솔루션은 파일 저장은 아니지만 고성능 분산 메모리 개체 캐싱 시스템으로 유용합니다.