아마존 S3 소개 (성능 향상)

Amazon S3 (Simple Storage Service)

AWS S3 (Simple Stoage Service)는 파일을 저장하기 위한 스토리지이다. 일반적인 파일시스템의 개념과는 약간 다르고, 파일 이름을 대표하는 key와 파일 자체로 구분되는 Object Storage이다.

용량 저장할 수 있는 파일의 크기는 개당 1byte~5TB이고, 총 저장 용량에는 제한이 없다. 디렉토리와 비슷한 개념으로, bucket이라는 개념을 가지고 있다.

기본적으로 3 copy를 지원하여, 데이타를 복제하고, 이 복제는 Amazon availability zone (AZ) 단위로 복제가 되기 때문에 데이타 센터 장애에 대한 대응성을 가지고 있다. 단 region 간 복제는 지원하지 않는다. 복제에 관련된 옵션으로는 RRS (Reduced Redundancy Storage)라는 것이 있는데, 이 옵션을 적용하면, 2 copy (원본 + 백업)만을 저장하기 때문에, 가격이 훨씬 더 저렴하다. 3 copy를 저장할 경우, S3에 대한 데이타 신뢰도는 99.999999999% 를 보장하고, 서비스에 대한 가용성은 99.99%를 보장한다.

S3에 접근하기 위한 인터페이스는 일반적은 file io api등은 사용할 수 없으며, REST/HTTP 기반의 프로토콜만 지원한다. 그래서, 성능이 다른 파일 시스템에 비해서 느리다.

그 외에 기타 부가적인 기능들을 살펴 보면 다음과 같다.

①     Retaining 기능 : 다른 주목할만한 기능 은 retain 기간을 지정할 수 있다. 즉 파일의 저장 기간을 지정할 수 있고, 그 기간이 지나면 자동으로 삭제가 된다.

②     Versioning : 저장된 파일에 대해서 여러 버전을 저장 및 관리할 수 있다. 참고로 이전 버전으로 저장된 파일 역시 똑같이 과금 되기 때문에, 금액 부분에 대해서 신경을 쓰기 바란다.

③     Encryption : S3는 상당히 다양한 형태의 암호화를 지원한다. HTTPS를 이용한 전송단의 암호화에서 부터, Server에서 저장될때 암호화를 적용할 수 있으며, Client에서 전송할때나 받을때, 암호화된 형태로 데이타를 주고 받을 수 있다.

타 시스템과 연동 관점에서 S3 서비스는 AWS 내에서 대용량 데이타를 저장하기 가장 알맞은 저장소이다. 그래서 다른 AWS의 서비스 (EMR 나 CloudFront, Glacier 등)에 자연스럽게 연동될 수 있는 기능을 제공하며, 다른 서비스들과 상호보완적인 관계를 갖는다. 예를 들어 SQS와 같은 큐 서비스에는 큰 객체(파일)을 저장할 수 없기 때문에 이벤트 메세지는 SQS에 저장하고, 실제 큰 파일은 S3에 저장해서 레퍼런스를 하던가, Dynamo와 같은 NoSQL DB도 레코드당 데이타 한계로 인해서, 메타 데이타는 Dynamo에 저장하고, 파일과 같은 큰 바이너리 데이타는 S3에 저장하고 레퍼런스를 하게 할 수 있다.

Partitioning

S3를 사용하면서 데이타의 양이 늘어나게 되면 성능이 떨어지게 되는 것을 체감할 수 있다.

S3는 내부적으로 여러개의 파일을 저정하기 위해서 물리적으로 파일을 여러개의 디스크에 분할 저장하는데, 이 분할 하는 로직을 파일명을 가지고 해쉬를 사용한다. 그래서 파일명이 유사하게 되면, 같은 파티션(디스크)에 파일이 써지기 때문에, 하나의 파티션에 많은 물리적인 IO를 유발하고 결과적으로 성능이 떨어지게 되는 것이다.

S3는 파일명을 가지고 hashing을 하여 파일을 분산 저장한다고 했다. 더 정확하게 이야기 하면 파일명의 앞부분인 prefix를 가지고 분산 키로 사용한다.

즉 예를 들어 파일명이

server.2012-12-31

server.2012-12-30

server.2012-12-29

server.2012-12-28

과 같이 앞의 prefix가 같다면, 파일은 같은 파티션에 저장될 가능성이 많다.

