블로그 이미지
평범하게 살고 싶은 월급쟁이 기술적인 토론 환영합니다.같이 이야기 하고 싶으시면 부담 말고 연락주세요:이메일-bwcho75골뱅이지메일 닷컴. 조대협


Archive»


 
 

매우 기본적인 부분인데, 함정(?)이 있어서 메모해놓습니다.


aws에서는 S3 버킷을 만들때 위와 같이 Region을 정할 수 있습니다.

그런데 US Standard라는 Region이 있는데, 이는 실제 존재하는 region이 아닙니다. Oregon이나 Ireland와 같이 실제 S3가 배포될 region을 명시적으로 정하는 것이 좋습니다. (특히 미국의 경우..)

EC2를 US West Oregon에서 사용하실거면, 반드시 S3도 같은 Region에 생성을 해야 속도가 빠릅니다.


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


문서를 보면 region가 S3 속도가 나옵니다.



원본 : http://aws.typepad.com/aws/2012/03/amazon-s3-performance-tips-tricks-seattle-hiring-event.html


아마존 S3를 이용하는 시스템에 대한 성능 테스트를 할때, 성능이 Leanear 하게 증가하지 않는데, 그 원인을 보면 다음과 같은 원리가 작용한다.


원인 분석

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를 요구할 경우에는 파티션을 권장하고 있다.
이 키 기반의 파티셔닝은 단지 S3 뿐만 아니라, NoSQL이나 HDFS와 같은 분산 파일 시스템에도 동일한 원리로 적용되기 때문에 반드시 참고하기 바란다.


요즘 Personal Storage Service를 분석하다보니, Cloud Storage쪽을 많이 보게 되는데,
트렌드가 대부분 S3나 SWIFT같은 Blob Storage를 뒤에 넣고, 중간에 이를 File System으로 바꿔주는 서버 계층을 두고, Client에 마치 NDrive 처럼 Fuse를 이용해서 마운트 하는게 대세다.
CyberDuck같은 오픈 소스를 보면 KT SS나 Amazon S3등을 Storage로 저장해서 파일을 저장할 수 있게 해준다.

요즘 관심이 가는 부분이 이 구조에서 중간에 File System으로 바꿔주는 엔진 부분인데,
De-duplication쪽이 관심이다. 이유인 즉, SWIFT의 경우 데이타 안정성(무결성)을 보장하기 위해서 물리적으로 3Copy를 유지하기 때문에 Storage용량이 많이 소요되고, 이를 줄이는 방법은 De-duplication이 적절하다.

Deduplication이란, 파일을 여러개의 블럭(Chunk)로 나눈후에, 저장시에 나눠서 저장하고, Update될때는 변경된 Block만 저장하는 방식으로 파일이 일부만 변경되거나 여러명이 같은 파일을 사용할 경우 용량 절감 효과를 볼 수 있다.

S3나 SWIFT같은 Object Storage는 하나의 파일을 하나의 Object로 저장한다. 우리가 알고 있는 파일 시스템과 그 구조가 틀리기 때문에 중간 계층을 두는데, KT나 RackSpace의 파일 저장 서비스는 하나의 파일을 하나의 Object로 저장하는 구조지만, OpenDedup이나 몇몇 솔루션은 하나의 파일을 여러개의 Chunk로 나눈 후에, Chunk를 하나의 Object로 처리해서 저장한다.  이렇게 Chunk로 나눌 경우 Chunk를 동시에 전송해서 접근 속도를 높일 수 있고, dedup을 지원하여 스토리지 용량을 절약할 수 있지만, 반대로 Chunk를 나누고 계산하는 시간에 CPU가 많이 소요 되는 단점을 가지고 있다.

대표적인 오픈소스가 Opendedup이 있는데, 코드 구조가 정말 마음에 든다. :)
http://opendedup.org/
에 있다.
코드를 분석해보니 구조가 대충 다음과 같이 나온다.

 


크게 두개의 컴포넌트가 있는데, DedupFileEngine과 DedupStoreEngine이 있다. FileEngine은 파일단위의 관리를 하고, DedupStorageEngine은 실제 Storage 저장소에 저장되는 Chunk를 관리한다.

하나의 파일은 Dedup 파일이라는 클래스로 관리가 된다. Chunk단위로 나뉘어진 데이타는 WritableCacheBuffer라는 형태로 메모리에 저장되고, Disk에 Writing될때, HCServiceProxy라는 컴포넌트가 Routing을 해서 DedupStorageEngine으로 보낸다. 이때 Routing을 Chunk의 첫번째 Byte의 Hash값을 0~255로 계산하여 Routing을 한다.

파일에 대한 메타 정보 - 디렉토리,Path,LastAccess,Permission등은 MetaDataDedupFile이라는 저장공간에 저장이 되며, 이 컴포넌트는 JDBM이라는 오픈 소스를 사용한다.

이 DedupFile들은 묶음으로 DedupFileStore라는 곳에 저장된다.
파일 전송을 위해서 각 DedupFile은 DedupFileChannel을 가지고 있고, 클라이언트에 파일을 전송하는 Network interface로 사용된다.

OpenDedup은 이 파일 시스템을 NFS나 CIFS등으로 시스템에 Mount할 수 있는데, 이 파일 시스템을 Mount하는 것은 Open Source의 Fuse를 사용한다.