2010-02-18 2 views
61

Java, Tomcat, MySQL 서버를 AWS EC2로 마이그레이션하려고합니다.EBS 또는 S3에서 이미지를 유지해야합니까?

이미 MySql 데이터를 저장하기 위해 EBS 볼륨을 연결했습니다. 내 웹 응용 프로그램에서 사람들이 이미지를 업로드 할 수 있습니다. 그래서 나는 그들을지지해야한다. 내 마음에는 두 가지 대안이 있습니다.

  1. 업로드 된 이미지를 EBS 볼륨에 저장합니다.
  2. S3 서비스를 사용하십시오.

내 메모는 다음과 같습니다. 내 전문 기술은 서버가 아닌 소프트웨어 개발이므로 회의에 대해 회의하십시오.

  • EBS 플러스 : S3 스토리지가 더 비쌉니다. (0.15 $/Gb> 0.1 $/Gb)

  • S3 plus : EBS의 서빙 스탯이 웹 서버 성능에 부정적인 영향을 줄 수 있습니다. 사실입니까? 이미지 검색은 특히 서버 성능에 영향을 줍니까? S3의 경우 내 서버는 통계 정보를 제공 할 책임이 없습니다.

  • S3 플러스 : EBS의 서빙 스탯은 입출력 비용이 발생할 수 있으며, 아마도 미성년자 일 수 있습니다.

  • EBS 플러스 : 사람들은 EBS가 빠릅니다.

  • S3 플러스 : 사람들은 S3가 지속성에 대해 더 안전하다고 말합니다.

  • EBS plus : API를 배울 필요가 없으며 EBS 볼륨에 이미지를 저장하는 것이 간단합니다.

즉 결정할 수 없으므로 안내하면 기쁠 것입니다.

감사합니다.

+0

S3는 http://aws.amazon.com/s3/pricing/ – MikeNereson

답변

47

현재 프로젝트에 S3을 사용하고 있으며 매우 잘 작동합니다.

EBS은 볼륨 + 기계를 연결해야한다는 의미입니다. 데이터를 채우고 백업 할 때 공간을 추가해야합니다 (S3 데이터를 백업해서는 안되며 중요하지는 않습니다).

또한 컴퓨터를 추가 할 때 별도의 컴퓨터로 이미지를 가져 오거나 이미지를 모두 복제해야합니다. 이는 또한 병목 현상을 추가 함을 의미합니다. 모든 시스템에 업로드하거나 하나의 시스템에서이를 관리하는 자체 업로드 프로세스를 관리해야합니다.

나는 S3을 권장합니다. 설정되어 있고 잊어 버렸습니다. 여러 컴퓨터가 동시에 업로드를 수행 할 수 있으며 업로드에 대해 다른 컴퓨터에 알릴 필요가 없습니다.

또한 Amazon Cloudfront를 S3에서 직접 다운로드하는 대신 이미지 앞에 저렴한 CDN으로 사용할 수 있습니다.

+5

S3 + Cloudfront의 경우 +1입니다. 나는 우리의 속성 중 하나를 위해 Flash 무비를 제공하기 위해 그것을 사용하고 있으며 매우 잘 작동합니다. – devstuff

8

이미 두 가지의 장단점에 대해 설명했습니다.

테라 바이트의 이미지를 저장할 계획이라면 스토리지 요구 사항이 날마다 증가하므로 S3은 아마도 이러한 상황에 맞게 제작 된 최상의 방법 일 것입니다. 많은 EBS 볼륨에 대해 sharding your data에 대해 걱정할 필요없이 무제한 저장 공간을 확보 할 수 있습니다.

S3의 반복 비용은 EBS보다 50 % 더 비쌉니다. 또한 API를 배우고 애플리케이션에 구현해야하지만, 이는 매우 빨리 흡수 할 수 있어야한다고 생각하는 일회성 비용입니다.

+0

에 따라 $ 0.14 GB- 달로 감소했습니다. 예 학습 api는 문제가되지 않습니다. 내가 분명히 밝히고 싶은 것은 서버 외부에서 통계를 제공하는 것 (즉, S3가 제공하는 것)이 내 RAM 사용에 긍정적 인 영향을 미치는지 여부이다. 나는 메모리 (RAM)가 내 서버의 병목 현상이 될 것이라고 예측한다. – javanes

+1

예. S3에서 서비스하면 EC2 인스턴스가이 책임에서 벗어나므로 일부 CPU 및 RAM 리소스가 절대적으로 절약됩니다. 얼마가 당신이 예상하는 소통량에 달려 있는지. 이 주제에 대한 다음의 Coding Horror 블로그 게시물을 확인하는 데 관심이있을 수 있습니다. http://www.codinghorror.com/blog/2007/03/using-amazon-s3-as-an-image-hosting-service.html –

52

가격 비교가 올바르지 않습니다. S3 요금은 GB USED 당 $ 0.14이며, EBS 요금은 사용 여부에 상관없이 PROVISIONED (EBS 볼륨의 크기) 당 $ 0.10입니다. 결과적으로 S3는 EBS보다 저렴할 수도 있고 아닐 수도 있습니다.

+11

아주 좋은 지적입니다. 아마도 코멘트가되어야합니다. 대답이 아닙니다. :) +1 어쨌든. – BMiner

+0

유효한 대답으로 보입니다. – Sorter

+0

질문은 S3와 EBS 사이를 결정하는 것과 관련하여 답으로 (주석이 아님) 이것을 선호합니다. 사용자는 두 지점 사이의 여유 공간 [우선 순위] (http://stackoverflow.com/a/38235022/4058484)에이 점을 우선 순위로 고려해야합니다. – hyip

5

이미지가 무한정 지속될 것으로 예상하십니까?

Amazon EBS FAQ는 매우 명확합니다. 연간 실패율은 "본질적으로 0"이 아닙니다. 그들은 0.1 %에서 0.5 %를 인용한다. 그것은 책상 밑의 디스크보다 낫지 만, 어떤 종류의 백업이 필요할 것입니다.

12

I 설정 stock photography TB의 데이터를 걸친 이미지의 수백만을 저장하는 사이트, 당신의 요구 사항에 대한 AWS에서 모범 사례의 일부 공유하고 싶습니다 위해 AWS에 솔루션을 구조화 한 :)

P1을 원본 이미지를 저장 S3 표준 옵션

P2)가 S3의 URL을 포함 이미지에 대한 비용

P3) 메타 데이터를 저장하는 S3 감소 중복 옵션 (RRS)의 엄지 손가락 등과 같은 재생 가능한 이미지를 저장할 수있는 파일은 아마존 RDS에 저장할 수 있습니다 또는 쿼리 복잡성에 따라 Amazon DynamoDB가 필요합니다. Amazon RDS에서 항목을 쿼리하십시오. 쿼리가 복잡하면 Amazon CloudSearch 또는 Apache Solr에 메타 데이터를 저장하는 것이 일반적입니다.

P4) Amazon CloudFront를 사용하여 대기 시간이 짧은 사용자에게 엄지 손가락을 배달하십시오.

P5) 이미지 변환을 대기열 중 하나는 EBS를 사용하려는 경우 아마존 EC2

P6)에 SQS 또는 RabbitMQ를 통해, 그들은 당신의 EC2와 확장 성이 없습니다. 이상적으로 GlusterFS를 모든 이미지에 대한 공통 스토리지 풀로 사용할 수 있습니다. 자동 확장 모드의 여러 Amazon EC2는 계속해서 연결하여 이미지에 액세스/쓰기 할 수 있습니다.