조대협의 블로그

원본 : http://aws.typepad.com/aws/2012/03/amazon-s3-performance-tips-tricks-seattle-hiring-event.html 아마존 S3를 이용하는 시스템에 대한 성능 테스트를 할때, 성능이 Leanear 하게 증가하지 않는데, 그 원인을 보면 다음과 같은 원리가 작용한다. 원인 분석S3는 내부적으로 여러개의 파일을 저정하기 위해서 물리적으로 파일을 여러개의 디스크에 분할 저장하는데, 이 분할 하는 로직을 파일명을 가지고 해쉬를 사용한다. 그래서 파일명이 유사하게 되면, 같은 파티션(디스크)에 파일이 써지기 때문에, 하나의 파티션에 많은 물리적인 IO를 유발하고 결과적으로 성능이 떨어지게 되는 것이다. 원리S3는 파일명을 가지고 hashing을 하여 ..

AWS (Amazon Web Service) 사용시 주의 사항 1. IP가 매번 바뀐다.aws의 ec2 instance는 restart시 마다 ip가 매번 바뀐다. ip를 바꾸지 않으려면 EIP (Elastic IP)를 사용해야 하는데, 비용이 크다. 그래서 이런 경우에는 aws에 자체 dns 서버를 세팅하고, instance 가 start up 될때 마다, 고유 서버의 dns 이름을 새로 binding된 ip와 맵핑해서 dns서버에 등록하도록 스크립트를 짜 놓으면 유용하다. 2. io bandwidth를 믿지 마라aws의 가장 큰 어려운 점이, 네트워크 대역폭이다. 아무래도 공유 서비스이다 보니 네트워크 대역폭이 매우 느리다. 즉 내부 서버간 예를 들어 application server - dbms 또..

이 구성은 Cassandra나 Riak과 같은 Dynamo 계열에 공통 적용 가능하다. 다른 것들도 마찬 가지일테지만. 1. RAID 5 사용 : NoSQL 클러스터는 Quorum 사용을 통해서 노드에 (서버) 대한 FAIL을 방지 하지만 디스크 장애 자체에 대해서는 보장이 불가능하다. 고로 비용 대비 적정한 RAID 5 사용이 권장 2. IO Scheduler : NOOP 사용. NOOP은 IO Scheduling을 다른 계층이 한다는 것을 전제 한다. 즉 중간에 RAID 구성이나 iSCSI 를 사용하는 경우를 전제한다. 테스트용이나 개발용으로 사용하면서 RAID 구성등을 하지 않는다면, NOOP을 사용할 필요가 없다. 3. ext4 또는 XFS 파일 시스템 사용 : ext3는 1 volume의 max..

NoSQL 하드웨어 구성에 있어서, DISK IO에 대한 메모. RAID 구성은 5가 정답 NoSQL의 N-Value를 통한 장애 대처 능력은 노드간 장애를 대처하기 위함이지, 노드의 디스크 장애 극복은 불가능함. 아주 큰 클러스터가 아니면 RAID 5가 정답, 아니면 스트라이핑 기반의 RAID 0가 정답(대규모 클러스터의 경우, 단 이 경우, 디스크 장애는 해당 노드의 장애를 의미함, 검출도 어려울듯...) IO Scheduler가 성능 튜닝 포인트라고는 하는데... 오늘 구글링에서 본 자료로는 Scheduler 바꾼다고 IO 자체 성능이 큰 차이가 없는 듯.. 이건 한번 테스트 해봐야 할듯. 결국은 네트워크 분리,캐쉬 튜닝을 어떻게 하느냐가 가능 큰 팩터가 될듯.