Transcript HADOOP 주키퍼
HADOOP
주키퍼
• 주키퍼 - 주키퍼는 하둡의 분산 상호조정 서비스를 이용하여 일반적 인 분산 응용프로그램을 구축하는 방법에 대해 다룬다.
- 분산 응용프로그램 작성은 부분적 실패 때문에 힘든데, 주키퍼는 부분적 실패를 안전하게 다루면서 분산 응용프로 그램을 구축하도록 Tool을 제공한다.
• 주키퍼
- 주키퍼의 특징 1. 단순하다.
→ 단순한 몇 개의 핵심적인 연산을 제공하는 간소화된 하나의 파일시스템이다.
2. 다양하게 활용된다.
→ 상호조정에 필요한 다양한 데이터 구조체와 프로토 콜 구축을 위한 풍부한 프리미티브를 제공한다.
• 주키퍼 - 주키퍼의 특징 3. 고가용성을 지원한다.
→ 컴퓨터 클러스터 상에서 동작하며, 고가용성을 보장하도록 설계되었다.
시스템에서 발생할 수 있는 단일 장애점 문제를 해결하도록 도와준다.
4. 느슨하게 연결된 상호작용을 제공한다.
→ 참여자의 익명성을 보장한다. (네트워크 세부 내용을 몰라도 통신 가능) 5. 라이브러리다.
→ 상호조정 패턴에 대한 구현물과 구현 방법을 공유 저장소에 오픈 소스로 제공한다.
※ 단일 장애점 : 한 대가 고장나면 전체 시스템이 작동되지 않는 것
• 주키퍼 - 주키퍼의 구조 1. 하나의 서버에만 서비스가 집중되지 않도록, 서비스를 알맞게 분산하여 동시에 처리하게 함 2. 하나의 서버에서 처리한 결과를 다른 서버들과도 동기화하여 데이터의 안정성을 보장 3. 현재 서비스를 제공하는 운영(active)서버에 문제가 발생하여 서비스를 제공할 수 없을 경우, 다른 대기 중인 서버를 운영서버로 바꿔서 서비스가 중지되지 않도록 함 4. 분산 환경을 구성하는 서버들의 환경설정을 통합관리
• 03. 주키퍼 서비스
데이터 모델
- znode는 데이터를 저장하고 ACL(접근 제어 리스트)을 포함한다. - znode는 상호 조정을 위해 설계되었고 그 용량은 1MB로 제한한다. - znode는 일부만 읽거나 일부만 쓸 수 없다.
→ 전체를 읽고 전체를 쓴다.
- znode는 경로로 참조되며, 주키퍼 내 경로는 슬래시(/)로 구분되는 유니코드 string 타입이 며, 경로는 절대경로를 사용한다.
- 경로를 표현하는 구성 요소는 유니코드 문자로 이루어지고, 일부 제약이 있다. (주키퍼 참고 문서를 확인)
• 03. 주키퍼 서비스
데이터 모델
임시 znode - znode는 임시 또는 영속적 타입을 가진다.
→ 임시 znode는 세션 종료 시 자동 삭제되며, 임시 자식 znode를 가질 수 없다.
영속적 znode는 클라이언트에 의해서만 삭제된다.
순차번호 - 순차 znode는 주키퍼에 의해 znode 이름 일부에 순차 번호가 부여.
→ 정렬이나, 클라이언트에 의한 참조, 락서비스의 공유락 구현을 위해 사용된다.
• 03. 주키퍼 서비스
데이터 모델
감시(watch) - znode에 변화가 있을 때, 클라이언트에게 이벤트를 통지한다.
- watcher는 한번만 작동된다.
→ 다수의 통지를 위해서는 일일이 등록해주어야 하며, exists 같은 경우 앞서 사용한 연산을 호출해야 한다.
• 03. 주키퍼 서비스
연산
• 03. 주키퍼 서비스
연산
- 주키퍼 update 연산은 조건적이다.
→ delete나 setData 같은 경우 버전 숫자를 지정해 주어야 하며, 일치하지 않은 경우 실패한다.
update 연산은 넌 블로킹 연산이여서 실패 시 다시 연산을 시도할지 다른 행동을 취할지 결정할 수 있다.
- 주키퍼는 파일시스템 처럼 보여도 간결함을 목적으로 하기 때문에, 일부 파일시스템 프리미티브를 제거하였다.
→ 파일 크기가 작고 전체를 읽고 쓰기 때문에 open, close, seek 연산을 제공하지 않는다.
• 03. 주키퍼 서비스
연산
다중갱신 - multi 연산은 여러 개의 프리미티브 연산을 하나의 갱신 단위로 묶어 연산의 성공과 실패를 반환하는 방식이다.
- 분산환경에서 전역적으로 불변성 유지를 위한 구조체 구축이 유용 - 프리미티브 주키퍼 연산만 사용한다면 한 방향만 갱신된 불안정한 상태에서 클라이언트에 접근할 수 있다.
→ 두 개의 znode에 대한 갱신을 multi 연산으로 묶으면 양방향 갱신을 원자적으로 실행시킬 수 있다.
• 03. 주키퍼 서비스
연산
감시 유발자 - 읽기 연산인 exists, getChildren, getData에 감시(watch)가 설정될 수 있고, 설정된 감시는 쓰기 연산인 create, delete, setData에서 유발된다.
ㅁ • 03. 주키퍼 서비스
연산
ACL - znode는 ACL 목록과 함께 생성된다.
→ ACL은 특정 연산을 수행할 수 있는지를 결정한다.
- ACL 인증과정이 있는데 주키퍼에서 제공하는 인증 체계가 있다.
1. digest : 클라이언트는 사용자 이름, 암호에 의해 인증된다.
2. sasl : 클라이언트는 커버로스를 사용하여 인증된다. 3. ip : 클라이언트는 IP에 의해 인증된다. ※커버로스 : 분산 컴퓨팅 환경에서 대칭키를 이용하여 사용자 인증을 제공하는 중앙 집중형 인증(authentication)방식으로 인증을 제공하는 중앙 집중형 인증 방식
• 03. 주키퍼 서비스
연산
ACL - digest 방식을 사용한 예 → zk.addAuthInfo(“인증체계” , “인증 받을 ID” , “권한”); - 자바의 경우 → new ACL ( Perms.READ , new ID(“ip” , “10.0.0.1”) );
• 03. 주키퍼 서비스
구현
- 주키퍼 서비스의 두가지 방식 1. 독립실행 모드 → 단일 주키퍼 서버가 존재, 간단한 구조, 테스트용으로 유용 but . 고가용성과 탄력성을 보장하지 않는다.
2. 복제 모드 → 실제 서비스에서는 앙상블이라는 컴퓨터의 클러스터에서 복제 모드로 수행된다.
• 03. 주키퍼 서비스
구현
복제모드 - 앙상블은 과반수 이상의 컴퓨터가 유지되는 동안 서비스 제공 → 장애가 발생하였더라도 과반수 이하라면 서비스를 제공한다.
이러한 이유로 과반수 룰을 적용하여 앙상블은 홀수대의 컴퓨터를 둔다.
- 주키퍼는 znode의 트리에 대한 모든 수정이 앙상블의 노드에 복제되도록 보장한다.
→ 소수 컴퓨터 장애시 최소한 한대의 컴퓨터는 가장 최신 상태를 가진 채 살아남아 다른 노드에 복제된다.
- 주키퍼는 zab이라는 프로토콜을 사용한다.
• 03. 주키퍼 서비스
구현 Zab 프로토콜 2단계
단계 1 : 책임자 선출 - 앙상블은 책임자라 불리는 특별한 멤버를 선출한다.
다른 컴퓨터는 후보자가 되며 과반수 이상이 책임자와 동기화되면 1단계는 끝난다.
단계 2 : 원자적 브로드캐스트 - 모든 쓰기 요청은 책임자에게 보내지고, 책임자는 후보자에게 업데이트 상태를 브로드캐스트 한다.
과반수 변경이 완료되면, 책임자는 업데이트 연산을 커밋하고, 클라이언트는 업데이트가 성공했다는 응답을 받는다.
• 03. 주키퍼 서비스
구현
단계 2 : 원자적 브로드캐스트 - 합의를 위한 프로토콜은 원자적 설계되었기 때문에 그 결과는 성공이나 실패이다.
⇒ 리더에 문제 발생시 후보자가 새로운 책임자가 된다.
새로운 리더 선출하는데 200ms가 걸리므로 선출하는 동안 성능저하는 그리 크지 않다.
• 03. 주키퍼 서비스
일관성
- 주키퍼 구현의 기본을 이해하면 서비스의 일관성 보장을 이해하는데 도움이 된다.
→ 앙상블 컴퓨터에 대한 ‘책임자’ , ‘후보자’라는 용어는 후보자가 많은 업데이트 연산 때문에 책임자보다 지연될 수 있음을 나타낸다. (책임자는 과반수만 넘기면 되기 때문에) - 주키퍼에 맞는 좋은 모델은 후보자 서버에 클라이언트가 연결되는 것이지만, 임의 선택이 불가능하기 때문에 책임자 서버에 연결될 수도 있다.
• 03. 주키퍼 서비스
• 03. 주키퍼 서비스
일관성
znode의 모든 업데이트 연산은 zxid라 불리는 유일한 식별자를 부여 받는다.
순서의 일관성
- 업데이트 연산은 보내진 순서대로 적용된다.
원자성
- 업데이트 연산은 실패 아니면 성공 둘 중 하나다.
단일 시스템 이미지
- 클라이언트는 연결된 서버와 상관없이 같은 시스템을 바라보는 것처럼 작동한다.
• 03. 주키퍼 서비스
일관성
znode의 모든 업데이트 연산은 zxid라 불리는 유일한 식별자를 부여 받는다.
지속성
- 업데이트 연산이 성공하면 그 내역은 유지된다.
적시성
- 클라이언트가 시스템을 볼 때 뒤처진 정보를 보여주지 않는다.
차라리 서버를 중단시켜 강제로 최신 서버로 연결하게 한다.
⇒ 읽기 연산은 주키퍼 서버의 메모리에서 이루어지고 쓰기 연산 순서를 정렬하지 않기 때문에 일치하지 않는 경우가 발생하므로 sync연산을 사용해야 한다.
• 03. 주키퍼 서비스
세션
- 주키퍼 클라이언트는 앙상블 내 서버의 목록을 가지고 설정에 들어가는데, 서버 중 하나에 연결 될 때까지 시도하며, 모든 서버가 연결 실패시 실패한다.
- 주키퍼 서버에 연결되면 서버는 클라이언트를 위해 세션을 생성 → 세션은 타임아웃 값을 가지고 있으며, 오랫동안 일을 안 한다면 클라이언트는 ping 요청을 통해 세션이 살아있도록 유지한다.
- 또 다른 주키퍼 서버로의 페일오버는 주키퍼 클라이언트에 의해 자동으로 이루어지며, 이때의 세션을 유효하도록 한다.
• 03. 주키퍼 서비스
세션 시간
- 주키퍼는 시간 관련 인자를 몇 개 가지고 있다.
-
틱 타임은 주키퍼 내의 시간에 대한 기본 단위이다.
→ 서버는 틱 타임을 이용하여 연산에 대한 스케줄링을 한다.
-
세션 타임아웃은 2틱보다 크거나 20틱 이하이다.
→ 일반적인 틱 타임 설정은 2초다
-
낮은 세션 타임아웃은 장애를 빨리 탐지 및 제거가 가능하다 but . 너무 낮으면 바쁠 경우 패킷이 늦게 도착해 세션 만료될 수 있다.
• 03. 주키퍼 서비스
세션 시간
- 긴 세션 타임 아웃은 임시 상태를 생성할 때 좋다.
→ 세션 타임 기간 내에 다시 세션을 재시작하여 세션 만료를 회피할 수 있다.
- 일반적으로 주키퍼 앙상블의 크기가 늘어날 수록 세션 타임 아웃도 늘어나야 한다.
• 03. 주키퍼 서비스
상태
- getState() 메소드를 호출하여 상태 질의가 가능하다.
→ state는 enum 타입으로 주키퍼 객체의 여러 가지 상태를 나타내준다.
public States getState()
• 04. 주키퍼로 응용프로그램 구현하기
탄력적인 주키퍼 응용프로그램
- 분산 컴퓨팅에서 ‘네트워크가 신뢰할 만하다’ 것은 잘못된 생각이다 → 실패할 수 있는 상황을 점검해야 한다.
- 주키퍼 연산은 throws절에 두 가지 타입의 예외를 선언한다.
1. InterrupterException → 연산이 인터럽트 될 경우 발생 , 실패가 아닌 취소를 의미한다 2. KeeperException → 주키퍼 서버가 오류 발생시 , 통신 문제 발생시 예외가 된다.
• 04. 주키퍼로 응용프로그램 구현하기
탄력적인 주키퍼 응용프로그램 상태 예외
znode 트리에 적용할 수 없어 연산이 실패한 경우 상태 예외가 발생한다.
-
동시에 znode를 변경할 때 발생한다.
회복 가능한 예외 -
응용프로그램이 같은 주키퍼 세션 내에서 회복 될 수 있을 때 발생
• 04. 주키퍼로 응용프로그램 구현하기
락 서비스 -
분산 락은 집단의 프로세스 사이에서 상호 배제를 제공하기 위한 메커니즘 이다.
- 한 순간에 오직 하나만 락을 소유 할 수 있으며, 분산 락은 규모가 큰 분산 시스템에서 책임자 선출을 위해 사용될 수 있다.
→ 책임자는 항상 락을 소유한다.