그래서 앞의 file prefix를 다양한 이름으로 바꿔 주는 것이 좋다.

예를 들어 일정 디렉토리 (디렉토리명으로도 파티셔닝이 된다.)로 다음과 같이 구분한다

a/server.2012-12-31

b/server.2012-12-30

c/server.2012-12-29

d/server.2012-12-28

위와 같은 구조를 취하면, 최소 4개 파티션에 분할 저장된다.

또는 위의 파일명의 경우 맨 마지막이 날짜로 rotation되는 형태이기 때문에, 다음과 같은 파일명으로 저장해도 파티셔닝 효과를 볼 수 있다.

13-21-2102.server

03-21-2102.server

92-21-2102.server

S3에서 내부적으로 어떤 원리로 partitioning을 하는지는 정확하게 나와 있지 않다. 단지 prefix를 이용한다고만 나와 있는데, 최소한 파일명(또는 디렉토리명)을 다른 문자로 시작하게 하면, 골고루 파티션에 분산하여 저장할 수 있다고 가이드 하고 있다.

최소한 50 TPS 이상의 S3 IO를 요구할 경우에는 파티션을 권장하고 있다.

※     참고 : http://aws.typepad.com/aws/2012/03/amazon-s3-performance-tips-tricks-seattle-hiring-event.html

이 키 기반의 파티셔닝은 단지 S3 뿐만 아니라, NoSQL이나 HDFS와 같은 분산 파일 시스템에도 동일한 원리로 적용되기 때문에 반드시 참고하기 바란다.

Bucket의 위치에 대해서

성능 관련해서 가장 기본적인 부분인데, 많이 실수하는 부분이 S3의 Bucket을 만들때 애플리케이션과 다른 Region에 Bucket을 만드는 경우가 있는데, 이 경우 성능 저하가 매우 심하게 발생한다.

Bucket을 만들때는 반드시 같은 애플리케이션이 실행되는 region과 반드시 같은 region을 사용하도록 한다.

http://blog.takipi.com/2013/03/20/aws-olypmics-speed-testing-amazon-ec2-s3-across-regions/

문서를 참고해보면, 각 region간의 평균적인 속도가 나오니 참고하기 바란다

Multipart uploading

S3에는 파일을 업로드 할때, multipart uploading이라는 기능을 제공한다. ( http://aws.typepad.com/aws/2010/11/amazon-s3-multipart-upload.html )

파일을 하나의 Connection에서 쭈욱 올리는 것이 일반적인 방법이라면

파일을 여러개의 블럭으로 나눠서 동시에 여러개의 Connection을 통해서 업로드 하는 방법이다. 이 경우 업로드가 Parallel하게 이루어지기 때문에 상당 부분의 성능 향상을 가지고 올 수 있다.

또 다른 장점은 큰 파일 하나를 여러개의 블럭으로 나눠서 전송하기 때문에, 만약에 전송중에 특정 블럭 전송이 실패하면, 전체 파일을 재 전송할 필요가 없이 실패한 특정 블럭만 다시 전송하면 된다. 이 multipart 업로드 기능을 구현은 SDK 형태로 재공되는 라이브러리를 사용하면 된다.

http://docs.aws.amazon.com/AmazonS3/latest/dev/uploadobjusingmpu.html

아마존 가이드에서는 100MB 이상의 파일 전송시에 권장하고 있는데, 사용해본 결과 꼭 100MB가 아니더라도 그 이하의 크기의 파일 전송에서도 충분한 성능 증가를 볼 수 있으니, 대규모의 업로드를 사용하는 경우 single upload vs multipart upload 성능을 테스트해보고 결정하기를 권장한다.

 

사용법이 매우 간단한 서비스이기는 하지만, 쉽고 안전하며, 데이타 저장소로써 필수적인 기능등은 거의 다 갖추고 있으며, 저렴한 가격에, 다른 서비스와 연계성이 높기 때문에, 필히 익혀둬야 하는 서비스이다. 단 S3를 이용한 시스템 설계시에는 일반 파일 시스템과 같은 형태로 접근을 하면 안된다. HTTP 형식으로 접근을 하기 때문에, 성능이 그만큼 나오지 않는다. 이 부분에 대한 고려만 충분히 하면 AWS에서 EC2 다음으로 가장 가치가 높은 서비스가 아닐까 싶다.