#3 클라우드 컴퓨팅 구현기술(4월26일 공부내용

1. 분산 코디네이터

1) 분산 락이나 동기화 문제

• 접근방법
  (1) NFS 같은 파일 공유 서비스 이용 : 모든 서버에 특정 디렉토리를 마운트 시키고 파일 락을 이용
  (2) DB 이용 : 레코드 락을 이용하여 락을 획득한 서버만 자원에 접근하게 함
  

• 단점
  둘 다 락 요청이 많아지면 서버에 부하가 집중되어 SPOF(Single Point Of Failure)가 될 수 있다.

2) 이중화

 - 고가용성을 위해 서버를 이중화 구성을 많이 한다. Active-Active, Active-Standby로 구성된다. 영어 단어처럼 활동하는 서버, 대기 서버라고 보면 된다.

3) 주키퍼(야후의 분산 코디네이터)

 - 분산 환경에서 코디네이터 서비스를 제공하는 아파치 오픈소스이다.

 - 네임 서비스, 환경설정, 그룹 멤버십, Double Barriers, 우선순위 큐, 공유 락 제어, 두 단계 커밋, 리더 선출 

 - 위와 같은 기능을 제공하는 것이 아니라 이런 기능을 쉽게 만들 수 있도록 메카니즘을 제공

 - 하둡과는 연관이 없음

 - 구글의 처비를 많이 참고했다고 알려짐

그림 1) 주키퍼 시스템 구성

(http://creatorw.tistory.com/tag/%EC%A3%BC%ED%82%A4%ED%8D%BC)

 - 주키퍼 서버는 데이터를 파일 트리노드와 같이 계층적으로 저장하고, 저장된 데이터는 주키퍼 서버들 사이에 복제되어 일부 서버가 장애를 발생해도 서비스를 계속해서 할 수 있음(데이터는 서버상태, 락 정보, 환경설정 정보 등과 같은 크기가 작은 메타데이터를 주로 저장)

 - 클러스터는 항상 3대 이상의 서버로 구성되야 함(분산시스템 시간에 배웠는데 까먹었다....) 아마 장애 발생 관련 이유일 것이다...

그림 2) 주키퍼 데이터 모델

(http://creatorw.tistory.com/53)

 - 파일 시스템은 로컬에 저장되어 있거나 마운트 되어 있는 파일과 디렉토리에 대한 접근을 수행하지만, 주키퍼는 클라이언트 라이브러리를 이용하여 네임스페이스에 대한 조회, 노드에 저장된 데이터를 원격 클라이언트에서도 접근할 수 있는 분산 시스템이다. 또한 데이터는 메모리에 존재하나 로그와 스냅샷 파일은 로컬 디스크에 저장된다. zoo.cfg에서 로그와 스냅샷을 로컬 어디에 저장할지 설정할 수 있다.

4) 주키퍼 예제

- zookeeper라이브러리 하나만 추가를 했는데 에러가 났다. 그래서 thrift때 사용하던 라이브러리 몇개를 추가시키니 실행이 되었다. log4j, slf4j-api, slf-log4j......

5) 정합성(Consistency)

 - DB는 정합성을 만족해야 한다.

  정합성이란? 모든 클라이언트는 항상 동일한 데이터를 보장받는 것을 의미한다.

  하지만 분산 서버에 데이터가 저장된 후 처리결과를 보내는 강한 정합성(빠르게 처리결과를 보여줌)이 아닌 이벤추얼(Eventual) 정합성을 갖고 있다. 이벤추얼 정합성은 수밀리 초내로 처리결과를 보여주는 것이 아니라 시간은 조금 늦으나 결과는 같아져 동일한 데이터를 보장할 수 있도록 하는 개념이다.

6) 크롤링이란? 최신 상태의 페이지를 유지하기 위해 웹을 탐색하는 것을 말한다.

http://v.daum.net/link/16695860