조대협의 블로그

I have summarized some of the follow-ups below as discussed: User Data and Meta Data – that can be used for bootstrapping as we discussed and I showed you a demonstration of - documentation: http://docs.amazonwebservices.com/AWSEC2/latest/UserGuide/AESDG-chapter-instancedata.html IP Addresses in VPC Auto Scaling Groups: Auto Scaling will automatically assign IP addresses using the DHCP provider ..

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 또..

AWS SQS(Simple Queue Service) AWS SQS(Simple Queue Service)는 말 그대로, Simple 한 message queue 서비스 이다.전반적인 기능을 보면 message에 대한 send, receive 기능만 가능하다.대신 AWS 클라우드 환경에서 메세지의 복제를 통해서 장애 대비 능력에 촛점이 맞춰져 있다. JMS 처럼 XA 기반 트렌젝션 관리 능력이나, Error Queue에 대한 처리, auto retry와 같은 고급 기능도 없고RabbitMQ 처럼, routing,pub/sub 등의 다양한 message exchange pattern도 지원하지 않는다. 단순한 enqueue/dequeue 기능의 큐이다. 몇 가지 특성을 살펴보면 1. message 크기는 ..

Amazon RDS 성능은 물리 서버의 30% 정도일 뿐!Amazon RDS에서 DB 테이블 재구성하는 이슈가 있어서 물리 장비 테스트 후 Amazon RDS에 적용한 적이 있습니다. 사용하고 있는 Amazon RDS 인스턴스가 성능이 나쁘지 않은만큼 물리 장비 대비 크게 뒤쳐지지 않을 것이라고 예상을 했습니다.그러나, 실제 적용해본 결과, 물리 서버 대비 30%정도 퍼포먼스만 발휘하는 결과가 나왔습니다. 로컬 물리 DB에서 15분 걸리던 작업이, Amazon RDS에서는 45분 이상 소요가 된 사례가 있습니다. 예상 시간보다 상당히 오래 걸려서 크게 당황을 했었죠.무엇보다 MySQL은 단일 쓰레드에서 Nested Loop 방식으로 SQL을 처리하기 때문에, CPU의 성능이 전체적인 DB 퍼포먼스에 직접..

AWS의 Zone은 같은 지역에 있는 물리적으로 다른 데이타 센터의 개념을 이야기 함.RDS의 Multi Zone replication은 한 데이타 센터가 고장 나더라도 다른 데이타 센터에서 서비스가 가능한 구조.기본적으로 Active-Stand by 형태로 복제하다가, 장애가 나면 stand by 서버로 fail over하는 구성 중요한 것중 하나는 MySQL RDS의 경우 자동 Back 시, 시스템이 일시적으로 멈추는 현상이 보이는데, Multi AZ deploy의 경우, back up시에, 자동 fail over하여, 멈추는 현상 없이 서비스가 가능함 http://aws.amazon.com/ko/about-aws/whats-new/2010/05/18/announcing-multi-az-deploym..

메모를 안해놓으면 또 까먹기 때문에, 정리 차원에서 몇가지 정리 1. MySQL HA over AWS먼저 MySQL을 아마존 위에서 Zone간 Fail Over를 위해서 몇가지를 고민했다. 1) MySQL ClusterMySQL의 클러스터링 버전으로, Zone간 Fail Over가 이론적으로 가능하다. 제품 자체도 기존 MySQL과 상당히 차별화 되어 있다.그러나 가격이 상당히 비싼 편이고, 아직은 AWS위에 deployment된 reference가 없기 때문에 상당한 risk를 둬야 한다. 2) Garela, Tungsten오픈소스로 Replication을 보장하지만, 국내 Support가 없기 때문에, Bug Fix가 어렵다. 그래서 Pass 3) HAProxy상당히 재미있는 개념인데, Proxy로 ..

미국의 NoSQL 인기 순위를 분석해보니, mongodb가 앞도적인 1위, 2위권은 cassandra,hbase 그리고 다음이 redis 맨 아래로 riak,couchdb 등이 있다.아무래도 기능이 편리한 mongodb 가 단연 인기고, 난이도는 있지만 확장성에 우위가 있는 cassandra,hbase가 그 뒤를 따른다. 분석 방법은 indeed.com 이나 monster.com의 구인 광고중, 해당 기술별 구인 광고를 분석하였다. mongodb 276cassandra 149hbase 146redis 91coherence 53couchdb 40riak 24

NoSQL 데이타 모델링 #2Facebook Server Side Architecture Group http://www.facebook.com/groups/serverside 조대협NoSQL 데이타 모델링 패턴 NoSQL 데이타 모델링 패턴[1]은 Key/Value 저장 구조에 Put/Get 밖에 없는 단순한 DBMS에 대해서 다양한 형태의 Query를 지원하기 위한 테이블을 디자인하기 위한 가이드 이다. 특히 RDBMS에는 있는 “ Order by를 이용한 Sorting, group by를 이용한 Grouping, Join등을 이용한 개체간의 relationship 정의, 그리고 Index 기능” 들을 데이타를 쿼리하는데, 상당히 유용한 기능인데, NoSQL은 이러한 기능들을 가지고 있지 않기 때문에,..

NoSQL 데이타 모델링 #1Facebook Server Side Architecture Group http://www.facebook.com/groups/serverside 조대협빅데이타,클라우드,NoSQL은 요즘 기술적인 화두중에 하나이다. 그중에서도 NoSQL은 많은 사람이 관심을 갖고 있음에도 불구하고, 기존의 RDBMS 데이타 모델링 관점에서 접근을 하기 때문에, 많은 문제를 유발한다. NoSQL은 데이타 베이스이기도 하지만 RDBMS와는 전혀 다른 성격을 가지고 있고, 접근 방식도 틀리다. 특히 테이블 구조를 정의 하는 데이타 모델에 따라서 NoSQL의 성능은 하늘과 땅차이만큼 차이가 난다. 이 글에서는 NoSQL의 데이타 모델링 기법에 대해서 소개하고자 한다.※ 깨지는 그림은 클릭해서 봐주세..

대용량 시스템 레퍼런스 디자인 SSAG - Face book Server Side Architecture Grouphttp://www.facebook.com/groups/serverside조대협 (bwcho75 골뱅이 지메일닷컴) I. 배경웹로직,JBOSS 가 유행이던, J2EE 시대만 하더라도, 웹서버+WAS+RDBMS면 대부분의 업무 시스템을 구현할 수 있었다. 오픈소스가 유행하면서 부터는 프레임웍 수는 다소 많기는 했지만 Spring,IBatis or Hibernate,Struts 정도면 대부분 구현이 가능했다.그러나 근래 수년 동안 벤더 중심에서 오픈소스 중심에서 기술의 중심이 구글,페이스북이 주도하는 B2C 기반의 서비스의 유행과 더불어 대규모 분산 시스템을 위한 대용량 아키텍쳐가 유행하게 되었..