zookeeper 살짝 보기
- Posted at 2009/03/25 19:40
- Filed under project/lucene_hadoop
zookeeper는 hadoop 서브 프로젝트 중 하나입니다. 구글 플랫폼 중 chubby에 해당합니다. chubby는 분산 락(lock) 서비스를 제공하는 플랫폼입니다. 분산 락 서비스에 대한 개념이 다소 생소한데 다음과 같이 이해하시면 됩니다.
분산된 환경에서 fault tolerant 한 시스템을 구성하기 위해서 어려운 부분이 공유 정보를 어디에 저장할 것인가 하는 부분입니다. 클러스터 환경에서 마스터 서버의 호스트 정보나 클러스터 참여하는 멤버들의 정보를 어디에선가 관리를 해야 하는데 이런 정보를 저장하는 무언가가 장애에 취약하다고 한다면 해당 클러스터를 아무리 견고하게 만들어도 장애에 취약하게 됩니다. 이런 부분은 SPOF(Single Point Of Failure)라고 하죠.
chubby는 보통 5대의 노드로 구성되며 5대의 노드에서 관리하는 모든 정보는 동기화됩니다. 즉 복제본이 5개 있게 됩니다. 5개의 노드사이에 네트워크가 단절될 경우 등에 대비는 내부적으로 처리하고 있기 때문에 chubby를 사용하는 사용자는 chubby에 저장되어 있는 데이터는 무조건 안전하다고 생각하면 됩니다.
chubby에 저장하는 정보는 lock인데 lock을 파일 시스템과 유사한 형태로 제공하기 때문에 사용자 입장에서는 replication 5이고 lock을 제공하는 작은 규모의 분산 파일 시스템처럼 보입니다.
lock의 생성, 삭제, 내용 변경 등과 같이 lock의 상태가 변경되었을 때 미리 등록되어 있는 클라이언트로 이벤트를 전송하는 기능을 수행합니다.
이런 기능을 이용하여 클러스터 관리 시스템을 쉽게 구성할 수 있습니다.
1. 클러스터 관리 시스템은 node 정보를 저장하는 path(예를 들면 /clusterA/nodes/)에 llock 정보가 변경되면 ock 이벤트를 받을 수 있도록 이벤트 콜백을 미리 등록한다.
2. 클러스터에 참여하는 노드가 시작될 때 chubby의 특정 path(예를 들면 /clusterA/nodes/) 아래에 에 노드의 호스트명을 이용하여 lock(/clusterA/nodes/10.12.111.11)을 생성한다.
3. chubby는 해당 path에 변경이 발생하면 콜백으로 등록된 클라이언트로 이벤트를 전송한다.
4. 클러스터 관리 시스템은 이벤트를 받아 새로 추가된 노드 정보를 받아서 클러스터에 추가한다.
5. 노드는 생성된 lock을 계속 유지한다.(chubby 모듈이 백그라운드로 세션을 유지시켜줌)
6. 노드에 장애가 발생하여 lock을 유지하지 못하면 chubby는 해당 path(/clusterA/nodes/10.12.111.11)의 lock을 해제시키고 해제된 정보를 이벤트로 보낸다.
7. 클러스터 관리 시스템은 이벤트를 받아 클러스터에서 제거한다.
이것은 chubby를 사용하는 하나의 사례일 뿐 다양한 용도로 사용할 수 있습니다. neptune의 경우 ROOT Tablet이 어느 TabletServer에서 서비스되고 있는 지에 대한 정보를 분산 락 서비스(pleiades)에 저장하고 있습니다.
이런 chubby와 동일한 기능을 수행하도록 만들어진것이 zookeeper입니다. zookeeper를 잠깐 살펴 보았는데 다른 기능은 자세히 못봤지만 다음 기능이 독특해 보였습니다.
zookeeper는 다음과 같은 특징이 있습니다.
- 이벤트 콜백은 한번만 유효하다.
왜 이렇게 구성했는지는 문서를 좀 봐야 하겠지만 이벤트는 다음과 같이 동작합니다. zookeeper 클라이언트 모듈을 사용하여 특정 path에 이벤트를 등록해 놓으면 해당 이벤트가 발생하여 등록된 callback 을 수행하면 등록된 callback은 제거되어 다시 받지 못하는 구조입니다. 즉 one-time callback 이라고 보시면 됩니다.
따라서 다시 받고 싶으면 등록을 다시 해야 하는데 처리하고 다시 등록하는 사이에 동일한 이벤트가 발생했다면 이벤트를 받지 못할 가능성이 존재하게 됩니다. 이 부분이 문제가 되는 부분이죠...
그리고 callback 등록하는 API 시멘틱이 조금 이상하게 되어 있습니다.
zookeeper.addWatcher(path, new MyWatcher()) 이런식이 될 줄 알고 열심히 찾아 봤는데
zookeeper.getData(path, new MyWatcher()); 또는
zookeeper.exists(path, new MyWatcher()); 와 같이 합니다.
하나의 메소드를 두가지 용도로 사용하고 있는거죠 getData()의 경우 path에 있는 데이터를 가져오는 기능과 watcher가 not null인 경우 callback을 등록하는 두가지 의미를 수행하고 있었습니다. 깔끔한 설계는 아닌 듯합니다. 제가 잘못 알고 있을수도 있고요... 암튼 좀더 자세히 본 후에 다시 포스팅 하겠습니다.
분산된 환경에서 fault tolerant 한 시스템을 구성하기 위해서 어려운 부분이 공유 정보를 어디에 저장할 것인가 하는 부분입니다. 클러스터 환경에서 마스터 서버의 호스트 정보나 클러스터 참여하는 멤버들의 정보를 어디에선가 관리를 해야 하는데 이런 정보를 저장하는 무언가가 장애에 취약하다고 한다면 해당 클러스터를 아무리 견고하게 만들어도 장애에 취약하게 됩니다. 이런 부분은 SPOF(Single Point Of Failure)라고 하죠.
chubby는 보통 5대의 노드로 구성되며 5대의 노드에서 관리하는 모든 정보는 동기화됩니다. 즉 복제본이 5개 있게 됩니다. 5개의 노드사이에 네트워크가 단절될 경우 등에 대비는 내부적으로 처리하고 있기 때문에 chubby를 사용하는 사용자는 chubby에 저장되어 있는 데이터는 무조건 안전하다고 생각하면 됩니다.
chubby에 저장하는 정보는 lock인데 lock을 파일 시스템과 유사한 형태로 제공하기 때문에 사용자 입장에서는 replication 5이고 lock을 제공하는 작은 규모의 분산 파일 시스템처럼 보입니다.
lock의 생성, 삭제, 내용 변경 등과 같이 lock의 상태가 변경되었을 때 미리 등록되어 있는 클라이언트로 이벤트를 전송하는 기능을 수행합니다.
이런 기능을 이용하여 클러스터 관리 시스템을 쉽게 구성할 수 있습니다.
1. 클러스터 관리 시스템은 node 정보를 저장하는 path(예를 들면 /clusterA/nodes/)에 llock 정보가 변경되면 ock 이벤트를 받을 수 있도록 이벤트 콜백을 미리 등록한다.
2. 클러스터에 참여하는 노드가 시작될 때 chubby의 특정 path(예를 들면 /clusterA/nodes/) 아래에 에 노드의 호스트명을 이용하여 lock(/clusterA/nodes/10.12.111.11)을 생성한다.
3. chubby는 해당 path에 변경이 발생하면 콜백으로 등록된 클라이언트로 이벤트를 전송한다.
4. 클러스터 관리 시스템은 이벤트를 받아 새로 추가된 노드 정보를 받아서 클러스터에 추가한다.
5. 노드는 생성된 lock을 계속 유지한다.(chubby 모듈이 백그라운드로 세션을 유지시켜줌)
6. 노드에 장애가 발생하여 lock을 유지하지 못하면 chubby는 해당 path(/clusterA/nodes/10.12.111.11)의 lock을 해제시키고 해제된 정보를 이벤트로 보낸다.
7. 클러스터 관리 시스템은 이벤트를 받아 클러스터에서 제거한다.
이것은 chubby를 사용하는 하나의 사례일 뿐 다양한 용도로 사용할 수 있습니다. neptune의 경우 ROOT Tablet이 어느 TabletServer에서 서비스되고 있는 지에 대한 정보를 분산 락 서비스(pleiades)에 저장하고 있습니다.
이런 chubby와 동일한 기능을 수행하도록 만들어진것이 zookeeper입니다. zookeeper를 잠깐 살펴 보았는데 다른 기능은 자세히 못봤지만 다음 기능이 독특해 보였습니다.
zookeeper는 다음과 같은 특징이 있습니다.
- 이벤트 콜백은 한번만 유효하다.
왜 이렇게 구성했는지는 문서를 좀 봐야 하겠지만 이벤트는 다음과 같이 동작합니다. zookeeper 클라이언트 모듈을 사용하여 특정 path에 이벤트를 등록해 놓으면 해당 이벤트가 발생하여 등록된 callback 을 수행하면 등록된 callback은 제거되어 다시 받지 못하는 구조입니다. 즉 one-time callback 이라고 보시면 됩니다.
따라서 다시 받고 싶으면 등록을 다시 해야 하는데 처리하고 다시 등록하는 사이에 동일한 이벤트가 발생했다면 이벤트를 받지 못할 가능성이 존재하게 됩니다. 이 부분이 문제가 되는 부분이죠...
그리고 callback 등록하는 API 시멘틱이 조금 이상하게 되어 있습니다.
zookeeper.addWatcher(path, new MyWatcher()) 이런식이 될 줄 알고 열심히 찾아 봤는데
zookeeper.getData(path, new MyWatcher()); 또는
zookeeper.exists(path, new MyWatcher()); 와 같이 합니다.
하나의 메소드를 두가지 용도로 사용하고 있는거죠 getData()의 경우 path에 있는 데이터를 가져오는 기능과 watcher가 not null인 경우 callback을 등록하는 두가지 의미를 수행하고 있었습니다. 깔끔한 설계는 아닌 듯합니다. 제가 잘못 알고 있을수도 있고요... 암튼 좀더 자세히 본 후에 다시 포스팅 하겠습니다.
Posted by 김형준
- Response
- No Trackback , 5 Comments
Trackback URL : http://www.jaso.co.kr/trackback/338
Comments List
-
cloud computing과 집단지성과는 집단지성관 관련된 데이터 분석을 하기 위해서는 대량의 컴퓨팅 환경이 필요한데 클라우드 컴퓨팅이 이런 문제를 해결해 줄 수 있는 거죠... 물론 클라우드 컴퓨팅이 아니라 분산컴퓨팅에서도 해결하지만 클라우드 컴퓨팅은 이런 기술을 모두 포함하고 있는 거죠...
