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


Archive»


 

'cluster'에 해당되는 글 4

  1. 2015.05.18 Apache Spark 클러스터 구조
  2. 2012.10.29 MySQL HA over AWS 옵션
  3. 2011.11.10 Redis 관련 정보
  4. 2009.11.18 MySQL cluster geographic replication
 



Apache Spark Cluster 구조

스팍의 기본 구조는 다음과 같다.
스팍 프로그램은 일반적으로 “Driver Program”이라고 하는데, 이 Driver Program 은 여러개의 병렬적인 작업으로 나뉘어져사 Spark의 Worker Node(서버)에 있는  Executor(프로세스)에서 실행된다.



1. SparkContext가 SparkClusterManager에 접속한다. 이 클러스터 메니져는 스팍 자체의 클러스터 메니져가 될 수 도 있고 Mesos,YARN 등이 될 수 있다. 이 클러스터 메니저를 통해서 가용한 Excutor 들을 할당 받는다
2. Excutor를 할당 받으면, 각각의 Executor들에게 수행할 코드를 보낸다.
3. 다음으로 각 Excutor 안에서 Task에서 로직을 수행한다.


  • Executor : Process
  • Task : A Unit of work that will sent to one executor

cf. Storm 과 개념이 헷갈릴 수 있는데, 
Storm 은 Node가 하드웨어 서버, Worker가 프로세스,Executor가 쓰레드
Spark 은 Worker Node가 하드웨어 서버, Executor가 프로세스 이다.  


MySQL HA over AWS 옵션

클라우드 컴퓨팅 & NoSQL | 2012.10.29 22:39 | Posted by 조대협

메모를 안해놓으면 또 까먹기 때문에, 정리 차원에서 몇가지 정리


1. MySQL HA over AWS

먼저 MySQL을 아마존 위에서 Zone간 Fail Over를 위해서 몇가지를 고민했다.


1) MySQL Cluster

MySQL의 클러스터링 버전으로, Zone간 Fail Over가 이론적으로 가능하다. 제품 자체도 기존 MySQL과 상당히 차별화 되어 있다.그러나 가격이 상당히 비싼 편이고, 아직은 AWS위에 deployment된 reference가 없기 때문에 상당한 risk를 둬야 한다.


2) Garela, Tungsten

오픈소스로 Replication을 보장하지만, 국내 Support가 없기 때문에, Bug Fix가 어렵다. 그래서 Pass


3) HAProxy

상당히 재미있는 개념인데, Proxy로 어떻게 DB Replication을 하느냐 하는 의문이 들었는데, 원리 자체는 쉽다. 양쪽 Zone에 MySQL을 배치한후, 그 앞에 HAProxy를 넣어서, SQL 부하를 양쪽에 똑같이 분산 시킨다(복제) 즉. insert SQL을 치면 양쪽에 모두 보내서 복제 하는 방식이다. Garela가 이런 방식의 구현 방식을 취한다고 한다.

그러나, 이 아키텍쳐의 경우 Application단에서, write/read를 명시적으로 나눠줘야 하고, error 핸들링이 어려우며 분산 트렌젝션 처리등이 어려운 제약 사항을 가지고 있다.


4) RDS
만사 제일 편한 옵션이기는 한데, 다양한 replication architecture 사용이 어렵다. 그리고 MySQL over EC2에 비해서 용량상 제약이 따른다.


5) Oracle Golden Gate

일단 내가 아는 DB Replication 솔루션 중에 최강이다. 그만큼 가격도 최강이다. 모 업체가 위의 옵션을 다 고민도 해보고 production에 적용도 해봤는데,결론이 OGG(Oracle Golden Gate)로 왔다.


기본적으로 이러한 여러가지 옵션이 존재하는 이유가, MySQL EE의 HA 옵션은 DBCR (Linux의 HA솔루션)을 이용하는 방식인데, 전통적인 HA 방식으로 서버가 죽으면, 상대편 서버로 HA하면서 IP를 옮기는 방식인데, 아마존에서는 작동을 안한다고 한다. 그리고 Fail over는 IP를 넘겨서 한다고 쳐도 (물론 back단에서는 MySQL 의 기능을 이용해서 data replicaiton을 해야 한다.) Fail Back이 어떻게 되는지에 대해서 상세한 시나리오는 없다.

조금 더 리서치가 필요한 영역이긴 한데, 이미 다들 안되는 방향으로 잡아서 더 이상 파보지는 않았다.


Redis 관련 정보

클라우드 컴퓨팅 & NoSQL/Redis | 2011.11.10 10:44 | Posted by 조대협

Redis는 Memcached의 대안으로 사용할 수 있는 솔루션이다.
성능이나 구조도 memcached에 비해서 나은 것 같은 것 같고, 클러스터, Pub/Sub 기능도 있다.

Redis Tutorial
http://simonwillison.net/static/2010/redis-tutorial/

Redis Cluster
http://redis.io/presentation/Redis_Cluster.pdf

물리적으로 분리된 위치에서 데이타 SYNC에 대한 솔루션을 research 하던중에 mysql에 대한 이야기가 많이 나온다. Facebook도 master 와 slave center (미국 서부와 동부)의 데이타를 mysql georeplication 을 이용해서 구현한것으로 보인다.


MySQL georeplication의 원리는 위의 그림과 같다. Master node의 변경 사항을 BinLog라는 형태로 저장하여 복제 대상에 전송한후 replay를 하는 방식이다. record & replay 방식인데, binlog는 오라클의 redo 로그와 유사하다. 데이타베이스의 redo 로그 자체를 레코딩해서 전송하는 방식이기 때문에 데이타 복제만이 가능하고 ETL과 같은 변환은 불가능하며, 변경된 부분만 전송하기 때문에, 성능이 빠르다. 그리고 XA(분산 트렌젝션)처리 등이 필요하지 않다.
사실 이 개념은 DR센터(재해복구를 위한 백업센터)로 데이타를 복제하는 아키텍쳐에 많이 사용되어 왔고, IBM의 CDC나 오라클의 Golden Gate가 매우 유사한 아키텍쳐를 사용한다.
그나저나 MySQL사용해본지가 몇년전인데, 정말 좋아졌다.